linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Lee Jones <lee.jones@linaro.org>
Cc: Rob Herring <robherring2@gmail.com>,
	Stephen Boyd <sboyd@codeaurora.org>, Nishanth Menon <nm@ti.com>,
	kernel@stlinux.com,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Rafael Wysocki <rjw@rjwysocki.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Sebastian Reichel <sre@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Arnd Bergmann <arnd.bergmann@linaro.org>,
	Ajit Pal Singh <ajitpal.singh@st.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
Date: Wed, 9 Sep 2015 21:32:12 +0530	[thread overview]
Message-ID: <20150909160212.GJ5266@linux> (raw)
In-Reply-To: <20150909133930.GE3260@x1>

On 09-09-15, 14:39, Lee Jones wrote:
> Okay, I see what you mean.  Sound fine, although only allows up to 31
> versions.  Not an issue for us I don't think, but could be for other
> vendors.  Taking a recent example, the kernel recently went up to
> v2.6.39 and some of the stable releases have gone up to v3.4.108.
> Depends what you wish to support.

Oh, that is always expandable. No one is stopping a platform to have
hw-versions as: cuts_part1 cuts_part2 cuts_part3, and that will give
us 96 bits :)

> > So, its not name of the supply really, but a virtual name given to the
> > voltage-range which we need to pick based on the hardware version.
> 
> We usually call these 'names'; reg-names, clock-names, pinctrl-names,
> phy-names, dma-names, etc.

Probably (opp-)supply-range-name suits well.

> > > I guess this is a Qcom specific feature.  I'll let Stephen comment.
> > 
> > No. So, my plan was to use this instead of the st,avs & pcode thing
> > you have got in your bindings. So, instead of 'slow' and 'fast' from
> > my example, it will have the corresponding strings for pcode numbers.
> > And at runtime the platform will pass a string to the OPP library, to
> > activate/add OPPs only for a specific opp-supply-version.
> 
> So you're using it to index into a 2 dimensional array of opp-hz's.

s/opp-hz's/opp-microvolt

> 
> Eek!

:)

> > I don't want 20 nodes but only ONE. And in your case, you may only
> > want to use pcode in the opp-supply-range-name property. But its fine
> > if you want to enable/disable some OPPs based on that as well :)
> 
> I'm not seeing how this can be achieved with 1 node.
> 
> I guess you mean one node per frequency?

Within an OPP table, OPP-nodes must have unique frequencies. i.e.
two nodes can't have same frequency.

In simple terms (mapping to your case) it is going to be like:
opp-table will have this:
opp-supply-range-names = "avs1", "avs2", ... , "avsn";

Each OPP node will have
opp-microvolt = <AVS1-volt>, <AVS2-volt>, <AVS3-volt> ... <AVSN-volt>;

The platform with tell opp core to use avsX and OPP core will take
care of rest.

> > Not really. So this is the logic (I perhaps need to write the
> > paragraph in the bindings in a better way):
> > 1. A regulator's voltage can be supplied as <target> or <target min max> now.
> 
> Understood.  I don't think we'll be using that, but if it's useful to
> others, then fine.

Bindings for this are already present in kernel, so this wasn't new.

> > 2. For each regulator we need to have an array of size mentioned above.
> 
> Using 2 properties to index in a 2D array like this look scarily like
> it'll be prone to all sorts of fumbling errors.
> 
> The complexity of all this will reduce massively by having a separate
> node per <regulator>-supply.  Using the same nodes for this is
> squeezing too much into a single node.  I was put off as soon as I saw
> you using 2D arrays in DT.

So for the pcode thing, probably a separate entry like:
opp-microvolt-pcode0 can be added to make things easy. opp-microvolts
bindings are already added to support multiple regulators, and I don't
really want to touch that again :)

> > Now this is what I call as ONE entry.
> > 
> > For each opp-supply-range-name string, we need a copy of this..
> 
> Fortunately for us we'll only have single celled opp-microvolt
> properties.

Haha. FWIW, you can't use voltage-tolerance with OPP-v2 bindings as
the triplets have replaced it. Just in case you were planning to use
that :)

> So I think our offering would look like this:
> 
> cpus {
> 	cpu@0 {
> 		compatible = "arm,cortex-a7";
> 		vcc-supply = <&cpu_supply0>;
> 		operating-points-v2 = <&cpu0_opp_table>;
> 	};
> };
> 
> cpu0_opp_table: opp_table0 {
> 	compatible = "operating-points-v2";
> 	opp-microvolt-names = "1", "2",  "3",  "4",  "5",  "6",  "7",  "8"
> 			      "9", "10", "11", "12", "13", "14", "15", "16";
> 
> 	opp0 {
> 		/*                  Major       Minor       Substrate */
> 		/*                  all         all         all       */
> 		opp-supported-hw = <0xffffffff  0xffffffff  0xffffffff>
> 		opp-hz           = <1000000000>;
> 		opp-microvolt    = <900000>, <915000>, <915000>, <925000>,
> 				   <925000>, <925000>, <935000>, <945000>,
> 				   <945000>, <945000>, <945000>, <955000>,
> 				   <956000>, <975000>, <975000>, <975000>,
> 	};

So this is based of the solution I proposed. But if we were to choose
the one you gave, it will be:

                opp-microvolt-1 = <900000>;
                opp-microvolt-2 = <915000>;
                opp-microvolt-3 = <915000>;
                opp-microvolt-4 = <925000>;
                opp-microvolt-5 = <925000>;
                opp-microvolt-6 = <925000>;
                opp-microvolt-7 = <935000>;
                opp-microvolt-8 = <945000>;
                opp-microvolt-9 = <945000>;
                opp-microvolt-10 = <945000>;
                opp-microvolt-11 = <945000>;
                opp-microvolt-12 = <955000>;
                opp-microvolt-13 = <956000>;
                opp-microvolt-14 = <975000>;
                opp-microvolt-15 = <975000>;
                opp-microvolt-16 = <975000>;

> 	opp1 {
> 		/*                  Major  Minor  Substrate */
> 		/*                  2      1 & 2  all       */
> 		opp-supported-hw = <0x2    0x3    0xffffffff>
> 		opp-hz           = <1100000000>;
> 		opp-microvolt    = <900000>, <915000>, <915000>, <925000>,
> 				   <925000>, <925000>, <935000>, <945000>,
> 				   <945000>, <945000>, <945000>, <955000>,
> 				   <956000>, <975000>, <975000>, <975000>,
> 	};
> 
> 	opp2 {
> 		/*                  Major  Minor  Substrate */
> 		/*                  2      5      4 & 5 & 6 */
> 		opp-supported-hw = <0x2    0x10   0x38>
> 		opp-hz           = <1200000000>;
> 		opp-microvolt    = <900000>, <915000>, <915000>, <925000>,
> 				   <925000>, <925000>, <935000>, <945000>,
> 				   <945000>, <945000>, <945000>, <955000>,
> 				   <956000>, <975000>, <975000>, <975000>,
> 	};
> };
> 
> Or have I got the wrong end of the stick?
> 
> NB: Note the suggested new property names.

Yeah, all looks fine to me.

-- 
viresh

  reply	other threads:[~2015-09-09 16:02 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27 15:20 [PATCH v4 1/2] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation Lee Jones
2015-07-27 15:20 ` [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones
2015-07-28  2:29   ` Viresh Kumar
2015-07-28  7:34     ` Lee Jones
2015-07-28  7:47       ` Viresh Kumar
2015-07-28  8:30         ` Lee Jones
2015-07-28 22:55     ` Stephen Boyd
2015-07-29  8:14       ` Lee Jones
2015-07-29 22:15         ` Stephen Boyd
2015-07-30  8:46           ` Lee Jones
2015-07-30 16:16             ` Rob Herring
2015-07-31 16:37               ` Stephen Boyd
2015-08-01 11:36                 ` Viresh Kumar
2015-08-03  3:46                 ` Viresh Kumar
2015-08-10 13:22                   ` Lee Jones
2015-08-11  8:00                     ` Viresh Kumar
2015-08-11  9:30                       ` Lee Jones
2015-08-11 10:09                         ` Viresh Kumar
2015-08-11 11:54                           ` Lee Jones
2015-08-11 12:01                             ` Viresh Kumar
2015-08-11 13:27                               ` Lee Jones
2015-08-11 14:28                                 ` Viresh Kumar
2015-08-11 15:17                                   ` Lee Jones
2015-08-12 11:08                                     ` Viresh Kumar
2015-08-26 12:06                                       ` Lee Jones
2015-09-02  8:06                                         ` Viresh Kumar
2015-09-02 18:58                                           ` Rob Herring
2015-09-09  6:27                                             ` Viresh Kumar
2015-09-09  7:59                                               ` Lee Jones
2015-09-09  8:30                                                 ` Viresh Kumar
2015-09-09 13:39                                                   ` Lee Jones
2015-09-09 16:02                                                     ` Viresh Kumar [this message]
2015-09-09 16:36                                                       ` Lee Jones
2015-09-09 23:50                                                         ` Rob Herring
2015-09-10  0:57                                                           ` Stephen Boyd
2015-09-10  1:04                                                             ` Viresh Kumar
2015-09-10  8:31                                                               ` Lee Jones
2015-09-16  4:33                                                                 ` Viresh Kumar
2015-09-16  6:52                                                                   ` Lee Jones
     [not found]   ` <1438010430-5802-2-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-07-28 13:55     ` Rob Herring
     [not found]       ` <CAL_JsqL=e+fL_67_GPKjt_7wJ81GfFx7m9gjxmBDvW_JBXWpfQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-28 14:39         ` Lee Jones
2015-07-28 15:35           ` Rob Herring
2015-07-28 15:43             ` Lee Jones
2015-07-28  2:23 ` [PATCH v4 1/2] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation Viresh Kumar
2015-07-28  7:41   ` Lee Jones
2015-07-28  7:50     ` Viresh Kumar
2015-07-28  8:35 ` Viresh Kumar
2015-07-28  8:55   ` Lee Jones

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=20150909160212.GJ5266@linux \
    --to=viresh.kumar@linaro.org \
    --cc=ajitpal.singh@st.com \
    --cc=arnd.bergmann@linaro.org \
    --cc=dbaryshkov@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@stlinux.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=robherring2@gmail.com \
    --cc=sboyd@codeaurora.org \
    --cc=sre@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).