From: Stephen Boyd <sboyd@codeaurora.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rob Herring <robherring2@gmail.com>,
Rafael Wysocki <rjw@rjwysocki.net>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
Nishanth Menon <nm@ti.com>, Mark Brown <broonie@kernel.org>,
Mike Turquette <mike.turquette@linaro.org>,
Grant Likely <grant.likely@linaro.org>,
Olof Johansson <olof@lixom.net>,
Sudeep Holla <Sudeep.Holla@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Viswanath Puttagunta <viswanath.puttagunta@linaro.org>,
Lucas Stach <l.stach@pengutronix.de>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Thomas Abraham <ta.omasab@gmail.com>,
Abhilash Kesavan <kesavan.abhilash@gmail.com>,
Kevin Hilman <khilman@linaro.org>,
Santosh
Subject: Re: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
Date: Fri, 19 Jun 2015 11:44:03 -0700 [thread overview]
Message-ID: <20150619184403.GC22132@codeaurora.org> (raw)
In-Reply-To: <20150618022543.GA28820@linux>
On 06/18, Viresh Kumar wrote:
> On 17-06-15, 18:30, Stephen Boyd wrote:
> > An operating-point(s?)-names property seems ok... but doesn't that mean
> > that every CPU that uses the OPP has to have the same list of
> > operating-point-names?
>
> Why do you think so? For me the operating-points-v2-names property
> will be present in CPU node (as there is no OPP node which can have
> it) and so every CPU is free to choose what it wants to.
Yes.
>
> > It would make sense to me if the operating points
> > were called something different depending on *which* CPU is using them,
> > but in this case the only name for the operating point is "slow" or
> > "fast", etc.
>
> I am completely confused now. :)
>
As am I.
> The problem you stated now was there with the current state of
> bindings. The name is embedded into the OPP table node and so is fixed
> for all the CPUs. Moving it to the CPU node will give all CPUs a
> chance to name it whatever they want to. And the same list has to be
> replicated to all CPUs sharing the clock rails.
>
Yes I don't see how the name will be different for any CPU, hence
my complaint/question about duplicate names in each CPU. I guess
it isn't any worse than clock-names though so I'm fine with it.
> > In reality we've assigned them names like speedX-binY-vZ so that we know
> > which speed bin, voltage bin, and version they're part of. Maybe OPP
> > node properties like qcom,speed-bin = <u32>, qcom,pvs-bin = <u32>, etc.
> > would be better?
>
> Lets see, only if we can't get the generic stuff for this.
>
> > At the least, operating-points-names will be required on qcom platforms.
> > A fixed ordering known to the platform would mean that we know exactly
> > how many voltage bins and speed bins and how many voltage bins per speed
> > bin are used for a particular SoC, which we've avoided knowing so far.
>
> What are we referring to fixed ordering? If we have both a list of
> phandles to OPP tables and a list of names, they can be rearranged in
> whatever fashion we want. Isn't it?
>
This is a reply to Rob's question about fixed ordering without a
names property. That's unlikely to work out for qcom chips.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT
Date: Fri, 19 Jun 2015 11:44:03 -0700 [thread overview]
Message-ID: <20150619184403.GC22132@codeaurora.org> (raw)
In-Reply-To: <20150618022543.GA28820@linux>
On 06/18, Viresh Kumar wrote:
> On 17-06-15, 18:30, Stephen Boyd wrote:
> > An operating-point(s?)-names property seems ok... but doesn't that mean
> > that every CPU that uses the OPP has to have the same list of
> > operating-point-names?
>
> Why do you think so? For me the operating-points-v2-names property
> will be present in CPU node (as there is no OPP node which can have
> it) and so every CPU is free to choose what it wants to.
Yes.
>
> > It would make sense to me if the operating points
> > were called something different depending on *which* CPU is using them,
> > but in this case the only name for the operating point is "slow" or
> > "fast", etc.
>
> I am completely confused now. :)
>
As am I.
> The problem you stated now was there with the current state of
> bindings. The name is embedded into the OPP table node and so is fixed
> for all the CPUs. Moving it to the CPU node will give all CPUs a
> chance to name it whatever they want to. And the same list has to be
> replicated to all CPUs sharing the clock rails.
>
Yes I don't see how the name will be different for any CPU, hence
my complaint/question about duplicate names in each CPU. I guess
it isn't any worse than clock-names though so I'm fine with it.
> > In reality we've assigned them names like speedX-binY-vZ so that we know
> > which speed bin, voltage bin, and version they're part of. Maybe OPP
> > node properties like qcom,speed-bin = <u32>, qcom,pvs-bin = <u32>, etc.
> > would be better?
>
> Lets see, only if we can't get the generic stuff for this.
>
> > At the least, operating-points-names will be required on qcom platforms.
> > A fixed ordering known to the platform would mean that we know exactly
> > how many voltage bins and speed bins and how many voltage bins per speed
> > bin are used for a particular SoC, which we've avoided knowing so far.
>
> What are we referring to fixed ordering? If we have both a list of
> phandles to OPP tables and a list of names, they can be rearranged in
> whatever fashion we want. Isn't it?
>
This is a reply to Rob's question about fixed ordering without a
names property. That's unlikely to work out for qcom chips.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-06-19 18:44 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 16:20 [PATCH V7 0/3] OPP: Introduce OPP (V2) bindings Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
[not found] ` <cover.1433434659.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-04 16:20 ` [PATCH V7 1/3] OPP: Add new bindings to address shortcomings of existing bindings Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
2015-06-04 18:37 ` Stephen Boyd
2015-06-04 18:37 ` Stephen Boyd
2015-06-05 2:41 ` Viresh Kumar
2015-06-05 2:41 ` Viresh Kumar
2015-06-16 13:34 ` Nishanth Menon
2015-06-16 13:34 ` Nishanth Menon
2015-06-04 16:20 ` [PATCH V7 2/3] OPP: Allow multiple OPP tables to be passed via DT Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
2015-06-17 13:23 ` Rob Herring
2015-06-17 13:23 ` Rob Herring
2015-06-17 13:33 ` Viresh Kumar
2015-06-17 13:33 ` Viresh Kumar
2015-06-17 13:47 ` Rob Herring
2015-06-17 13:47 ` Rob Herring
2015-06-17 14:42 ` Viresh Kumar
2015-06-17 14:42 ` Viresh Kumar
2015-06-18 1:30 ` Stephen Boyd
2015-06-18 1:30 ` Stephen Boyd
2015-06-18 2:25 ` Viresh Kumar
2015-06-18 2:25 ` Viresh Kumar
2015-06-18 2:50 ` Viresh Kumar
2015-06-18 2:50 ` Viresh Kumar
2015-06-19 18:47 ` Stephen Boyd
2015-06-19 18:47 ` Stephen Boyd
[not found] ` <20150619184747.GD22132-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-06-19 18:52 ` Rob Herring
2015-06-19 18:52 ` Rob Herring
[not found] ` <CAL_JsqJfWDO4r_FP6xHSxRkMM-pSnbEUB=d9Gj6mhvPY+ouLxA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-20 2:24 ` Viresh Kumar
2015-06-20 2:24 ` Viresh Kumar
2015-06-19 18:44 ` Stephen Boyd [this message]
2015-06-19 18:44 ` Stephen Boyd
2015-06-20 2:18 ` Viresh Kumar
2015-06-20 2:18 ` Viresh Kumar
2015-06-04 16:20 ` [PATCH V7 3/3] OPP: Add binding for 'opp-suspend' Viresh Kumar
2015-06-04 16:20 ` Viresh Kumar
2015-06-13 8:40 ` Viresh Kumar
2015-06-13 8:40 ` Viresh Kumar
2015-06-15 22:30 ` Rafael J. Wysocki
2015-06-15 22:30 ` Rafael J. Wysocki
2015-06-15 23:35 ` Rob Herring
2015-06-15 23:35 ` Rob Herring
[not found] ` <CAL_JsqJb4P2Z2esgm5ffjWV37MU2KUF4gBdUpwSV8+21iTD1Bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-16 0:31 ` Viresh Kumar
2015-06-16 0:31 ` Viresh Kumar
2015-06-16 2:54 ` Viresh Kumar
2015-06-16 2:54 ` Viresh Kumar
2015-06-16 19:23 ` Rob Herring
2015-06-16 19:23 ` Rob Herring
2015-06-16 21:21 ` Rafael J. Wysocki
2015-06-16 21:21 ` Rafael J. Wysocki
2015-06-17 2:38 ` Viresh Kumar
2015-06-17 2:38 ` Viresh Kumar
2015-06-17 9:38 ` Rafael J. Wysocki
2015-06-17 9:38 ` Rafael J. Wysocki
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=20150619184403.GC22132@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=Sudeep.Holla@arm.com \
--cc=arnd.bergmann@linaro.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=kesavan.abhilash@gmail.com \
--cc=khilman@linaro.org \
--cc=l.stach@pengutronix.de \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=mike.turquette@linaro.org \
--cc=nm@ti.com \
--cc=olof@lixom.net \
--cc=rjw@rjwysocki.net \
--cc=robherring2@gmail.com \
--cc=ta.omasab@gmail.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=viresh.kumar@linaro.org \
--cc=viswanath.puttagunta@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 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.