Getting spurious IRQ assertions from FIQ configured source, iMX6Q, Linux 3.0.x kernel

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Getting spurious IRQ assertions from FIQ configured source, iMX6Q, Linux 3.0.x kernel

1,745 Views
jdscott
Contributor I

I've configured an FIQ using this Freescale demo as a reference: https://community.freescale.com/docs/DOC-95578, and it runs well for a while. At some point during operation (roughly between a minute and 3 minutes), the interrupt source will appear asserted in the CPU as an IRQ, rather than an FIQ.

When I fist noticed this issue, I saw that Linux kernel would pick up the IRQ, notice that no IRQ handler was registered for the source, then disable the GPIO peripheral's interrupt. I then registered an IRQ handler for that spurious IRQ which takes note of the occurrence, clears the GPIO interrupt, and exits without disabling the GPIO interrupt configuration. After this spurious IRQ assertion, it will continue being asserted as an FIQ for some time but it will come into the processor as an IRQ again later and at seemingly random times. Also in my spurious IRQ handler, I have verified that the configuration in the GIC hasn't changed, that it is running on the correct CPU core, and by all intents and purposes it should be a FIQ assertion but it is not!

The FIQ source is a negative-edge on a 50KHz square wave signal through the GPIO 1 bank peripheral. The FIQ handler, when actually entered, exits cleanly and with plenty of time to spare ( ~ 10 us). We've seen on our oscilloscope that our interrupt source is asserting the GPIO line at a solid 50KHz, and when the source is serviced as an IRQ the time-to-enter in the ISR is unacceptably long.

The troubling thing is the FIQ operates correctly, until it is not seen as an FIQ by the target core.

Has anyone seen anything like this? Is there an errata for a configuration such as this? Why would the FIQ come in as an IRQ?

Thanks for your time.

Labels (2)
0 Kudos
Reply
1 Reply

705 Views
joshuaclayton
Contributor III

JD, as you know,

we have been working around this issue with a fallback irq, which seems to have become the standard thing to do for this race condition.

I just came across an LKML discussion about better workarounds proposed for mainline kernel:

LKML: Marek Vasut: Re: [PATCH v8 0/4] arm: KGDB NMI/FIQ support

0 Kudos
Reply