mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexandre Torgue <alexandre.torgue@st.com>
To: Marek Vasut <marex@denx.de>, Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] Add GPIO level-sensitive interrupt support
Date: Wed, 19 Feb 2020 10:20:26 +0100	[thread overview]
Message-ID: <d271f09b-6391-779a-b133-66bcdfbb0ec6@st.com> (raw)
In-Reply-To: <088e786c-511e-cf95-fc41-5343b8134407@denx.de>



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





  reply	other threads:[~2020-02-19  9:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-18 13:12 Alexandre Torgue
2020-02-18 13:12 ` [PATCH v2 1/2] irqchip/stm32: Add irq retrigger support Alexandre Torgue
2020-02-18 17:51   ` Marek Vasut
2020-02-19 11:33   ` Alexandre Torgue
2020-02-19 11:43     ` Marc Zyngier
2020-02-19 13:07       ` Alexandre Torgue
2020-02-19 13:13         ` Marc Zyngier
2020-02-19 13:17           ` Alexandre Torgue
2020-02-18 13:12 ` [PATCH v2 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Alexandre Torgue
2020-02-18 17:51   ` Marek Vasut
2020-02-19 11:34   ` Alexandre Torgue
2020-02-19 12:07     ` Marc Zyngier
2020-02-19 12:59       ` Alexandre Torgue
2020-02-18 16:25 ` [PATCH v2 0/2] Add GPIO level-sensitive interrupt support Marek Vasut
2020-02-18 18:10   ` Alexandre Torgue
2020-02-18 18:13     ` Marek Vasut
2020-02-19  9:20       ` Alexandre Torgue [this message]
2020-02-19 17:24         ` Marek Vasut
2020-02-20 13:09           ` Alexandre Torgue
2020-02-21 16:41             ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d271f09b-6391-779a-b133-66bcdfbb0ec6@st.com \
    --to=alexandre.torgue@st.com \
    --cc=jason@lakedaemon.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=marex@denx.de \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome