'i2c read failed' problem
werner at openmoko.org
Sun Apr 15 08:17:21 CEST 2007
Harald Welte wrote:
> Ok, seems like I've managed to hunt down this problem.
Ah yes, race conditions in code that was never designed for
concurrency :-( I guess NAND operations may have similar issues,
they're only a lot less likely to clash.
> Another possible solution was for the bootmenu code to use interrupts,
Add more race conditions ? ;-)
How about putting
around (well, inside) i2c_write and i2c_read ? Any code that needs
larger atomic sections, e.g., pcf50606_reg_set_bit_mask and
pcf50606_reg_clear_bits, could just do the same, without affecting
the locking inside the I2C functions.
That should work unless we have something that needs very low
interrupt latency. Is USB kind enough to allow us a bit of delay ?
This still leaves the ordering problem. Perhaps we could just set
a "fast_charge" flag that is checked at the end of the
initialization. So if the fast charge was set before initialization,
initialization may first clear it, but then check the flag and set
In fact, we could do this all inside pcf50606_charge_autofast, and
use pcf50606_charge_autofast(-1) to mean "set to the previously
That should be clean, and - most of all - simple.
/ Werner Almesberger, Buenos Aires, Argentina werner at almesberger.net /
More information about the openmoko-uboot