archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <>
To: Stephan Gerhold <>
Cc: Ulf Hansson <>,
	"Rafael J. Wysocki" <>,
	Kevin Hilman <>, Nishanth Menon <>,
	Stephen Boyd <>,
	Linux PM <>,
	Linux Kernel Mailing List <>,
	Niklas Cassel <>
Subject: Re: [RFC PATCH 3/3] opp: Power on (virtual) power domains managed by the OPP core
Date: Tue, 25 Aug 2020 10:13:08 +0530	[thread overview]
Message-ID: <20200825044308.4y3w2urcikban7if@vireshk-i7> (raw)
In-Reply-To: <>

On 24-08-20, 17:08, Stephan Gerhold wrote:
> On Mon, Aug 24, 2020 at 04:36:57PM +0200, Ulf Hansson wrote:
> > That said, perhaps should rely on the consumer to deploy runtime PM
> > support, but let the OPP core to set up the device links for the genpd
> > virtual devices!?
> > 
> Yes, that would be the alternative option.

That is the right option IMO.

> I would be fine with it as long as it also works for the CPUfreq case.
> I don't think anything manages runtime PM for the CPU device, just
> like no-one calls dev_pm_opp_set_rate(cpu_dev, 0). So with my patch the
> power domain is essentially kept always-on (except for system suspend).
> At least in my case this is intended.
> If device links also keep the power domains on if the consumer device
> does not make use of runtime PM it should work fine for my case.

With device link, you only need to do rpm enable/disable on the consumer device
and it will get propagated by itself.

> Personally, I think my original patch (without device links) fits better
> into the OPP API, for the following two reasons.
> With device links:
>   1. Unlike regulators/interconnects, attached power domains would be
>      controlled by runtime PM instead of dev_pm_opp_set_rate(opp_dev, 0).
>   2. ... some driver using OPP tables might not make use of runtime PM.
>      In that case, the power domains would stay on the whole time,
>      even if dev_pm_opp_set_rate(opp_dev, 0) was called.
> With my patch, the power domain state is directly related to the
> dev_pm_opp_set_rate(opp_dev, 0) call, which is more intuitive than
> relying on the runtime PM state in my opinion.

So opp-set-rate isn't in the best of shape TBH, some things are left for the
drivers while other are done by it. Regulator-enable/disable was moved to it
some time back as people needed something like that. While on the other hand,
clk_enable/disable doesn't happen there, nor does rpm enable/disable.

Maybe one day we may want to do that, but lets make sure someone wants to do
that first.

Anyway, even in that case both of the changes would be required. We must make
device links nevertheless first. And later on if required, we may want to do rpm
enable/disable on the consumer device itself.


  reply	other threads:[~2020-08-25  4:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30  8:01 [RFC PATCH 0/3] opp: required_opps: Power on genpd, scale down in reverse order Stephan Gerhold
2020-07-30  8:01 ` [RFC PATCH 1/3] opp: Reduce code duplication in _set_required_opps() Stephan Gerhold
2020-08-24 11:18   ` Viresh Kumar
2020-08-24 11:30     ` Stephan Gerhold
2020-08-24 12:10       ` Viresh Kumar
2020-08-24 12:23         ` Stephan Gerhold
2020-07-30  8:01 ` [RFC PATCH 2/3] opp: Set required OPPs in reverse order when scaling down Stephan Gerhold
2020-08-21 16:31   ` Stephan Gerhold
2020-08-24 11:30     ` Viresh Kumar
2020-08-24 11:42       ` Stephan Gerhold
2020-07-30  8:01 ` [RFC PATCH 3/3] opp: Power on (virtual) power domains managed by the OPP core Stephan Gerhold
2020-08-24 11:27   ` Viresh Kumar
2020-08-24 11:55     ` Stephan Gerhold
2020-08-24 14:36       ` Ulf Hansson
2020-08-24 15:08         ` Stephan Gerhold
2020-08-25  4:43           ` Viresh Kumar [this message]
2020-08-25  6:43             ` Ulf Hansson
2020-08-25  7:33               ` Stephan Gerhold
2020-08-25 12:42                 ` Ulf Hansson
2020-08-26  8:31                   ` Stephan Gerhold
2020-08-12  8:53 ` [RFC PATCH 0/3] opp: required_opps: Power on genpd, scale down in reverse order Ulf Hansson

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200825044308.4y3w2urcikban7if@vireshk-i7 \ \ \ \ \ \ \ \ \ \ \

* 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).