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: 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

  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).