'i2c read failed' problem
werner at openmoko.org
Sun Apr 15 15:56:36 CEST 2007
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 Almesberger, Buenos Aires, Argentina werner at almesberger.net /
More information about the openmoko-uboot