Hello, On Wed, Jul 03, 2013 at 03:34:12PM +0200, Christoph G. Baumann wrote: > > > No, I haven't. I saw the report from Christoph in the linux-arm-kernel > > > mailing list: > > > http://marc.info/?l=linux-arm-kernel&m=137277422127826&w=2 > > > > > > And thought it could be nice if we could get it fixed for mx23 and mx28. > > > > How/when does this error manifest on the scope/LA? > > the problem turned up when Uwe Kleine-König worked on implementing SMBus and > I2C_M_RECV_LEN support for i.MX28 (my employer commissioned Pengutronix in that > case). The receiving of such messages stops after the first (length information) > byte. > Maybe Uwe can comment on that. OK, I'm trying to sum up: To support I2C_M_RECV_LEN in the mxs driver I did: 1 // prepare sending SAD+R 2 CTRL0 = RUN | RETAIN_CLOCK | PRE_SEND_START | MASTER_MODE | DIRECTION | XFER_COUNT(1); 3 poll DEBUG0 until DMAREQ is set; 4 // send SAD+R 5 DATA = addr_data 6 // prepare reading length byte 7 CTRL0 = RUN | RETAIN_CLOCK | MASTER_MODE | XFER_COUNT(1); 8 poll DEBUG0 until DMAREQ is set; 9 // read first data indicating length 10 data = DATA & 0xff 11 // send an ack, i.e. clean CTRL0_CLOCK_HELD 12 CTRL0 = RUN | ACKNOWLEDGE | MASTER_MODE 13 sleep 1ms 14 // trigger reading rest of the message 15 CTRL0 = RUN | SEND_NAK_ON_LAST | MASTER_MODE | MXS_I2C_CTRL0_POST_SEND_STOP 16 for (i = 0; i < (data + 3) / 4; ++i) 17 read from DATA In line 10 the length bit is read out successfully, but sending the ACK in line 12 doesn't work, the i.MX28 pulls SDA low, but doesn't generate a clock pulse on SCL and instead releases SDA and starts reading the following byte. Dropping RETAIN_CLOCK in line 7 and/or dropping RUN from line 12 didn't help. Freescale's support suggested to set CTRL1.ACK_MODE and some other things that didn't help and pointed out the imx23 i2c errata. (I.e. "when RETAIN_CLOCK is set, the ninth clock pulse (ACK) is not generated. However, the SDA line is read at the proper timing interval. If RETAIN_CLOCK is cleared, the ninth clock pulse is generated.") The suggested workaround was to either use a Big buffer, read Many bytes until the slave sends a NACK and interpret the result as smaller read. Or use gpio bit banging. I didn't understand the suggested workaround in the errata document, and the support guy didn't succeed to explain it to me. "The suggested workaround in this errata is to set the ACK_MODE bit in HW_I2C_CTRL1 register. In i.MX233, this bit is default zero and requires software to explicitly set it to 1. In i.MX28, this bit is '1' by default already. Unfortunately, this does not solve the 9th clock pulse issue if RETAIN_CLOCK is set in the receiving data phase." Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
