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/[email protected]/msg12699.html
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
