From: Marek Vasut <marex@denx.de>
To: Marc Zyngier <maz@kernel.org>, Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Torgue <alexandre.torgue@st.com>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-kernel@vger.kernel.org,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip
Date: Mon, 23 Mar 2020 20:04:23 +0100 [thread overview]
Message-ID: <a7fc5e43-34c2-a4e6-e0c5-1584f17fb024@denx.de> (raw)
In-Reply-To: <c991edca3e8925cf0489c0a5676f77b2@kernel.org>
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 ?
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: Marc Zyngier <maz@kernel.org>, Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Torgue <alexandre.torgue@st.com>,
linux-kernel@vger.kernel.org,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Jason Cooper <jason@lakedaemon.net>
Subject: Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip
Date: Mon, 23 Mar 2020 20:04:23 +0100 [thread overview]
Message-ID: <a7fc5e43-34c2-a4e6-e0c5-1584f17fb024@denx.de> (raw)
In-Reply-To: <c991edca3e8925cf0489c0a5676f77b2@kernel.org>
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 ?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-23 19:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 14:32 [PATCH v3 0/2] Add GPIO level-sensitive interrupt support Alexandre Torgue
2020-02-19 14:32 ` Alexandre Torgue
2020-02-19 14:32 ` [PATCH v3 1/2] irqchip/stm32: Add irq retrigger support Alexandre Torgue
2020-02-19 14:32 ` Alexandre Torgue
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Alexandre Torgue
2020-02-19 14:32 ` [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Alexandre Torgue
2020-02-19 14:32 ` Alexandre Torgue
2020-02-20 9:04 ` Linus Walleij
2020-02-20 9:04 ` Linus Walleij
2020-02-20 9:17 ` Marc Zyngier
2020-02-20 9:17 ` Marc Zyngier
2020-03-23 19:04 ` Marek Vasut [this message]
2020-03-23 19:04 ` Marek Vasut
2020-03-23 19:19 ` Marek Vasut
2020-03-23 19:19 ` Marek Vasut
2020-03-23 19:31 ` Marc Zyngier
2020-03-23 19:31 ` Marc Zyngier
2020-03-23 19:37 ` Marek Vasut
2020-03-23 19:37 ` Marek Vasut
2020-03-23 19:49 ` Marc Zyngier
2020-03-23 19:49 ` Marc Zyngier
2020-03-23 23:52 ` Marek Vasut
2020-03-23 23:52 ` Marek Vasut
2020-03-23 19:25 ` Marc Zyngier
2020-03-23 19:25 ` Marc Zyngier
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Alexandre Torgue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7fc5e43-34c2-a4e6-e0c5-1584f17fb024@denx.de \
--to=marex@denx.de \
--cc=alexandre.torgue@st.com \
--cc=jason@lakedaemon.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.