Erratic MPC8248 CPM2 I2C behaviour

[Joakim Tjernlund]

On Tue, 2008-12-02 at 11:50 +0100, Laurent Pinchart wrote:
> Hi Joakim,
> 
> On Tuesday 02 December 2008 09:39:59 Joakim Tjernlund wrote:
> > On Mon, 2008-12-01 at 15:28 -0800, Mike Ditto wrote:
> > > Laurent Pinchart <laurentp at cse-semaphore.com> wrote:
> > > > Transmission timeout after one second. The first TX buffer descriptor
> > > > status hasn't been modified by the CPM. The CPM state dump shows that
> > > > processing of
> > >
> > > ...
> > >
> > > This sounds very similar to a problem I have seen on MPC8247 and
> > > MPC8248.
> > >
> > > It could be a variation of the CPM bug documented by Freescale as
> > > erratum CPM98.  But the key difference is that we see a persistent
> > > failure, while the erratum only mentions a problem with "the next
> > > transaction".  What we see is that once the I2C engine gets confused
> > > by some anomaly on the SCL signal, it stops processing buffer
> > > descriptors entirely until it is turned off and back on.  You can
> > > observe this bug by momentarily grounding the SCL line (it's an
> > > open-collector bus) with a jumper while you attempt an I/O.
> > >
> > > Our production equipment is using Linux 2.6 with the out-of-tree
> > > i2c-algo-8260.c by Dan Malek and Brad Parker.  I modified this
> > > driver to shut off the I2C controller and turn it back on when it
> > > hits this problem, and now it can recover from this condition.
> > >
> > > However, this does not explain how the controller gets into the
> > > frozen state in the first place.  We see it very rarely in production
> > > units and have not been able to identify the cause.  If it is
> > > similar to erratum CPM98 then it could be noise on the SCL signal or
> > > perhaps an I2C device that doesn't conform to the protocol perfectly.
> > > Also beware, if you are using some kind of multiplexer, that you don't
> > > direct the multiplexer to switch to a different bus (segment) while a
> > > transaction is in progress.
> > >
> > > In testing with the current (2.6.27) i2c-cpm.c driver, I found that
> > > it is sufficient to #define I2C_CHIP_ERRATA to allow it to recover
> > > from the CPM I2C freeze.  However, I don't know if I like this
> > > approach because it turns off the I2C engine after every transfer,
> > > even successful ones, and I don't know if this will affect reliability
> > > or performance.  And I don't know if this will actually prevent the
> > > freeze from happening, although I presume that it would protect the
> > > I2C engine from getting confused by a glitch that happens while no
> > > transfer is in progress.
> > >
> > > I am not aware of any documentation for what exactly the I2C_CHIP_ERRATA
> > > conditional code in i2c-cpm.c is meant to work around.
> >
> > The I2C_CHIP_ERRATA is mine and refers to mpc8xx, mpc860 in my case. The
> > driver was adapted by me some years ago in 2.4 and now someone has
> > ported it to 2.6 it seems. From memory, you should check that mrblr is
> > one byte bigger than your max transfer size.
> 
> I've checked that, there's no problem there. The transfer that fails doesn't 
> involve any rx buffer anyway, so mrblr is irrelevant here.

hmm, as I recall that doesn't matter. Mrblr should always be > transfer
size. This was for 8xx though so maybe it doesn't matter for you.
Try setting mrblr = transfer size, see if that trigger any problems.

 Jocke