'i2c read failed' problem

[Werner Almesberger]

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

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 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
it again.

In fact, we could do this all inside pcf50606_charge_autofast, and
use pcf50606_charge_autofast(-1) to mean "set to the previously
recorded state".

That should be clean, and - most of all - simple.

Cheers, Werner

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