Re: STM32MP1 level triggered interrupts

[Marc Zyngier <maz@kernel.org>]

On 2020-01-23 10:52, Uwe Kleine-König wrote:
> On Thu, Jan 23, 2020 at 10:44:03AM +0000, Marc Zyngier wrote:
>> 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.
> 
> Ack, you won't want to look into the registers of the irq generating
> device for that. I assumed the line's state is observable in an
> irq-controller specific way.

Unfortunately, that's not always the case. And if the mux has been
designed for edge-signalling only, this particular feature is unlikely
to exist because it makes little sense in this context (the input
events are only transient, so you wouldn't observe much). Instead, you
would implement a set of latches.

But who knows, maybe as a debug feature (although looking at the TRM
didn't lead to anything useful)...

>> Doing this kind of tricks in 2020 is pretty poor for a modern SoC.
> 
> With the above assumption given, I think that is ok even in 2020. (But 
> I
> wonder about SoCs in 2020 not being able to handle level sensitive irqs
> :-)

Quite. Seems incredibly restrictive, and very unfortunate.

         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