Re: STM32MP1 level triggered interrupts

[Marc Zyngier <maz@kernel.org>]

On 2020-01-23 22:21, Marek Vasut wrote:
> 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.

That is exactly what Uwe was suggesting above (doing the resampling and
retriggering in SW). It remains to be seen whether the GPIO block offers
a way to to read the raw state of the wire.

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

These things are usually cargo-culted from one SoC to another. I'm 
pretty
sure this started as a way to handle edge interrupts on a smaller 
system,
and ended up being copy/pasted in the newer design.

On modern systems, interrupt MUXs are just a disaster: you can't balance
interrupts across CPUs, and they cost cycles to handle. The only benefit
is that you don't have to route all GIC input signals to the GPIO block.
You just route a single one, and slap the mux next to it.

But hey, too late. Hopefully someone at ST is reading this and will feed
back to the design teams.

         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