From: Ulf Hansson <ulf.hansson@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
Stephen Boyd <sboyd@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-pm@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
Stephan Gerhold <stephan.gerhold@kernkonzept.com>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] OPP: Call dev_pm_opp_set_opp() for required OPPs
Date: Wed, 25 Oct 2023 15:51:44 +0200 [thread overview]
Message-ID: <CAPDyKFrxFmNZpNdwQs3CS0NzmDjtCaNSQWkT=zW1Tm+MommWkA@mail.gmail.com> (raw)
In-Reply-To: <6de4fcb5bb943a131d0cdf0a858bd35af02a2f88.1697710527.git.viresh.kumar@linaro.org>
On Thu, 19 Oct 2023 at 12:22, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> Configuring the required OPP was never properly implemented, we just
> took an exception for genpds and configured them directly, while leaving
> out all other required OPP types.
>
> Now that a standard call to dev_pm_opp_set_opp() takes care of
> configuring the opp->level too, the special handling for genpds can be
> avoided by simply calling dev_pm_opp_set_opp() for the required OPPs,
> which shall eventually configure the corresponding level for genpds.
>
> This also makes it possible for us to configure other type of required
> OPPs (no concrete users yet though), via the same path. This is how
> other frameworks take care of parent nodes, like clock, regulators, etc,
> where we recursively call the same helper.
>
> In order to call dev_pm_opp_set_opp() for the virtual genpd devices,
> they must share the OPP table of the genpd. Call _add_opp_dev() for them
> to get that done.
>
> This commit also extends the struct dev_pm_opp_config to pass required
> devices, for non-genpd cases, which can be used to call
> dev_pm_opp_set_opp() for the non-genpd required devices.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/opp/core.c | 144 ++++++++++++++++++-----------------------
> drivers/opp/of.c | 12 ++--
> drivers/opp/opp.h | 8 +--
> include/linux/pm_opp.h | 7 +-
> 4 files changed, 76 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index aab8c8e79146..056b51abc501 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
[...]
> -static int _opp_set_required_opps_genpd(struct device *dev,
> - struct opp_table *opp_table, struct dev_pm_opp *opp, bool scaling_down)
> +/* This is only called for PM domain for now */
> +static int _set_required_opps(struct device *dev, struct opp_table *opp_table,
> + struct dev_pm_opp *opp, bool up)
> {
> - struct device **genpd_virt_devs = opp_table->genpd_virt_devs;
> + struct device **devs = opp_table->required_devs;
> int index, target, delta, ret;
>
> - if (!genpd_virt_devs)
> - return 0;
Rather than continue the path below, wouldn't it be better to return 0
"if (!devs)" here?
If I understand correctly, the code below does manage this condition,
so it's not strictly needed though.
> + /* required-opps not fully initialized yet */
> + if (lazy_linking_pending(opp_table))
> + return -EBUSY;
>
> /* Scaling up? Set required OPPs in normal order, else reverse */
> - if (!scaling_down) {
> + if (up) {
> index = 0;
> target = opp_table->required_opp_count;
> delta = 1;
> @@ -1092,9 +1069,11 @@ static int _opp_set_required_opps_genpd(struct device *dev,
> }
>
> while (index != target) {
> - ret = _set_performance_state(dev, genpd_virt_devs[index], opp, index);
> - if (ret)
> - return ret;
> + if (devs[index]) {
> + ret = dev_pm_opp_set_opp(devs[index], opp);
> + if (ret)
> + return ret;
> + }
>
> index += delta;
> }
[...]
>
> /*
> @@ -2429,15 +2374,10 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev,
> int index = 0, ret = -EINVAL;
> const char * const *name = names;
>
> - if (opp_table->genpd_virt_devs)
> + /* Checking only the first one is enough ? */
> + if (opp_table->required_devs[0])
The allocation of opp_table->required_devs is being done from
_opp_table_alloc_required_tables(), which doesn't necessarily
allocate/assign the data for it.
Maybe check "opp_table->required_devs" instead, to make that clear?
> return 0;
>
> - opp_table->genpd_virt_devs = kcalloc(opp_table->required_opp_count,
> - sizeof(*opp_table->genpd_virt_devs),
> - GFP_KERNEL);
> - if (!opp_table->genpd_virt_devs)
> - return -ENOMEM;
> -
> while (*name) {
> if (index >= opp_table->required_opp_count) {
> dev_err(dev, "Index can't be greater than required-opp-count - 1, %s (%d : %d)\n",
> @@ -2452,13 +2392,25 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev,
> goto err;
> }
>
> - opp_table->genpd_virt_devs[index] = virt_dev;
> + /*
> + * Add the virtual genpd device as a user of the OPP table, so
> + * we can call dev_pm_opp_set_opp() on it directly.
> + *
> + * This will be automatically removed when the OPP table is
> + * removed, don't need to handle that here.
> + */
> + if (!_add_opp_dev(virt_dev, opp_table->required_opp_tables[index])) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + opp_table->required_devs[index] = virt_dev;
> index++;
> name++;
> }
>
> if (virt_devs)
> - *virt_devs = opp_table->genpd_virt_devs;
> + *virt_devs = opp_table->required_devs;
>
> return 0;
>
> @@ -2468,10 +2420,34 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev,
>
> }
>
> +static void _opp_set_required_devs(struct opp_table *opp_table,
> + struct device **required_devs)
> +{
> + int i;
> +
> + /* Another CPU that shares the OPP table has set the required devs ? */
Not sure I fully understand the above comment. Is this the only
relevant use-case or could there be others too?
> + if (opp_table->required_devs[0])
Maybe check opp_table->required_devs instead?
> + return;
> +
> + for (i = 0; i < opp_table->required_opp_count; i++)
> + opp_table->required_devs[i] = required_devs[i];
To be safe, don't we need to check the in-parameter required_devs?
Or we should simply rely on the callers of dev_pm_opp_set_config() to
do the right thing?
[...]
Besides the minor things above, this looks really great to me! Feel free to add:
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
next prev parent reply other threads:[~2023-10-25 13:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 10:21 [RFT PATCH 0/2] OPP: Simplify required-opp handling Viresh Kumar
2023-10-19 10:22 ` [PATCH 1/2] OPP: Use _set_opp_level() for single genpd case Viresh Kumar
2023-10-19 11:16 ` Ulf Hansson
2023-10-20 3:45 ` Viresh Kumar
2023-10-20 10:02 ` Ulf Hansson
2023-10-20 10:56 ` Viresh Kumar
2023-10-20 11:09 ` Ulf Hansson
2023-10-25 6:54 ` Viresh Kumar
2023-10-25 10:40 ` Ulf Hansson
2023-10-25 10:48 ` Viresh Kumar
2023-10-25 13:47 ` Stephan Gerhold
2023-10-25 15:24 ` Viresh Kumar
2023-10-25 16:16 ` Stephan Gerhold
2023-10-26 9:53 ` Ulf Hansson
2023-10-30 10:29 ` Viresh Kumar
2023-11-03 11:58 ` Ulf Hansson
2023-11-06 7:08 ` Viresh Kumar
2023-11-10 13:50 ` Ulf Hansson
2023-11-15 5:32 ` Viresh Kumar
2023-11-16 10:44 ` Viresh Kumar
2023-10-19 10:22 ` [PATCH 2/2] OPP: Call dev_pm_opp_set_opp() for required OPPs Viresh Kumar
2023-10-24 11:18 ` Stephan Gerhold
2023-10-25 7:36 ` Viresh Kumar
2023-10-25 12:17 ` Stephan Gerhold
2023-10-25 15:20 ` Viresh Kumar
2023-10-25 16:03 ` Ulf Hansson
2023-10-26 7:44 ` Viresh Kumar
2023-10-25 13:51 ` Ulf Hansson [this message]
2023-10-25 15:09 ` Viresh Kumar
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='CAPDyKFrxFmNZpNdwQs3CS0NzmDjtCaNSQWkT=zW1Tm+MommWkA@mail.gmail.com' \
--to=ulf.hansson@linaro.org \
--cc=konrad.dybcio@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=nm@ti.com \
--cc=rafael@kernel.org \
--cc=sboyd@kernel.org \
--cc=stephan.gerhold@kernkonzept.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vireshk@kernel.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).