* STM32MP1 level triggered interrupts @ 2020-01-20 18:32 Marek Vasut 2020-01-21 17:12 ` Alexandre Torgue 0 siblings, 1 reply; 27+ messages in thread From: Marek Vasut @ 2020-01-20 18:32 UTC (permalink / raw) To: Linux ARM, linux-stm32 Cc: Maxime Coquelin, Patrick Delaunay, Alexandre Torgue 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-20 18:32 STM32MP1 level triggered interrupts Marek Vasut @ 2020-01-21 17:12 ` Alexandre Torgue 2020-01-21 17:21 ` Marc Zyngier 2020-01-21 17:41 ` Marek Vasut 0 siblings, 2 replies; 27+ messages in thread From: Alexandre Torgue @ 2020-01-21 17:12 UTC (permalink / raw) To: Marek Vasut, Linux ARM, linux-stm32; +Cc: Maxime Coquelin, Patrick Delaunay 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-21 17:12 ` Alexandre Torgue @ 2020-01-21 17:21 ` Marc Zyngier 2020-01-22 16:56 ` Alexandre Torgue 2020-01-21 17:41 ` Marek Vasut 1 sibling, 1 reply; 27+ messages in thread From: Marc Zyngier @ 2020-01-21 17:21 UTC (permalink / raw) To: Alexandre Torgue Cc: Marek Vasut, Maxime Coquelin, Patrick Delaunay, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-21 17:21 ` Marc Zyngier @ 2020-01-22 16:56 ` Alexandre Torgue 0 siblings, 0 replies; 27+ messages in thread From: Alexandre Torgue @ 2020-01-22 16:56 UTC (permalink / raw) To: Marc Zyngier Cc: Marek Vasut, Maxime Coquelin, Patrick Delaunay, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-21 17:12 ` Alexandre Torgue 2020-01-21 17:21 ` Marc Zyngier @ 2020-01-21 17:41 ` Marek Vasut 2020-01-22 17:19 ` Alexandre Torgue 1 sibling, 1 reply; 27+ messages in thread From: Marek Vasut @ 2020-01-21 17:41 UTC (permalink / raw) To: Alexandre Torgue, Linux ARM, linux-stm32 Cc: Maxime Coquelin, Patrick Delaunay 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-21 17:41 ` Marek Vasut @ 2020-01-22 17:19 ` Alexandre Torgue 2020-01-22 19:29 ` Marek Vasut 0 siblings, 1 reply; 27+ messages in thread From: Alexandre Torgue @ 2020-01-22 17:19 UTC (permalink / raw) To: Marek Vasut, Linux ARM, linux-stm32; +Cc: Maxime Coquelin, Patrick Delaunay 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-22 17:19 ` Alexandre Torgue @ 2020-01-22 19:29 ` Marek Vasut 2020-01-23 8:27 ` Alexandre Torgue 0 siblings, 1 reply; 27+ messages in thread From: Marek Vasut @ 2020-01-22 19:29 UTC (permalink / raw) To: Alexandre Torgue, Linux ARM, linux-stm32 Cc: Maxime Coquelin, Patrick Delaunay 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-22 19:29 ` Marek Vasut @ 2020-01-23 8:27 ` Alexandre Torgue 2020-01-23 9:22 ` Marc Zyngier 0 siblings, 1 reply; 27+ messages in thread From: Alexandre Torgue @ 2020-01-23 8:27 UTC (permalink / raw) To: Marek Vasut, Linux ARM, linux-stm32; +Cc: Maxime Coquelin, Patrick Delaunay 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 8:27 ` Alexandre Torgue @ 2020-01-23 9:22 ` Marc Zyngier 2020-01-23 10:12 ` Uwe Kleine-König 2020-01-23 22:21 ` Marek Vasut 0 siblings, 2 replies; 27+ messages in thread From: Marc Zyngier @ 2020-01-23 9:22 UTC (permalink / raw) To: Alexandre Torgue Cc: Marek Vasut, Maxime Coquelin, Patrick Delaunay, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 9:22 ` Marc Zyngier @ 2020-01-23 10:12 ` Uwe Kleine-König 2020-01-23 10:44 ` Marc Zyngier 2020-01-23 22:21 ` Marek Vasut 1 sibling, 1 reply; 27+ messages in thread From: Uwe Kleine-König @ 2020-01-23 10:12 UTC (permalink / raw) To: Marc Zyngier Cc: Marek Vasut, Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 10:12 ` Uwe Kleine-König @ 2020-01-23 10:44 ` Marc Zyngier 2020-01-23 10:52 ` Uwe Kleine-König 0 siblings, 1 reply; 27+ messages in thread From: Marc Zyngier @ 2020-01-23 10:44 UTC (permalink / raw) To: Uwe Kleine-König Cc: Marek Vasut, Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 10:44 ` Marc Zyngier @ 2020-01-23 10:52 ` Uwe Kleine-König 2020-01-23 11:18 ` Marc Zyngier 0 siblings, 1 reply; 27+ messages in thread From: Uwe Kleine-König @ 2020-01-23 10:52 UTC (permalink / raw) To: Marc Zyngier Cc: Marek Vasut, Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 10:52 ` Uwe Kleine-König @ 2020-01-23 11:18 ` Marc Zyngier 2020-01-23 22:21 ` Marek Vasut 0 siblings, 1 reply; 27+ messages in thread From: Marc Zyngier @ 2020-01-23 11:18 UTC (permalink / raw) To: Uwe Kleine-König Cc: Marek Vasut, Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 11:18 ` Marc Zyngier @ 2020-01-23 22:21 ` Marek Vasut 2020-01-24 9:17 ` Alexandre Torgue 2020-01-24 9:21 ` Marc Zyngier 0 siblings, 2 replies; 27+ messages in thread From: Marek Vasut @ 2020-01-23 22:21 UTC (permalink / raw) To: Marc Zyngier, Uwe Kleine-König Cc: Linux ARM, Maxime Coquelin, Alexandre Torgue, Patrick Delaunay, linux-stm32 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 22:21 ` Marek Vasut @ 2020-01-24 9:17 ` Alexandre Torgue 2020-01-24 9:24 ` Marc Zyngier 2020-01-24 12:25 ` Marek Vasut 2020-01-24 9:21 ` Marc Zyngier 1 sibling, 2 replies; 27+ messages in thread From: Alexandre Torgue @ 2020-01-24 9:17 UTC (permalink / raw) To: Marek Vasut, Marc Zyngier, Uwe Kleine-König Cc: Linux ARM, Maxime Coquelin, Patrick Delaunay, linux-stm32 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-24 9:17 ` Alexandre Torgue @ 2020-01-24 9:24 ` Marc Zyngier 2020-01-28 18:32 ` Marek Vasut 2020-01-24 12:25 ` Marek Vasut 1 sibling, 1 reply; 27+ messages in thread From: Marc Zyngier @ 2020-01-24 9:24 UTC (permalink / raw) To: Alexandre Torgue Cc: Marek Vasut, Patrick Delaunay, Maxime Coquelin, Uwe Kleine-König, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-24 9:24 ` Marc Zyngier @ 2020-01-28 18:32 ` Marek Vasut 2020-02-05 10:26 ` Marek Vasut 2020-02-05 11:42 ` Marc Zyngier 0 siblings, 2 replies; 27+ messages in thread From: Marek Vasut @ 2020-01-28 18:32 UTC (permalink / raw) To: Marc Zyngier, Alexandre Torgue Cc: Linux ARM, linux-stm32, Maxime Coquelin, Patrick Delaunay, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-28 18:32 ` Marek Vasut @ 2020-02-05 10:26 ` Marek Vasut 2020-02-05 11:42 ` Marc Zyngier 1 sibling, 0 replies; 27+ messages in thread From: Marek Vasut @ 2020-02-05 10:26 UTC (permalink / raw) To: Marc Zyngier, Alexandre Torgue Cc: Linux ARM, linux-stm32, Maxime Coquelin, Patrick Delaunay, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-28 18:32 ` Marek Vasut 2020-02-05 10:26 ` Marek Vasut @ 2020-02-05 11:42 ` Marc Zyngier 2020-02-05 11:53 ` Marek Vasut 1 sibling, 1 reply; 27+ messages in thread From: Marc Zyngier @ 2020-02-05 11:42 UTC (permalink / raw) To: Marek Vasut Cc: Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, Uwe Kleine-König, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-02-05 11:42 ` Marc Zyngier @ 2020-02-05 11:53 ` Marek Vasut 2020-02-05 12:32 ` Marc Zyngier 0 siblings, 1 reply; 27+ messages in thread From: Marek Vasut @ 2020-02-05 11:53 UTC (permalink / raw) To: Marc Zyngier Cc: Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, Uwe Kleine-König, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-02-05 11:53 ` Marek Vasut @ 2020-02-05 12:32 ` Marc Zyngier 2020-02-05 15:36 ` Alexandre TORGUE 0 siblings, 1 reply; 27+ messages in thread From: Marc Zyngier @ 2020-02-05 12:32 UTC (permalink / raw) To: Marek Vasut Cc: Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, Uwe Kleine-König, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: STM32MP1 level triggered interrupts 2020-02-05 12:32 ` Marc Zyngier @ 2020-02-05 15:36 ` Alexandre TORGUE 2020-02-06 2:00 ` Marek Vasut 0 siblings, 1 reply; 27+ messages in thread From: Alexandre TORGUE @ 2020-02-05 15:36 UTC (permalink / raw) To: Marc Zyngier, Marek Vasut Cc: Linux ARM, linux-stm32, Maxime Coquelin, Patrick DELAUNAY, Uwe Kleine-König > >>>> [...] > >>>> > >>>>>> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-02-05 15:36 ` Alexandre TORGUE @ 2020-02-06 2:00 ` Marek Vasut 0 siblings, 0 replies; 27+ messages in thread From: Marek Vasut @ 2020-02-06 2:00 UTC (permalink / raw) To: Alexandre TORGUE, Marc Zyngier Cc: Linux ARM, linux-stm32, Maxime Coquelin, Patrick DELAUNAY, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-24 9:17 ` Alexandre Torgue 2020-01-24 9:24 ` Marc Zyngier @ 2020-01-24 12:25 ` Marek Vasut 1 sibling, 0 replies; 27+ messages in thread From: Marek Vasut @ 2020-01-24 12:25 UTC (permalink / raw) To: Alexandre Torgue, Marc Zyngier, Uwe Kleine-König Cc: Linux ARM, Maxime Coquelin, Patrick Delaunay, linux-stm32 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 22:21 ` Marek Vasut 2020-01-24 9:17 ` Alexandre Torgue @ 2020-01-24 9:21 ` Marc Zyngier 2020-01-24 9:35 ` Alexandre Torgue 1 sibling, 1 reply; 27+ messages in thread From: Marc Zyngier @ 2020-01-24 9:21 UTC (permalink / raw) To: Marek Vasut Cc: Alexandre Torgue, Patrick Delaunay, Maxime Coquelin, Uwe Kleine-König, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-24 9:21 ` Marc Zyngier @ 2020-01-24 9:35 ` Alexandre Torgue 0 siblings, 0 replies; 27+ messages in thread From: Alexandre Torgue @ 2020-01-24 9:35 UTC (permalink / raw) To: Marc Zyngier, Marek Vasut Cc: Linux ARM, linux-stm32, Maxime Coquelin, Patrick Delaunay, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: STM32MP1 level triggered interrupts 2020-01-23 9:22 ` Marc Zyngier 2020-01-23 10:12 ` Uwe Kleine-König @ 2020-01-23 22:21 ` Marek Vasut 1 sibling, 0 replies; 27+ messages in thread From: Marek Vasut @ 2020-01-23 22:21 UTC (permalink / raw) To: Marc Zyngier, Alexandre Torgue Cc: Maxime Coquelin, Patrick Delaunay, linux-stm32, Linux ARM 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2020-02-06 2:01 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-20 18:32 STM32MP1 level triggered interrupts Marek Vasut 2020-01-21 17:12 ` Alexandre Torgue 2020-01-21 17:21 ` Marc Zyngier 2020-01-22 16:56 ` Alexandre Torgue 2020-01-21 17:41 ` Marek Vasut 2020-01-22 17:19 ` Alexandre Torgue 2020-01-22 19:29 ` Marek Vasut 2020-01-23 8:27 ` Alexandre Torgue 2020-01-23 9:22 ` Marc Zyngier 2020-01-23 10:12 ` Uwe Kleine-König 2020-01-23 10:44 ` Marc Zyngier 2020-01-23 10:52 ` Uwe Kleine-König 2020-01-23 11:18 ` Marc Zyngier 2020-01-23 22:21 ` Marek Vasut 2020-01-24 9:17 ` Alexandre Torgue 2020-01-24 9:24 ` Marc Zyngier 2020-01-28 18:32 ` Marek Vasut 2020-02-05 10:26 ` Marek Vasut 2020-02-05 11:42 ` Marc Zyngier 2020-02-05 11:53 ` Marek Vasut 2020-02-05 12:32 ` Marc Zyngier 2020-02-05 15:36 ` Alexandre TORGUE 2020-02-06 2:00 ` Marek Vasut 2020-01-24 12:25 ` Marek Vasut 2020-01-24 9:21 ` Marc Zyngier 2020-01-24 9:35 ` Alexandre Torgue 2020-01-23 22:21 ` Marek Vasut
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).