From: Viresh Kumar <viresh.kumar@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
nm@ti.com, Viresh Kumar <vireshk@kernel.org>,
linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Vincent Guittot <vincent.guittot@linaro.org>,
robh@kernel.org, d-gerlach@ti.com, broonie@kernel.org
Subject: Re: [PATCH V2 5/8] PM / OPP: Add infrastructure to manage multiple regulators
Date: Wed, 26 Oct 2016 11:35:12 +0530 [thread overview]
Message-ID: <20161026060512.GI9162@vireshk-i7> (raw)
In-Reply-To: <20161025164953.GT26139@codeaurora.org>
On 25-10-16, 09:49, Stephen Boyd wrote:
> On 10/20, Viresh Kumar wrote:
> > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> > index 37fad2eb0f47..45c70ce07864 100644
> > --- a/drivers/base/power/opp/core.c
> > +++ b/drivers/base/power/opp/core.c
> > @@ -235,21 +237,44 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev)
> > return 0;
> > }
> >
> > - reg = opp_table->regulator;
> > - if (IS_ERR(reg)) {
> > + count = opp_table->regulator_count;
> > +
> > + if (!count) {
> > /* Regulator may not be required for device */
> > rcu_read_unlock();
> > return 0;
> > }
> >
> > - list_for_each_entry_rcu(opp, &opp_table->opp_list, node) {
> > - if (!opp->available)
> > - continue;
> > + size = count * sizeof(*regulators);
> > + regulators = kmemdup(opp_table->regulators, size, GFP_KERNEL);
>
> How do we allocate under RCU? Doesn't that spit out big warnings?
That doesn't. I even tried enabling several locking debug config options.
> > + if (!regulators) {
> > + rcu_read_unlock();
> > + return 0;
> > + }
> > +
> > + min_uV = kmalloc(count * (sizeof(*min_uV) + sizeof(*max_uV)),
>
> Do we imagine min_uV is going to be a different size from max_uV?
> It may be better to have a struct for min/max pair and then
> stride them. Then the kmalloc() can become a kmalloc_array().
done.
> > - *opp_table = _add_opp_table(dev);
> > - if (!*opp_table) {
> > - kfree(opp);
> > + /* allocate new OPP node + and supplies structures */
> > + opp = kzalloc(sizeof(*opp) + supply_size, GFP_KERNEL);
> > + if (!opp) {
> > + kfree(table);
> > return NULL;
> > }
> >
> > + opp->supplies = (struct dev_pm_opp_supply *)(opp + 1);
>
> So put the supplies at the end of the OPP structure as an empty
> array?
Yes. Added a comment to clarify as well.
> > -int dev_pm_opp_set_regulator(struct device *dev, const char *name)
> > +int dev_pm_opp_set_regulators(struct device *dev, const char *names[],
>
> Make names a const char * const *?
Done.
> I seem to recall arrays as
> function arguments has some problem but my C mastery is failing
> right now.
I am not sure why it would be a problem, and of course what gets passed is the
address and not the array.
> > + for (i = 0; i < count; i++) {
> > + reg = regulator_get_optional(dev, names[i]);
> > + pr_info("%s: %d: %p: %s\n", __func__, __LINE__, reg, names[i]);
>
> Debug noise?
Yes.
> > +static bool opp_debug_create_supplies(struct dev_pm_opp *opp,
> > + struct opp_table *opp_table,
> > + struct dentry *pdentry)
> > +{
> > + struct dentry *d;
> > + int i = 0;
> > + char name[] = "supply-X"; /* support only 0-9 supplies */
>
> But we don't verify that's the case? Why not use kasprintf() and
> free() and then there isn't any limit?
Done.
> > diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
> > index b7fcd0a1b58b..c857fb07a5bc 100644
> > --- a/drivers/base/power/opp/of.c
> > +++ b/drivers/base/power/opp/of.c
> > @@ -105,12 +106,13 @@ static bool _opp_is_supported(struct device *dev, struct opp_table *opp_table,
> > static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev,
> > struct opp_table *opp_table)
> > {
> > - u32 microvolt[3] = {0};
> > - u32 val;
> > - int count, ret;
> > + u32 *microvolt, *microamp = NULL;
> > + int supplies, vcount, icount, ret, i, j;
> > struct property *prop = NULL;
> > char name[NAME_MAX];
> >
> > + supplies = opp_table->regulator_count ? opp_table->regulator_count : 1;
>
> We can't have regulator_count == 1 by default?
It is used at various places to distinguish if regulators are set by platform
code or not. The OPP core can still be used just for DT data, i.e. no opp-set.
And so it is important to support cases where the regulators aren't set.
> > @@ -155,7 +155,8 @@ enum opp_table_access {
> > * @supported_hw_count: Number of elements in supported_hw array.
> > * @prop_name: A name to postfix to many DT properties, while parsing them.
> > * @clk: Device's clock handle
> > - * @regulator: Supply regulator
> > + * @regulators: Supply regulators
> > + * @regulator_count: Number of Power Supply regulators
>
> Lowercase Power Supply please.
Done.
> > * @dentry: debugfs dentry pointer of the real device directory (not links).
> > * @dentry_name: Name of the real dentry.
> > *
> > diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> > index 5c07ae05d69a..15cb26118dc7 100644
> > --- a/drivers/cpufreq/cpufreq-dt.c
> > +++ b/drivers/cpufreq/cpufreq-dt.c
> > @@ -186,7 +186,10 @@ static int cpufreq_init(struct cpufreq_policy *policy)
> > */
> > name = find_supply_name(cpu_dev);
> > if (name) {
> > - ret = dev_pm_opp_set_regulator(cpu_dev, name);
> > + const char *names[] = {name};
> > +
> > + ret = dev_pm_opp_set_regulators(cpu_dev, names,
>
> We can't just do &names instead here? Hmm...
I don't think so. You sure we can do it ?
--
viresh
next prev parent reply other threads:[~2016-10-26 6:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-20 8:44 [PATCH V2 0/8] PM / OPP: Multiple regulator support Viresh Kumar
2016-10-20 8:44 ` [PATCH V2 1/8] PM / OPP: Reword binding supporting multiple regulators per device Viresh Kumar
[not found] ` <891ef8705e13dff331a3135647f4c18f88402a12.1476952750.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-10-24 22:48 ` Stephen Boyd
2016-10-20 8:44 ` [PATCH V2 2/8] PM / OPP: Don't use OPP structure outside of rcu protected section Viresh Kumar
2016-10-24 22:52 ` Stephen Boyd
2016-10-25 3:37 ` Viresh Kumar
2016-10-20 8:44 ` [PATCH V2 3/8] PM / OPP: Manage supply's voltage/current in a separate structure Viresh Kumar
2016-10-20 8:44 ` [PATCH V2 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage() Viresh Kumar
2016-10-24 23:14 ` Stephen Boyd
2016-10-25 3:45 ` Viresh Kumar
2016-10-25 20:26 ` Stephen Boyd
2016-10-26 3:34 ` Viresh Kumar
2016-10-20 8:44 ` [PATCH V2 5/8] PM / OPP: Add infrastructure to manage multiple regulators Viresh Kumar
2016-10-21 22:32 ` Dave Gerlach
2016-10-24 3:35 ` Viresh Kumar
2016-10-25 16:49 ` Stephen Boyd
2016-10-26 6:05 ` Viresh Kumar [this message]
2016-11-10 1:37 ` Stephen Boyd
2016-10-20 8:45 ` [PATCH V2 6/8] PM / OPP: Separate out _generic_opp_set_rate() Viresh Kumar
2016-10-25 18:59 ` Stephen Boyd
2016-10-26 6:07 ` Viresh Kumar
2016-10-20 8:45 ` [PATCH V2 7/8] PM / OPP: Allow platform specific custom opp_set_rate() callbacks Viresh Kumar
2016-10-25 19:01 ` Stephen Boyd
2016-10-26 6:07 ` Viresh Kumar
2016-10-20 8:45 ` [PATCH V2 8/8] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators() Viresh Kumar
2016-10-25 19:01 ` Stephen Boyd
2016-10-21 13:39 ` [PATCH V2 0/8] PM / OPP: Multiple regulator support Rafael J. Wysocki
2016-10-21 15:40 ` Viresh Kumar
2016-10-24 1:08 ` Dave Gerlach
2016-10-24 4:26 ` Viresh Kumar
2016-10-25 21:13 ` Dave Gerlach
2016-10-26 3:21 ` 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=20161026060512.GI9162@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=broonie@kernel.org \
--cc=d-gerlach@ti.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=vincent.guittot@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).