'i2c read failed' problem
laforge at openmoko.org
Sun Apr 15 09:36:42 CEST 2007
On Sun, Apr 15, 2007 at 03:17:21AM -0300, Werner Almesberger wrote:
> 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 ? ;-)
i just hate it flooding the i2c bus with requests for which we have
clearly better ways to signalize it to the CPU.
> 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's more or less what the corresponding kernel code does, yes. but
then, in the specific issue of usb / charger interaction, it uses a work
queue to get i2c out of the way of usb interrupt code.
> That should work unless we have something that needs very low
> interrupt latency. Is USB kind enough to allow us a bit of delay ?
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
> 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
> it again.
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?
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-uboot