AnsweredAssumed Answered

i.MX6 PCIe interrupt mapping changes during runtime

Question asked by Andreas Geißler on Aug 22, 2018
Latest reply on Nov 12, 2018 by Karina Valencia Aguilar

Hello,

 

I am using an i.MX6qdl processor on a customer platform. An FPGA is connected to the PCIe interface to communicate with the internal IP's, using legacy interrupts. We figured out, that when running long-term tests sometimes the interrupt mapping seems to be changed for some reason. The interrupt of the FPGA is mapped to irq 300 after booting. After starting the long-term tests do perform traffic on the PCIe bus, within a few days (It does not occurs very often), it happens that the interrupt of the FPGA is shown up on irq 299 where the handler is not registered and nobody cares about the interrupt:

 

72:          0          0          0          0       GPC 114 Level     mmdc_1

73:          0          0          0          0       GPC   8 Level     2800000.ipu

74:          0          0          0          0       GPC   7 Level     2800000.ipu

241:          0          0          0          0  gpio-mxc   6 Edge      ad7606

299:     100000          0          0          0       GPC 123 Level     PCIe PME

300:     544352          0          0          0       GPC 121 Level     16Z087

301:         16          0          0          0     GIC-0 137 Level     2101000.jr0

 

[171521.126091] irq 299: nobody cared (try booting with the "irqpoll" option)

[171521.135735] Disabling IRQ #299

 

We already know that we have to disable MSI for legacy interrupts otherwise nothing would work. After the first received wrong interrupt the IRQ gets disabled and the communication with the FPGA stops working. We check the interrupt behavior also manually after the error case and it really shows that the interrupt of the FPGA is shown on a different bit of the GIC:


Reading CPU irq status register of CPU before error:

 

root@men-cc10:~# memrw 0x020dc024 l
Value at 0x20dc024 (0x76ff7024): 0x82000000

 


Reading CPU irq status register of CPU after error:

 

root@men-cc10:~# memrw 0x020dc024 l
Value at 0x20dc024 (0x76f16024): 0x84000000

 

Disable irq within FPGA and read status register of CPU again:


root@men-cc10:~# memrw 0x020dc024 l
Value at 0x20dc024 (0x76f0b024): 0x80000000

 

Reenable irq within FPGA and read status register of CPU again:


root@men-cc10:~# memrw 0x020dc024 l
Value at 0x20dc024 (0x76ff4024): 0x84000000

 

- Did we missed something when disabling the MSI?

- Or is this an already known issue with an existing workaround?

- What can be the reason for this behavior?

 

Regards,

Andreas

Outcomes