[U-Boot] [PATCH 2/2] OMAP4/5: I2C: New I2C driver files added

[Tom Rini <trini@ti.com>]

On Fri, Mar 29, 2013 at 06:36:40PM +0200, Lubomir Popov wrote:

> New I2C driver that fixes read-related issues with some types
> of I2C chips. The i2c_read function now performs bulk read of
> the requested number of bytes in a single transaction and
> completes much faster. Whether to use Stop-Start or Repeated
> Start between the address and data phases is configurable
> (e.g. in the board config header).
> 
> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
> 
> ---
> 
> The main feature of this new driver is that now i2c_read operates
> correctly with chips that have addressable registers wider than 8 bits
> (such as TI temperature sensors), or that have multiple non-addressable
> registers that have to be retrieved in a bulk transaction (such as TI
> clock distributors). The old driver (omap24xx_i2c.c) performs separate
> read transactions for every byte requested and returns invalid data in
> these cases (except possibly the first byte; this invalid data is in
> fact presented by the chips, so the driver does not know that it is
> invalid).
> 
> The new driver performs a standard bulk read transaction (with S-P by
> default, or with Sr if configured so) and works correctly with all types
> of I2C devices.
> 
> The i2c_write and i2c_probe functions have also been modified.
> 
> I have tested the driver on OMAP4430, 4460, 4470 and 5430 and found no
> issues so far. Nevertheless, folks, any additional testing is strongly
> encouraged; the driver should also work on OMAP3 and derivatives, but I
> didn't have this opportunity, so any feedback is welcome.

I'd really like to see this as just making the read/write changes a
define on the existing driver, and let omap4/5/am33xx opt-in, and leave
the other platforms to opt-in and the user base requests and tests.

And we can do the bus_free and similar cleanup as incremental changes in
the old driver too.

As for the probe change, we need to be careful there because a similar
attempt showed some very large problems on OMAP4 (I think omap4430 even
I think, I've still got the failing platform around), or just accept
that some cases will not be probed but can still be talked with.  i2c
doesn't have a defined probe at the spec level, so we're always in
danger of doing something wrong and missing a device.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130402/e90c4768/attachment.pgp>