'i2c read failed' problem

[Werner Almesberger]

Harald Welte wrote:
> i just hate it flooding the i2c bus with requests for which we have
> clearly better ways to signalize it to the CPU.

Ah well, we can always optimize later :) E.g., an interrupt handler
could set a flag, and we'd only touch I2C if it is set. But I'd
rather keep u-boot optimizations for later, so that we don't
introduce new bugs.

> that depends on the interrupt (usb has two).  unfortunately, from my
> experience, the usb control interrupt (from where we also enable/disable
> the fast charge) is extremely time critical.  That was where even a
> memcpy of 16 bytes added too much latency for the code to still work
> reliably :(

Hmm, does this mean that we can't reliably support USB with that
hardware at all ? After all, interrupts get disabled for a short
while all over the kernel.

Moving all I2C operations out of interrupts, e.g., with something
like workqueues, would help at least for u-boot.

> the question is: when is initialization done?  can we rely on the fact
> that board_late_init() will always be the last in the chain?

Well, anyone who initializes the PMU would have to "refresh" the
settings, but board_late_init is the only one doing that, no ?
But perhaps that's not what you mean ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/