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@xxxxxxxxxxxx > > > > > > 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 |
