Messages in this thread | | | Date | Mon, 23 Mar 2020 19:25:19 +0000 | From | Marc Zyngier <> | Subject | Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip |
| |
On Mon, 23 Mar 2020 20:04:23 +0100 Marek Vasut <marex@denx.de> wrote:
> On 2/20/20 10:17 AM, Marc Zyngier wrote: > > On 2020-02-20 09:04, Linus Walleij wrote: > >> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue > >> <alexandre.torgue@st.com> wrote: > >> > >>> GPIO hardware block is directly linked to EXTI block but EXTI handles > >>> external interrupts only on edge. To be able to handle GPIO interrupt on > >>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq > >>> chip) > >>> is retriggered following interrupt type and gpio line value. > >>> > >>> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> > >>> Tested-by: Marek Vasut <marex@denx.de> > >> > >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > >> > >> If Marc want to merge it with patch 1/2 go ahead! > > > > I'll queue the whole thing for 5.7. > > I have a feeling this doesn't work with threaded interrupts. > > If the interrupt handler runs in a thread context, the EOI will happen > almost right away (while the IRQ handler runs) and so will the code > handling the IRQ retriggering. But since the IRQ handler still runs and > didn't return yet, the retriggering doesn't cause the IRQ handler to be > called again once it finishes, even if the IRQ line is still asserted. > And that could result in some of the retriggers now happening I think. > Or am I doing something wrong ?
Wouldn't the hardirq handler mask the interrupt? This should certainly be the case when IRQF_ONESHOT is set.
M. -- Jazz is not dead. It just smells funny...
| |