From: Dmitry Osipenko <digetx@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
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, 10 Sep 2021 14:24:38 +0300 [thread overview]
Message-ID: <8dadc395-e7f4-9dcc-b484-60c119063007@gmail.com> (raw)
In-Reply-To: <CAPDyKFoFCVcjrGXQ56y0iSNPhE8-orpZiHvnAQTQW1b8oW4f5A@mail.gmail.com>
09.09.2021 17:39, Ulf Hansson пишет:
> On Thu, 9 Sept 2021 at 15:48, Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 07.09.2021 12:57, Ulf Hansson пишет:
>>> I don't mind extending the genpd API, but it needs to serve a good purpose.
>>>
>>> As I said earlier, genpd doesn't know nor can control how the consumer
>>> driver deploys runtime PM. Unfortunately, that also includes genpd
>>> providers, as the behavior isn't a platform or PM domain specific
>>> thing. This means genpd needs to be generic enough so it works for all
>>> cases.
>>>
>>> In the $subject patch, we rely on the pm_runtime_suspended() check in
>>> dev_pm_genpd_set_performance_state(), which should work for all cases,
>>> even if it may be sub-optimal for some scenarios.
>>>
>>> Note that, in the approach your suggested [1],
>>> pm_runtime_status_suspended() is used instead. This doesn't work when
>>> a consumer driver doesn't enable runtime PM - or calls
>>> pm_runtime_set_active() during ->probe(), because
>>> genpd_runtime_resume() won't be invoked to restore the gpd->rpm_state.
>>>
>>> That said, I wouldn't mind to simply skip adding the
>>> ->dev_get_performance_state() all together, if that is what you
>>> prefer? In this way, it becomes the responsibility for the consumer
>>> driver to do right thing, with the cost of some boilerplate code added
>>> in its ->probe() routine.
>>
>> Until a day ago, it wasn't clear to me that consumer drivers now can set
>> up rpm_pstate during probe(), which is a cleaner solution that works
>> well. So let's skip adding the questionable ->dev_get_performance_state().
>>
>> The boilerplate code in the probe() is minimal in comparison to a
>> previous variant with the state-syncing done by rpm-resume callbacks of
>> consumer drivers, it's good enough.
>
> Alright, that sounds good to me as well.
>
> I am happy to help with review of the consumer driver changes, just
> keep me posted.
Thank you and Viresh for the help, very appreciate it!
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
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, 10 Sep 2021 14:24:38 +0300 [thread overview]
Message-ID: <8dadc395-e7f4-9dcc-b484-60c119063007@gmail.com> (raw)
In-Reply-To: <CAPDyKFoFCVcjrGXQ56y0iSNPhE8-orpZiHvnAQTQW1b8oW4f5A@mail.gmail.com>
09.09.2021 17:39, Ulf Hansson пишет:
> On Thu, 9 Sept 2021 at 15:48, Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 07.09.2021 12:57, Ulf Hansson пишет:
>>> I don't mind extending the genpd API, but it needs to serve a good purpose.
>>>
>>> As I said earlier, genpd doesn't know nor can control how the consumer
>>> driver deploys runtime PM. Unfortunately, that also includes genpd
>>> providers, as the behavior isn't a platform or PM domain specific
>>> thing. This means genpd needs to be generic enough so it works for all
>>> cases.
>>>
>>> In the $subject patch, we rely on the pm_runtime_suspended() check in
>>> dev_pm_genpd_set_performance_state(), which should work for all cases,
>>> even if it may be sub-optimal for some scenarios.
>>>
>>> Note that, in the approach your suggested [1],
>>> pm_runtime_status_suspended() is used instead. This doesn't work when
>>> a consumer driver doesn't enable runtime PM - or calls
>>> pm_runtime_set_active() during ->probe(), because
>>> genpd_runtime_resume() won't be invoked to restore the gpd->rpm_state.
>>>
>>> That said, I wouldn't mind to simply skip adding the
>>> ->dev_get_performance_state() all together, if that is what you
>>> prefer? In this way, it becomes the responsibility for the consumer
>>> driver to do right thing, with the cost of some boilerplate code added
>>> in its ->probe() routine.
>>
>> Until a day ago, it wasn't clear to me that consumer drivers now can set
>> up rpm_pstate during probe(), which is a cleaner solution that works
>> well. So let's skip adding the questionable ->dev_get_performance_state().
>>
>> The boilerplate code in the probe() is minimal in comparison to a
>> previous variant with the state-syncing done by rpm-resume callbacks of
>> consumer drivers, it's good enough.
>
> Alright, that sounds good to me as well.
>
> I am happy to help with review of the consumer driver changes, just
> keep me posted.
Thank you and Viresh for the help, very appreciate it!
_______________________________________________
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-10 11:24 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
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 [this message]
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=8dadc395-e7f4-9dcc-b484-60c119063007@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: link
Be 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.