From: Ulf Hansson <firstname.lastname@example.org>
To: Stephan Gerhold <email@example.com>, Mark Brown <firstname.lastname@example.org>
Cc: "Rafael J . Wysocki" <email@example.com>,
Viresh Kumar <firstname.lastname@example.org>,
Dmitry Baryshkov <email@example.com>,
Linux PM <firstname.lastname@example.org>,
Dmitry Osipenko <email@example.com>,
Jonathan Hunter <firstname.lastname@example.org>,
Thierry Reding <email@example.com>,
Roja Rani Yarubandi <firstname.lastname@example.org>,
Bjorn Andersson <email@example.com>,
Vincent Guittot <firstname.lastname@example.org>,
Stephen Boyd <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Rajendra Nayak <email@example.com>
Subject: Re: [PATCH v2 4/4] PM: domains: Drop/restore performance state votes for devices at system PM
Date: Tue, 8 Jun 2021 16:08:55 +0200 [thread overview]
Message-ID: <CAPDyKFrvrikCZLX1EvmLZumeCnfAxUUssO2OWc130TG8oeyfirstname.lastname@example.org> (raw)
On Tue, 8 Jun 2021 at 14:53, Stephan Gerhold <email@example.com> wrote:
> On Thu, Jun 03, 2021 at 12:20:57PM +0200, Ulf Hansson wrote:
> > + Mark Brown, Dmitry Baryshkov
> > On Thu, 3 Jun 2021 at 11:34, Ulf Hansson <firstname.lastname@example.org> wrote:
> > >
> > > Recent changes in genpd drops and restore performance state votes for
> > > devices during runtime PM.
> > >
> > > For the similar reasons, but to avoid the same kind of boilerplate code in
> > > device PM callbacks for system sleep in subsystems/drivers, let's drop and
> > > restore performance states votes in genpd for the attached devices during
> > > system sleep.
> > >
> > > Signed-off-by: Ulf Hansson <email@example.com>
> > After a second thought, it looks like we maybe should defer to apply
> > this final patch of the series. At least until we figured out how to
> > address the below issue:
> > So, I noticed that we have things like "regulator-fixed-domain", that
> > uses "required-opps" to enable/disable a regulator through the
> > dev_pm_set_performance_state() interface.
> Not directly related to your concern, but related to another discussion
> we had recently: To me, this looks mostly like another solution for
> voting for performance states without doing full DVFS, also known as
> assigned-performance-states  or required-opps on devices . :)
> It's just wrapped in a regulator interface here. Actually, if we
> implement , the regulator-fixed-domain should mostly just become some
> sort of simple wrapper around runtime PM for the regulator device, since
> the required-opp might be applied automatically then.
Honestly, I am not sure about what the regulator-fixed-domain intends
to model, but I assume it's something that fits well to be modelled as
a plain regulator, to start with.
Perhaps Mark can chime in and spread some light over this?
> : https://firstname.lastname@example.org/
> : https://lore.kernel.org/linux-arm-msm/YLYV3ov%2FiBffZMg4@gerhold.net/
> > We likely don't want to drop the performance state internally in genpd
> > when genpd_suspend_noirq() gets called, for the corresponding struct
> > device for the regulator.
> So your concern is that the performance state is dropped during suspend
> even though the regulator core thinks the regulator stays enabled?
> I played with regulator-fixed-domain a bit and I would say this is
> already broken (unless you rely on one of the side effects I mentioned
> in ). The power domain gets powered off entirely during system
> suspend, and then the performance state won't have any effect either.
Right, I get your point.
Although, this isn't a problem, because the on/off and performance
states are today considered as orthogonal in gendp. Well, at least
currently until/if we decide to change this.
> I guess we would need some way to say that this device should only be
> managed through runtime PM and never automatically suspended during
> system suspend?
For the on/off state, genpd uses the system wakeup interface to
understand whether the device is used in a wakeup path, see the call
to device_wakeup_path() in genpd_finish_suspend().
If that's the case the PM domain stays powered on during system suspend.
Potentially we could use the same interface (or something similar) to
support these kinds of cases.
> : https://lore.kernel.org/linux-pm/YLkOAyydZMnxkEyemail@example.com/
next prev parent reply other threads:[~2021-06-08 14:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 9:34 [PATCH v2 0/4] PM: domains: Avoid boilerplate code for DVFS in subsystem/drivers Ulf Hansson
2021-06-03 9:34 ` [PATCH v2 1/4] PM: domains: Split code in dev_pm_genpd_set_performance_state() Ulf Hansson
2021-06-03 9:34 ` [PATCH v2 2/4] PM: domains: Return early if perf state is already set for the device Ulf Hansson
2021-06-03 9:34 ` [PATCH v2 3/4] PM: domains: Drop/restore performance state votes for devices at runtime PM Ulf Hansson
2021-06-03 9:55 ` Viresh Kumar
2021-06-03 10:31 ` Ulf Hansson
2021-06-03 11:17 ` Ulf Hansson
2021-06-04 3:53 ` Viresh Kumar
2021-06-04 7:45 ` Ulf Hansson
2021-06-07 4:47 ` Viresh Kumar
2021-06-09 12:25 ` Ulf Hansson
2021-06-03 19:02 ` Dmitry Osipenko
2021-06-03 19:08 ` Dmitry Osipenko
2021-06-04 7:20 ` Ulf Hansson
2021-06-03 9:34 ` [PATCH v2 4/4] PM: domains: Drop/restore performance state votes for devices at system PM Ulf Hansson
2021-06-03 10:20 ` Ulf Hansson
2021-06-03 11:15 ` Mark Brown
2021-06-03 13:48 ` Ulf Hansson
2021-06-08 12:53 ` Stephan Gerhold
2021-06-08 14:08 ` Ulf Hansson [this message]
2021-06-08 14:20 ` Mark Brown
2021-06-08 14:39 ` Ulf Hansson
2021-06-08 15:37 ` Stephan Gerhold
2021-06-03 11:12 ` [PATCH v2 0/4] PM: domains: Avoid boilerplate code for DVFS in subsystem/drivers Stephan Gerhold
2021-06-03 15:27 ` Ulf Hansson
2021-06-03 17:14 ` Stephan Gerhold
2021-06-04 7:18 ` Ulf Hansson
2021-06-04 8:23 ` Stephan Gerhold
2021-06-04 10:57 ` Ulf Hansson
2021-06-04 11:50 ` Stephan Gerhold
2021-06-11 16:42 ` Rafael J. Wysocki
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).