Dear Uwe Kleine-König, > 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: See the other patch I sent , esp. the write PIO command [1], then the order would be: 1 // prepare sending SAD+R 2 CTRL0 = RETAIN_CLOCK | PRE_SEND_START | MASTER_MODE | DIRECTION | XFER_COUNT(1); 3 DATA = addr_data 4 CTRL0 |= RUN ^ this stuff is explained in MX23 RM, see the comment above mxs_i2c_pio_trigger_write_cmd() in the patch. > 6 // prepare reading length byte > 7 CTRL0 = RUN | RETAIN_CLOCK | MASTER_MODE | XFER_COUNT(1); I think you can force the controller to send ACK here automatically. > 8 poll DEBUG0 until DMAREQ is set; DMAREQ doesn't work in READ xfer :-( > 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 See above, also don't use RETAIN_CLOCK above then. > 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 Use DMA here, you can't PIO READ more than 4 bytes. > 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 suspect is likely doable, but it'd need non-trivial amount of fiddling. Unless I get motivated enough to implement this, I'm not plumbing in it. Rather than that, I'd like to find out what's wrong with the PIO on MX23. > 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 [1] http://www.mail-archive.com/linux-i2c@xxxxxxxxxxxxxxx/msg12699.html Best regards, Marek Vasut -- 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
