mbox series

[v2,0/2] Add GPIO level-sensitive interrupt support

Message ID 20200218131218.10789-1-alexandre.torgue@st.com (mailing list archive)
Headers show
Series Add GPIO level-sensitive interrupt support | expand

Message

Alexandre TORGUE Feb. 18, 2020, 1:12 p.m. UTC
This series adds the possibility to handle gpio interrupts on level.

GPIO hardware block is directly linked to EXTI block but EXTI handles
external interrupts only on edge. To be able to handle GPIO interrupt on
level a "hack" is done in gpio irq chip: parent interrupt (exti irq chip)
is retriggered following interrupt type and gpio line value.

In exti irq chip, retrigger ops function is added.

Changes since v1:
 - Fix issue reported by Marek: return statment in "stm32_gpio_set_type"
   function.

Regards
Alex

Alexandre Torgue (2):
  irqchip/stm32: Add irq retrigger support
  pinctrl: stm32: Add level interrupt support to gpio irq chip

 drivers/irqchip/irq-stm32-exti.c      | 14 ++++++++-
 drivers/pinctrl/stm32/pinctrl-stm32.c | 45 +++++++++++++++++++++++++--
 2 files changed, 56 insertions(+), 3 deletions(-)

Comments

Marek Vasut Feb. 18, 2020, 4:25 p.m. UTC | #1
On 2/18/20 2:12 PM, Alexandre Torgue wrote:
> This series adds the possibility to handle gpio interrupts on level.
> 
> GPIO hardware block is directly linked to EXTI block but EXTI handles
> external interrupts only on edge. To be able to handle GPIO interrupt on
> level a "hack" is done in gpio irq chip: parent interrupt (exti irq chip)
> is retriggered following interrupt type and gpio line value.
> 
> In exti irq chip, retrigger ops function is added.

btw. this might be unrelated, but is it possible to have e.g. gpioC2 set
as trigger-level-low and gpioD2 set as trigger-edge-falling ? It seems
8eb2dfee9fb1 ("pinctrl: stm32: add lock mechanism for irqmux selection")
prevents that.
Alexandre TORGUE Feb. 18, 2020, 6:10 p.m. UTC | #2
Hi Marek

On 2/18/20 5:25 PM, Marek Vasut wrote:
> On 2/18/20 2:12 PM, Alexandre Torgue wrote:
>> This series adds the possibility to handle gpio interrupts on level.
>>
>> GPIO hardware block is directly linked to EXTI block but EXTI handles
>> external interrupts only on edge. To be able to handle GPIO interrupt on
>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq chip)
>> is retriggered following interrupt type and gpio line value.
>>
>> In exti irq chip, retrigger ops function is added.
> 
> btw. this might be unrelated, but is it possible to have e.g. gpioC2 set
> as trigger-level-low and gpioD2 set as trigger-edge-falling ? It seems
> 8eb2dfee9fb1 ("pinctrl: stm32: add lock mechanism for irqmux selection")
> prevents that.
> 

No it's not possible. Each gpio line doesn't have a dedicated Exti line 
Each Exti line is muxing between gpio banks.

Mapping is done as following:

EXTI0 = A0 or B0 or C0 .... or Z0 : selected by Mux
EXTI1 = A1 or B1 or C1 ....or Z1 : selected by Mux
EXTI2 = A2 or B2 or C2 ....or Z2 : selected by Mux
...

regards
Alexandre
Marek Vasut Feb. 18, 2020, 6:13 p.m. UTC | #3
On 2/18/20 7:10 PM, Alexandre Torgue wrote:
> Hi Marek

Hi,

> On 2/18/20 5:25 PM, Marek Vasut wrote:
>> On 2/18/20 2:12 PM, Alexandre Torgue wrote:
>>> This series adds the possibility to handle gpio interrupts on level.
>>>
>>> GPIO hardware block is directly linked to EXTI block but EXTI handles
>>> external interrupts only on edge. To be able to handle GPIO interrupt on
>>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq
>>> chip)
>>> is retriggered following interrupt type and gpio line value.
>>>
>>> In exti irq chip, retrigger ops function is added.
>>
>> btw. this might be unrelated, but is it possible to have e.g. gpioC2 set
>> as trigger-level-low and gpioD2 set as trigger-edge-falling ? It seems
>> 8eb2dfee9fb1 ("pinctrl: stm32: add lock mechanism for irqmux selection")
>> prevents that.
>>
> 
> No it's not possible. Each gpio line doesn't have a dedicated Exti line
> Each Exti line is muxing between gpio banks.

OK, that confirms my assumption.

> Mapping is done as following:
> 
> EXTI0 = A0 or B0 or C0 .... or Z0 : selected by Mux
> EXTI1 = A1 or B1 or C1 ....or Z1 : selected by Mux
> EXTI2 = A2 or B2 or C2 ....or Z2 : selected by Mux
> ...

Is it at least possible to have IRQs of the same type on the same exti
line? E.g. gpioA2 of trigger-edge-falling and gpioB2 trigger-edge-falling ?
Alexandre TORGUE Feb. 19, 2020, 9:20 a.m. UTC | #4
On 2/18/20 7:13 PM, Marek Vasut wrote:
> On 2/18/20 7:10 PM, Alexandre Torgue wrote:
>> Hi Marek
> 
> Hi,
> 
>> On 2/18/20 5:25 PM, Marek Vasut wrote:
>>> On 2/18/20 2:12 PM, Alexandre Torgue wrote:
>>>> This series adds the possibility to handle gpio interrupts on level.
>>>>
>>>> GPIO hardware block is directly linked to EXTI block but EXTI handles
>>>> external interrupts only on edge. To be able to handle GPIO interrupt on
>>>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq
>>>> chip)
>>>> is retriggered following interrupt type and gpio line value.
>>>>
>>>> In exti irq chip, retrigger ops function is added.
>>>
>>> btw. this might be unrelated, but is it possible to have e.g. gpioC2 set
>>> as trigger-level-low and gpioD2 set as trigger-edge-falling ? It seems
>>> 8eb2dfee9fb1 ("pinctrl: stm32: add lock mechanism for irqmux selection")
>>> prevents that.
>>>
>>
>> No it's not possible. Each gpio line doesn't have a dedicated Exti line
>> Each Exti line is muxing between gpio banks.
> 
> OK, that confirms my assumption.
> 
>> Mapping is done as following:
>>
>> EXTI0 = A0 or B0 or C0 .... or Z0 : selected by Mux
>> EXTI1 = A1 or B1 or C1 ....or Z1 : selected by Mux
>> EXTI2 = A2 or B2 or C2 ....or Z2 : selected by Mux
>> ...
> 
> Is it at least possible to have IRQs of the same type on the same exti
> line? E.g. gpioA2 of trigger-edge-falling and gpioB2 trigger-edge-falling ?
> 

Sorry I don't catch your point. If you already succeed to get gpioA2, 
then you will failed to get gpioB2 but looking at function call stack we 
could get an other issue.

Lets take example where you succeed to get gpioa2 as interrupt (using 
interrupt bindings) and now you try to do the same for gpiob2, you will 
have (roughly):

stm32_gpio_irq_request_resources (for gpiob2) --> succeed

stm32_gpio_set_type
  |
  |--> stm32_exti_set_type type -> change exti line 2 trigger registers
                                   with gpiob2 binding.

stm32_gpio_domain_activate --> failed as exti line2 is already used
			       by gpioa2.

So as stm32_gpio_set_type is called before checking than exti line is 
available, type could be changed and behavior of gpioa2 interrupt broken.

Solution would be to move the exti line mux check from 
stm32_gpio_domain_activate to  stm32_gpio_irq_request_resources callback.

Regards
Alex
Marek Vasut Feb. 19, 2020, 5:24 p.m. UTC | #5
On 2/19/20 10:20 AM, Alexandre Torgue wrote:
Hi,
[...]
>>>>> This series adds the possibility to handle gpio interrupts on level.
>>>>>
>>>>> GPIO hardware block is directly linked to EXTI block but EXTI handles
>>>>> external interrupts only on edge. To be able to handle GPIO
>>>>> interrupt on
>>>>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq
>>>>> chip)
>>>>> is retriggered following interrupt type and gpio line value.
>>>>>
>>>>> In exti irq chip, retrigger ops function is added.
>>>>
>>>> btw. this might be unrelated, but is it possible to have e.g. gpioC2
>>>> set
>>>> as trigger-level-low and gpioD2 set as trigger-edge-falling ? It seems
>>>> 8eb2dfee9fb1 ("pinctrl: stm32: add lock mechanism for irqmux
>>>> selection")
>>>> prevents that.
>>>>
>>>
>>> No it's not possible. Each gpio line doesn't have a dedicated Exti line
>>> Each Exti line is muxing between gpio banks.
>>
>> OK, that confirms my assumption.
>>
>>> Mapping is done as following:
>>>
>>> EXTI0 = A0 or B0 or C0 .... or Z0 : selected by Mux
>>> EXTI1 = A1 or B1 or C1 ....or Z1 : selected by Mux
>>> EXTI2 = A2 or B2 or C2 ....or Z2 : selected by Mux
>>> ...
>>
>> Is it at least possible to have IRQs of the same type on the same exti
>> line? E.g. gpioA2 of trigger-edge-falling and gpioB2
>> trigger-edge-falling ?
>>
> 
> Sorry I don't catch your point. If you already succeed to get gpioA2,
> then you will failed to get gpioB2 but looking at function call stack we
> could get an other issue.

Considering the EXTI line limitations, I'd like to know what kind of IRQ
input configuration is allowed/valid and what kind of configuration is
not valid.

> Lets take example where you succeed to get gpioa2 as interrupt (using
> interrupt bindings) and now you try to do the same for gpiob2, you will
> have (roughly):
> 
> stm32_gpio_irq_request_resources (for gpiob2) --> succeed
> 
> stm32_gpio_set_type
>  |
>  |--> stm32_exti_set_type type -> change exti line 2 trigger registers
>                                   with gpiob2 binding.
> 
> stm32_gpio_domain_activate --> failed as exti line2 is already used
>                    by gpioa2.
> 
> So as stm32_gpio_set_type is called before checking than exti line is
> available, type could be changed and behavior of gpioa2 interrupt broken.
> 
> Solution would be to move the exti line mux check from
> stm32_gpio_domain_activate to  stm32_gpio_irq_request_resources callback.

So the hardware does support using both gpioA2 and gpioB2 as an
interrupt source, for different drivers, if they are of the same
interrupt type. Except the current implementation does not permit that.

If the interrupt types are different, that is not supported by the hardware.

Correct ?
Alexandre TORGUE Feb. 20, 2020, 1:09 p.m. UTC | #6
Hi Marek

On 2/19/20 6:24 PM, Marek Vasut wrote:
> On 2/19/20 10:20 AM, Alexandre Torgue wrote:
> Hi,
> [...]
>>>>>> This series adds the possibility to handle gpio interrupts on level.
>>>>>>
>>>>>> GPIO hardware block is directly linked to EXTI block but EXTI handles
>>>>>> external interrupts only on edge. To be able to handle GPIO
>>>>>> interrupt on
>>>>>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq
>>>>>> chip)
>>>>>> is retriggered following interrupt type and gpio line value.
>>>>>>
>>>>>> In exti irq chip, retrigger ops function is added.
>>>>>
>>>>> btw. this might be unrelated, but is it possible to have e.g. gpioC2
>>>>> set
>>>>> as trigger-level-low and gpioD2 set as trigger-edge-falling ? It seems
>>>>> 8eb2dfee9fb1 ("pinctrl: stm32: add lock mechanism for irqmux
>>>>> selection")
>>>>> prevents that.
>>>>>
>>>>
>>>> No it's not possible. Each gpio line doesn't have a dedicated Exti line
>>>> Each Exti line is muxing between gpio banks.
>>>
>>> OK, that confirms my assumption.
>>>
>>>> Mapping is done as following:
>>>>
>>>> EXTI0 = A0 or B0 or C0 .... or Z0 : selected by Mux
>>>> EXTI1 = A1 or B1 or C1 ....or Z1 : selected by Mux
>>>> EXTI2 = A2 or B2 or C2 ....or Z2 : selected by Mux
>>>> ...
>>>
>>> Is it at least possible to have IRQs of the same type on the same exti
>>> line? E.g. gpioA2 of trigger-edge-falling and gpioB2
>>> trigger-edge-falling ?
>>>
>>
>> Sorry I don't catch your point. If you already succeed to get gpioA2,
>> then you will failed to get gpioB2 but looking at function call stack we
>> could get an other issue.
> 
> Considering the EXTI line limitations, I'd like to know what kind of IRQ
> input configuration is allowed/valid and what kind of configuration is
> not valid.

As a mux is used to select which GPIO[A..Z]_X has to be mapped on exti_X 
line, only one GPIO can be used on the EXTI line.

For example, on EXTI2 you could map either gpioa2 or gpiob2 or 
....gpioz2 but not gpioa2 and gpiob2 in the same time.


> 
>> Lets take example where you succeed to get gpioa2 as interrupt (using
>> interrupt bindings) and now you try to do the same for gpiob2, you will
>> have (roughly):
>>
>> stm32_gpio_irq_request_resources (for gpiob2) --> succeed
>>
>> stm32_gpio_set_type
>>   |
>>   |--> stm32_exti_set_type type -> change exti line 2 trigger registers
>>                                    with gpiob2 binding.
>>
>> stm32_gpio_domain_activate --> failed as exti line2 is already used
>>                     by gpioa2.
>>
>> So as stm32_gpio_set_type is called before checking than exti line is
>> available, type could be changed and behavior of gpioa2 interrupt broken.
>>
>> Solution would be to move the exti line mux check from
>> stm32_gpio_domain_activate to  stm32_gpio_irq_request_resources callback.
> 
> So the hardware does support using both gpioA2 and gpioB2 as an
> interrupt source, for different drivers, if they are of the same
> interrupt type. Except the current implementation does not permit that.
> 

No hardware doesn't allow it for reason explain above.

> If the interrupt types are different, that is not supported by the hardware.
> 
> Correct ?
>
Marek Vasut Feb. 21, 2020, 4:41 p.m. UTC | #7
On 2/20/20 2:09 PM, Alexandre Torgue wrote:
> Hi Marek

Hi,

> On 2/19/20 6:24 PM, Marek Vasut wrote:
>> On 2/19/20 10:20 AM, Alexandre Torgue wrote:
>> Hi,
>> [...]
>>>>>>> This series adds the possibility to handle gpio interrupts on level.
>>>>>>>
>>>>>>> GPIO hardware block is directly linked to EXTI block but EXTI
>>>>>>> handles
>>>>>>> external interrupts only on edge. To be able to handle GPIO
>>>>>>> interrupt on
>>>>>>> level a "hack" is done in gpio irq chip: parent interrupt (exti irq
>>>>>>> chip)
>>>>>>> is retriggered following interrupt type and gpio line value.
>>>>>>>
>>>>>>> In exti irq chip, retrigger ops function is added.
>>>>>>
>>>>>> btw. this might be unrelated, but is it possible to have e.g. gpioC2
>>>>>> set
>>>>>> as trigger-level-low and gpioD2 set as trigger-edge-falling ? It
>>>>>> seems
>>>>>> 8eb2dfee9fb1 ("pinctrl: stm32: add lock mechanism for irqmux
>>>>>> selection")
>>>>>> prevents that.
>>>>>>
>>>>>
>>>>> No it's not possible. Each gpio line doesn't have a dedicated Exti
>>>>> line
>>>>> Each Exti line is muxing between gpio banks.
>>>>
>>>> OK, that confirms my assumption.
>>>>
>>>>> Mapping is done as following:
>>>>>
>>>>> EXTI0 = A0 or B0 or C0 .... or Z0 : selected by Mux
>>>>> EXTI1 = A1 or B1 or C1 ....or Z1 : selected by Mux
>>>>> EXTI2 = A2 or B2 or C2 ....or Z2 : selected by Mux
>>>>> ...
>>>>
>>>> Is it at least possible to have IRQs of the same type on the same exti
>>>> line? E.g. gpioA2 of trigger-edge-falling and gpioB2
>>>> trigger-edge-falling ?
>>>>
>>>
>>> Sorry I don't catch your point. If you already succeed to get gpioA2,
>>> then you will failed to get gpioB2 but looking at function call stack we
>>> could get an other issue.
>>
>> Considering the EXTI line limitations, I'd like to know what kind of IRQ
>> input configuration is allowed/valid and what kind of configuration is
>> not valid.
> 
> As a mux is used to select which GPIO[A..Z]_X has to be mapped on exti_X
> line, only one GPIO can be used on the EXTI line.
> 
> For example, on EXTI2 you could map either gpioa2 or gpiob2 or
> ....gpioz2 but not gpioa2 and gpiob2 in the same time.

Got it, thank you for the clarification.

Maybe that could be something to improve for MP2 :-)