Hi, On 18/08/12 11:52, Wolfram Sang wrote: > On Wed, Aug 08, 2012 at 09:42:32AM +0200, Roland Stigge wrote: >> On transactions with n>=2 bytes, the controller actually wrongly >> clocks in n+1 bytes. This is caused by the (wrong) assumption >> that RFE in the Status Register is 1 iff there is no byte already >> ordered (via a dummy TX byte). This lead to the implementation of >> synchronized byte ordering, e.g.: >> >> Dummy-TX - RX - Dummy-TX - RX - ... >> >> But since RFE actually stays high after some Dummy-TX, it rather >> looks like: >> >> Dummy-TX - Dummy-TX - RX - Dummy-TX - RX - (RX) >> >> The last RX byte is clocked in by the bus controller, but ignored >> by the kernel when filling the userspace buffer. >> >> This patch fixes the issue by asking for RX via Dummy-TX >> asynchronously. Introducing a separate counter for TX bytes. >> >> Signed-off-by: Roland Stigge <stigge@xxxxxxxxx> >> >> --- Applies to v3.6-rc1 >> >> This patch for i2c-pnx affects PNX4008 and LPC32xx (and LPC31xx, >> not yet in mainline). Can you please test? >> >> Thanks in advance! > > I assume you checked this on LPC32xx? Yes. The bug surfaced when we debugged unexpected behaviour with I2C clients. A colleague noticed that sometimes, there were more bytes transferred than expected, confusing some I2C clients. The patch fixes exactly that. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
