'i2c read failed' problem

Harald Welte 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
> 
> local_irq_save(flags);
> ...
> local_irq_restore(flags);
> 
> 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
reliably :(

> 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 mailing list