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
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [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 at 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
next prev parent reply other threads:[~2015-09-09 16:02 UTC|newest]
Thread overview: 103+ 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 ` Lee Jones
2015-07-27 15:20 ` [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs Lee Jones
2015-07-27 15:20 ` Lee Jones
2015-07-28 2:29 ` Viresh Kumar
2015-07-28 2:29 ` Viresh Kumar
2015-07-28 7:34 ` Lee Jones
2015-07-28 7:34 ` Lee Jones
2015-07-28 7:47 ` Viresh Kumar
2015-07-28 7:47 ` Viresh Kumar
2015-07-28 8:30 ` Lee Jones
2015-07-28 8:30 ` Lee Jones
2015-07-28 22:55 ` Stephen Boyd
2015-07-28 22:55 ` Stephen Boyd
2015-07-29 8:14 ` Lee Jones
2015-07-29 8:14 ` Lee Jones
2015-07-29 22:15 ` Stephen Boyd
2015-07-29 22:15 ` Stephen Boyd
2015-07-30 8:46 ` Lee Jones
2015-07-30 8:46 ` Lee Jones
2015-07-30 16:16 ` Rob Herring
2015-07-30 16:16 ` Rob Herring
2015-07-30 16:16 ` Rob Herring
2015-07-31 16:37 ` Stephen Boyd
2015-07-31 16:37 ` Stephen Boyd
2015-08-01 11:36 ` Viresh Kumar
2015-08-01 11:36 ` Viresh Kumar
2015-08-03 3:46 ` Viresh Kumar
2015-08-03 3:46 ` Viresh Kumar
2015-08-10 13:22 ` Lee Jones
2015-08-10 13:22 ` Lee Jones
2015-08-11 8:00 ` Viresh Kumar
2015-08-11 8:00 ` Viresh Kumar
2015-08-11 8:00 ` Viresh Kumar
2015-08-11 9:30 ` Lee Jones
2015-08-11 9:30 ` Lee Jones
2015-08-11 10:09 ` Viresh Kumar
2015-08-11 10:09 ` Viresh Kumar
2015-08-11 10:09 ` Viresh Kumar
2015-08-11 11:54 ` Lee Jones
2015-08-11 11:54 ` Lee Jones
2015-08-11 12:01 ` Viresh Kumar
2015-08-11 12:01 ` Viresh Kumar
2015-08-11 13:27 ` Lee Jones
2015-08-11 13:27 ` Lee Jones
2015-08-11 14:28 ` Viresh Kumar
2015-08-11 14:28 ` Viresh Kumar
2015-08-11 15:17 ` Lee Jones
2015-08-11 15:17 ` Lee Jones
2015-08-12 11:08 ` Viresh Kumar
2015-08-12 11:08 ` Viresh Kumar
2015-08-26 12:06 ` Lee Jones
2015-08-26 12:06 ` Lee Jones
2015-09-02 8:06 ` Viresh Kumar
2015-09-02 8:06 ` Viresh Kumar
2015-09-02 8:06 ` Viresh Kumar
2015-09-02 18:58 ` Rob Herring
2015-09-02 18:58 ` Rob Herring
2015-09-09 6:27 ` Viresh Kumar
2015-09-09 6:27 ` Viresh Kumar
2015-09-09 7:59 ` Lee Jones
2015-09-09 7:59 ` Lee Jones
2015-09-09 8:30 ` Viresh Kumar
2015-09-09 8:30 ` Viresh Kumar
2015-09-09 8:30 ` Viresh Kumar
2015-09-09 13:39 ` Lee Jones
2015-09-09 13:39 ` Lee Jones
2015-09-09 16:02 ` Viresh Kumar [this message]
2015-09-09 16:02 ` Viresh Kumar
2015-09-09 16:36 ` Lee Jones
2015-09-09 16:36 ` Lee Jones
2015-09-09 23:50 ` Rob Herring
2015-09-09 23:50 ` Rob Herring
2015-09-10 0:57 ` Stephen Boyd
2015-09-10 0:57 ` Stephen Boyd
2015-09-10 1:04 ` Viresh Kumar
2015-09-10 1:04 ` Viresh Kumar
2015-09-10 8:31 ` Lee Jones
2015-09-10 8:31 ` Lee Jones
2015-09-16 4:33 ` Viresh Kumar
2015-09-16 4:33 ` Viresh Kumar
2015-09-16 6:52 ` Lee Jones
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
2015-07-28 13:55 ` Rob Herring
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 14:39 ` Lee Jones
2015-07-28 14:39 ` Lee Jones
2015-07-28 15:35 ` Rob Herring
2015-07-28 15:35 ` Rob Herring
2015-07-28 15:43 ` Lee Jones
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 2:23 ` Viresh Kumar
2015-07-28 7:41 ` Lee Jones
2015-07-28 7:41 ` Lee Jones
2015-07-28 7:50 ` Viresh Kumar
2015-07-28 7:50 ` Viresh Kumar
2015-07-28 8:35 ` Viresh Kumar
2015-07-28 8:35 ` Viresh Kumar
2015-07-28 8:55 ` Lee Jones
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 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.