[Linux-stm32] STM32MP1 level triggered interrupts

[Marek Vasut]

On 1/23/20 12:18 PM, Marc Zyngier wrote:
> 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.

So I wonder, the EXTI should be able to read the GPIO line which caused
the interrupt when the interrupt handler returns, and trigger the
interrupt again if the line is still low. This might need some phandle
from the EXTI to GPIO bank in DT, but should be generally doable, no ?
It's a crutch all right.

But I still wonder, what is the purpose of the EXTImux in that SoC?
Shouldn't that permit routing GPIOs directly into GIC SPIs, which would
then permit detecting at least level-high interrupts ?

-- 
Best regards,
Marek Vasut