Hi, On 08/02/21 1:29 PM, Sebastian Andrzej Siewior wrote: > On 2021-02-05 11:15:13 [+0100], angelo@xxxxxxxxxxxxxxxx wrote: >> Hi all, > Hi, > >> applied patch-5.4.70-rt40 over linux-imx from nxp >> (imx_5.4.70_2.3.0), this since imx8qxp-mek board seems not >> totally supported in mainline stable 5.4. >> >> The patch applies properly, but at boot, at 50% of the cases, >> i get: >> > … >> [ 2.231799] 003: imx-lpi2c 37230000.i2c: using scl,sda for recovery >> [ 2.232464] 003: pca953x 16-0020: using no AI >> [ 2.517161] 000: irq 464: nobody cared (try booting with the >> "irqpoll" option) >> [ 2.517170] 000: CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 5.4.70-rt40-00116-gc1de1cbc567a-dirty #51 >> [ 2.517176] 000: Hardware name: Freescale i.MX8QXP MEK (DT) >> [ 2.517181] 000: Call trace: > … >> [ 2.517233] 000: handle_edge_irq+0xbc/0x200 >> [ 2.517238] 000: generic_handle_irq+0x24/0x38 >> [ 2.517244] 000: imx_intmux_irq_handler+0xac/0x140 >> [ 2.517252] 000: generic_handle_irq+0x24/0x38 >> [ 2.517259] 000: __handle_domain_irq+0x90/0x100 >> [ 2.517267] 000: gic_handle_irq+0x5c/0x14c >> [ 2.517272] 000: el1_irq+0xb8/0x180 >> [ 2.517277] 000: arch_cpu_idle+0x1c/0x30 >> [ 2.517284] 000: default_idle_call+0x20/0x48 >> [ 2.517291] 000: do_idle+0x248/0x288 >> [ 2.517297] 000: cpu_startup_entry+0x24/0x78 >> [ 2.517303] 000: rest_init+0xd4/0xe0 >> [ 2.517308] 000: arch_call_rest_init+0xc/0x14 >> [ 2.517316] 000: start_kernel+0x414/0x448 >> [ 2.517322] 000: handlers: >> [ 2.517331] 000: [<00000000206db772>] irq_default_primary_handler >> threaded [<00000000ffd05448>] lpi2c_imx_isr >> [ 2.517341] 000: Disabling IRQ #464 >> >> I know nxp related issues are probably now welcome here, >> but if some chance/hint to have rt working, welcome. > > From the backtrace it looks like the IRQ #464 is handled by > lpi2c_imx_isr(), returns always with IRQ_NONE but the IRQ fires again > and again. > It appears that IRQ-masking is not working properly but then the > stacktrace says handle_edge_irq() and I have my doubts if it is really > an EDGE interrupt. > Looking at lpi2c_imx_isr() in v5.11, it returns always with IRQ_HANDLED > looks like different code between your BSP and upstream. Also always > returning IRQ_HANDLED will duct tape the problem if the driver is > handling / acking the interrupt > > You should see something a big number of interrupts (in > /proc/interrupts) for the #464 interrupt. > I suggest to update something more recent like v5.10 without the FSL > bsp if possible. > >> Regards, > > Sebastian > I finally found a solution, replacing drivers/irqchip/irq-imx-intmux.c code with mainline. It seems quite reliable, i cannot replicate the issue anymore. Any comment is welcome. Regards, -- Angelo Dureghello +++ kernelspace +++ +E: angelo@xxxxxxxxxxxxxxxx
