Hi, > Am 13.09.2024 um 14:09 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>: > > Am Wed, 11 Sep 2024 11:40:04 +0200 > schrieb "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx>: > >> Hi, >> >>> Am 28.04.2023 um 20:30 schrieb Reid Tonking <reidt@xxxxxx>: >>> >>> On 10:43-20230428, Tony Lindgren wrote: >>>> * Raghavendra, Vignesh <vigneshr@xxxxxx> [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 :) > 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. 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. So there may be boards which happily run with the patch and some don't. Maybe a race condition with hardware. But I think the assumption that "ARDY always gets set after a new command when register access is ready so there's no need for NACK interrupt to control this" may not hold in all situations. Potentially if a new command is never ready. BR, Nikolaus
