[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <158769585826.135303.15159589318457908652@swboyd.mtv.corp.google.com>
Date: Thu, 23 Apr 2020 19:37:38 -0700
From: Stephen Boyd <swboyd@...omium.org>
To: Maulik Shah <mkshah@...eaurora.org>, bjorn.andersson@...aro.org,
evgreen@...omium.org, mka@...omium.org
Cc: linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
agross@...nel.org, linus.walleij@...aro.org, tglx@...utronix.de,
maz@...nel.org, jason@...edaemon.net, dianders@...omium.org,
rnayak@...eaurora.org, ilina@...eaurora.org, lsrao@...eaurora.org
Subject: Re: [RFC v3] irqchip: qcom: pdc: Introduce irq_set_wake call
Quoting Maulik Shah (2020-04-22 05:14:21)
>
> We discussed this in RFC v2, pasting your reply from same.
>
>> That looks like a bug. It appears that gpiolib is only hooking the irq
>> disable path here so that it can keep track of what irqs are not in use
>> by gpiolib and allow them to be used for GPIO purposes when the irqs are
>> disabled. See commit 461c1a7d4733 ("gpiolib: override
>> irq_enable/disable"). That code in gpiolib should probably see if lazy
>> mode has been disabled on the irq and do similar things to what genirq
>> does and then let genirq mask the gpios if they trigger during the time
>> when the irq is disabled. Regardless of this design though, I don't
>> understand why this matters.
Yeah. I'm saying that the gpiolib code that forces all gpio irqs to be
non-lazy is broken. Please send a patch to fix gpiolib so that irqs can
be lazy again. I thought it didn't matter before but now that I've
learned more it sounds like we have to use lazy irqs here so that irqs
stay enabled on the path to suspend while they're disabled but marked
for wakeup. Otherwise I don't know how to make this work.
Powered by blists - more mailing lists