[Linux-stm32] STM32MP1 level triggered interrupts

[Alexandre Torgue]

On 1/24/20 10:21 AM, Marc Zyngier wrote:
> 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.

You are right.

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

Done.

> 
>          M.