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 <lpo...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
