From: Primoz Fiser <primoz.fiser@norik.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
linux-kernel@vger.kernel.org, Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
upstream@lists.phytec.de, Marco Felsch <m.felsch@pengutronix.de>,
Oleksij Rempel <linux@rempel-privat.de>,
NXP Linux Team <linux-imx@nxp.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
francesco.dolcini@toradex.com
Subject: Re: [PATCH] i2c: imx: increase retries on arbitration loss
Date: Fri, 16 Dec 2022 13:23:29 +0100 [thread overview]
Message-ID: <5c2e0531-e7c3-1b37-35ed-c8e9795a0d18@norik.com> (raw)
In-Reply-To: <20221216111308.wckibotr5d3q6ree@pengutronix.de>
Hi all,
On 16. 12. 22 12:13, Uwe Kleine-König wrote:
> 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/
Ohh I see.
Reading through the thread I guess we aren't getting this mainlined at
all :)
But let me switch side and ask why do you think leaving retries = 0 is a
good idea?
The only solid point in the thread seems to be that in that case we are
not covering up the potential i2c hardware issues?
Yeah fair point but on the other hand, goal of this patch would be to
improve robustness in case of otherwise good performing hardware. From
user perspective I just want it to work despite it retrying under the
hood from time to time. I think Francesco had the same idea.
>
> 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.
Using I2C_RETRIES ioctl for this seems a bit of an overkill considering
other i2c bus drivers also set retries to non-zero value. But anyways,
thank you for the idea.
>
> Best regards
> Uwe
>
BR,
Primoz
next prev parent reply other threads:[~2022-12-16 12:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 8:45 [PATCH] i2c: imx: increase retries on arbitration loss Primoz Fiser
2022-12-16 9:45 ` Marco Felsch
2022-12-16 10:41 ` Primoz Fiser
2022-12-16 11:02 ` Oleksij Rempel
2022-12-16 11:13 ` Uwe Kleine-König
2022-12-16 12:23 ` Primoz Fiser [this message]
2022-12-16 12:51 ` Francesco Dolcini
2022-12-28 8:01 ` Primoz Fiser
2022-12-30 14:40 ` Francesco Dolcini
2022-12-30 16:12 ` Oleksij Rempel
2022-12-30 16:47 ` Francesco Dolcini
2022-12-30 17:09 ` Francesco Dolcini
2022-12-30 17:25 ` Oleksij Rempel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c2e0531-e7c3-1b37-35ed-c8e9795a0d18@norik.com \
--to=primoz.fiser@norik.com \
--cc=festevam@gmail.com \
--cc=francesco.dolcini@toradex.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=m.felsch@pengutronix.de \
--cc=o.rempel@pengutronix.de \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=upstream@lists.phytec.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox