From: Doug Anderson <dianders@chromium.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Maulik Shah <mkshah@codeaurora.org>,
Stephen Boyd <swboyd@chromium.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Evan Green <evgreen@chromium.org>,
LinusW <linus.walleij@linaro.org>, Marc Zyngier <maz@kernel.org>,
Matthias Kaehlcke <mka@chromium.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Andy Gross <agross@kernel.org>,
Jason Cooper <jason@lakedaemon.net>,
Rajendra Nayak <rnayak@codeaurora.org>,
Lina Iyer <ilina@codeaurora.org>,
Srinivas Rao L <lsrao@codeaurora.org>,
"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v5 3/6] genirq/PM: Introduce IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag
Date: Tue, 8 Sep 2020 12:05:21 -0700 [thread overview]
Message-ID: <CAD=FV=X0wjOYC9u1y=fhDTVSW+jd5G8ydSYJEE-a8BTfnhRgTA@mail.gmail.com> (raw)
In-Reply-To: <87pn7150li.fsf@nanos.tec.linutronix.de>
Hi,
On Fri, Sep 4, 2020 at 2:54 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Doug,
>
> On Thu, Sep 03 2020 at 16:19, Doug Anderson wrote:
> > On Thu, Sep 3, 2020 at 5:57 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >> That pending interrupt will not prevent the machine from going into
> >> suspend and if it's an edge interrupt then an unmask in
> >> suspend_device_irq() won't help. Edge interrupts are not resent in
> >> hardware. They are fire and forget from the POV of the device
> >> hardware.
> >
> > Ah, interesting. I didn't think about this case exactly. I might
> > have a fix for it anyway. At some point in time I was thinking that
> > the world could be solved by relying on lazily-disabled interrupts and
> > I wrote up a patch to make sure that they woke things up. If you're
> > willing to check out our gerrit you can look at:
> >
> > https://crrev.com/c/2314693
> >
> > ...if not I can post it as a RFC for you.
>
> I actually tried despite my usual aversion against web
> interfaces. Aversion confirmed :)
>
> You could have included the 5 lines of patch into your reply to spare me
> the experience. :)
Sorry! :( Inline patches are a bit of a pain for me since I'm
certifiably insane and use the gmail web interface for kernel mailing
lists. Everyone has their pet aversions, I guess. ;-)
> > I'm sure I've solved the problem in a completely incorrect and broken
> > way, but hopefully the idea makes sense. In discussion we decided not
> > to go this way because it looked like IRQ clients could request an IRQ
> > with IRQ_DISABLE_UNLAZY and then that'd break us. :( ...but even so I
> > think the patch is roughly right and would address your point #1.
>
> Kinda :) But that's still incomplete because it does not handle the case
> where the interrupt arrives between disable_irq() and enable_irq_wake().
> See below.
Huh, I thought I'd handled this with the code in irq_set_irq_wake()
which checked if it was pending and did a wakeup. In any case, I
trust your understanding of this code far better than I trust mine.
How should we proceed then? Do you want to post up an official patch?
At the moment I don't have any test cases that need your patch since
the interrupts I'm dealing with are not lazily disabled. However, I
still do agree that it's the right thing to do.
> >> 2) irq chip has a irq_disable() callback or has IRQ_DISABLE_UNLAZY set
> >>
> >> In that case disable_irq() will mask it at the hardware level and it
> >> stays that way until enable_irq() is invoked.
> >>
> >> #1 kinda works and the gap is reasonably trivial to fix in
> >> suspend_device_irq() by checking the pending state and telling the PM
> >> core that there is a wakeup pending.
> >>
> >> #2 Needs an indication from the chip flags that an interrupt which is
> >> masked has to be unmasked when it is a enabled wakeup source.
> >>
> >> I assume your problem is #2, right? If it's #1 then UNMASK_IF_WAKEUP is
> >> the wrong answer.
> >
> > Right, the problem is #2. We're not in the lazy mode.
>
> Right and that's where we want the new chip flag with the unmask if
> armed.
OK, so we're back in Maulik's court to spin, right? I think the last
word before our tangent was at:
http://lore.kernel.org/r/87y2m1vhkm.fsf@nanos.tec.linutronix.de
There you were leaning towards #2 ("a new function
disable_wakeup_irq_for_suspend()"). Presumably you'd now be
suggesting #1 ("Do the symmetric thing") since I've pointed out the
bunch of drivers that would need to change.
-Doug
next prev parent reply other threads:[~2020-09-08 19:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-22 16:16 [PATCH v5 0/6] irqchip: qcom: pdc: Introduce irq_set_wake call Maulik Shah
2020-08-22 16:16 ` [PATCH v5 1/6] pinctrl: qcom: Set IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags Maulik Shah
2020-08-31 18:33 ` Bjorn Andersson
2020-08-22 16:16 ` [PATCH v5 2/6] pinctrl: qcom: Use return value from irq_set_wake() call Maulik Shah
2020-08-31 18:19 ` Bjorn Andersson
2020-08-22 16:16 ` [PATCH v5 3/6] genirq/PM: Introduce IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag Maulik Shah
2020-08-25 10:12 ` Stephen Boyd
2020-08-25 21:38 ` Thomas Gleixner
2020-08-26 9:52 ` Maulik Shah
2020-08-26 10:15 ` Thomas Gleixner
2020-08-31 15:12 ` Doug Anderson
2020-09-01 9:51 ` Thomas Gleixner
2020-09-02 20:26 ` Doug Anderson
2020-09-03 12:57 ` Thomas Gleixner
2020-09-03 23:19 ` Doug Anderson
2020-09-04 9:54 ` Thomas Gleixner
2020-09-08 19:05 ` Doug Anderson [this message]
2020-09-10 8:51 ` Thomas Gleixner
2020-08-22 16:16 ` [PATCH v5 4/6] pinctrl: qcom: Set " Maulik Shah
2020-08-25 10:14 ` Stephen Boyd
2020-08-25 19:58 ` Doug Anderson
2020-08-22 16:17 ` [PATCH v5 5/6] irqchip: qcom-pdc: " Maulik Shah
2020-08-25 10:14 ` Stephen Boyd
2020-08-25 19:59 ` Doug Anderson
2020-08-22 16:17 ` [PATCH v5 6/6] irqchip: qcom-pdc: Reset PDC interrupts during init Maulik Shah
2020-08-25 10:14 ` Stephen Boyd
2020-08-25 20:00 ` Doug Anderson
2020-08-27 22:48 ` [PATCH v5 0/6] irqchip: qcom: pdc: Introduce irq_set_wake call Linus Walleij
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='CAD=FV=X0wjOYC9u1y=fhDTVSW+jd5G8ydSYJEE-a8BTfnhRgTA@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=evgreen@chromium.org \
--cc=ilina@codeaurora.org \
--cc=jason@lakedaemon.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsrao@codeaurora.org \
--cc=maz@kernel.org \
--cc=mka@chromium.org \
--cc=mkshah@codeaurora.org \
--cc=rafael@kernel.org \
--cc=rnayak@codeaurora.org \
--cc=swboyd@chromium.org \
--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;
as well as URLs for NNTP newsgroup(s).