Messages in this thread | | | Date | Fri, 29 Apr 2022 18:51:44 +0100 | From | Daniel Thompson <> | Subject | Re: [PATCH] irqchip/exiu: Fix acknowledgment of edge triggered interrupts |
| |
On Fri, Apr 29, 2022 at 02:28:58PM +0100, Daniel Thompson wrote: > On Wed, Apr 27, 2022 at 05:29:33PM +0200, Ard Biesheuvel wrote: > > On Wed, 27 Apr 2022 at 16:27, Daniel Thompson > > <daniel.thompson@linaro.org> wrote: > > > > > > Currently the EXIU uses the fasteoi interrupt flow that is configured by > > > it's parent (irq-gic-v3.c). With this flow the only chance to clear the > > > interrupt request happens during .irq_eoi() and (obviously) this happens > > > after the interrupt handler has run. EXIU requires edge triggered > > > interrupts to be acked prior to interrupt handling. Without this we > > > risk incorrect interrupt dismissal when a new interrupt is delivered > > > after the handler reads and acknowledges the peripheral but before the > > > irq_eoi() takes place. > > > > > > Fix this by clearing the interrupt request from .irq_ack() instead. This > > > requires switching to the fasteoi-ack flow instead of the fasteoi flow. > > > This approach is inspired by the nmi code found in irq-sun6i-r.c . > > > > > > > How are level triggered EXIU interrupts affected by this change? > > Functionally they should not be affected simply because the controller > does not care when (or even if) software writes to IREQCLR... and > testing on SC2A11/Developerbox with a hacked gpio-keys driver does > back this up.
If, and only if, you do the experiment properly... and this afternoon the penny dropped and I fixed that.
In summary, level triggered interrupts require IREQCLR to happen at EOI (to avoid spurious re-entry) whilst edge triggered interrupts require IREQCLR to be acked before ISR is entered (to avoid spurious dismissal).
v2 is on its way...
Daniel.
| |