From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Lina Iyer <lina.iyer@linaro.org>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Tomasz Figa <t.figa@samsung.com>,
Chander Kashyap <k.chander@samsung.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Nicolas Pitre <nico@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Kevin Hilman <khilman@linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Sebastian Capella <sebcape@gmail.com>,
Mark Brown <broonie@kernel.org>, Antti Miettinen <ananaza@iki.fi>,
Paul Walmsley <paul@pwsan.com>,
Geoff Levand <geoff@infradead.org>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
Stephen Boyd <sboyd@codeaurora.org>,
Amit
Subject: Re: [PATCH v7 2/8] Documentation: arm: define DT idle states bindings
Date: Wed, 13 Aug 2014 23:11:01 +0100 [thread overview]
Message-ID: <20140813221101.GA32697@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140813192533.GA32624@ilina-mac.local>
On Wed, Aug 13, 2014 at 08:25:36PM +0100, Lina Iyer wrote:
> Hi Lorenzo,
>
> On Wed, Aug 13, 2014 at 04:52:01PM +0100, Lorenzo Pieralisi wrote:
> >+===========================================
> >+4 - Examples
> >+===========================================
> >+
> >+Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
> >+
> >+cpus {
> >+ #size-cells = <0>;
> >+ #address-cells = <2>;
> >+
> >+ CPU0: cpu@0 {
> >+ device_type = "cpu";
> >+ compatible = "arm,cortex-a57";
> >+ reg = <0x0 0x0>;
> >+ enable-method = "psci";
> >+ cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> >+ &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> >+ };
> Sorry for jumping in late. I havent gone through all the patches yet or
> followed on previous discussions, if somebody could answer this or point
> me to the discussion, it would be great.
> Why is the cpu defining the possible cluster idle states? Would it be
> better that cluster states form a separate node, something like this -
>
> CLUSTER0: cluster@0 {
> ...
> cpus = <&CPU0 &CPU1 &CPU2 &CPU3>;
> cluster-idle-states = <&CLUTER_RETENTION_0, &CLUSTER_SLEEP_0>;
> };
> };
>
> Allowing for something like this to be defined -
>
> super_cluster0: cluster@101 {
> ...
> clusters = <&CLUSTER0 &CLUSTER1>;
> cluster-idle-states = <&SOC_RETENTION, &SOC_SLEEP>;
> };
> };
>
> And each cluster-idle-state follows the general idle definition as
> provided in this document, and an indicator what the compising
> components should idle at, for this idle state to be available.
>
> CLUSTER_SLEEP_0: cluster-sleep@0 {
> ...
> /* sleep definition for cluster0's retention */
> min-idle-state = <CPU_SLEEP_0>;
> };
>
> SOC_SLEEP: cluster-sleep@101 {
> ...
> min-idle-state = <&CLUSTER_SLEEP_0>;
> };
>
>
> Opens up the idle state for a lot of heirarchical possibilities, which
> if you think, is generally how the SoC is.
We have been thinking for 7 patch versions + some more for this specific
document, which is ready to go after extensive debate.
It is probably better to have a look at archives first since honestly it
is impossible to summarize 6 months worth of discussions in few lines.
I think the hierarchy you mention should be implemented using power
domains, which is how the SoC implements power management and that's
what defines idle states hierarchy.
To be 100% precise, I would like to detect what cpus are affected by an
idle state entry by defining for each idle state what power domain
(which can be hierarchical) is affected, not by grouping them under
a tag "cluster" "supercluster" or whatchamacallit.
I removed power domains to simplify the current proposal which is sufficient
as a starting point, but they are next on my TODO list and were part of the
initial bindings, consider yourself welcome to help us define the way forward
keeping this document as a starting point.
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 2/8] Documentation: arm: define DT idle states bindings
Date: Wed, 13 Aug 2014 23:11:01 +0100 [thread overview]
Message-ID: <20140813221101.GA32697@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140813192533.GA32624@ilina-mac.local>
On Wed, Aug 13, 2014 at 08:25:36PM +0100, Lina Iyer wrote:
> Hi Lorenzo,
>
> On Wed, Aug 13, 2014 at 04:52:01PM +0100, Lorenzo Pieralisi wrote:
> >+===========================================
> >+4 - Examples
> >+===========================================
> >+
> >+Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
> >+
> >+cpus {
> >+ #size-cells = <0>;
> >+ #address-cells = <2>;
> >+
> >+ CPU0: cpu at 0 {
> >+ device_type = "cpu";
> >+ compatible = "arm,cortex-a57";
> >+ reg = <0x0 0x0>;
> >+ enable-method = "psci";
> >+ cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
> >+ &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
> >+ };
> Sorry for jumping in late. I havent gone through all the patches yet or
> followed on previous discussions, if somebody could answer this or point
> me to the discussion, it would be great.
> Why is the cpu defining the possible cluster idle states? Would it be
> better that cluster states form a separate node, something like this -
>
> CLUSTER0: cluster at 0 {
> ...
> cpus = <&CPU0 &CPU1 &CPU2 &CPU3>;
> cluster-idle-states = <&CLUTER_RETENTION_0, &CLUSTER_SLEEP_0>;
> };
> };
>
> Allowing for something like this to be defined -
>
> super_cluster0: cluster at 101 {
> ...
> clusters = <&CLUSTER0 &CLUSTER1>;
> cluster-idle-states = <&SOC_RETENTION, &SOC_SLEEP>;
> };
> };
>
> And each cluster-idle-state follows the general idle definition as
> provided in this document, and an indicator what the compising
> components should idle at, for this idle state to be available.
>
> CLUSTER_SLEEP_0: cluster-sleep at 0 {
> ...
> /* sleep definition for cluster0's retention */
> min-idle-state = <CPU_SLEEP_0>;
> };
>
> SOC_SLEEP: cluster-sleep at 101 {
> ...
> min-idle-state = <&CLUSTER_SLEEP_0>;
> };
>
>
> Opens up the idle state for a lot of heirarchical possibilities, which
> if you think, is generally how the SoC is.
We have been thinking for 7 patch versions + some more for this specific
document, which is ready to go after extensive debate.
It is probably better to have a look at archives first since honestly it
is impossible to summarize 6 months worth of discussions in few lines.
I think the hierarchy you mention should be implemented using power
domains, which is how the SoC implements power management and that's
what defines idle states hierarchy.
To be 100% precise, I would like to detect what cpus are affected by an
idle state entry by defining for each idle state what power domain
(which can be hierarchical) is affected, not by grouping them under
a tag "cluster" "supercluster" or whatchamacallit.
I removed power domains to simplify the current proposal which is sufficient
as a starting point, but they are next on my TODO list and were part of the
initial bindings, consider yourself welcome to help us define the way forward
keeping this document as a starting point.
Lorenzo
next prev parent reply other threads:[~2014-08-13 22:11 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 15:51 [PATCH v7 0/8] ARM generic idle states Lorenzo Pieralisi
2014-08-13 15:51 ` Lorenzo Pieralisi
2014-08-13 15:52 ` [PATCH v7 1/8] arm64: kernel: refactor the CPU suspend API for retention states Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
2014-08-18 7:47 ` Hanjun Guo
2014-08-18 7:47 ` Hanjun Guo
2014-08-18 14:20 ` Catalin Marinas
2014-08-18 14:20 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 2/8] Documentation: arm: define DT idle states bindings Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
[not found] ` <1407945127-27554-3-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2014-08-13 19:25 ` Lina Iyer
2014-08-13 19:25 ` Lina Iyer
2014-08-13 22:11 ` Lorenzo Pieralisi [this message]
2014-08-13 22:11 ` Lorenzo Pieralisi
2014-08-15 17:20 ` Lina Iyer
2014-08-15 17:20 ` Lina Iyer
2014-08-15 17:51 ` Lorenzo Pieralisi
2014-08-15 17:51 ` Lorenzo Pieralisi
2014-08-18 14:20 ` Catalin Marinas
2014-08-18 14:20 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 3/8] drivers: cpuidle: implement DT based idle states infrastructure Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
2014-08-13 16:31 ` Nicolas Pitre
2014-08-13 16:31 ` Nicolas Pitre
2014-08-13 17:04 ` Lorenzo Pieralisi
2014-08-13 17:04 ` Lorenzo Pieralisi
2014-08-13 17:29 ` Nicolas Pitre
2014-08-13 17:29 ` Nicolas Pitre
2014-08-14 11:29 ` Lorenzo Pieralisi
2014-08-14 11:29 ` Lorenzo Pieralisi
2014-08-14 15:47 ` Nicolas Pitre
2014-08-14 15:47 ` Nicolas Pitre
2014-08-14 16:02 ` Lorenzo Pieralisi
2014-08-14 16:02 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 14:21 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 4/8] arm64: kernel: introduce cpu_init_idle CPU operation Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 14:21 ` Catalin Marinas
[not found] ` <1407945127-27554-1-git-send-email-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
2014-08-13 15:52 ` [PATCH v7 5/8] arm64: add PSCI CPU_SUSPEND based cpu_suspend support Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 14:21 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 6/8] drivers: cpuidle: CPU idle ARM64 driver Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 22:30 ` Lorenzo Pieralisi
2014-08-18 22:30 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 22:25 ` Lorenzo Pieralisi
2014-08-18 22:25 ` Lorenzo Pieralisi
2014-08-13 15:52 ` [PATCH v7 7/8] drivers: cpuidle: initialize big.LITTLE driver through DT Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 14:21 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 8/8] drivers: cpuidle: initialize Exynos " Lorenzo Pieralisi
2014-08-13 15:52 ` Lorenzo Pieralisi
2014-08-15 21:12 ` Lina Iyer
2014-08-15 21:12 ` Lina Iyer
2014-08-15 21:40 ` Lorenzo Pieralisi
2014-08-15 21:40 ` Lorenzo Pieralisi
2014-08-15 21:45 ` Lina Iyer
2014-08-15 21:45 ` Lina Iyer
2014-08-15 21:52 ` Lorenzo Pieralisi
2014-08-15 21:52 ` Lorenzo Pieralisi
2014-08-18 14:22 ` Catalin Marinas
2014-08-18 14:22 ` Catalin Marinas
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=20140813221101.GA32697@e102568-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Charles.Garcia-Tobin@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=ananaza@iki.fi \
--cc=broonie@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=geoff@infradead.org \
--cc=grant.likely@linaro.org \
--cc=k.chander@samsung.com \
--cc=khilman@linaro.org \
--cc=lina.iyer@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=nico@linaro.org \
--cc=paul@pwsan.com \
--cc=pdeschrijver@nvidia.com \
--cc=sboyd@codeaurora.org \
--cc=sebcape@gmail.com \
--cc=t.figa@samsung.com \
--cc=vincent.guittot@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.