* [PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback
@ 2020-11-05 7:38 Maulik Shah
2020-11-10 13:31 ` Linus Walleij
2020-11-11 16:09 ` Doug Anderson
0 siblings, 2 replies; 4+ messages in thread
From: Maulik Shah @ 2020-11-05 7:38 UTC (permalink / raw)
To: linus.walleij, bjorn.andersson, agross
Cc: linux-kernel, linux-arm-msm, linux-gpio, dianders, swboyd,
evgreen, mka, rnayak, ilina, lsrao, Maulik Shah
When GPIOs that are routed to PDC are used as output they can still latch
the IRQ pending at GIC. As a result the spurious IRQ was handled when the
client driver change the direction to input to starts using it as IRQ.
Currently such erroneous latched IRQ are cleared with .irq_enable callback
however if the driver continue to use GPIO as interrupt and invokes
disable_irq() followed by enable_irq() then everytime during enable_irq()
previously latched interrupt gets cleared.
This can make edge IRQs not seen after enable_irq() if they had arrived
after the driver has invoked disable_irq() and were pending at GIC.
Move clearing erroneous IRQ to .irq_request_resources callback as this is
the place where GPIO direction is changed as input and its locked as IRQ.
While at this add a missing check to invoke msm_gpio_irq_clear_unmask()
from .irq_enable callback only when GPIO is not routed to PDC.
Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
---
drivers/pinctrl/qcom/pinctrl-msm.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index c4bcda9..77a25bd 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -815,21 +815,14 @@ static void msm_gpio_irq_clear_unmask(struct irq_data *d, bool status_clear)
static void msm_gpio_irq_enable(struct irq_data *d)
{
- /*
- * Clear the interrupt that may be pending before we enable
- * the line.
- * This is especially a problem with the GPIOs routed to the
- * PDC. These GPIOs are direct-connect interrupts to the GIC.
- * Disabling the interrupt line at the PDC does not prevent
- * the interrupt from being latched at the GIC. The state at
- * GIC needs to be cleared before enabling.
- */
- if (d->parent_data) {
- irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, 0);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
+
+ if (d->parent_data)
irq_chip_enable_parent(d);
- }
- msm_gpio_irq_clear_unmask(d, true);
+ if (!test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ msm_gpio_irq_clear_unmask(d, true);
}
static void msm_gpio_irq_disable(struct irq_data *d)
@@ -1104,6 +1097,19 @@ static int msm_gpio_irq_reqres(struct irq_data *d)
ret = -EINVAL;
goto out;
}
+
+ /*
+ * Clear the interrupt that may be pending before we enable
+ * the line.
+ * This is especially a problem with the GPIOs routed to the
+ * PDC. These GPIOs are direct-connect interrupts to the GIC.
+ * Disabling the interrupt line at the PDC does not prevent
+ * the interrupt from being latched at the GIC. The state at
+ * GIC needs to be cleared before enabling.
+ */
+ if (d->parent_data && test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, 0);
+
return 0;
out:
module_put(gc->owner);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback
2020-11-05 7:38 [PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback Maulik Shah
@ 2020-11-10 13:31 ` Linus Walleij
2020-11-10 21:28 ` Bjorn Andersson
2020-11-11 16:09 ` Doug Anderson
1 sibling, 1 reply; 4+ messages in thread
From: Linus Walleij @ 2020-11-10 13:31 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson
Cc: Andy Gross, linux-kernel, MSM, open list:GPIO SUBSYSTEM,
open list:GPIO SUBSYSTEM <linux-gpio@vger.kernel.org>,
Andy Gross <agross@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Doug Anderson <dianders@chromium.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Lina Iyer <ilina@codeaurora.org>,,
Stephen Boyd, Evan Green, Matthias Kaehlcke, Rajendra Nayak,
Lina Iyer,
open list:GPIO SUBSYSTEM <linux-gpio@vger.kernel.org>,
Andy Gross <agross@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Doug Anderson <dianders@chromium.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Lina Iyer <ilina@codeaurora.org>,
On Thu, Nov 5, 2020 at 8:38 AM Maulik Shah <mkshah@codeaurora.org> wrote:
> When GPIOs that are routed to PDC are used as output they can still latch
> the IRQ pending at GIC. As a result the spurious IRQ was handled when the
> client driver change the direction to input to starts using it as IRQ.
>
> Currently such erroneous latched IRQ are cleared with .irq_enable callback
> however if the driver continue to use GPIO as interrupt and invokes
> disable_irq() followed by enable_irq() then everytime during enable_irq()
> previously latched interrupt gets cleared.
>
> This can make edge IRQs not seen after enable_irq() if they had arrived
> after the driver has invoked disable_irq() and were pending at GIC.
>
> Move clearing erroneous IRQ to .irq_request_resources callback as this is
> the place where GPIO direction is changed as input and its locked as IRQ.
>
> While at this add a missing check to invoke msm_gpio_irq_clear_unmask()
> from .irq_enable callback only when GPIO is not routed to PDC.
>
> Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
> Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
This looks critical so I applied it for fixes so we get some
rotation in linux-next.
If Bjorn has other opinions he will tell us :)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback
2020-11-10 13:31 ` Linus Walleij
@ 2020-11-10 21:28 ` Bjorn Andersson
0 siblings, 0 replies; 4+ messages in thread
From: Bjorn Andersson @ 2020-11-10 21:28 UTC (permalink / raw)
To: Linus Walleij
Cc: Maulik Shah, Andy Gross, linux-kernel, MSM,
open list:GPIO SUBSYSTEM,
open list:GPIO SUBSYSTEM <linux-gpio@vger.kernel.org>,
Andy Gross <agross@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Doug Anderson <dianders@chromium.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Lina Iyer <ilina@codeaurora.org>,,
Stephen Boyd, Evan Green, Matthias Kaehlcke, Rajendra Nayak,
Lina Iyer,
open list:GPIO SUBSYSTEM <linux-gpio@vger.kernel.org>,
Andy Gross <agross@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Doug Anderson <dianders@chromium.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Lina Iyer <ilina@codeaurora.org>,
On Tue 10 Nov 07:31 CST 2020, Linus Walleij wrote:
> On Thu, Nov 5, 2020 at 8:38 AM Maulik Shah <mkshah@codeaurora.org> wrote:
>
> > When GPIOs that are routed to PDC are used as output they can still latch
> > the IRQ pending at GIC. As a result the spurious IRQ was handled when the
> > client driver change the direction to input to starts using it as IRQ.
> >
> > Currently such erroneous latched IRQ are cleared with .irq_enable callback
> > however if the driver continue to use GPIO as interrupt and invokes
> > disable_irq() followed by enable_irq() then everytime during enable_irq()
> > previously latched interrupt gets cleared.
> >
> > This can make edge IRQs not seen after enable_irq() if they had arrived
> > after the driver has invoked disable_irq() and were pending at GIC.
> >
> > Move clearing erroneous IRQ to .irq_request_resources callback as this is
> > the place where GPIO direction is changed as input and its locked as IRQ.
> >
> > While at this add a missing check to invoke msm_gpio_irq_clear_unmask()
> > from .irq_enable callback only when GPIO is not routed to PDC.
> >
> > Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
> > Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
>
> This looks critical so I applied it for fixes so we get some
> rotation in linux-next.
>
> If Bjorn has other opinions he will tell us :)
>
No objections, the patch looks reasonable to me.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback
2020-11-05 7:38 [PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback Maulik Shah
2020-11-10 13:31 ` Linus Walleij
@ 2020-11-11 16:09 ` Doug Anderson
1 sibling, 0 replies; 4+ messages in thread
From: Doug Anderson @ 2020-11-11 16:09 UTC (permalink / raw)
To: Maulik Shah
Cc: LinusW, Bjorn Andersson, Andy Gross, LKML, linux-arm-msm,
open list:GPIO SUBSYSTEM, Stephen Boyd, Evan Green,
Matthias Kaehlcke, Rajendra Nayak, Lina Iyer, Srinivas Rao L
Hi,
On Wed, Nov 4, 2020 at 11:38 PM Maulik Shah <mkshah@codeaurora.org> wrote:
>
> When GPIOs that are routed to PDC are used as output they can still latch
> the IRQ pending at GIC. As a result the spurious IRQ was handled when the
> client driver change the direction to input to starts using it as IRQ.
>
> Currently such erroneous latched IRQ are cleared with .irq_enable callback
> however if the driver continue to use GPIO as interrupt and invokes
> disable_irq() followed by enable_irq() then everytime during enable_irq()
> previously latched interrupt gets cleared.
>
> This can make edge IRQs not seen after enable_irq() if they had arrived
> after the driver has invoked disable_irq() and were pending at GIC.
>
> Move clearing erroneous IRQ to .irq_request_resources callback as this is
> the place where GPIO direction is changed as input and its locked as IRQ.
>
> While at this add a missing check to invoke msm_gpio_irq_clear_unmask()
> from .irq_enable callback only when GPIO is not routed to PDC.
>
> Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
> Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c | 32 +++++++++++++++++++-------------
> 1 file changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index c4bcda9..77a25bd 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -815,21 +815,14 @@ static void msm_gpio_irq_clear_unmask(struct irq_data *d, bool status_clear)
>
> static void msm_gpio_irq_enable(struct irq_data *d)
> {
> - /*
> - * Clear the interrupt that may be pending before we enable
> - * the line.
> - * This is especially a problem with the GPIOs routed to the
> - * PDC. These GPIOs are direct-connect interrupts to the GIC.
> - * Disabling the interrupt line at the PDC does not prevent
> - * the interrupt from being latched at the GIC. The state at
> - * GIC needs to be cleared before enabling.
> - */
> - if (d->parent_data) {
> - irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, 0);
> + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> + struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
> +
> + if (d->parent_data)
> irq_chip_enable_parent(d);
> - }
>
> - msm_gpio_irq_clear_unmask(d, true);
> + if (!test_bit(d->hwirq, pctrl->skip_wake_irqs))
> + msm_gpio_irq_clear_unmask(d, true);
I'm happy that this patch landed and it seems a definite improvement.
However, it seems like we're still clearing important edges in the
case where the PDC isn't used. Can't we just unconditionally move the
clearing to msm_gpio_irq_reqres()?
-Doug
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-11-11 16:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-05 7:38 [PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback Maulik Shah
2020-11-10 13:31 ` Linus Walleij
2020-11-10 21:28 ` Bjorn Andersson
2020-11-11 16:09 ` Doug Anderson
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).