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
next prev parent 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).