From: Stephan Gerhold <firstname.lastname@example.org>
To: Ulf Hansson <email@example.com>
Cc: "Rafael J . Wysocki" <firstname.lastname@example.org>,
Viresh Kumar <email@example.com>,
firstname.lastname@example.org, Dmitry Osipenko <email@example.com>,
Jonathan Hunter <firstname.lastname@example.org>,
Thierry Reding <email@example.com>,
Rajendra Nayak <firstname.lastname@example.org>,
Roja Rani Yarubandi <email@example.com>,
Bjorn Andersson <firstname.lastname@example.org>,
Vincent Guittot <email@example.com>,
Stephen Boyd <firstname.lastname@example.org>,
Subject: Re: [PATCH v2 0/4] PM: domains: Avoid boilerplate code for DVFS in subsystem/drivers
Date: Thu, 3 Jun 2021 13:12:55 +0200 [thread overview]
Message-ID: <YLi5N06Qs+gYHgYg@gerhold.net> (raw)
On Thu, Jun 03, 2021 at 11:34:34AM +0200, Ulf Hansson wrote:
> Various discussions on LKML have pointed out that many subsystem/drivers for
> devices that may be attached to a genpd and which manages DVFS/OPP though the
> genpd performance states, would need very similar updates.
> More precisely, they would likely have to call dev_pm_opp_set_rate|opp() to
> drop and restore OPPs (which propagates upwards into performance states votes
> in genpd), every time their devices should enter/exit a low power state, via
> their device PM callbacks.
> Rather than having to add the boilerplate code for these things into the
> subsystems/drivers, this series implements the logic internally into genpd.
> Concerns have been raised about this approach, mostly by myself, around that it
> limits flexibility. On the other hand, it starts to look like more and more
> people are requesting this to be manged internally in genpd, for good reasons.
> So, I think it's worth to give this a try.
> In the long run, if it turns out that the flexibility was indeed needed, we can
> always deal with that as special cases on top.
Do I understand your patch set correctly that you basically make the
performance state votes conditional to the "power-on" vote of the device
(which is automatically toggled during runtime/system PM)?
If yes, I think that's a good thing. It was always really confusing to me
that a device can make performance state votes if it doesn't actually
want the power domain to be powered on.
What happens if a driver calls dev_pm_genpd_set_performance_state(...)
while the device is suspended? Will that mess up the performance state
when the device resumes?
I think this might also go into the direction of my problem with the OPP
core for CPU DVFS  since the OPP core currently does not "power-on"
the power domains, it just sets a performance state. I got kind of stuck
with all the complexity of power domains in Linux so I think we never
next prev parent reply other threads:[~2021-06-03 11:13 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
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 ` Stephan Gerhold [this message]
2021-06-03 15:27 ` [PATCH v2 0/4] PM: domains: Avoid boilerplate code for DVFS in subsystem/drivers 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).