All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Nicola Mazzucato <nicola.mazzucato@arm.com>
Cc: Lukasz Luba <lukasz.luba@arm.com>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	chris.redpath@arm.com, morten.rasmussen@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Date: Tue, 20 Oct 2020 16:18:49 +0530	[thread overview]
Message-ID: <20201020104849.xh4prj4az5islmpt@vireshk-i7> (raw)
In-Reply-To: <e3b3a583-5e0f-f512-85e6-81c55a0e6db5@arm.com>

On 19-10-20, 14:36, Nicola Mazzucato wrote:
> Hi Viresh,
> 
> 
> On 10/19/20 10:46 AM, Viresh Kumar wrote:
> > On 19-10-20, 09:50, Nicola Mazzucato wrote:
> >> Hi Viresh,
> >>
> >> thank you for your suggestion on using 'opp-shared'.
> >> I think it could work for most of the cases we explained earlier.
> >>
> >> Summarising, there are two parts of this entire proposal:
> >> 1) where/how to get the information: now we are focusing on taking advantage of
> >> 'opp-shared' within an empty opp table
> >> 2) and how/where this information will be consumed
> >>
> >> Further details below:
> >>
> >> 1) a CPUFreq driver that takes the OPPs from firmware, can call
> >> dev_pm_opp_of_get_sharing_cpus like you suggested. When doing so, a provided
> >> cpumaksk will be populated with the corresponding cpus that share the same
> >> (empty) table opp in DT.
> >> All good so far.
> > 
> > Great.
> > 
> >> The current opp core is not expecting an empty table and therefore some errors
> >> are thrown when this happens.
> >> Since we are now allowing this corner-case, I am presenting below where I think
> >> some minor corrections may be needed:
> >>
> >> --- a/drivers/opp/of.c
> >> +++ b/drivers/opp/of.c
> >> @@ static void _opp_table_alloc_required_tables(struct opp_table *opp_table,
> >>         struct device_node *required_np, *np;
> >>         int count, i;
> >>
> >>         /* Traversing the first OPP node is all we need */
> >>         np = of_get_next_available_child(opp_np, NULL);
> >>         if (!np) {
> >> -               dev_err(dev, "Empty OPP table\n");
> >> +               dev_warn(dev, "Empty OPP table\n");
> >> +
> >> +               /*
> >> +                * With empty table we remove shared_opp. This is to leave the
> >> +                * responsibility to decide which opp are shared to the opp users
> >> +                */
> >> +               opp_table->shared_opp = OPP_TABLE_ACCESS_EXCLUSIVE;
> >> +
> >>                 return;
> >>         }
> >>
> >> @@ int dev_pm_opp_of_find_icc_paths(struct device *dev,
> >>         int ret, i, count, num_paths;
> >>         struct icc_path **paths;
> >>
> >>         ret = _bandwidth_supported(dev, opp_table);
> >> -       if (ret <= 0)
> >> +       if (ret == -EINVAL)
> >> +               return 0; /* Empty OPP table is a valid corner-case, let's not
> >> fail */
> >> +       else if (ret <= 0)
> >>                 return ret;
> >>
> >> The above are not 'strictly' necessary to achieve the intended goal, but they
> >> make clearer that an empty table is now allowed and not an error anymore.
> >> What it is your point of view on this?
> > 
> > Why is this stuff getting called in your case ? We shouldn't be trying
> > to create an OPP table here and it should still be an error in the
> > code if we are asked to parse an empty OPP table.
> 
> A driver that gets a set of opp-points from f/w needs to add them to each
> device. To do so, it will call dev_pm_opp_add(). If an opp_table struct for this
> device is not found, one will be created and the opp-point will be added to it.
> When allocation a new opp_table the opp will try to initialise it by parsing the
> values in DT. It will also try to find_icc_paths.
> 
> Everything happens silently if we don't have a table in DT.

Right, you need something like your patch here.

-- 
viresh

WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Nicola Mazzucato <nicola.mazzucato@arm.com>
Cc: devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	chris.redpath@arm.com, Ionela Voinescu <ionela.voinescu@arm.com>,
	morten.rasmussen@arm.com, Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Date: Tue, 20 Oct 2020 16:18:49 +0530	[thread overview]
Message-ID: <20201020104849.xh4prj4az5islmpt@vireshk-i7> (raw)
In-Reply-To: <e3b3a583-5e0f-f512-85e6-81c55a0e6db5@arm.com>

On 19-10-20, 14:36, Nicola Mazzucato wrote:
> Hi Viresh,
> 
> 
> On 10/19/20 10:46 AM, Viresh Kumar wrote:
> > On 19-10-20, 09:50, Nicola Mazzucato wrote:
> >> Hi Viresh,
> >>
> >> thank you for your suggestion on using 'opp-shared'.
> >> I think it could work for most of the cases we explained earlier.
> >>
> >> Summarising, there are two parts of this entire proposal:
> >> 1) where/how to get the information: now we are focusing on taking advantage of
> >> 'opp-shared' within an empty opp table
> >> 2) and how/where this information will be consumed
> >>
> >> Further details below:
> >>
> >> 1) a CPUFreq driver that takes the OPPs from firmware, can call
> >> dev_pm_opp_of_get_sharing_cpus like you suggested. When doing so, a provided
> >> cpumaksk will be populated with the corresponding cpus that share the same
> >> (empty) table opp in DT.
> >> All good so far.
> > 
> > Great.
> > 
> >> The current opp core is not expecting an empty table and therefore some errors
> >> are thrown when this happens.
> >> Since we are now allowing this corner-case, I am presenting below where I think
> >> some minor corrections may be needed:
> >>
> >> --- a/drivers/opp/of.c
> >> +++ b/drivers/opp/of.c
> >> @@ static void _opp_table_alloc_required_tables(struct opp_table *opp_table,
> >>         struct device_node *required_np, *np;
> >>         int count, i;
> >>
> >>         /* Traversing the first OPP node is all we need */
> >>         np = of_get_next_available_child(opp_np, NULL);
> >>         if (!np) {
> >> -               dev_err(dev, "Empty OPP table\n");
> >> +               dev_warn(dev, "Empty OPP table\n");
> >> +
> >> +               /*
> >> +                * With empty table we remove shared_opp. This is to leave the
> >> +                * responsibility to decide which opp are shared to the opp users
> >> +                */
> >> +               opp_table->shared_opp = OPP_TABLE_ACCESS_EXCLUSIVE;
> >> +
> >>                 return;
> >>         }
> >>
> >> @@ int dev_pm_opp_of_find_icc_paths(struct device *dev,
> >>         int ret, i, count, num_paths;
> >>         struct icc_path **paths;
> >>
> >>         ret = _bandwidth_supported(dev, opp_table);
> >> -       if (ret <= 0)
> >> +       if (ret == -EINVAL)
> >> +               return 0; /* Empty OPP table is a valid corner-case, let's not
> >> fail */
> >> +       else if (ret <= 0)
> >>                 return ret;
> >>
> >> The above are not 'strictly' necessary to achieve the intended goal, but they
> >> make clearer that an empty table is now allowed and not an error anymore.
> >> What it is your point of view on this?
> > 
> > Why is this stuff getting called in your case ? We shouldn't be trying
> > to create an OPP table here and it should still be an error in the
> > code if we are asked to parse an empty OPP table.
> 
> A driver that gets a set of opp-points from f/w needs to add them to each
> device. To do so, it will call dev_pm_opp_add(). If an opp_table struct for this
> device is not found, one will be created and the opp-point will be added to it.
> When allocation a new opp_table the opp will try to initialise it by parsing the
> values in DT. It will also try to find_icc_paths.
> 
> Everything happens silently if we don't have a table in DT.

Right, you need something like your patch here.

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-20 10:48 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24  9:53 [PATCH v2 0/2] CPUFreq: Add support for cpu performance dependencies Nicola Mazzucato
2020-09-24  9:53 ` Nicola Mazzucato
2020-09-24  9:53 ` [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Nicola Mazzucato
2020-09-24  9:53   ` Nicola Mazzucato
2020-10-08 13:42   ` Ionela Voinescu
2020-10-08 13:42     ` Ionela Voinescu
2020-09-24  9:53 ` [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Nicola Mazzucato
2020-09-24  9:53   ` Nicola Mazzucato
2020-10-06  7:19   ` Viresh Kumar
2020-10-06  7:19     ` Viresh Kumar
2020-10-07 12:58     ` Nicola Mazzucato
2020-10-07 12:58       ` Nicola Mazzucato
2020-10-08 11:02       ` Viresh Kumar
2020-10-08 11:02         ` Viresh Kumar
2020-10-08 15:03         ` Ionela Voinescu
2020-10-08 15:03           ` Ionela Voinescu
2020-10-08 15:57           ` Rafael J. Wysocki
2020-10-08 15:57             ` Rafael J. Wysocki
2020-10-08 17:08             ` Ionela Voinescu
2020-10-08 17:08               ` Ionela Voinescu
2020-10-12 16:06             ` Sudeep Holla
2020-10-12 16:06               ` Sudeep Holla
2020-10-08 16:00           ` Nicola Mazzucato
2020-10-08 16:00             ` Nicola Mazzucato
2020-10-09  5:39             ` Viresh Kumar
2020-10-09  5:39               ` Viresh Kumar
2020-10-09 11:10               ` Nicola Mazzucato
2020-10-09 11:10                 ` Nicola Mazzucato
2020-10-09 11:17                 ` Viresh Kumar
2020-10-09 11:17                   ` Viresh Kumar
2020-10-09 14:01                 ` Rob Herring
2020-10-09 14:01                   ` Rob Herring
2020-10-09 15:28                   ` Nicola Mazzucato
2020-10-09 15:28                     ` Nicola Mazzucato
2020-10-12  4:19                     ` Viresh Kumar
2020-10-12  4:19                       ` Viresh Kumar
2020-10-12 10:22                   ` Lukasz Luba
2020-10-12 10:22                     ` Lukasz Luba
2020-10-12 10:50                     ` Rafael J. Wysocki
2020-10-12 10:50                       ` Rafael J. Wysocki
2020-10-12 11:05                       ` Lukasz Luba
2020-10-12 11:05                         ` Lukasz Luba
2020-10-12 10:59                     ` Ionela Voinescu
2020-10-12 10:59                       ` Ionela Voinescu
2020-10-12 13:48                       ` Lukasz Luba
2020-10-12 13:48                         ` Lukasz Luba
2020-10-12 16:30                         ` Ionela Voinescu
2020-10-12 16:30                           ` Ionela Voinescu
2020-10-12 18:19                           ` Lukasz Luba
2020-10-12 18:19                             ` Lukasz Luba
2020-10-12 22:01                             ` Ionela Voinescu
2020-10-12 22:01                               ` Ionela Voinescu
2020-10-13 11:53                               ` Rafael J. Wysocki
2020-10-13 11:53                                 ` Rafael J. Wysocki
2020-10-13 12:39                                 ` Ionela Voinescu
2020-10-13 12:39                                   ` Ionela Voinescu
2020-10-15 15:56                                   ` Rafael J. Wysocki
2020-10-15 15:56                                     ` Rafael J. Wysocki
2020-10-15 18:38                                     ` Ionela Voinescu
2020-10-15 18:38                                       ` Ionela Voinescu
2020-10-12 13:59                     ` Rob Herring
2020-10-12 13:59                       ` Rob Herring
2020-10-12 16:02                     ` Sudeep Holla
2020-10-12 16:02                       ` Sudeep Holla
2020-10-12 15:54                   ` Sudeep Holla
2020-10-12 15:54                     ` Sudeep Holla
2020-10-12 15:49               ` Sudeep Holla
2020-10-12 15:49                 ` Sudeep Holla
2020-10-12 16:52                 ` Ionela Voinescu
2020-10-12 16:52                   ` Ionela Voinescu
2020-10-12 17:18                   ` Lukasz Luba
2020-10-12 17:18                     ` Lukasz Luba
2020-10-14  4:25                     ` Viresh Kumar
2020-10-14  4:25                       ` Viresh Kumar
2020-10-14  9:11                       ` Lukasz Luba
2020-10-14  9:11                         ` Lukasz Luba
2020-10-19  8:50                       ` Nicola Mazzucato
2020-10-19  8:50                         ` Nicola Mazzucato
2020-10-19  9:46                         ` Viresh Kumar
2020-10-19  9:46                           ` Viresh Kumar
2020-10-19 13:36                           ` Nicola Mazzucato
2020-10-19 13:36                             ` Nicola Mazzucato
2020-10-20 10:48                             ` Viresh Kumar [this message]
2020-10-20 10:48                               ` Viresh Kumar
2020-10-13 13:53               ` Lukasz Luba
2020-10-13 13:53                 ` Lukasz Luba
2020-10-14  4:20                 ` Viresh Kumar
2020-10-14  4:20                   ` 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=20201020104849.xh4prj4az5islmpt@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=chris.redpath@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=morten.rasmussen@arm.com \
    --cc=nicola.mazzucato@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --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 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.