[Linux-stm32] STM32MP1 level triggered interrupts

[Alexandre Torgue]

On 1/23/20 11:21 PM, 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.
> 
> 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 ?
> 

For this SoC, EXTI block detects external line edges and rises a GIC SPI 
interrupt. This EXTi block is mainly used to handle HW events like 
buttons, clocks ... So first issue seems more to be a design issue (your 
design doesn't fit with MP1 datasheet).

Now, let's find a solution. I'll have a look on your proposition: "check 
the line in EOI callback and retrig".

Marc, this kind a solution could be acceptable on your side ?

regards
Alex