[U-Boot] [PATCH 1/1] OMAP4/5: I2C: New read/write/probe functions

Lubomir Popov lpopov at mm-sol.com
Thu May 9 18:20:19 CEST 2013


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 at 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


More information about the U-Boot mailing list