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!