* [PATCH v3 0/2] Add GPIO level-sensitive interrupt support @ 2020-02-19 14:32 Alexandre Torgue 2020-02-19 14:32 ` [PATCH v3 1/2] irqchip/stm32: Add irq retrigger support Alexandre Torgue 2020-02-19 14:32 ` [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Alexandre Torgue 0 siblings, 2 replies; 14+ messages in thread From: Alexandre Torgue @ 2020-02-19 14:32 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Linus Walleij Cc: linux-arm-kernel, linux-kernel, linux-gpio, marex, alexandre.torgue 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 v2: - Fix issues reported by Marc: - do not retrigger uselessly a second time in exti irq retrigger callback - minor comments in pinctrl patch 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(-) -- 2.17.1 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v3 1/2] irqchip/stm32: Add irq retrigger support 2020-02-19 14:32 [PATCH v3 0/2] Add GPIO level-sensitive interrupt support Alexandre Torgue @ 2020-02-19 14:32 ` Alexandre Torgue 2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Alexandre Torgue 2020-02-19 14:32 ` [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Alexandre Torgue 1 sibling, 1 reply; 14+ messages in thread From: Alexandre Torgue @ 2020-02-19 14:32 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Linus Walleij Cc: linux-arm-kernel, linux-kernel, linux-gpio, marex, alexandre.torgue This commit introduces retrigger support for stm32_ext_h chip. It consists to rise the GIC interrupt mapped to an EXTI line. Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Tested-by: Marek Vasut <marex@denx.de> diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c index e00f2fa27f00..faa8482c8246 100644 --- a/drivers/irqchip/irq-stm32-exti.c +++ b/drivers/irqchip/irq-stm32-exti.c @@ -604,12 +604,24 @@ static void stm32_exti_h_syscore_deinit(void) unregister_syscore_ops(&stm32_exti_h_syscore_ops); } +static int stm32_exti_h_retrigger(struct irq_data *d) +{ + struct stm32_exti_chip_data *chip_data = irq_data_get_irq_chip_data(d); + const struct stm32_exti_bank *stm32_bank = chip_data->reg_bank; + void __iomem *base = chip_data->host_data->base; + u32 mask = BIT(d->hwirq % IRQS_PER_BANK); + + writel_relaxed(mask, base + stm32_bank->swier_ofst); + + return 0; +} + static struct irq_chip stm32_exti_h_chip = { .name = "stm32-exti-h", .irq_eoi = stm32_exti_h_eoi, .irq_mask = stm32_exti_h_mask, .irq_unmask = stm32_exti_h_unmask, - .irq_retrigger = irq_chip_retrigger_hierarchy, + .irq_retrigger = stm32_exti_h_retrigger, .irq_set_type = stm32_exti_h_set_type, .irq_set_wake = stm32_exti_h_set_wake, .flags = IRQCHIP_MASK_ON_SUSPEND, -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [tip: irq/core] irqchip/stm32: Add irq retrigger support 2020-02-19 14:32 ` [PATCH v3 1/2] irqchip/stm32: Add irq retrigger support Alexandre Torgue @ 2020-03-29 20:26 ` tip-bot2 for Alexandre Torgue 0 siblings, 0 replies; 14+ messages in thread From: tip-bot2 for Alexandre Torgue @ 2020-03-29 20:26 UTC (permalink / raw) To: linux-tip-commits; +Cc: Alexandre Torgue, Marc Zyngier, Marek Vasut, x86, LKML The following commit has been merged into the irq/core branch of tip: Commit-ID: 25591d4c6459ce416a319832ce806be7b86183dc Gitweb: https://git.kernel.org/tip/25591d4c6459ce416a319832ce806be7b86183dc Author: Alexandre Torgue <alexandre.torgue@st.com> AuthorDate: Wed, 19 Feb 2020 15:32:28 +01:00 Committer: Marc Zyngier <maz@kernel.org> CommitterDate: Sun, 08 Mar 2020 14:25:45 irqchip/stm32: Add irq retrigger support This commit introduces retrigger support for stm32_ext_h chip. It consists to rise the GIC interrupt mapped to an EXTI line. Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20200219143229.18084-2-alexandre.torgue@st.com --- drivers/irqchip/irq-stm32-exti.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c index e00f2fa..faa8482 100644 --- a/drivers/irqchip/irq-stm32-exti.c +++ b/drivers/irqchip/irq-stm32-exti.c @@ -604,12 +604,24 @@ static void stm32_exti_h_syscore_deinit(void) unregister_syscore_ops(&stm32_exti_h_syscore_ops); } +static int stm32_exti_h_retrigger(struct irq_data *d) +{ + struct stm32_exti_chip_data *chip_data = irq_data_get_irq_chip_data(d); + const struct stm32_exti_bank *stm32_bank = chip_data->reg_bank; + void __iomem *base = chip_data->host_data->base; + u32 mask = BIT(d->hwirq % IRQS_PER_BANK); + + writel_relaxed(mask, base + stm32_bank->swier_ofst); + + return 0; +} + static struct irq_chip stm32_exti_h_chip = { .name = "stm32-exti-h", .irq_eoi = stm32_exti_h_eoi, .irq_mask = stm32_exti_h_mask, .irq_unmask = stm32_exti_h_unmask, - .irq_retrigger = irq_chip_retrigger_hierarchy, + .irq_retrigger = stm32_exti_h_retrigger, .irq_set_type = stm32_exti_h_set_type, .irq_set_wake = stm32_exti_h_set_wake, .flags = IRQCHIP_MASK_ON_SUSPEND, ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-02-19 14:32 [PATCH v3 0/2] Add GPIO level-sensitive interrupt support Alexandre Torgue 2020-02-19 14:32 ` [PATCH v3 1/2] irqchip/stm32: Add irq retrigger support Alexandre Torgue @ 2020-02-19 14:32 ` Alexandre Torgue 2020-02-20 9:04 ` Linus Walleij 2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Alexandre Torgue 1 sibling, 2 replies; 14+ messages in thread From: Alexandre Torgue @ 2020-02-19 14:32 UTC (permalink / raw) To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Linus Walleij Cc: linux-arm-kernel, linux-kernel, linux-gpio, marex, alexandre.torgue 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..d330b30729a5 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]; + u8 irq_type[STM32_GPIO_PINS_PER_BANK]; }; 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 level; + + irq_chip_eoi_parent(d); + + /* If level interrupt type then retrig */ + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); + if ((level == 0 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_LOW) || + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) + irq_chip_retrigger_hierarchy(d); +}; + +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; + + 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; + } + + bank->irq_type[d->hwirq] = type; + + 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, -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-02-19 14:32 ` [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Alexandre Torgue @ 2020-02-20 9:04 ` Linus Walleij 2020-02-20 9:17 ` Marc Zyngier 2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Alexandre Torgue 1 sibling, 1 reply; 14+ messages in thread From: Linus Walleij @ 2020-02-20 9:04 UTC (permalink / raw) To: Alexandre Torgue Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM, Marek Vasut On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue <alexandre.torgue@st.com> wrote: > 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> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> If Marc want to merge it with patch 1/2 go ahead! Alternatively I can merge both patches. Thanks to you & Marek for hashing this out, excellent work! Yours, Linus Walleij ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-02-20 9:04 ` Linus Walleij @ 2020-02-20 9:17 ` Marc Zyngier 2020-03-23 19:04 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Marc Zyngier @ 2020-02-20 9:17 UTC (permalink / raw) To: Linus Walleij Cc: Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM, Marek Vasut On 2020-02-20 09:04, Linus Walleij wrote: > On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue > <alexandre.torgue@st.com> wrote: > >> 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> > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > If Marc want to merge it with patch 1/2 go ahead! I'll queue the whole thing for 5.7. Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-02-20 9:17 ` Marc Zyngier @ 2020-03-23 19:04 ` Marek Vasut 2020-03-23 19:19 ` Marek Vasut 2020-03-23 19:25 ` Marc Zyngier 0 siblings, 2 replies; 14+ messages in thread From: Marek Vasut @ 2020-03-23 19:04 UTC (permalink / raw) To: Marc Zyngier, Linus Walleij Cc: Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM On 2/20/20 10:17 AM, Marc Zyngier wrote: > On 2020-02-20 09:04, Linus Walleij wrote: >> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue >> <alexandre.torgue@st.com> wrote: >> >>> 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> >> >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >> >> If Marc want to merge it with patch 1/2 go ahead! > > I'll queue the whole thing for 5.7. I have a feeling this doesn't work with threaded interrupts. If the interrupt handler runs in a thread context, the EOI will happen almost right away (while the IRQ handler runs) and so will the code handling the IRQ retriggering. But since the IRQ handler still runs and didn't return yet, the retriggering doesn't cause the IRQ handler to be called again once it finishes, even if the IRQ line is still asserted. And that could result in some of the retriggers now happening I think. Or am I doing something wrong ? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-03-23 19:04 ` Marek Vasut @ 2020-03-23 19:19 ` Marek Vasut 2020-03-23 19:31 ` Marc Zyngier 2020-03-23 19:25 ` Marc Zyngier 1 sibling, 1 reply; 14+ messages in thread From: Marek Vasut @ 2020-03-23 19:19 UTC (permalink / raw) To: Marc Zyngier, Linus Walleij Cc: Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM On 3/23/20 8:04 PM, Marek Vasut wrote: > On 2/20/20 10:17 AM, Marc Zyngier wrote: >> On 2020-02-20 09:04, Linus Walleij wrote: >>> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue >>> <alexandre.torgue@st.com> wrote: >>> >>>> 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> >>> >>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >>> >>> If Marc want to merge it with patch 1/2 go ahead! >> >> I'll queue the whole thing for 5.7. > > I have a feeling this doesn't work with threaded interrupts. > > If the interrupt handler runs in a thread context, the EOI will happen > almost right away (while the IRQ handler runs) and so will the code > handling the IRQ retriggering. But since the IRQ handler still runs and > didn't return yet, the retriggering doesn't cause the IRQ handler to be > called again once it finishes, even if the IRQ line is still asserted. > And that could result in some of the retriggers now happening I think. > Or am I doing something wrong ? The patch below makes my usecase work, but I don't know whether it's correct. Basically once the threaded IRQ handler finishes and unmasks the IRQ, check whether the line is asserted and retrigger if so. diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c index 9ac9ecfc2f34..060dbcb7ae72 100644 --- a/drivers/pinctrl/stm32/pinctrl-stm32.c +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c @@ -371,12 +371,26 @@ static void stm32_gpio_irq_release_resources(struct irq_data *irq_data) gpiochip_unlock_as_irq(&bank->gpio_chip, irq_data->hwirq); } +static void stm32_gpio_irq_unmask(struct irq_data *d) +{ + struct stm32_gpio_bank *bank = d->domain->host_data; + int level; + + irq_chip_unmask_parent(d); + + /* If level interrupt type then retrig */ + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); + if ((level == 0 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_LOW) || + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) + irq_chip_retrigger_hierarchy(d); +} + static struct irq_chip stm32_gpio_irq_chip = { .name = "stm32gpio", .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_unmask = stm32_gpio_irq_unmask, .irq_set_type = stm32_gpio_set_type, .irq_set_wake = irq_chip_set_wake_parent, .irq_request_resources = stm32_gpio_irq_request_resources, ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-03-23 19:19 ` Marek Vasut @ 2020-03-23 19:31 ` Marc Zyngier 2020-03-23 19:37 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Marc Zyngier @ 2020-03-23 19:31 UTC (permalink / raw) To: Marek Vasut Cc: Linus Walleij, Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM On Mon, 23 Mar 2020 20:19:39 +0100 Marek Vasut <marex@denx.de> wrote: > On 3/23/20 8:04 PM, Marek Vasut wrote: > > On 2/20/20 10:17 AM, Marc Zyngier wrote: > >> On 2020-02-20 09:04, Linus Walleij wrote: > >>> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue > >>> <alexandre.torgue@st.com> wrote: > >>> > >>>> 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> > >>> > >>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > >>> > >>> If Marc want to merge it with patch 1/2 go ahead! > >> > >> I'll queue the whole thing for 5.7. > > > > I have a feeling this doesn't work with threaded interrupts. > > > > If the interrupt handler runs in a thread context, the EOI will happen > > almost right away (while the IRQ handler runs) and so will the code > > handling the IRQ retriggering. But since the IRQ handler still runs and > > didn't return yet, the retriggering doesn't cause the IRQ handler to be > > called again once it finishes, even if the IRQ line is still asserted. > > And that could result in some of the retriggers now happening I think. > > Or am I doing something wrong ? > > The patch below makes my usecase work, but I don't know whether it's > correct. Basically once the threaded IRQ handler finishes and unmasks > the IRQ, check whether the line is asserted and retrigger if so. > > diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c > b/drivers/pinctrl/stm32/pinctrl-stm32.c > index 9ac9ecfc2f34..060dbcb7ae72 100644 > --- a/drivers/pinctrl/stm32/pinctrl-stm32.c > +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c > @@ -371,12 +371,26 @@ static void > stm32_gpio_irq_release_resources(struct irq_data *irq_data) > gpiochip_unlock_as_irq(&bank->gpio_chip, irq_data->hwirq); > } > > +static void stm32_gpio_irq_unmask(struct irq_data *d) > +{ > + struct stm32_gpio_bank *bank = d->domain->host_data; > + int level; > + > + irq_chip_unmask_parent(d); > + > + /* If level interrupt type then retrig */ > + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); > + if ((level == 0 && bank->irq_type[d->hwirq] == > IRQ_TYPE_LEVEL_LOW) || > + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) > + irq_chip_retrigger_hierarchy(d); > +} > + > static struct irq_chip stm32_gpio_irq_chip = { > .name = "stm32gpio", > .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_unmask = stm32_gpio_irq_unmask, > .irq_set_type = stm32_gpio_set_type, > .irq_set_wake = irq_chip_set_wake_parent, > .irq_request_resources = stm32_gpio_irq_request_resources, > OK, I see your problem now. The usual flow is along the line of Ack+Eoi, and that's what the current code guarantees. Threaded interrupts do Ack+Mask+Eoi, followed by an Unmask once the thread finishes. This unmask needs to do the retrigger as well, as you found out. Can you please refactor the above so that we have the common code between unmask and eoi in a separate function, send a proper patch, and I'll apply it on top of the current irq/irqchip-5.7 branch. Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-03-23 19:31 ` Marc Zyngier @ 2020-03-23 19:37 ` Marek Vasut 2020-03-23 19:49 ` Marc Zyngier 0 siblings, 1 reply; 14+ messages in thread From: Marek Vasut @ 2020-03-23 19:37 UTC (permalink / raw) To: Marc Zyngier Cc: Linus Walleij, Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM On 3/23/20 8:31 PM, Marc Zyngier wrote: > On Mon, 23 Mar 2020 20:19:39 +0100 > Marek Vasut <marex@denx.de> wrote: > >> On 3/23/20 8:04 PM, Marek Vasut wrote: >>> On 2/20/20 10:17 AM, Marc Zyngier wrote: >>>> On 2020-02-20 09:04, Linus Walleij wrote: >>>>> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue >>>>> <alexandre.torgue@st.com> wrote: >>>>> >>>>>> 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> >>>>> >>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >>>>> >>>>> If Marc want to merge it with patch 1/2 go ahead! >>>> >>>> I'll queue the whole thing for 5.7. >>> >>> I have a feeling this doesn't work with threaded interrupts. >>> >>> If the interrupt handler runs in a thread context, the EOI will happen >>> almost right away (while the IRQ handler runs) and so will the code >>> handling the IRQ retriggering. But since the IRQ handler still runs and >>> didn't return yet, the retriggering doesn't cause the IRQ handler to be >>> called again once it finishes, even if the IRQ line is still asserted. >>> And that could result in some of the retriggers now happening I think. >>> Or am I doing something wrong ? >> >> The patch below makes my usecase work, but I don't know whether it's >> correct. Basically once the threaded IRQ handler finishes and unmasks >> the IRQ, check whether the line is asserted and retrigger if so. >> >> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c >> b/drivers/pinctrl/stm32/pinctrl-stm32.c >> index 9ac9ecfc2f34..060dbcb7ae72 100644 >> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c >> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c >> @@ -371,12 +371,26 @@ static void >> stm32_gpio_irq_release_resources(struct irq_data *irq_data) >> gpiochip_unlock_as_irq(&bank->gpio_chip, irq_data->hwirq); >> } >> >> +static void stm32_gpio_irq_unmask(struct irq_data *d) >> +{ >> + struct stm32_gpio_bank *bank = d->domain->host_data; >> + int level; >> + >> + irq_chip_unmask_parent(d); >> + >> + /* If level interrupt type then retrig */ >> + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); >> + if ((level == 0 && bank->irq_type[d->hwirq] == >> IRQ_TYPE_LEVEL_LOW) || >> + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) >> + irq_chip_retrigger_hierarchy(d); >> +} >> + >> static struct irq_chip stm32_gpio_irq_chip = { >> .name = "stm32gpio", >> .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_unmask = stm32_gpio_irq_unmask, >> .irq_set_type = stm32_gpio_set_type, >> .irq_set_wake = irq_chip_set_wake_parent, >> .irq_request_resources = stm32_gpio_irq_request_resources, >> > > OK, I see your problem now. > > The usual flow is along the line of Ack+Eoi, and that's what the > current code guarantees. > > Threaded interrupts do Ack+Mask+Eoi, followed by an Unmask once the > thread finishes. This unmask needs to do the retrigger as well, as you > found out. > > Can you please refactor the above so that we have the common code > between unmask and eoi in a separate function, send a proper patch, and > I'll apply it on top of the current irq/irqchip-5.7 branch. Sure, I can. Do we still need this retriggering in the irq_eoi too ? Also, are there any other hidden details I might've missed ? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-03-23 19:37 ` Marek Vasut @ 2020-03-23 19:49 ` Marc Zyngier 2020-03-23 23:52 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Marc Zyngier @ 2020-03-23 19:49 UTC (permalink / raw) To: Marek Vasut Cc: Linus Walleij, Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM On Mon, 23 Mar 2020 20:37:54 +0100 Marek Vasut <marex@denx.de> wrote: > On 3/23/20 8:31 PM, Marc Zyngier wrote: > > On Mon, 23 Mar 2020 20:19:39 +0100 > > Marek Vasut <marex@denx.de> wrote: > > > >> On 3/23/20 8:04 PM, Marek Vasut wrote: > >>> On 2/20/20 10:17 AM, Marc Zyngier wrote: > >>>> On 2020-02-20 09:04, Linus Walleij wrote: > >>>>> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue > >>>>> <alexandre.torgue@st.com> wrote: > >>>>> > >>>>>> 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> > >>>>> > >>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > >>>>> > >>>>> If Marc want to merge it with patch 1/2 go ahead! > >>>> > >>>> I'll queue the whole thing for 5.7. > >>> > >>> I have a feeling this doesn't work with threaded interrupts. > >>> > >>> If the interrupt handler runs in a thread context, the EOI will happen > >>> almost right away (while the IRQ handler runs) and so will the code > >>> handling the IRQ retriggering. But since the IRQ handler still runs and > >>> didn't return yet, the retriggering doesn't cause the IRQ handler to be > >>> called again once it finishes, even if the IRQ line is still asserted. > >>> And that could result in some of the retriggers now happening I think. > >>> Or am I doing something wrong ? > >> > >> The patch below makes my usecase work, but I don't know whether it's > >> correct. Basically once the threaded IRQ handler finishes and unmasks > >> the IRQ, check whether the line is asserted and retrigger if so. > >> > >> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c > >> b/drivers/pinctrl/stm32/pinctrl-stm32.c > >> index 9ac9ecfc2f34..060dbcb7ae72 100644 > >> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c > >> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c > >> @@ -371,12 +371,26 @@ static void > >> stm32_gpio_irq_release_resources(struct irq_data *irq_data) > >> gpiochip_unlock_as_irq(&bank->gpio_chip, irq_data->hwirq); > >> } > >> > >> +static void stm32_gpio_irq_unmask(struct irq_data *d) > >> +{ > >> + struct stm32_gpio_bank *bank = d->domain->host_data; > >> + int level; > >> + > >> + irq_chip_unmask_parent(d); > >> + > >> + /* If level interrupt type then retrig */ > >> + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); > >> + if ((level == 0 && bank->irq_type[d->hwirq] == > >> IRQ_TYPE_LEVEL_LOW) || > >> + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) > >> + irq_chip_retrigger_hierarchy(d); > >> +} > >> + > >> static struct irq_chip stm32_gpio_irq_chip = { > >> .name = "stm32gpio", > >> .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_unmask = stm32_gpio_irq_unmask, > >> .irq_set_type = stm32_gpio_set_type, > >> .irq_set_wake = irq_chip_set_wake_parent, > >> .irq_request_resources = stm32_gpio_irq_request_resources, > >> > > > > OK, I see your problem now. > > > > The usual flow is along the line of Ack+Eoi, and that's what the > > current code guarantees. > > > > Threaded interrupts do Ack+Mask+Eoi, followed by an Unmask once the > > thread finishes. This unmask needs to do the retrigger as well, as you > > found out. > > > > Can you please refactor the above so that we have the common code > > between unmask and eoi in a separate function, send a proper patch, and > > I'll apply it on top of the current irq/irqchip-5.7 branch. > > Sure, I can. Do we still need this retriggering in the irq_eoi too ? Absolutely, because that's what matters for the non-threaded case (there is no mask/unmask on that path). It is also never wrong to over-resample (it just slows things down). > Also, are there any other hidden details I might've missed ? Probably. But let's fix one bug at a time, shall we? ;-) And let's hope that ST doesn't take this as a excuse not to clean up their act in their next SoC! Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-03-23 19:49 ` Marc Zyngier @ 2020-03-23 23:52 ` Marek Vasut 0 siblings, 0 replies; 14+ messages in thread From: Marek Vasut @ 2020-03-23 23:52 UTC (permalink / raw) To: Marc Zyngier Cc: Linus Walleij, Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM On 3/23/20 8:49 PM, Marc Zyngier wrote: > On Mon, 23 Mar 2020 20:37:54 +0100 > Marek Vasut <marex@denx.de> wrote: > >> On 3/23/20 8:31 PM, Marc Zyngier wrote: >>> On Mon, 23 Mar 2020 20:19:39 +0100 >>> Marek Vasut <marex@denx.de> wrote: >>> >>>> On 3/23/20 8:04 PM, Marek Vasut wrote: >>>>> On 2/20/20 10:17 AM, Marc Zyngier wrote: >>>>>> On 2020-02-20 09:04, Linus Walleij wrote: >>>>>>> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue >>>>>>> <alexandre.torgue@st.com> wrote: >>>>>>> >>>>>>>> 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> >>>>>>> >>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> >>>>>>> >>>>>>> If Marc want to merge it with patch 1/2 go ahead! >>>>>> >>>>>> I'll queue the whole thing for 5.7. >>>>> >>>>> I have a feeling this doesn't work with threaded interrupts. >>>>> >>>>> If the interrupt handler runs in a thread context, the EOI will happen >>>>> almost right away (while the IRQ handler runs) and so will the code >>>>> handling the IRQ retriggering. But since the IRQ handler still runs and >>>>> didn't return yet, the retriggering doesn't cause the IRQ handler to be >>>>> called again once it finishes, even if the IRQ line is still asserted. >>>>> And that could result in some of the retriggers now happening I think. >>>>> Or am I doing something wrong ? >>>> >>>> The patch below makes my usecase work, but I don't know whether it's >>>> correct. Basically once the threaded IRQ handler finishes and unmasks >>>> the IRQ, check whether the line is asserted and retrigger if so. >>>> >>>> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c >>>> b/drivers/pinctrl/stm32/pinctrl-stm32.c >>>> index 9ac9ecfc2f34..060dbcb7ae72 100644 >>>> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c >>>> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c >>>> @@ -371,12 +371,26 @@ static void >>>> stm32_gpio_irq_release_resources(struct irq_data *irq_data) >>>> gpiochip_unlock_as_irq(&bank->gpio_chip, irq_data->hwirq); >>>> } >>>> >>>> +static void stm32_gpio_irq_unmask(struct irq_data *d) >>>> +{ >>>> + struct stm32_gpio_bank *bank = d->domain->host_data; >>>> + int level; >>>> + >>>> + irq_chip_unmask_parent(d); >>>> + >>>> + /* If level interrupt type then retrig */ >>>> + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); >>>> + if ((level == 0 && bank->irq_type[d->hwirq] == >>>> IRQ_TYPE_LEVEL_LOW) || >>>> + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) >>>> + irq_chip_retrigger_hierarchy(d); >>>> +} >>>> + >>>> static struct irq_chip stm32_gpio_irq_chip = { >>>> .name = "stm32gpio", >>>> .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_unmask = stm32_gpio_irq_unmask, >>>> .irq_set_type = stm32_gpio_set_type, >>>> .irq_set_wake = irq_chip_set_wake_parent, >>>> .irq_request_resources = stm32_gpio_irq_request_resources, >>>> >>> >>> OK, I see your problem now. >>> >>> The usual flow is along the line of Ack+Eoi, and that's what the >>> current code guarantees. >>> >>> Threaded interrupts do Ack+Mask+Eoi, followed by an Unmask once the >>> thread finishes. This unmask needs to do the retrigger as well, as you >>> found out. >>> >>> Can you please refactor the above so that we have the common code >>> between unmask and eoi in a separate function, send a proper patch, and >>> I'll apply it on top of the current irq/irqchip-5.7 branch. >> >> Sure, I can. Do we still need this retriggering in the irq_eoi too ? > > Absolutely, because that's what matters for the non-threaded case > (there is no mask/unmask on that path). It is also never wrong to > over-resample (it just slows things down). > >> Also, are there any other hidden details I might've missed ? > > Probably. But let's fix one bug at a time, shall we? ;-) And let's hope > that ST doesn't take this as a excuse not to clean up their act in > their next SoC! Indeed. Patch is out, thanks for the feedback :) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-03-23 19:04 ` Marek Vasut 2020-03-23 19:19 ` Marek Vasut @ 2020-03-23 19:25 ` Marc Zyngier 1 sibling, 0 replies; 14+ messages in thread From: Marc Zyngier @ 2020-03-23 19:25 UTC (permalink / raw) To: Marek Vasut Cc: Linus Walleij, Alexandre Torgue, Thomas Gleixner, Jason Cooper, Linux ARM, linux-kernel, open list:GPIO SUBSYSTEM On Mon, 23 Mar 2020 20:04:23 +0100 Marek Vasut <marex@denx.de> wrote: > On 2/20/20 10:17 AM, Marc Zyngier wrote: > > On 2020-02-20 09:04, Linus Walleij wrote: > >> On Wed, Feb 19, 2020 at 3:32 PM Alexandre Torgue > >> <alexandre.torgue@st.com> wrote: > >> > >>> 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> > >> > >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > >> > >> If Marc want to merge it with patch 1/2 go ahead! > > > > I'll queue the whole thing for 5.7. > > I have a feeling this doesn't work with threaded interrupts. > > If the interrupt handler runs in a thread context, the EOI will happen > almost right away (while the IRQ handler runs) and so will the code > handling the IRQ retriggering. But since the IRQ handler still runs and > didn't return yet, the retriggering doesn't cause the IRQ handler to be > called again once it finishes, even if the IRQ line is still asserted. > And that could result in some of the retriggers now happening I think. > Or am I doing something wrong ? Wouldn't the hardirq handler mask the interrupt? This should certainly be the case when IRQF_ONESHOT is set. M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 14+ messages in thread
* [tip: irq/core] pinctrl: stm32: Add level interrupt support to gpio irq chip 2020-02-19 14:32 ` [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Alexandre Torgue 2020-02-20 9:04 ` Linus Walleij @ 2020-03-29 20:26 ` tip-bot2 for Alexandre Torgue 1 sibling, 0 replies; 14+ messages in thread From: tip-bot2 for Alexandre Torgue @ 2020-03-29 20:26 UTC (permalink / raw) To: linux-tip-commits Cc: Alexandre Torgue, Marc Zyngier, Marek Vasut, Linus Walleij, x86, LKML The following commit has been merged into the irq/core branch of tip: Commit-ID: 47beed513a85b3561e74cbb4dd7af848716fa4e0 Gitweb: https://git.kernel.org/tip/47beed513a85b3561e74cbb4dd7af848716fa4e0 Author: Alexandre Torgue <alexandre.torgue@st.com> AuthorDate: Wed, 19 Feb 2020 15:32:29 +01:00 Committer: Marc Zyngier <maz@kernel.org> CommitterDate: Sun, 08 Mar 2020 14:25:45 pinctrl: stm32: Add level interrupt support to gpio irq chip 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> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200219143229.18084-3-alexandre.torgue@st.com --- drivers/pinctrl/stm32/pinctrl-stm32.c | 45 ++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c index 2d5e043..d330b30 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]; + u8 irq_type[STM32_GPIO_PINS_PER_BANK]; }; 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 level; + + irq_chip_eoi_parent(d); + + /* If level interrupt type then retrig */ + level = stm32_gpio_get(&bank->gpio_chip, d->hwirq); + if ((level == 0 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_LOW) || + (level == 1 && bank->irq_type[d->hwirq] == IRQ_TYPE_LEVEL_HIGH)) + irq_chip_retrigger_hierarchy(d); +}; + +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; + + 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; + } + + bank->irq_type[d->hwirq] = type; + + 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, ^ permalink raw reply related [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-03-29 20:26 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-19 14:32 [PATCH v3 0/2] Add GPIO level-sensitive interrupt support Alexandre Torgue 2020-02-19 14:32 ` [PATCH v3 1/2] irqchip/stm32: Add irq retrigger support Alexandre Torgue 2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Alexandre Torgue 2020-02-19 14:32 ` [PATCH v3 2/2] pinctrl: stm32: Add level interrupt support to gpio irq chip Alexandre Torgue 2020-02-20 9:04 ` Linus Walleij 2020-02-20 9:17 ` Marc Zyngier 2020-03-23 19:04 ` Marek Vasut 2020-03-23 19:19 ` Marek Vasut 2020-03-23 19:31 ` Marc Zyngier 2020-03-23 19:37 ` Marek Vasut 2020-03-23 19:49 ` Marc Zyngier 2020-03-23 23:52 ` Marek Vasut 2020-03-23 19:25 ` Marc Zyngier 2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Alexandre Torgue
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).