Re: [PATCH v2] i2c: omap: Fix standard mode false ACK readings

[H. Nikolaus Schaller]

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