linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Linux PM <linux-pm@vger.kernel.org>,
	Dmitry Osipenko <digetx@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Stephan Gerhold <stephan@gerhold.net>,
	Roja Rani Yarubandi <rojay@codeaurora.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] PM: domains: Drop/restore performance state votes for devices at runtime PM
Date: Wed, 9 Jun 2021 14:25:21 +0200	[thread overview]
Message-ID: <CAPDyKFrQWUWsuEn6NfT5zjXbSDArgmceW=JpKNwwH2Rm19=iXw@mail.gmail.com> (raw)
In-Reply-To: <20210607044738.3aec6o4imq6u3x6e@vireshk-i7>

On Mon, 7 Jun 2021 at 06:47, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 04-06-21, 09:45, Ulf Hansson wrote:
> > Starting calls from the subsystem/driver:
> >
> > ------
> > dev_pm_genpd_set_performance_state(dev, 100);
> > "run a use case with device runtime resumed"
> > ...
> > "use case ends"
> > dev_pm_genpd_set_performance_state(dev, 0);
> > pm_runtime_put()
> >     ->genpd_runtime_suspend()
> >     gpd_data->performance_state == 0, -> gpd_data->rpm_pstate = 0;
> > ...
> > "new use case start"
> > dev_pm_genpd_set_performance_state(dev, 100);
> > pm_runtime_get_sync()
> >     ->genpd_runtime_resume()
> >     gpd_data->performance_state == 100, -> gpd_data->rpm_pstate = 0;
> > (This is where we need to check for "zero" to not override the value)
> > .....
> > ------
> >
> > I wouldn't say that the above is the way how I see the calls to
> > dev_pm_genpd_set_performance_state (or actually
> > dev_pm_opp_set_rate|opp()) being deployed. The calls should rather be
> > done from the subsystem/driver's ->runtime_suspend|resume() callback,
> > then the path above would work in the way you suggest.
> >
> > Although, as we currently treat performance states and power states in
> > genpd orthogonally, I wanted to make sure we could cope with both
> > situations.
>
> I think letting the drivers to call
> dev_pm_genpd_set_performance_state(dev, 0) from suspend/resume makes
> it really ugly/racy as both depend on the gpd_data->performance_state
> for this. It doesn't look nice. And we shouldn't try to protect such
> drivers.
>
> Anyway, your call :)

Well, I am not sure we have an option at this point. As long as we
allow performance states to be managed orthogonally to on/off states
in genpd, the check in genpd_restore_performance_state() is needed.

I have started to prepare a new version of the series - and will add a
comment about this in the code to try to clarify this.

[...]

Kind regards
Uffe

  reply	other threads:[~2021-06-09 12:26 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 [this message]
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 ` [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

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='CAPDyKFrQWUWsuEn6NfT5zjXbSDArgmceW=JpKNwwH2Rm19=iXw@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rnayak@codeaurora.org \
    --cc=rojay@codeaurora.org \
    --cc=sboyd@kernel.org \
    --cc=stephan@gerhold.net \
    --cc=thierry.reding@gmail.com \
    --cc=vincent.guittot@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 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).