[Linux-stm32] STM32MP1 level triggered interrupts

[Marc Zyngier]

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...