[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=W2i7dfcg2J2a-EO8nBvwHU0AMp79Esoy1Y=H_hNc+jvw@mail.gmail.com>
Date: Mon, 30 Nov 2020 13:30:09 -0800
From: Doug Anderson <dianders@...omium.org>
To: Marc Zyngier <maz@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Linus Walleij <linus.walleij@...aro.org>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Neeraj Upadhyay <neeraju@...eaurora.org>,
Stephen Boyd <swboyd@...omium.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Srinivas Ramana <sramana@...eaurora.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Maulik Shah <mkshah@...eaurora.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
Andy Gross <agross@...nel.org>,
Archana Sathyakumar <asathyak@...eaurora.org>,
Lina Iyer <ilina@...eaurora.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] irqchip: qcom-pdc: Fix phantom irq when changing
between rising/falling
Hi,
On Tue, Nov 24, 2020 at 9:47 AM Douglas Anderson <dianders@...omium.org> wrote:
>
> We have a problem if we use gpio-keys and configure wakeups such that
> we only want one edge to wake us up. AKA:
> wakeup-event-action = <EV_ACT_DEASSERTED>;
> wakeup-source;
>
> Specifically we end up with a phantom interrupt that blocks suspend if
> the line was already high and we want wakeups on rising edges (AKA we
> want the GPIO to go low and then high again before we wake up). The
> opposite is also problematic.
>
> Specifically, here's what's happening today:
> 1. Normally, gpio-keys configures to look for both edges. Due to the
> current workaround introduced in commit c3c0c2e18d94 ("pinctrl:
> qcom: Handle broken/missing PDC dual edge IRQs on sc7180"), if the
> line was high we'd configure for falling edges.
> 2. At suspend time, we change to look for rising edges.
> 3. After qcom_pdc_gic_set_type() runs, we get a phantom interrupt.
>
> We can solve this by just clearing the phantom interrupt.
>
> NOTE: it is possible that this could cause problems for a client with
> very specific needs, but there's not much we can do with this
> hardware. As an example, let's say the interrupt signal is currently
> high and the client is looking for falling edges. The client now
> changes to look for rising edges. The client could possibly expect
> that if the line has a short pulse low (and back high) that it would
> always be detected. Specifically no matter when the pulse happened,
> it should either have tripped the (old) falling edge trigger or the
> (new) rising edge trigger. We will simply not trip it. We could
> narrow down the race a bit by polling our parent before changing
> types, but no matter what we do there will still be a period of time
> where we can't tell the difference between a real transition (or more
> than one transition) and the phantom.
>
> Fixes: f55c73aef890 ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs")
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> Reviewed-by: Maulik Shah <mkshah@...eaurora.org>
> Tested-by: Maulik Shah <mkshah@...eaurora.org>
NOTE: even though this has Maulik's tags, he has requested [1] that we
should wait before landing while he talks with HW folks.
[1] https://lore.kernel.org/linux-arm-msm/603c691f-3614-d87b-075a-0889e9ffc453@codeaurora.org/
-Doug
Powered by blists - more mailing lists