linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Rob Herring <robh@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Rafael Wysocki <rjw@rjwysocki.net>,
	nm@ti.com, linaro-kernel@lists.linaro.org,
	linux-pm@vger.kernel.org, rob.herring@linaro.org,
	lee.jones@linaro.org, Mark Brown <broonie@kernel.org>,
	devicetree@vger.kernel.org,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	open list <linux-kernel@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Pawel Moll <pawel.moll@arm.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
Date: Thu, 15 Oct 2015 17:22:43 -0700	[thread overview]
Message-ID: <20151016002243.GA23912@codeaurora.org> (raw)
In-Reply-To: <55F72C97.2030306@kernel.org>

On 09/14, Rob Herring wrote:
> On 09/11/2015 07:01 AM, Viresh Kumar wrote:
> > Regulators already have stable DT bindings, wherein the consumer (of
> > supplies) will have following for each regulator/supply.
> > 
> > <name>-supply: <phandle to the regulator node>;
> > 
> > Current OPP bindings extend above, by transforming it into a list of
> > phandles. But we missed the <name> string, which is used to identify the
> > regulator.
> > 
> > And looking from regulators perspective, having two different ways of
> > specifying regulators doesn't seem like a step forward, it also means we
> > have to update every single device binding. And things will become
> > complex.
> > 
> > Another way to support multiple regulators per device (in OPP V2
> > bindings) is to leave regulator consumer bindings as is, and create a
> > 'supply-names' property in the opp-table node, which will contain a list
> > of strings. The names in this list shall match 'name' from the
> > '<name>-supply' strings present in the device node.
> > 
> > The strings in this list also specify the order in which values must be
> > present in 'opp-microvolt' and 'opp-microamp' properties.
> > 
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/opp/opp.txt | 26 +++++++++++++++++++-------
> >  1 file changed, 19 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > index 0cb44dc21f97..8759bc4783ed 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -69,6 +69,13 @@ This describes the OPPs belonging to a device. This node can have following
> >  - compatible: Allow OPPs to express their compatibility. It should be:
> >    "operating-points-v2".
> >  
> > +- supply-names: This is a required property, only if multiple supplies are
> > +  available for the device. Otherwise it is optional.
> > +
> > +  This list is used to pass names of all the device supplies. The order of names
> > +  present here is important, as that should match the order in which values are
> > +  present in 'opp-microvolt' and 'opp-microamp' properties.
> > +
> 
> What if we have a 2nd device and supply rail? For example, what if the
> L2$ has a separate rail from the cores but is linked to the OPPs.

I'm lost why we need this property at all. What happened to using

 opp-microvolt-0 = <1 2 3>;
 opp-microvolt-1 = <1>;
 opp-microvolt-2 = <3 4 5>;
 etc.

That seems to avoid any problem with 3 vs. 1 element properties
combined into one large array. Having supply-names seems too
brittle and would tie us to a particular OPP user's decision to
call supplies by some name.

Also, I've seen devices that are split across two power domains.
These devices aren't CPUs, but they are other devices including
L2 caches. So we're going to need either multiple regulator
support or multiple "power domain at a particular performance
levels" support somehow.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  parent reply	other threads:[~2015-10-16  0:22 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 12:01 [PATCH 00/16] PM / OPP: multiple regulators & opp-transition support Viresh Kumar
2015-09-11 12:01 ` [PATCH 01/16] PM / OPP: Add 'supply-names' binding Viresh Kumar
2015-09-14 20:22   ` Rob Herring
     [not found]     ` <55F72C97.2030306-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2015-09-15  2:47       ` Viresh Kumar
2015-10-08  9:27         ` Viresh Kumar
2015-10-16  0:22     ` Stephen Boyd [this message]
2015-10-16  6:02       ` Viresh Kumar
2015-10-16 19:16         ` Stephen Boyd
2015-10-17  4:10           ` Viresh Kumar
2015-10-21 13:18             ` Viresh Kumar
2015-10-22 16:39             ` Mark Brown
2015-10-27  8:19               ` Viresh Kumar
2015-10-28  8:17                 ` Mark Brown
     [not found]                   ` <20151028081742.GC28319-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-10-29 23:38                     ` Stephen Boyd
2016-03-01  6:45     ` Viresh Kumar
2016-03-01 15:09       ` Nishanth Menon
2016-03-02  2:50       ` Mark Brown
2016-03-02 10:28         ` Viresh Kumar
2016-03-02 11:24           ` Mark Brown
2016-03-02 15:26             ` Nishanth Menon
2016-03-02 15:30               ` Mark Brown
2016-03-02 15:43                 ` Nishanth Menon
2015-10-22 16:30   ` Mark Brown
2015-09-11 12:01 ` [PATCH 02/16] PM / OPP: Add 'opp-microvolt-triplets' binding Viresh Kumar
2015-09-14 20:30   ` Rob Herring
2015-09-15  3:30     ` Viresh Kumar
2015-09-19 15:39       ` Mark Brown
2015-09-11 12:01 ` [PATCH 03/16] PM / OPP: Improve debug print messages with pr_fmt Viresh Kumar
2015-09-11 12:02 ` [PATCH 04/16] PM / OPP: Rename routines specific to old bindings with _v1 Viresh Kumar
2015-09-11 12:02 ` [PATCH 05/16] PM / OPP: Parse all power-supply related bindings together Viresh Kumar
2015-09-11 12:02 ` [PATCH 06/16] PM / OPP: Create separate structure for regulator/supplies Viresh Kumar
2015-09-11 12:02 ` [PATCH 07/16] PM / OPP: Add multiple regulators support Viresh Kumar
2015-09-11 12:02 ` [PATCH 08/16] PM / OPP: get/put regulators from OPP core Viresh Kumar
2015-09-11 12:02 ` [PATCH 09/16] PM / OPP: Disable OPPs that aren't supported by the regulators Viresh Kumar
2015-09-11 12:02 ` [PATCH 10/16] PM / OPP: Introduce dev_pm_opp_get_max_volt_latency() Viresh Kumar
2015-09-11 12:02 ` [PATCH 11/16] PM / OPP: Introduce dev_pm_opp_get_max_transition_latency() Viresh Kumar
2015-09-11 12:02 ` [PATCH 12/16] PM / OPP: Parse clock and voltage tolerance for v1 bindings Viresh Kumar
2015-09-11 12:02 ` [PATCH 13/16] PM / OPP: Manage device clk as well Viresh Kumar
2015-09-11 12:02 ` [PATCH 14/16] PM / OPP: Add dev_pm_opp_set_regulator() to specify regulator Viresh Kumar
2015-09-11 12:02 ` [PATCH 15/16] PM / OPP: Add dev_pm_opp_set_rate() Viresh Kumar
2015-09-11 12:02 ` [PATCH 16/16] PM / OPP: don't print error message for deferred probing 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=20151016002243.GA23912@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=lee.jones@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=nm@ti.com \
    --cc=pawel.moll@arm.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=rob.herring@linaro.org \
    --cc=robh@kernel.org \
    --cc=viresh.kumar@linaro.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).