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

["Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

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/  |