Re: [PATCH v1] i2c: imx: Retry transfer on transient failure

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Wed, Jul 13, 2022 at 03:43:29PM +0200, Francesco Dolcini wrote:
> On Wed, Jul 13, 2022 at 03:24:37PM +0200, Oleksij Rempel wrote:
> > On Wed, Jul 13, 2022 at 01:57:50PM +0200, Francesco Dolcini wrote:
> > > + oleksandr.suvorov@foundries.io
> > > 
> > > Hello all,
> > > 
> > > On Tue, Jul 12, 2022 at 12:05:04PM +0200, Francesco Dolcini wrote:
> > > > On Tue, Jul 12, 2022 at 11:05:14AM +0200, Uwe Kleine-König wrote:
> > > > > In which situations does this help? Please mention these in the
> > > > > commit log.
> > > > I'll do
> > > 
> > > I did some investigation on this, unfortunately we have this change
> > > laying around since 1 year, it was written by Oleksandr, and in the
> > > meantime he moved to a new company. I added him to this email thread, so
> > > he can comment in case he remembers more.
> > > 
> > > We introduced this change while working on OV5640 camera sensor on an
> > > apalis-imx6q evaluation board, without this change we had some sporadic
> > > i2c communication issues. Unfortunately I do not have any better
> > > details.
> > > 
> > > To me looks like having some (3? 5?) retry as a default is somehow
> > > more reasonable than to never retry, not sure if this should be
> > > implemented as a default for all the i2c adapters. From what I was able
> > > to see that would not be a trivial change (the retry parameter is coming
> > > from the i2c_imx driver, there is no obvious way to have a default in
> > > the i2c core).
> > > 
> > > Would it work for you to keep the change as it is (just getting rid
> > > of the useless define) and add a little bit more blurb to the commit
> > > message to include the various comments collected so far?
> > 
> > I assume, it is related to reset time or other reason where the camera
> > is not responding. In this case, amount of retries would depend on I2C
> > CLK speed and host CPU speed.
> > 
> 
> The retry on the I2C IMX driver would trigger only on tx arbitration
> failure, that would be the SDA being tied low by the slave in an
> unexpected moment, correct? 

If it is the case, it is better to understand why. Are there some
special timing requirements?

> If the camera does not respond it will just
> not ack the transaction and that would not be recovered by the retry
> in this change.
> 
> Can this just a layout/cabling issue with some noise on the SDA line? We
> are talking about somehow long board to board cables with various
> signals on it. This is an issue that we had for sure in the past,
> however I do have record of this only on a different camera.

If it is cabling issue, then I would take a look at pinmux
configuration. If it is so noisy, that some errors are expected, then it would
affect camera configuration as well. I mean, system is potentially
writing trash to the config register.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |