[PATCH] i2c: imx: increase retries on arbitration loss

Uwe Kleine-König u.kleine-koenig at pengutronix.de
Fri Dec 16 03:13:08 PST 2022


On Fri, Dec 16, 2022 at 12:02:27PM +0100, Oleksij Rempel wrote:
> On Fri, Dec 16, 2022 at 11:41:08AM +0100, Primoz Fiser wrote:
> > Hi Marco,
> > 
> > On 16. 12. 22 10:45, Marco Felsch wrote:
> > > Hi Primoz,
> > > 
> > > On 22-12-16, Primoz Fiser wrote:
> > > > By default, retries value is set to 0 (no retries). Set retries to more
> > > > sensible value of 3 to allow i2c core to re-attempt transfer in case of
> > > > i2c arbitration loss (i2c-imx returns -EAGAIN errno is such case).
> > > 
> > > apart the fact that the number of retries vary a lot and so the client
> > > driver behaviour can vary a lot which is not good IMHO, why do you think
> > > that 3 is a sufficient number?
> > 
> > IMHO it is better than leaving it at 0 (no retries)?
> > 
> > Setting it to sensible value like 3 will at least attempt to make transfer
> > in case arbitration-loss occurs.
> > 
> > > 
> > > If an arbitration loss happen, why do you think that retrying it 3 times
> > > changes that?
> > 
> > I our case, setting retries to non-zero value solves issues with PMIC
> > shutdown on phyboard-mira which in some rare cases fails with "Failed to
> > shutdown (err =  -11)" (-EAGAIN).
> > 
> > To me it makes common sense retries is set to non-zero value especially for
> > such rare conditions/situations.
> 
> https://lore.kernel.org/all/Ys1bw9zuIwWS+bqw@shikoro/

Also in the same thread there is the question about better setting it in
the i2c core if 3 instead of 0 is a good idea for the imx driver.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20221216/9b5166f6/attachment.sig>


More information about the linux-arm-kernel mailing list