From: Marc Zyngier <maz@kernel.org>
To: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Linus Walleij <linus.walleij@linaro.org>,
marex@denx.de, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip
Date: Wed, 19 Feb 2020 12:07:15 +0000 [thread overview]
Message-ID: <53f72a8b241da3032a42b80c86b7c6ab@kernel.org> (raw)
In-Reply-To: <f82caf02-5a47-ce3e-ec85-313712ef6de0@st.com>
On 2020-02-19 11:34, Alexandre Torgue wrote:
> Fix Marc email address.
>
> On 2/18/20 2:12 PM, Alexandre Torgue wrote:
>> This patch adds level interrupt support to gpio irq chip.
A commit message should not contain "this patch".
>>
>> 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.
>>
>> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>> Tested-by: Marek Vasut <marex@denx.de>
>>
>> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c
>> b/drivers/pinctrl/stm32/pinctrl-stm32.c
>> index 2d5e0435af0a..dae236562543 100644
>> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
>> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
>> @@ -92,6 +92,7 @@ struct stm32_gpio_bank {
>> u32 bank_nr;
>> u32 bank_ioport_nr;
>> u32 pin_backup[STM32_GPIO_PINS_PER_BANK];
>> + u32 irq_type[STM32_GPIO_PINS_PER_BANK];
Do you really need a u32 here? an array of u8 seems enough. After all,
you only need two bits of information per interrupts (level or not,
low or high).
>> };
>> struct stm32_pinctrl {
>> @@ -303,6 +304,46 @@ static const struct gpio_chip stm32_gpio_template
>> = {
>> .get_direction = stm32_gpio_get_direction,
>> };
>> +void stm32_gpio_irq_eoi(struct irq_data *d)
>> +{
>> + struct stm32_gpio_bank *bank = d->domain->host_data;
>> + int line;
>> +
>> + irq_chip_eoi_parent(d);
>> +
>> + /* If level interrupt type then retrig */
>> + line = stm32_gpio_get(&bank->gpio_chip, d->hwirq);
>> + if ((line == 0 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_LOW) ||
>> + (line == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH))
>> + irq_chip_retrigger_hierarchy(d);
s/line/level/
>> +};
>> +
>> +static int stm32_gpio_set_type(struct irq_data *d, unsigned int type)
>> +{
>> + struct stm32_gpio_bank *bank = d->domain->host_data;
>> + u32 parent_type;
>> +
>> + bank->irq_type[d->hwirq] = type;
It would make more sense if this this assignment was done *after*
sanitizing the type value.
>> +
>> + switch (type) {
>> + case IRQ_TYPE_EDGE_RISING:
>> + case IRQ_TYPE_EDGE_FALLING:
>> + case IRQ_TYPE_EDGE_BOTH:
>> + parent_type = type;
>> + break;
>> + case IRQ_TYPE_LEVEL_HIGH:
>> + parent_type = IRQ_TYPE_EDGE_RISING;
>> + break;
>> + case IRQ_TYPE_LEVEL_LOW:
>> + parent_type = IRQ_TYPE_EDGE_FALLING;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return irq_chip_set_type_parent(d, parent_type);
>> +};
>> +
>> static int stm32_gpio_irq_request_resources(struct irq_data
>> *irq_data)
>> {
>> struct stm32_gpio_bank *bank = irq_data->domain->host_data;
>> @@ -332,11 +373,11 @@ static void
>> stm32_gpio_irq_release_resources(struct irq_data *irq_data)
>> static struct irq_chip stm32_gpio_irq_chip = {
>> .name = "stm32gpio",
>> - .irq_eoi = irq_chip_eoi_parent,
>> + .irq_eoi = stm32_gpio_irq_eoi,
>> .irq_ack = irq_chip_ack_parent,
>> .irq_mask = irq_chip_mask_parent,
>> .irq_unmask = irq_chip_unmask_parent,
>> - .irq_set_type = irq_chip_set_type_parent,
>> + .irq_set_type = stm32_gpio_set_type,
>> .irq_set_wake = irq_chip_set_wake_parent,
>> .irq_request_resources = stm32_gpio_irq_request_resources,
>> .irq_release_resources = stm32_gpio_irq_release_resources,
>>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Alexandre Torgue <alexandre.torgue@st.com>
Cc: marex@denx.de, Jason Cooper <jason@lakedaemon.net>,
Linus Walleij <linus.walleij@linaro.org>,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip
Date: Wed, 19 Feb 2020 12:07:15 +0000 [thread overview]
Message-ID: <53f72a8b241da3032a42b80c86b7c6ab@kernel.org> (raw)
In-Reply-To: <f82caf02-5a47-ce3e-ec85-313712ef6de0@st.com>
On 2020-02-19 11:34, Alexandre Torgue wrote:
> Fix Marc email address.
>
> On 2/18/20 2:12 PM, Alexandre Torgue wrote:
>> This patch adds level interrupt support to gpio irq chip.
A commit message should not contain "this patch".
>>
>> 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.
>>
>> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>> Tested-by: Marek Vasut <marex@denx.de>
>>
>> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c
>> b/drivers/pinctrl/stm32/pinctrl-stm32.c
>> index 2d5e0435af0a..dae236562543 100644
>> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
>> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
>> @@ -92,6 +92,7 @@ struct stm32_gpio_bank {
>> u32 bank_nr;
>> u32 bank_ioport_nr;
>> u32 pin_backup[STM32_GPIO_PINS_PER_BANK];
>> + u32 irq_type[STM32_GPIO_PINS_PER_BANK];
Do you really need a u32 here? an array of u8 seems enough. After all,
you only need two bits of information per interrupts (level or not,
low or high).
>> };
>> struct stm32_pinctrl {
>> @@ -303,6 +304,46 @@ static const struct gpio_chip stm32_gpio_template
>> = {
>> .get_direction = stm32_gpio_get_direction,
>> };
>> +void stm32_gpio_irq_eoi(struct irq_data *d)
>> +{
>> + struct stm32_gpio_bank *bank = d->domain->host_data;
>> + int line;
>> +
>> + irq_chip_eoi_parent(d);
>> +
>> + /* If level interrupt type then retrig */
>> + line = stm32_gpio_get(&bank->gpio_chip, d->hwirq);
>> + if ((line == 0 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_LOW) ||
>> + (line == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH))
>> + irq_chip_retrigger_hierarchy(d);
s/line/level/
>> +};
>> +
>> +static int stm32_gpio_set_type(struct irq_data *d, unsigned int type)
>> +{
>> + struct stm32_gpio_bank *bank = d->domain->host_data;
>> + u32 parent_type;
>> +
>> + bank->irq_type[d->hwirq] = type;
It would make more sense if this this assignment was done *after*
sanitizing the type value.
>> +
>> + switch (type) {
>> + case IRQ_TYPE_EDGE_RISING:
>> + case IRQ_TYPE_EDGE_FALLING:
>> + case IRQ_TYPE_EDGE_BOTH:
>> + parent_type = type;
>> + break;
>> + case IRQ_TYPE_LEVEL_HIGH:
>> + parent_type = IRQ_TYPE_EDGE_RISING;
>> + break;
>> + case IRQ_TYPE_LEVEL_LOW:
>> + parent_type = IRQ_TYPE_EDGE_FALLING;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return irq_chip_set_type_parent(d, parent_type);
>> +};
>> +
>> static int stm32_gpio_irq_request_resources(struct irq_data
>> *irq_data)
>> {
>> struct stm32_gpio_bank *bank = irq_data->domain->host_data;
>> @@ -332,11 +373,11 @@ static void
>> stm32_gpio_irq_release_resources(struct irq_data *irq_data)
>> static struct irq_chip stm32_gpio_irq_chip = {
>> .name = "stm32gpio",
>> - .irq_eoi = irq_chip_eoi_parent,
>> + .irq_eoi = stm32_gpio_irq_eoi,
>> .irq_ack = irq_chip_ack_parent,
>> .irq_mask = irq_chip_mask_parent,
>> .irq_unmask = irq_chip_unmask_parent,
>> - .irq_set_type = irq_chip_set_type_parent,
>> + .irq_set_type = stm32_gpio_set_type,
>> .irq_set_wake = irq_chip_set_wake_parent,
>> .irq_request_resources = stm32_gpio_irq_request_resources,
>> .irq_release_resources = stm32_gpio_irq_release_resources,
>>
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
next prev parent reply other threads:[~2020-02-19 12:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 13:12 [PATCH v2 0/2] Add GPIO level-sensitive interrupt support Alexandre Torgue
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 13:12 ` Alexandre Torgue
2020-02-18 17:51 ` Marek Vasut
2020-02-18 17:51 ` Marek Vasut
2020-02-19 11:33 ` Alexandre Torgue
2020-02-19 11:33 ` Alexandre Torgue
2020-02-19 11:43 ` Marc Zyngier
2020-02-19 11:43 ` Marc Zyngier
2020-02-19 13:07 ` Alexandre Torgue
2020-02-19 13:07 ` Alexandre Torgue
2020-02-19 13:13 ` Marc Zyngier
2020-02-19 13:13 ` Marc Zyngier
2020-02-19 13:17 ` Alexandre Torgue
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 13:12 ` Alexandre Torgue
2020-02-18 17:51 ` Marek Vasut
2020-02-18 17:51 ` Marek Vasut
2020-02-19 11:34 ` Alexandre Torgue
2020-02-19 11:34 ` Alexandre Torgue
2020-02-19 12:07 ` Marc Zyngier [this message]
2020-02-19 12:07 ` Marc Zyngier
2020-02-19 12:59 ` Alexandre Torgue
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 16:25 ` Marek Vasut
2020-02-18 18:10 ` Alexandre Torgue
2020-02-18 18:10 ` Alexandre Torgue
2020-02-18 18:13 ` Marek Vasut
2020-02-18 18:13 ` Marek Vasut
2020-02-19 9:20 ` Alexandre Torgue
2020-02-19 9:20 ` Alexandre Torgue
2020-02-19 17:24 ` Marek Vasut
2020-02-19 17:24 ` Marek Vasut
2020-02-20 13:09 ` Alexandre Torgue
2020-02-20 13:09 ` Alexandre Torgue
2020-02-21 16:41 ` Marek Vasut
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=53f72a8b241da3032a42b80c86b7c6ab@kernel.org \
--to=maz@kernel.org \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.