Re: [PATCH] i2c: i2c_mxs: Set ACK_MODE bit

[Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg12699.html

Best regards,
Marek Vasut