STM32MP1 level triggered interrupts

STM32MP1 level triggered interrupts

[Marek Vasut]

Hi,

I have a device connected to STM32MP157C which requires active-low
level-triggered interrupt sink. The device interrupt line is connected
to the SoC gpio-C bank, which has it's interrupt line routed into EXTI,
which can only handle edge triggered interrupts to my understanding.

However, ARM GIC should be able to do both and EXTI has this irqmux /
EXTImux functionality, which -- if my understanding is correct -- is
capable of routing a select GPIO line directly into the GIC as an EXTIn
interrupt signal. Thus, this might permit handling active low
level-triggered interrupts. Is there some DT binding to configure this yet ?

Or is there some other, better, way ?

-- 
Best regards,
Marek Vasut

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Alexandre Torgue]

Hi Marek,

On 1/20/20 7:32 PM, Marek Vasut wrote:
> Hi,
> 
> I have a device connected to STM32MP157C which requires active-low
> level-triggered interrupt sink. The device interrupt line is connected
> to the SoC gpio-C bank, which has it's interrupt line routed into EXTI,
> which can only handle edge triggered interrupts to my understanding.

correct.

> 
> However, ARM GIC should be able to do both and EXTI has this irqmux /
> EXTImux functionality, which -- if my understanding is correct -- is
> capable of routing a select GPIO line directly into the GIC as an EXTIn
> interrupt signal. Thus, this might permit handling active low
> level-triggered interrupts. Is there some DT binding to configure this yet ?
> 
> Or is there some other, better, way ?
> 

For SPIs, GIC controller handles rising edge triggered interrupt and 
active high level-sensitive. GIC integration in STM32MP157c makes that 
only active high level-sensitive configuration for SPI interrupts is 
supported.

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


regards
Alex



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

On 2020-01-21 17:12, Alexandre Torgue wrote:
> Hi Marek,
> 
> On 1/20/20 7:32 PM, Marek Vasut wrote:
>> Hi,
>> 
>> I have a device connected to STM32MP157C which requires active-low
>> level-triggered interrupt sink. The device interrupt line is connected
>> to the SoC gpio-C bank, which has it's interrupt line routed into 
>> EXTI,
>> which can only handle edge triggered interrupts to my understanding.
> 
> correct.
> 
>> 
>> However, ARM GIC should be able to do both and EXTI has this irqmux /
>> EXTImux functionality, which -- if my understanding is correct -- is
>> capable of routing a select GPIO line directly into the GIC as an 
>> EXTIn
>> interrupt signal. Thus, this might permit handling active low
>> level-triggered interrupts. Is there some DT binding to configure this 
>> yet ?
>> 
>> Or is there some other, better, way ?
>> 
> 
> For SPIs, GIC controller handles rising edge triggered interrupt and
> active high level-sensitive. GIC integration in STM32MP157c makes that
> only active high level-sensitive configuration for SPI interrupts is
> supported.

This statement is a slight exaggeration. *any* GIC will happily service
rising-edge triggered SPIs, as it is mandated by the spec. What I 
suspect
is that there is no SPI that is routed out of the SoC for anyone to 
directly
plug anything into it.

          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

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

On 1/21/20 6:12 PM, Alexandre Torgue wrote:
> Hi Marek,

Hi,

> On 1/20/20 7:32 PM, Marek Vasut wrote:
>> Hi,
>>
>> I have a device connected to STM32MP157C which requires active-low
>> level-triggered interrupt sink. The device interrupt line is connected
>> to the SoC gpio-C bank, which has it's interrupt line routed into EXTI,
>> which can only handle edge triggered interrupts to my understanding.
> 
> correct.

OK

>> However, ARM GIC should be able to do both and EXTI has this irqmux /
>> EXTImux functionality, which -- if my understanding is correct -- is
>> capable of routing a select GPIO line directly into the GIC as an EXTIn
>> interrupt signal. Thus, this might permit handling active low
>> level-triggered interrupts. Is there some DT binding to configure this
>> yet ?
>>
>> Or is there some other, better, way ?
>>
> 
> For SPIs, GIC controller handles rising edge triggered interrupt and
> active high level-sensitive. GIC integration in STM32MP157c makes that
> only active high level-sensitive configuration for SPI interrupts is
> supported.

So technically , there is a possibility to handle level-sensitive
active-high interrupts. Can one such interrupt be routed through the
EXTImux into a GIC SPI then ?

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

> regards
> Alex

-- 
Best regards,
Marek Vasut

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Alexandre Torgue]

On 1/21/20 6:21 PM, Marc Zyngier wrote:
> On 2020-01-21 17:12, Alexandre Torgue wrote:
>> Hi Marek,
>>
>> On 1/20/20 7:32 PM, Marek Vasut wrote:
>>> Hi,
>>>
>>> I have a device connected to STM32MP157C which requires active-low
>>> level-triggered interrupt sink. The device interrupt line is connected
>>> to the SoC gpio-C bank, which has it's interrupt line routed into EXTI,
>>> which can only handle edge triggered interrupts to my understanding.
>>
>> correct.
>>
>>>
>>> However, ARM GIC should be able to do both and EXTI has this irqmux /
>>> EXTImux functionality, which -- if my understanding is correct -- is
>>> capable of routing a select GPIO line directly into the GIC as an EXTIn
>>> interrupt signal. Thus, this might permit handling active low
>>> level-triggered interrupts. Is there some DT binding to configure 
>>> this yet ?
>>>
>>> Or is there some other, better, way ?
>>>
>>
>> For SPIs, GIC controller handles rising edge triggered interrupt and
>> active high level-sensitive. GIC integration in STM32MP157c makes that
>> only active high level-sensitive configuration for SPI interrupts is
>> supported.
> 
> This statement is a slight exaggeration. *any* GIC will happily service
> rising-edge triggered SPIs, as it is mandated by the spec. What I suspect
> is that there is no SPI that is routed out of the SoC for anyone to 
> directly
> plug anything into it.

Yes correct. No SPI are routed out of the SoC. External interruptions 
are mapped to Exti. Exti is then routed to the GIC with other signals.

Regards
Alex

> 
>           M.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Alexandre Torgue]

On 1/21/20 6:41 PM, Marek Vasut wrote:
> On 1/21/20 6:12 PM, Alexandre Torgue wrote:
>> Hi Marek,
> 
> Hi,
> 
>> On 1/20/20 7:32 PM, Marek Vasut wrote:
>>> Hi,
>>>
>>> I have a device connected to STM32MP157C which requires active-low
>>> level-triggered interrupt sink. The device interrupt line is connected
>>> to the SoC gpio-C bank, which has it's interrupt line routed into EXTI,
>>> which can only handle edge triggered interrupts to my understanding.
>>
>> correct.
> 
> OK
> 
>>> However, ARM GIC should be able to do both and EXTI has this irqmux /
>>> EXTImux functionality, which -- if my understanding is correct -- is
>>> capable of routing a select GPIO line directly into the GIC as an EXTIn
>>> interrupt signal. Thus, this might permit handling active low
>>> level-triggered interrupts. Is there some DT binding to configure this
>>> yet ?
>>>
>>> Or is there some other, better, way ?
>>>
>>
>> For SPIs, GIC controller handles rising edge triggered interrupt and
>> active high level-sensitive. GIC integration in STM32MP157c makes that
>> only active high level-sensitive configuration for SPI interrupts is
>> supported.
> 
> So technically , there is a possibility to handle level-sensitive
> active-high interrupts. Can one such interrupt be routed through the
> EXTImux into a GIC SPI then ?

Not for external signals. Externals signals are routed to the EXTI 
block. Allowed configurations are: rising/falling/both. Following a 
rising or falling edge, EXTI will trig a other signal mapped to the GIC.
This GIC interrupt is configured as high level sensitive (and remains 
high until EXTI edge pending register is read).

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

> 
>> regards
>> Alex
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

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

-- 
Best regards,
Marek Vasut

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Alexandre Torgue]

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 :$

> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

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.

         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

Re: STM32MP1 level triggered interrupts

[Uwe Kleine-König]

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.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

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.

Doing this kind of tricks in 2020 is pretty poor for a modern SoC.

         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

Re: STM32MP1 level triggered interrupts

[Uwe Kleine-König]

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.

> 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
:-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

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

Re: 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

On 1/23/20 10:22 AM, 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.

Thank you for confirming my suspicion.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: 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






_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

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

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

On 2020-01-24 09:17, Alexandre Torgue wrote:
> On 1/23/20 11:21 PM, Marek Vasut wrote:

[...]

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

It will depend on the nature of the hack you will have to put in there.
If it is 100% reliable, why not? Anything short of that, probably not.

         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

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

On 1/24/20 10:17 AM, Alexandre Torgue wrote:
[...]
>>>>> 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).

I am asking about the EXTImux block, see the DM00327659 datasheet
section 24.2 EXTI block diagram , figure 140 and exti[15:0] . Maybe that
permits routing external events directly to GIC SPIs ?

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

That could probably work.

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


-- 
Best regards,
Marek Vasut

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

On 1/24/20 10:24 AM, Marc Zyngier wrote:
> On 2020-01-24 09:17, Alexandre Torgue wrote:
>> On 1/23/20 11:21 PM, Marek Vasut wrote:
> 
> [...]
> 
>>> 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 ?
> 
> It will depend on the nature of the hack you will have to put in there.
> If it is 100% reliable, why not? Anything short of that, probably not.

I had another look into this, and what we would end up is some sort of
phandle from exti to all the gpioX nodes in DT, would that be OK ?
However, if we do that, then we will have the pinctrl controller (which
has the gpio banks as subnodes) require the exti through a phandle and
exti require the gpio banks through a phandle, so we end up with some
sort of cyclic dependency there.

So we would need to somehow have exti lazily deal with it's gpioX
controller phandles only when someone requests level interrupt ? That
would probably do.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

On 1/28/20 7:32 PM, Marek Vasut wrote:
> On 1/24/20 10:24 AM, Marc Zyngier wrote:
>> On 2020-01-24 09:17, Alexandre Torgue wrote:
>>> On 1/23/20 11:21 PM, Marek Vasut wrote:
>>
>> [...]
>>
>>>> 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 ?
>>
>> It will depend on the nature of the hack you will have to put in there.
>> If it is 100% reliable, why not? Anything short of that, probably not.
> 
> I had another look into this, and what we would end up is some sort of
> phandle from exti to all the gpioX nodes in DT, would that be OK ?
> However, if we do that, then we will have the pinctrl controller (which
> has the gpio banks as subnodes) require the exti through a phandle and
> exti require the gpio banks through a phandle, so we end up with some
> sort of cyclic dependency there.
> 
> So we would need to somehow have exti lazily deal with it's gpioX
> controller phandles only when someone requests level interrupt ? That
> would probably do.

Bump? Thoughts?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

On 2020-01-28 18:32, Marek Vasut wrote:
> On 1/24/20 10:24 AM, Marc Zyngier wrote:
>> On 2020-01-24 09:17, Alexandre Torgue wrote:
>>> On 1/23/20 11:21 PM, Marek Vasut wrote:
>> 
>> [...]
>> 
>>>> 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 ?
>> 
>> It will depend on the nature of the hack you will have to put in 
>> there.
>> If it is 100% reliable, why not? Anything short of that, probably not.
> 
> I had another look into this, and what we would end up is some sort of
> phandle from exti to all the gpioX nodes in DT, would that be OK ?
> However, if we do that, then we will have the pinctrl controller (which
> has the gpio banks as subnodes) require the exti through a phandle and
> exti require the gpio banks through a phandle, so we end up with some
> sort of cyclic dependency there.
> 
> So we would need to somehow have exti lazily deal with it's gpioX
> controller phandles only when someone requests level interrupt ? That
> would probably do.

TBH, I don't have much of an opinion here. If you can deal with the 
plumbing
that's required to make this thing work reliably, then why not?

What I insist on is that the sampling/retriggering is made 100% 
reliable.
I'd prefer we don't offer the functionality if it there is any doubt 
about it.

         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

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

On 2/5/20 12:42 PM, Marc Zyngier wrote:
> On 2020-01-28 18:32, Marek Vasut wrote:
>> On 1/24/20 10:24 AM, Marc Zyngier wrote:
>>> On 2020-01-24 09:17, Alexandre Torgue wrote:
>>>> On 1/23/20 11:21 PM, Marek Vasut wrote:
>>>
>>> [...]
>>>
>>>>> 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 ?
>>>
>>> It will depend on the nature of the hack you will have to put in there.
>>> If it is 100% reliable, why not? Anything short of that, probably not.
>>
>> I had another look into this, and what we would end up is some sort of
>> phandle from exti to all the gpioX nodes in DT, would that be OK ?
>> However, if we do that, then we will have the pinctrl controller (which
>> has the gpio banks as subnodes) require the exti through a phandle and
>> exti require the gpio banks through a phandle, so we end up with some
>> sort of cyclic dependency there.
>>
>> So we would need to somehow have exti lazily deal with it's gpioX
>> controller phandles only when someone requests level interrupt ? That
>> would probably do.
> 
> TBH, I don't have much of an opinion here. If you can deal with the
> plumbing
> that's required to make this thing work reliably, then why not?
> 
> What I insist on is that the sampling/retriggering is made 100% reliable.
> I'd prefer we don't offer the functionality if it there is any doubt
> about it.

That question was more in the direction of ST, to see how it fits in
their design/plans. I would hate to work on something only to have it
rejected because ST developed something else in parallel.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: STM32MP1 level triggered interrupts

[Marc Zyngier]

On 2020-02-05 11:53, Marek Vasut wrote:
> On 2/5/20 12:42 PM, Marc Zyngier wrote:
>> On 2020-01-28 18:32, Marek Vasut wrote:
>>> On 1/24/20 10:24 AM, Marc Zyngier wrote:
>>>> On 2020-01-24 09:17, Alexandre Torgue wrote:
>>>>> On 1/23/20 11:21 PM, Marek Vasut wrote:
>>>> 
>>>> [...]
>>>> 
>>>>>> 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 ?
>>>> 
>>>> It will depend on the nature of the hack you will have to put in 
>>>> there.
>>>> If it is 100% reliable, why not? Anything short of that, probably 
>>>> not.
>>> 
>>> I had another look into this, and what we would end up is some sort 
>>> of
>>> phandle from exti to all the gpioX nodes in DT, would that be OK ?
>>> However, if we do that, then we will have the pinctrl controller 
>>> (which
>>> has the gpio banks as subnodes) require the exti through a phandle 
>>> and
>>> exti require the gpio banks through a phandle, so we end up with some
>>> sort of cyclic dependency there.
>>> 
>>> So we would need to somehow have exti lazily deal with it's gpioX
>>> controller phandles only when someone requests level interrupt ? That
>>> would probably do.
>> 
>> TBH, I don't have much of an opinion here. If you can deal with the
>> plumbing
>> that's required to make this thing work reliably, then why not?
>> 
>> What I insist on is that the sampling/retriggering is made 100% 
>> reliable.
>> I'd prefer we don't offer the functionality if it there is any doubt
>> about it.
> 
> That question was more in the direction of ST, to see how it fits in
> their design/plans. I would hate to work on something only to have it
> rejected because ST developed something else in parallel.

I think this is more of a "whoever needs it writes it" case, and ST
obviously didn't care much about supporting external level interrupts.

So if you have the need *and* a clear idea on how to make it work, 
please
post patches. If ST wakes up and wants to chime in, LKML is the right
forum for having the discussion.

Thanks,

         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

RE: STM32MP1 level triggered interrupts

[Alexandre TORGUE]

> >>>> [...]
> >>>>
> >>>>>> 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 ?
> >>>>
> >>>> It will depend on the nature of the hack you will have to put in
> >>>> there.
> >>>> If it is 100% reliable, why not? Anything short of that, probably
> >>>> not.
> >>>
> >>> I had another look into this, and what we would end up is some sort
> >>> of phandle from exti to all the gpioX nodes in DT, would that be OK
> >>> ?
> >>> However, if we do that, then we will have the pinctrl controller
> >>> (which has the gpio banks as subnodes) require the exti through a
> >>> phandle and exti require the gpio banks through a phandle, so we end
> >>> up with some sort of cyclic dependency there.
> >>>
> >>> So we would need to somehow have exti lazily deal with it's gpioX
> >>> controller phandles only when someone requests level interrupt ?
> >>> That would probably do.
> >>
> >> TBH, I don't have much of an opinion here. If you can deal with the
> >> plumbing that's required to make this thing work reliably, then why
> >> not?
> >>
> >> What I insist on is that the sampling/retriggering is made 100%
> >> reliable.
> >> I'd prefer we don't offer the functionality if it there is any doubt
> >> about it.
> >
> > That question was more in the direction of ST, to see how it fits in
> > their design/plans. I would hate to work on something only to have it
> > rejected because ST developed something else in parallel.
> 
> I think this is more of a "whoever needs it writes it" case, and ST obviously didn't
> care much about supporting external level interrupts.
> 
> So if you have the need *and* a clear idea on how to make it work, please post
> patches. If ST wakes up and wants to chime in, LKML is the right forum for having
> the discussion.
> 

Sorry for the delay (just back from business trip). This topic has triggered internal
Discussions to update our design for future product. So thanks for that.
Now we have to find a solution for MP1. I have to work on it (find a way to read
gpio line value from exti). If you have something to propose don't hesitate to share it with us.

Regards
Alexandre

> Thanks,
> 
>          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

Re: STM32MP1 level triggered interrupts

[Marek Vasut]

On 2/5/20 4:36 PM, Alexandre TORGUE wrote:
> 
>>>>>> [...]
>>>>>>
>>>>>>>> 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 ?
>>>>>>
>>>>>> It will depend on the nature of the hack you will have to put in
>>>>>> there.
>>>>>> If it is 100% reliable, why not? Anything short of that, probably
>>>>>> not.
>>>>>
>>>>> I had another look into this, and what we would end up is some sort
>>>>> of phandle from exti to all the gpioX nodes in DT, would that be OK
>>>>> ?
>>>>> However, if we do that, then we will have the pinctrl controller
>>>>> (which has the gpio banks as subnodes) require the exti through a
>>>>> phandle and exti require the gpio banks through a phandle, so we end
>>>>> up with some sort of cyclic dependency there.
>>>>>
>>>>> So we would need to somehow have exti lazily deal with it's gpioX
>>>>> controller phandles only when someone requests level interrupt ?
>>>>> That would probably do.
>>>>
>>>> TBH, I don't have much of an opinion here. If you can deal with the
>>>> plumbing that's required to make this thing work reliably, then why
>>>> not?
>>>>
>>>> What I insist on is that the sampling/retriggering is made 100%
>>>> reliable.
>>>> I'd prefer we don't offer the functionality if it there is any doubt
>>>> about it.
>>>
>>> That question was more in the direction of ST, to see how it fits in
>>> their design/plans. I would hate to work on something only to have it
>>> rejected because ST developed something else in parallel.
>>
>> I think this is more of a "whoever needs it writes it" case, and ST obviously didn't
>> care much about supporting external level interrupts.
>>
>> So if you have the need *and* a clear idea on how to make it work, please post
>> patches. If ST wakes up and wants to chime in, LKML is the right forum for having
>> the discussion.
>>
> 
> Sorry for the delay (just back from business trip). This topic has triggered internal
> Discussions to update our design for future product. So thanks for that.
> Now we have to find a solution for MP1. I have to work on it (find a way to read
> gpio line value from exti). If you have something to propose don't hesitate to share it with us.

I believe the proposal is explained above. The question is whether that
is acceptable.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel