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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.284-letux+ (hns@xxxxxxxxxxxxxx) (gcc version 4.9.2 (GCC)) #13659 SMP PREEMPT Tue Jun 6 13:29:28 CEST 2023
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: Data cache writeback
[    0.000000] cma: Reserved 16 MiB at 0xbe800000
[    0.000000] On node 0 totalpages: 261632
[    0.000000]   Normal zone: 1536 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 196608 pages, LIFO batch:63
[    0.000000]   HighMem zone: 65024 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
...
[    6.994384] input: TSC2007 Touchscreen as /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0048/input/input6
[    7.092163] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module
[    7.104370] bmp280 1-0076: 1-0076 supply vddd not found, using dummy regulator
[   28.092681] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[   28.099060] rcu:     Tasks blocked on level-0 rcu_node (CPUs 0-0): P1220
[   28.105804] rcu:     (detected by 0, t=2102 jiffies, g=957, q=32)
[   28.111877] udevd           R  running task        0  1220      1 0x00000000

or another one:

[   28.025939] rcu: INFO: rcu_preempt self-detected stall on CPU
[   28.031951] rcu:     0-...!: (2100 ticks this GP) idle=126/1/0x40000004 softirq=1484/1484 fqs=0 
[   28.040863] rcu:      (t=2100 jiffies g=1037 q=26)
[   28.045593] rcu: rcu_preempt kthread starved for 2100 jiffies! g1037 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
[   28.056365] rcu: RCU grace-period kthread stack dump:
[   28.061645] rcu_preempt     I    0    10      2 0x00000000

My guess is that the assumption that there is a new command after NACK may be wrong, depending on what i2c operations are ongoing.
I once had a hint that it could be related to twl4030 power management code. Where I could imagine it may do locked i2c access.
Unfortunately I did not save that boot log stack dump.

Reverting this patch for either v4.19.238 or v6.11-rc7 makes the device boot again.

Any proper fix (beyond revert) is welcome.

BR,
Nikolaus




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux