From: Stephan Gerhold <stephan@gerhold.net>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Stephan Gerhold <stephan.gerhold@kernkonzept.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Ilia Lin <ilia.lin@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2 2/3] cpufreq: qcom-nvmem: Enable virtual power domain devices
Date: Thu, 19 Oct 2023 19:07:40 +0200 [thread overview]
Message-ID: <ZTFiXJ2XO4WQN_gu@gerhold.net> (raw)
In-Reply-To: <CAPDyKFruYqngQoW21Ra+hm4ybjS7LoD4casYbo8bP4J+hLUnaA@mail.gmail.com>
On Thu, Oct 19, 2023 at 05:19:53PM +0200, Ulf Hansson wrote:
> On Thu, 19 Oct 2023 at 16:49, Stephan Gerhold <stephan@gerhold.net> wrote:
> > On Thu, Oct 19, 2023 at 04:12:56PM +0200, Ulf Hansson wrote:
> > > On Thu, 19 Oct 2023 at 15:05, Stephan Gerhold <stephan@gerhold.net> wrote:
> > > > On Thu, Oct 19, 2023 at 01:26:19PM +0200, Ulf Hansson wrote:
> > > > > BTW, if you really need something like the above, the proper way to do
> > > > > it would instead be to call device_set_awake_path() for the device.
> > > > >
> > > > > This informs genpd that the device needs to stay powered-on during
> > > > > system suspend (assuming that GENPD_FLAG_ACTIVE_WAKEUP has been set
> > > > > for it), hence it will keep the corresponding PM domain powered-on
> > > > > too.
> > > >
> > > > Thanks, I can try if this works as alternative to the
> > > > dev_pm_syscore_device()!
> > >
> > > Yes, please. We don't want to abuse the dev_pm_syscore_device() thingy.
> >
> > Could you clarify the idea behind GENPD_FLAG_ACTIVE_WAKEUP? Would I set
> > it conditionally for all RPMPDs or just the ones consumed by the CPU?
> > How does the genpd *provider* know if one of its *consumer* devices
> > needs to have its power domain kept on for wakeup?
>
> We are thinking of the GENPD_FLAG_ACTIVE_WAKEUP as a platform
> configuration type of flag for the genpd in question. The consumer
> driver shouldn't need to know about the details of what is happening
> on the PM domain level - only whether it needs its device to remain
> powered-on during system suspend or not.
>
Thanks! I will test if this works for RPMPD and post new versions of the
patches. By coincidence I think this flag might actually be useful as
temporary solution for CPR. If I:
1. Change $subject patch to use device_set_awake_path() instead, and
2. Set GENPD_FLAG_ACTIVE_WAKEUP for the RPMPD genpds, but
3. Do *not* set GENPD_FLAG_ACTIVE_WAKEUP for the CPR genpd.
Then the genpd ->power_on|off() callbacks should still be called
for CPR during system suspend, right? :D
> I suspect that the GENPD_FLAG_ACTIVE_WAKEUP is probably okay to set
> for most genpds, but there may be some exceptions.
>
Out of curiosity, do you have an example for such an exception where
GENPD_FLAG_ACTIVE_WAKEUP shouldn't be set, aside from workarounds like
I just described?
As you said, the consumer device should just say that it wants to stay
powered for wakeup during suspend. But if its power domains get powered
off, I would expect that to break. How could a genpd driver still
provide power without being powered on? Wouldn't that rather be a low
performance state?
Thanks,
Stephan
next prev parent reply other threads:[~2023-10-19 17:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 8:06 [PATCH v2 0/3] cpufreq: Add basic cpufreq scaling for Qualcomm MSM8909 Stephan Gerhold
2023-10-18 8:06 ` [PATCH v2 1/3] cpufreq: qcom-nvmem: Simplify driver data allocation Stephan Gerhold
2023-10-18 8:45 ` Konrad Dybcio
2023-10-18 8:06 ` [PATCH v2 2/3] cpufreq: qcom-nvmem: Enable virtual power domain devices Stephan Gerhold
2023-10-19 10:24 ` Ulf Hansson
2023-10-19 11:26 ` Ulf Hansson
2023-10-19 13:05 ` Stephan Gerhold
2023-10-19 14:12 ` Ulf Hansson
2023-10-19 14:48 ` Stephan Gerhold
2023-10-19 15:19 ` Ulf Hansson
2023-10-19 17:07 ` Stephan Gerhold [this message]
2023-10-20 10:20 ` Ulf Hansson
2023-10-24 12:03 ` Stephan Gerhold
2023-10-24 12:49 ` Ulf Hansson
2023-10-24 13:07 ` Stephan Gerhold
2023-10-24 16:11 ` Ulf Hansson
2023-10-24 16:25 ` Stephan Gerhold
2023-10-25 10:05 ` Ulf Hansson
2023-11-01 14:56 ` Stephan Gerhold
2023-10-18 8:06 ` [PATCH v2 3/3] cpufreq: qcom-nvmem: Add MSM8909 Stephan Gerhold
2023-10-18 8:42 ` Konrad Dybcio
2023-10-19 10:50 ` Ulf Hansson
2023-10-19 6:16 ` [PATCH v2 0/3] cpufreq: Add basic cpufreq scaling for Qualcomm MSM8909 Viresh Kumar
2023-10-19 10:19 ` Ulf Hansson
2023-10-19 10:21 ` Viresh Kumar
2023-10-19 10:23 ` Viresh Kumar
2023-10-19 13:48 ` Stephan Gerhold
2023-10-20 3:21 ` Viresh Kumar
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=ZTFiXJ2XO4WQN_gu@gerhold.net \
--to=stephan@gerhold.net \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ilia.lin@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=stable@vger.kernel.org \
--cc=stephan.gerhold@kernkonzept.com \
--cc=ulf.hansson@linaro.org \
--cc=viresh.kumar@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.