From: Andreas Kemnade <andreas@kemnade.info>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Reid Tonking <reidt@ti.com>, Tony Lindgren <tony@atomide.com>,
"Raghavendra, Vignesh" <vigneshr@ti.com>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Janusz Krzysztofik <jmkrzyszt@gmail.com>,
Linux-OMAP <linux-omap@vger.kernel.org>,
linux-i2c@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] i2c: omap: Fix standard mode false ACK readings
Date: Fri, 13 Sep 2024 15:32:51 +0200 [thread overview]
Message-ID: <20240913153251.48ffafbd@akair> (raw)
In-Reply-To: <0903DB3E-1A44-44BB-87DC-01C65B97AE4E@goldelico.com>
Am Fri, 13 Sep 2024 14:28:59 +0200
schrieb "H. Nikolaus Schaller" <hns@goldelico.com>:
> Hi,
>
>
> > Am 13.09.2024 um 14:09 schrieb Andreas Kemnade
> > <andreas@kemnade.info>:
> >
> > Am Wed, 11 Sep 2024 11:40:04 +0200
> > schrieb "H. Nikolaus Schaller" <hns@goldelico.com>:
> >
> >> Hi,
> >>
> >>> Am 28.04.2023 um 20:30 schrieb Reid Tonking <reidt@ti.com>:
> >>>
> >>> On 10:43-20230428, Tony Lindgren wrote:
> >>>> * Raghavendra, Vignesh <vigneshr@ti.com> [230427 13:18]:
> >>>>> On 4/27/2023 1:19 AM, Reid Tonking wrote:
> >>>>>> Using standard mode, rare false ACK responses were appearing
> >>>>>> with i2cdetect tool. This was happening due to NACK interrupt
> >>>>>> triggering ISR thread before register access interrupt was
> >>>>>> ready. Removing the NACK interrupt's ability to trigger ISR
> >>>>>> thread lets register access ready interrupt do this instead.
> >>>>>>
> >>>>
> >>>> So is it safe to leave NACK interrupt unhandled until we get the
> >>>> next interrupt, does the ARDY always trigger after hitting this?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Tony
> >>>
> >>> Yep, the ARDY always gets set after a new command when register
> >>> access is ready so there's no need for NACK interrupt to control
> >>> this.
> >>
> >> I have tested one GTA04A5 board where this patch breaks boot on
> >> v4.19.283 or v6.11-rc7 (where it was inherited from some earlier
> >> -rc series).
> >>
> >> The device is either stuck with no signs of activity or reports RCU
> >> stalls after a 20 second pause.
> >>
> > cannot reproduce it here.
>
> That is good for you :)
>
which does not mean that there is no problem...
> > I had a patch to disable 1Ghz on that
> > device in my tree. Do you have anything strange in your
> > tree?
>
> No, and the omap3 is running with 800 MHz only.
>
So you have a patch disabling 1Ghz OPP in there? The error messages
look like things I got when 1Ghz was enabled, so better double check.
if it is letux, then there is e.g. the interrupt reversal in there.
Maybe it unveils some problem which should be fixed, maybe it is
harmful, it was never well reviewed...
> I haven't tested on another board but the bug is very reproducible
> and I was able to bisect it to this patch, which makes the difference.
>
the error messages, esp. regarding rcu do not look so related to this.
Maybe having this patch or not triggers some other bug. Maybe we trigger
some race conditions. Or i2c error checking regarding OPP setting...
> So there may be boards which happily run with the patch and some
> don't. Maybe a race condition with hardware.
>
I am not ruling out that this patch has nasty side effects but I think
there is more in the game.
Regards,
Andreas
next prev parent reply other threads:[~2024-09-13 13:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230426194956.689756-1-reidt@ti.com>
[not found] ` <445b3cbf-ffbc-6f77-47db-c30fc599e88f@ti.com>
[not found] ` <20230428074330.GJ14287@atomide.com>
[not found] ` <20230428183037.wbhds54dz5l4v5xa@reidt-t5600.dhcp.ti.com>
2024-09-11 9:40 ` [PATCH v2] i2c: omap: Fix standard mode false ACK readings H. Nikolaus Schaller
2024-09-13 12:09 ` Andreas Kemnade
2024-09-13 12:28 ` H. Nikolaus Schaller
2024-09-13 13:32 ` Andreas Kemnade [this message]
2024-09-13 15:01 ` H. Nikolaus Schaller
2024-11-06 9:23 ` Andreas Kemnade
2024-11-06 12:16 ` H. Nikolaus Schaller
2024-11-06 15:09 ` H. Nikolaus Schaller
2025-02-02 22:42 ` Ing. Josua Mayer
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=20240913153251.48ffafbd@akair \
--to=andreas@kemnade.info \
--cc=aaro.koskinen@iki.fi \
--cc=hns@goldelico.com \
--cc=jmkrzyszt@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=reidt@ti.com \
--cc=tony@atomide.com \
--cc=vigneshr@ti.com \
/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