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
