From: Dmitry Osipenko <digetx@gmail.com> To: Ulf Hansson <ulf.hansson@linaro.org> 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 13:06:27 +0300 [thread overview] Message-ID: <1124dae5-478f-f0ca-ea91-b6945f7c9254@gmail.com> (raw) In-Reply-To: <CAPDyKFr2oQnKOhKhWt_9VyBoe=HQ7Y0uZUMKTcZ05a7G9RaBYA@mail.gmail.com> 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? >> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com> To: Ulf Hansson <ulf.hansson@linaro.org> 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 13:06:27 +0300 [thread overview] Message-ID: <1124dae5-478f-f0ca-ea91-b6945f7c9254@gmail.com> (raw) In-Reply-To: <CAPDyKFr2oQnKOhKhWt_9VyBoe=HQ7Y0uZUMKTcZ05a7G9RaBYA@mail.gmail.com> 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? >> 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-03 10:06 UTC|newest] Thread overview: 58+ 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 ` 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-02 10:16 ` Ulf Hansson 2021-09-03 6:01 ` Dmitry Osipenko 2021-09-03 6:01 ` Dmitry Osipenko 2021-09-03 8:22 ` Ulf Hansson 2021-09-03 8:22 ` Ulf Hansson 2021-09-03 9:58 ` Dmitry Osipenko 2021-09-03 9:58 ` Dmitry Osipenko 2021-09-03 14:03 ` Ulf Hansson 2021-09-03 14:03 ` Ulf Hansson 2021-09-05 8:26 ` Dmitry Osipenko 2021-09-05 8:26 ` Dmitry Osipenko 2021-09-06 10:24 ` Ulf Hansson 2021-09-06 10:24 ` Ulf Hansson 2021-09-06 14:11 ` Dmitry Osipenko 2021-09-06 14:11 ` Dmitry Osipenko 2021-09-06 17:34 ` Ulf Hansson 2021-09-06 17:34 ` Ulf Hansson 2021-09-06 19:33 ` Dmitry Osipenko 2021-09-06 19:33 ` Dmitry Osipenko 2021-09-07 10:16 ` Ulf Hansson 2021-09-07 10:16 ` Ulf Hansson 2021-09-09 13:48 ` Dmitry Osipenko 2021-09-09 13:48 ` Dmitry Osipenko 2021-09-09 14:45 ` Ulf Hansson 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 ` 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-02 10:16 ` Ulf Hansson 2021-09-03 6:00 ` Dmitry Osipenko 2021-09-03 6:00 ` Dmitry Osipenko 2021-09-03 8:55 ` Ulf Hansson 2021-09-03 8:55 ` Ulf Hansson 2021-09-03 10:06 ` Dmitry Osipenko [this message] 2021-09-03 10:06 ` Dmitry Osipenko 2021-09-03 14:09 ` Ulf Hansson 2021-09-03 14:09 ` Ulf Hansson 2021-09-05 9:11 ` Dmitry Osipenko 2021-09-05 9:11 ` Dmitry Osipenko 2021-09-06 10:53 ` Ulf Hansson 2021-09-06 10:53 ` Ulf Hansson 2021-09-06 14:35 ` Dmitry Osipenko 2021-09-06 14:35 ` Dmitry Osipenko 2021-09-07 3:40 ` Viresh Kumar 2021-09-07 3:40 ` Viresh Kumar 2021-09-07 8:10 ` Dmitry Osipenko 2021-09-07 8:10 ` Dmitry Osipenko 2021-09-07 9:57 ` Ulf Hansson 2021-09-07 9:57 ` Ulf Hansson 2021-09-09 13:48 ` Dmitry Osipenko 2021-09-09 13:48 ` Dmitry Osipenko 2021-09-09 14:39 ` Ulf Hansson 2021-09-09 14:39 ` Ulf Hansson 2021-09-10 11:24 ` Dmitry Osipenko 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=1124dae5-478f-f0ca-ea91-b6945f7c9254@gmail.com \ --to=digetx@gmail.com \ --cc=bjorn.andersson@linaro.org \ --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=ulf.hansson@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.