Hi Tom,
On 09/05/13 18:25, Tom Rini wrote:
On Thu, Apr 04, 2013 at 04:40:16PM +0300, Lubomir Popov wrote:
These new functions are built for OMAP4 and OMAP5 only. The major improvement is that the new i2c_read fixes the inability to read correctly from certain types of I2C chips.
- Rewritten i2c_read to operate correctly with all types of chips.
- Optimized i2c_write. Both read/write functions try to identify unconfigured bus.
- New i2c_probe performs write access vs read. Optionally selectable via CONFIG_I2C_PROBE_WRITE.
- Driver supports up to I2C5 (OMAP5; I2C_BASE5 must be defined).
Signed-off-by: Lubomir Popov lpopov@mm-sol.com
So, I've tested the i2c_probe on the was failing last time we tried a write-style probe and it's OK. But I'm not sure that we're obeying the comments I spell out in 168a5acb81a8d92a7effcb2727aaa89367b97e05 about why we can't do a write-style probe all the same. Can you be sure we're following the constraints there? Thanks!
Quite a long time has passed since I played with that faulty i2c_probe for the first time (on an old version of U-Boot that I initially ported for our OMAP5 board, and this totally erroneous output was in fact the reason for me to rework the I2C driver). As far as I remember, the main issue was that the byte count register was loaded with the value of 1, although no data was transmitted after the address byte (when the transfer is aborted), leaving the controller in a bad state after the first probe. This explains why only the first probe result is valid, and the following faulty positive probes of all subsequent addresses. So this was actually a bug; while fixing it, I decided to rewrite the poorly designed i2c_read as well, and also touched the other functions a bit. Because the changes were significant, I decided to present a separate driver and even submitted it to the list; later I patched the existing omap24xx_i2c.c with the most important changes only. You know this history.
Meanwhile I upgraded to the current version of U-Boot and found that the probe was changed to read access vs write (the above revert, right?). Nevertheless I stayed with my driver; as you know, it has been tested on OMAP4430/60/70 and OMAP5430, with not a single issue found so far.
I don't see any conflict with the TRM whatsoever (for OMAP4/5 at least).
Best regards, Lubo