Re: arm64: imx8qxp: irq 464: nobody cared (try booting with the "irqpoll" option)

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

 



On 2021-02-08 19:26:28 [+0100], angelo@xxxxxxxxxxxxxxxx wrote:
> Hi Sebastian,
Hi,

> > 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.
> 
> On imx_5.4.70_2.3.0, still the irq routine is returning
> always IRQ_HANDLED. So i am supposing proper handling is
> probably not the issue.
> 
> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/i2c/busses/i2c-imx-lpi2c.c?h=imx_5.4.70_2.3.0#n528

interesting. This does not explain why the core disabled it.

> > 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.
> 
> As an interrupt parent for this i2c module, devicetree
> specify a special "intmux" controller/module,
> (interrupt multiplexer module).
> 
> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/irqchip/irq-imx-intmux.c?h=imx_5.4.70_2.3.0
> 
> It uses handle_edge_irq so it should be fine,.

It is hard to tell without a look into the manual. From browsing over
the driver, that lock in imx_intmux_irq_mask() should be a
raw_spinlock_t. There should be a warning otherwise with
CONFIG_DEBUG_ATOMIC_SLEEP. But then this is an EDGE handler without
irq_ack. So it does nothing. And mask/unmask is probably only used on
request_irq() / free_irq() so no warning here.

> Issue seems coming after an initial i2c "read" from a pca953x i2c-gpio
> expander connected in this i2c bus. This i2c register read is issued
> from
> 
> ret = devm_gpiochip_add_data(&client->dev, &chip->gpio_chip, chip);
> 
> https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpio/gpio-pca953x.c?h=imx_5.4.70_2.3.0#n1112
> 
> That following a bit the code seems to involve some spinlocks.
> 
> After this i2c read, that probably triggers the first interrupt,
> looking by oscilloscope, seems i2c communication is interrupted.
> 
> I am still investigating on this, every help/hint is welcome.

My guess is that the interrupt muxing is not working properly.

Sebastian



[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux