From: Viresh Kumar <viresh.kumar@linaro.org>
To: Dave Gerlach <d-gerlach@ti.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
Rob Herring <robh@kernel.org>, Mark Brown <broonie@kernel.org>,
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>,
devicetree@vger.kernel.org
Subject: Re: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device
Date: Wed, 16 Nov 2016 08:48:44 +0530 [thread overview]
Message-ID: <20161116031844.GD17245@vireshk-i7> (raw)
In-Reply-To: <032e1bb4-c9e9-c588-a8c0-dd019bb64254@ti.com>
On 15-11-16, 16:11, Dave Gerlach wrote:
> On 11/15/2016 12:56 PM, Stephen Boyd wrote:
> >On 11/15, Viresh Kumar wrote:
> >>There are two important pieces of information we need for multiple
> >>regulator support:
> >>- Which regulator in the consumer node corresponds to which entry in
> >> the OPP table. As Mark mentioned earlier, DT should be able to get
> >> us this.
> >
> >This is also possible from C code though. Or is there some case
> >where it isn't possible if we're sharing the same table with two
> >devices? I'm lost on when this would ever happen.
> >
> >It feels like trying to keep the OPP table agnostic of the
> >consuming device and the device's binding is more trouble than
> >it's worth. Especially considering we have opp-shared and *-name
> >now.
>
> I agree with this, I do not like having to pass a list of regulator names to
> the opp core that I *hope* the device I am controlling has provided.
What do you mean by that? Are you saying this from DT's point of view
or of the code? i.e. Are you saying that you don't like the
dev_pm_opp_set_regulators() API ?
> The
> intent seems to be to use the cpufreq-dt driver as is and not pass any
I would like to kill all regulators code from cpufreq-dt sometime
soon. All that is left there is making sure we have a regulator in
place, but I strongly feel OPP core is the right place for doing that
now.
> cpu-supply anymore so the cpufreq-dt driver has no knowledge of what
> regulators are present (it operates as it would today on a system with no
> regulator required). But as is it will move forward regardless of whether or
> not we actually intended to provide a multi regulator set up or platform
> set_opp helper, and this probably isn't ideal.
Yes and that's why I am more inclined towards my above comment. We
shall make it consistent.
> I would think cpufreq-dt/opp
> core should be have knowledge of what regulators are needed to achieve these
> opp transitions and make sure everything is in place before moving ahead.
The last patch in my series does what you are looking for:
PM / OPP: Don't assume platform doesn't have regulators
Isn't it ?
--
viresh
next prev parent reply other threads:[~2016-11-16 3:18 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 6:32 [PATCH V3 0/9] PM / OPP: Multiple regulator support Viresh Kumar
2016-10-26 6:32 ` [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device Viresh Kumar
2016-11-09 14:58 ` Mark Brown
2016-11-10 4:04 ` Viresh Kumar
2016-11-10 16:36 ` Mark Brown
2016-11-10 18:09 ` Viresh Kumar
2016-11-10 22:51 ` Stephen Boyd
2016-11-11 3:11 ` Viresh Kumar
2016-11-15 1:59 ` Rob Herring
2016-11-15 2:13 ` Stephen Boyd
2016-11-15 3:31 ` Viresh Kumar
2016-11-15 18:56 ` Stephen Boyd
2016-11-15 22:11 ` Dave Gerlach
2016-11-16 3:18 ` Viresh Kumar [this message]
[not found] ` <20161115185645.GA25626-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-11-16 3:08 ` Viresh Kumar
2016-10-26 6:32 ` [PATCH V3 2/9] PM / OPP: Don't use OPP structure outside of rcu protected section Viresh Kumar
2016-10-26 6:32 ` [PATCH V3 3/9] PM / OPP: Manage supply's voltage/current in a separate structure Viresh Kumar
2016-10-26 6:32 ` [PATCH V3 4/9] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage() Viresh Kumar
2016-10-26 6:33 ` [PATCH V3 5/9] PM / OPP: Add infrastructure to manage multiple regulators Viresh Kumar
2016-10-26 6:33 ` [PATCH V3 6/9] PM / OPP: Separate out _generic_opp_set_rate() Viresh Kumar
2016-10-26 6:33 ` [PATCH V3 7/9] PM / OPP: Allow platform specific custom set_opp() callbacks Viresh Kumar
2016-10-26 6:33 ` [PATCH V3 8/9] PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators() Viresh Kumar
2016-10-26 6:33 ` [PATCH V3 9/9] PM / OPP: Don't assume platform doesn't have regulators Viresh Kumar
2016-11-10 1:17 ` Stephen Boyd
2016-11-10 5:16 ` [PATCH V4 " Viresh Kumar
2016-11-02 4:51 ` [PATCH V3 0/9] PM / OPP: Multiple regulator support Viresh Kumar
2016-11-10 1:19 ` Stephen Boyd
2016-11-10 4:11 ` Viresh Kumar
2016-11-15 22:10 ` [TEST PATCH] WIP: Test OPP multi regulator support with ti-opp-domain driver Dave Gerlach
2016-11-16 1:38 ` kbuild test robot
2016-11-16 2:01 ` kbuild test robot
2016-11-16 3:27 ` Viresh Kumar
2016-11-18 3:06 ` [PATCH V3 0/9] PM / OPP: Multiple regulator support Viresh Kumar
2016-11-18 10:43 ` Mark Brown
2016-11-22 3:49 ` Viresh Kumar
2016-11-22 18:41 ` Mark Brown
2016-11-23 3:46 ` Viresh Kumar
2016-11-23 12:29 ` Mark Brown
2016-11-24 5:07 ` Viresh Kumar
2016-11-24 10:19 ` Mark Brown
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=20161116031844.GD17245@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=broonie@kernel.org \
--cc=d-gerlach@ti.com \
--cc=devicetree@vger.kernel.org \
--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).