From: Ulf Hansson <ulf.hansson@linaro.org>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>,
Linux PM <linux-pm@vger.kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Thierry Reding <thierry.reding@gmail.com>,
Rajendra Nayak <rnayak@codeaurora.org>,
Stephan Gerhold <stephan@gerhold.net>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] PM: domains: Add a ->dev_get_performance_state() callback to genpd
Date: Fri, 3 Sep 2021 16:09:45 +0200 [thread overview]
Message-ID: <CAPDyKFqE+thX0pLTg9d-ds7Tj3hsB78EmDB1Cryh26tN3kvQDA@mail.gmail.com> (raw)
In-Reply-To: <1124dae5-478f-f0ca-ea91-b6945f7c9254@gmail.com>
On Fri, 3 Sept 2021 at 12:06, Dmitry Osipenko <digetx@gmail.com> wrote:
>
> 03.09.2021 11:55, Ulf Hansson пишет:
> > On Fri, 3 Sept 2021 at 08:00, Dmitry Osipenko <digetx@gmail.com> wrote:
> >>
> >> 02.09.2021 13:16, Ulf Hansson пишет:
> >>> Hardware may be preprogrammed to a specific performance state, which may
> >>> not be zero initially during boot. This may lead to that genpd's current
> >>> performance state becomes inconsistent with the state of the hardware. To
> >>> deal with this, the driver for a device that is being attached to its
> >>> genpd, need to request an initial performance state vote, which is
> >>> typically done by calling some of the OPP APIs while probing.
> >>>
> >>> In some cases this would lead to boilerplate code in the drivers. Let's
> >>> make it possible to avoid this, by adding a new optional callback to genpd
> >>> and invoke it per device during the attach process. In this way, the genpd
> >>> provider driver can inform genpd about the initial performance state that
> >>> is needed for the device.
> >>>
> >>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> >>> ---
> >>> drivers/base/power/domain.c | 8 +++++---
> >>> include/linux/pm_domain.h | 2 ++
> >>> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> >>> index 800adf831cae..1a6f3538af8d 100644
> >>> --- a/drivers/base/power/domain.c
> >>> +++ b/drivers/base/power/domain.c
> >>> @@ -2640,13 +2640,15 @@ static void genpd_dev_pm_sync(struct device *dev)
> >>> genpd_queue_power_off_work(pd);
> >>> }
> >>>
> >>> -static int genpd_get_default_performance_state(struct device *dev,
> >>> +static int genpd_get_default_performance_state(struct generic_pm_domain *genpd,
> >>> + struct device *dev,
> >>> unsigned int index)
> >>> {
> >>> int pstate = of_get_required_opp_performance_state(dev->of_node, index);
> >>>
> >>> if (pstate == -ENODEV || pstate == -EOPNOTSUPP)
> >>> - return 0;
> >>> + pstate = genpd->dev_get_performance_state ?
> >>> + genpd->dev_get_performance_state(genpd, dev) : 0;
> >>>
> >>> return pstate;
> >>> }
> >>> @@ -2701,7 +2703,7 @@ static int __genpd_dev_pm_attach(struct device *dev, struct device *base_dev,
> >>> }
> >>>
> >>> /* Set the default performance state */
> >>> - pstate = genpd_get_default_performance_state(dev, index);
> >>> + pstate = genpd_get_default_performance_state(pd, dev, index);
> >>
> >> If base device is suspended, then its performance state is zero.
> >>
> >> When device will be rpm-resumed, then its performance should be set to
> >> the default state.
> >> You're setting performance state of the wrong device, it should be the
> Are you okay with my variant of handling the suspended device?
Not sure if you intended to post this line?
In any case, I am happy to help and review to move things forward.
>
>
> >> base device and not the virtual domain device.
> >
> > No I am not. :-) Let me elaborate.
> >
> > For the single PM domain case, 'dev' and 'base_dev' are pointing to
> > the same device. So this works fine.
> >
> > For the multiple PM domain case or when attaching goes via
> > genpd_dev_pm_attach_by_id(), 'dev' is the virtual device registered in
> > genpd_dev_pm_attach_by_id(). In this case, it's 'dev' that is becoming
> > attached to genpd and not the 'base_dev'. Note also that, runtime PM
> > has not been enabled for 'dev' yet at this point and 'dev' has been
> > assigned the same OF node as 'base_dev", to allow OF parsing to work
> > as is for it.
> >
> > Moreover, to deal with runtime PM in the multiple PM domain case, the
> > consumer driver should create a device link. Along the lines of this:
> > device_link_add(base_dev, dev, DL_FLAG_PM_RUNTIME |
> > DL_FLAG_STATELESS), thus assigning the virtual device ('dev') as the
> > supplier for its consumer device ('base_dev').
> >
> >>
> >> These all is handled properly by my patch [1]. Hence it's complicated
> >> for the reason.
> >
> > See above. It shouldn't have to be complicated. If it still is, there
> > is something to fix for the multiple PM domain case.
> >> [1]
> Alright, it actually works now on Tegra using the dev in the callback
> for the case of multiple domains, I re-checked it. Previously, when I
> tried that, there was a conflict in regards to OPP usage, I don't
> remember details anymore. Maybe the recent changes that were suggested
> by Viresh helped with that. So yes, there is no need to pass the base
> device anymore.
Great! So, it seems like $subject patch should be a way forward for you then?
BTW, I forgot to add your Suggested-by: tag for the patch, you
certainly deserve at least that. Or perhaps you are fine with
co-developed by tag?
Kind regards
Uffe
next prev parent reply other threads:[~2021-09-03 14:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-02 10:16 [PATCH 0/3] PM: domains: Improvements for performance states in genpd Ulf Hansson
2021-09-02 10:16 ` [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach Ulf Hansson
2021-09-03 6:01 ` Dmitry Osipenko
2021-09-03 8:22 ` Ulf Hansson
2021-09-03 9:58 ` Dmitry Osipenko
2021-09-03 14:03 ` Ulf Hansson
2021-09-05 8:26 ` Dmitry Osipenko
2021-09-06 10:24 ` Ulf Hansson
2021-09-06 14:11 ` Dmitry Osipenko
2021-09-06 17:34 ` Ulf Hansson
2021-09-06 19:33 ` Dmitry Osipenko
2021-09-07 10:16 ` Ulf Hansson
2021-09-09 13:48 ` Dmitry Osipenko
2021-09-09 14:45 ` Ulf Hansson
2021-09-02 10:16 ` [PATCH 2/3] PM: domains: Restructure some code in __genpd_dev_pm_attach() Ulf Hansson
2021-09-02 10:16 ` [PATCH 3/3] PM: domains: Add a ->dev_get_performance_state() callback to genpd Ulf Hansson
2021-09-03 6:00 ` Dmitry Osipenko
2021-09-03 8:55 ` Ulf Hansson
2021-09-03 10:06 ` Dmitry Osipenko
2021-09-03 14:09 ` Ulf Hansson [this message]
2021-09-05 9:11 ` Dmitry Osipenko
2021-09-06 10:53 ` Ulf Hansson
2021-09-06 14:35 ` Dmitry Osipenko
2021-09-07 3:40 ` Viresh Kumar
2021-09-07 8:10 ` Dmitry Osipenko
2021-09-07 9:57 ` Ulf Hansson
2021-09-09 13:48 ` Dmitry Osipenko
2021-09-09 14:39 ` Ulf Hansson
2021-09-10 11:24 ` Dmitry Osipenko
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=CAPDyKFqE+thX0pLTg9d-ds7Tj3hsB78EmDB1Cryh26tN3kvQDA@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=digetx@gmail.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rnayak@codeaurora.org \
--cc=stephan@gerhold.net \
--cc=thierry.reding@gmail.com \
--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).