linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Marek Vasut <marex@denx.de>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Patrick Delaunay <patrick.delaunay@st.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: STM32MP1 level triggered interrupts
Date: Thu, 23 Jan 2020 10:44:03 +0000	[thread overview]
Message-ID: <03fd1cb7b5985b3221f66c6b0058adc8@kernel.org> (raw)
In-Reply-To: <20200123101225.nscpc5t4nmlarbw2@pengutronix.de>

On 2020-01-23 10:12, Uwe Kleine-König wrote:
> On Thu, Jan 23, 2020 at 09:22:48AM +0000, Marc Zyngier wrote:
>> On 2020-01-23 08:27, Alexandre Torgue wrote:
>> > On 1/22/20 8:29 PM, Marek Vasut wrote:
>> > > On 1/22/20 6:19 PM, Alexandre Torgue wrote:
>> > >
>> > > Hi,
>> > >
>> > > [...]
>> > >
>> > > > > > Concerning, your question:
>> > > > > >
>> > > > > > Setting your gpioC interruption as "falling edge" should
>> > > > > > be enough. On
>> > > > > > gpioCx falling edge, a high-level signal is generated by
>> > > > > > exti and sent
>> > > > > > to GIC (which triggers GIC interrupt). This signal
>> > > > > > remains high until
>> > > > > > stm32_irq_ack is called.
>> > > > > >
>> > > > > > So you only need: (ex for gpioc 1).
>> > > > > >
>> > > > > > interrupt-parent = <&gpioc>;
>> > > > > > interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
>> > > > >
>> > > > > How does this deal with the case where the device holds the
>> > > > > interrupt
>> > > > > line low (since it's level-sensitive, active low) after the driver
>> > > > > interrupt handler finishes ? Does such condition generate another
>> > > > > interrupt and call the driver interrupt handler again ? I
>> > > > > would expect
>> > > > > the answer is no, because the interrupt is edge-triggered
>> > > > > and there is
>> > > > > no edge.
>> > > >
>> > > > Your assumption is good. If your device continue to hold the
>> > > > line to low
>> > > > at the end of your interrupt handler, no more interrupt will be
>> > > > generated.
>> > >
>> > > But does that basically mean that such a device cannot be used with
>> > > STM32MP1 or am I fundamentally mistaken and don't understand how a
>> > > level-triggered interrupt works ? :)
>> >
>> > You need to release the line in your device interrupt handler. If not,
>> > yes, you will miss interrupts :$
>> 
>> So to sum it up, this SoC doesn't support external level interrupts
>> on its own, full stop. You'd need some additional external sampling
>> HW to retrigger an edge on EOI.
> 
> Or you need software support that marks the irq pending again if on
> unmask the irq line is still active.

Assuming you can actually observe the state of the line directly,
without having to add specific knowledge of the generating device.

Doing this kind of tricks in 2020 is pretty poor for a modern SoC.

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-23 10:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 18:32 STM32MP1 level triggered interrupts Marek Vasut
2020-01-21 17:12 ` Alexandre Torgue
2020-01-21 17:21   ` Marc Zyngier
2020-01-22 16:56     ` Alexandre Torgue
2020-01-21 17:41   ` Marek Vasut
2020-01-22 17:19     ` Alexandre Torgue
2020-01-22 19:29       ` Marek Vasut
2020-01-23  8:27         ` Alexandre Torgue
2020-01-23  9:22           ` Marc Zyngier
2020-01-23 10:12             ` Uwe Kleine-König
2020-01-23 10:44               ` Marc Zyngier [this message]
2020-01-23 10:52                 ` Uwe Kleine-König
2020-01-23 11:18                   ` Marc Zyngier
2020-01-23 22:21                     ` Marek Vasut
2020-01-24  9:17                       ` Alexandre Torgue
2020-01-24  9:24                         ` Marc Zyngier
2020-01-28 18:32                           ` Marek Vasut
2020-02-05 10:26                             ` Marek Vasut
2020-02-05 11:42                             ` Marc Zyngier
2020-02-05 11:53                               ` Marek Vasut
2020-02-05 12:32                                 ` Marc Zyngier
2020-02-05 15:36                                   ` Alexandre TORGUE
2020-02-06  2:00                                     ` Marek Vasut
2020-01-24 12:25                         ` Marek Vasut
2020-01-24  9:21                       ` Marc Zyngier
2020-01-24  9:35                         ` Alexandre Torgue
2020-01-23 22:21             ` Marek Vasut

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=03fd1cb7b5985b3221f66c6b0058adc8@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandre.torgue@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=marex@denx.de \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=patrick.delaunay@st.com \
    --cc=u.kleine-koenig@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).