From: Stephen Warren <swarren@wwwdotorg.org>
To: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
Cc: Mark Rutland <mark.rutland@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: Wed, 21 Aug 2013 16:48:12 -0600 [thread overview]
Message-ID: <521543AC.4020709@wwwdotorg.org> (raw)
In-Reply-To: <52133E26.1000801@arm.com>
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?
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'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"?
next prev parent reply other threads:[~2013-08-21 22:48 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 [this message]
2013-08-22 11:59 ` Mark Rutland
2013-08-22 15:32 ` Sudeep KarkadaNagesha
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=521543AC.4020709@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=Pawel.Moll@arm.com \
--cc=Sudeep.KarkadaNagesha@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 \
/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.