From: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
Nishanth Menon <nm@ti.com>,
"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
Pawel Moll <Pawel.Moll@arm.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [RFC PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP
Date: Thu, 22 Aug 2013 16:32:10 +0100 [thread overview]
Message-ID: <52162EFA.2070108@arm.com> (raw)
In-Reply-To: <20130822115957.GC9799@e106331-lin.cambridge.arm.com>
On 22/08/13 12:59, Mark Rutland wrote:
> On Wed, Aug 21, 2013 at 11:48:12PM +0100, Stephen Warren wrote:
>> On 08/20/2013 04:00 AM, Sudeep KarkadaNagesha wrote:
>> ...
>>> Until we get more feedback and agreement on new proposal can we have
>>> this simple amendment in this patch to the existing binding ? Since the
>>> new proposal[1] is backward compatible(this patch adding support for
>>> option#5 to existing option#1), we will have to add support for other
>>> binding options in [1] later.
>>>
>>> This is needed to support shared OPPs with simple/single OPP profile
>>> and also to fix the broken and unused binding
>>> @Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
>>>
>>> Regards,
>>> Sudeep
>>>
>>> [1] http://www.spinics.net/lists/cpufreq/msg06563.html
>>
>> Presumably the desire for cpu1's node to say "go look at cpu0's node for
>> OPP" is because they share OPPs. Don't they share OPPs because they are
>> parts of the same device - that device being the CPU complex. As such,
>> why not define the OPPs in /cpus rather than in each of /cpus/cpuN?
>
> I'd very much like for it to be possible to factor out common properties
> into the /cpus node, but it should follow the ePAPR recommendation fo
> being treated as a fallback if not present in a particular /cpus/cpu@N
> node -- that way we can handle clusters with differing OPPs. The
> property might just be a phandle to a table node, but it should be
> possible to make it common.
>
Yes we can have this fallback mechanism, but only from cpu devices(OPP
library handles non-cpu devices too).
Referring the table node, I have a generic question on DT nodes.
Does each DT node have to represent a unique device ? If so having a
property common to one/more devices in a separate node doesn't sound
correct.
>>
>> Of course, that doesn't help if there are separate CPU and GPU nodes
>> that just happen to have the same set of OPPs and you want to share them
>> to save DT space. Is that at all likely?
>
> I suspect that the OPPs for CPUs and GPUs are likely to be quite
> distict, and they are logically separate regardless. I'm not averse to
> sharing of tables if we can handle them in a standard fashion.
>
IMO sharing OPPs just for saving DT space might lead to confusions(no
strong opinion though).
>>
>> I'd suggest/bike-shed that operating-points-device is not the correct
>> property name; it somehow implies that the other device actively defines
>> the OPPs for this device, rather than just happening to have the same
>> OPPs. Perhaps "operating-points-identical-to"?
>>
>
> I'd rather not have properties that point elsewhere and say "treat me
> the same as this node". I'd rather we have common properties as
> described above.
>
Agreed, but for platforms with multiple CPU clusters, since we have only
one /cpus node, we ned to have table node which is arguable if node has
represent a device(as mentioned above)
Regards,
Sudeep
next prev parent reply other threads:[~2013-08-22 15:32 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 18:00 [RFC PATCH 0/2] PM / OPP: updates to enable sharing OPPs info Sudeep KarkadaNagesha
2013-07-30 18:00 ` [RFC PATCH 1/2] PM / OPP: add support to specify phandle of another node for OPP Sudeep KarkadaNagesha
2013-07-30 18:34 ` Stephen Warren
2013-07-30 20:48 ` Nishanth Menon
2013-07-30 21:25 ` Stephen Warren
2013-07-31 11:14 ` Sudeep KarkadaNagesha
2013-07-31 14:46 ` Nishanth Menon
2013-07-31 15:28 ` Sudeep KarkadaNagesha
2013-07-31 15:53 ` Nishanth Menon
2013-07-31 16:40 ` Sudeep KarkadaNagesha
2013-07-31 19:13 ` Nishanth Menon
2013-07-31 19:55 ` Nishanth Menon
2013-07-31 15:29 ` Mark Rutland
2013-07-31 15:58 ` Nishanth Menon
2013-07-31 16:11 ` Mark Rutland
2013-07-31 16:27 ` Nishanth Menon
2013-08-01 13:54 ` Mark Rutland
2013-08-01 16:25 ` Nishanth Menon
2013-08-02 13:15 ` Mark Rutland
2013-08-06 13:45 ` Nishanth Menon
2013-08-07 16:17 ` Mark Rutland
2013-08-20 10:00 ` Sudeep KarkadaNagesha
2013-08-20 14:01 ` Nishanth Menon
2013-08-20 16:07 ` Sudeep KarkadaNagesha
2013-08-21 22:48 ` Stephen Warren
2013-08-22 11:59 ` Mark Rutland
2013-08-22 15:32 ` Sudeep KarkadaNagesha [this message]
2013-08-22 15:50 ` Mark Rutland
2013-08-22 16:28 ` Sudeep KarkadaNagesha
2013-08-23 12:26 ` Mark Rutland
2013-08-01 16:49 ` Stephen Warren
2013-08-02 13:43 ` Sudeep KarkadaNagesha
2013-08-06 13:29 ` Nishanth Menon
2013-07-31 21:59 ` Stephen Warren
2013-07-31 21:59 ` Stephen Warren
2013-07-31 21:51 ` Stephen Warren
2013-08-01 12:15 ` Nishanth Menon
2013-08-01 16:46 ` Stephen Warren
2013-07-31 10:46 ` Sudeep KarkadaNagesha
2013-07-30 18:00 ` [RFC PATCH 2/2] PM / OPP: check for existing OPP list when initialising from device tree Sudeep KarkadaNagesha
2013-07-31 16:39 ` Nishanth Menon
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=52162EFA.2070108@arm.com \
--to=sudeep.karkadanagesha@arm.com \
--cc=Pawel.Moll@arm.com \
--cc=cpufreq@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=nm@ti.com \
--cc=rjw@sisk.pl \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.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.