[v9,04/11] dt: psci: Update DT bindings to support hierarchical PSCI states
diff mbox series

Message ID 20181003143824.13059-5-ulf.hansson@linaro.org
State Not Applicable, archived
Headers show
Series
  • PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)
Related show

Commit Message

Ulf Hansson Oct. 3, 2018, 2:38 p.m. UTC
From: Lina Iyer <lina.iyer@linaro.org>

Update DT bindings to represent hierarchical CPU and CPU PM domain idle
states for PSCI. Also update the PSCI examples to clearly show how
flattened and hierarchical idle states can be represented in DT.

Cc: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Co-developed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
---
 .../devicetree/bindings/arm/psci.txt          | 156 ++++++++++++++++++
 1 file changed, 156 insertions(+)

Comments

Sudeep Holla Oct. 10, 2018, 3:03 p.m. UTC | #1
On Wed, Oct 03, 2018 at 04:38:17PM +0200, Ulf Hansson wrote:
> From: Lina Iyer <lina.iyer@linaro.org>
> 
> Update DT bindings to represent hierarchical CPU and CPU PM domain idle
> states for PSCI. Also update the PSCI examples to clearly show how
> flattened and hierarchical idle states can be represented in DT.
> 
> Cc: Lina Iyer <ilina@codeaurora.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> Co-developed-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  .../devicetree/bindings/arm/psci.txt          | 156 ++++++++++++++++++
>  1 file changed, 156 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> index a2c4f1d52492..17aa3d3a1c8e 100644
> --- a/Documentation/devicetree/bindings/arm/psci.txt
> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> @@ -105,7 +105,163 @@ Case 3: PSCI v0.2 and PSCI v0.1.
>  		...
>  	};
>  
> +ARM systems can have multiple cores sometimes in hierarchical arrangement.
> +This often, but not always, maps directly to the processor power topology of
> +the system. Individual nodes in a topology have their own specific power states
> +and can be better represented in DT hierarchically.
> +
> +For these cases, the definitions of the idle states for the CPUs and the CPU
> +topology, must conform to the domain idle state specification [3]. The domain
> +idle states themselves, must be compatible with the defined 'domain-idle-state'
> +binding [1], and also need to specify the arm,psci-suspend-param property for
> +each idle state.
> +
> +DT allows representing CPUs and CPU idle states in two different ways -
> +
> +The flattened model as given in Example 1, lists CPU's idle states followed by
> +the domain idle state that the CPUs may choose. Note that the idle states are
> +all compatible with "arm,idle-state".
> +
> +Example 2 represents the hierarchical model of CPUs and domain idle states.
> +CPUs define their domain provider in their psci DT node. The domain controls
> +the power to the CPU and possibly other h/w blocks that would enter an idle
> +state along with the CPU. The CPU's idle states may therefore be considered as
> +the domain's idle states and have the compatible "arm,idle-state". Such domains
> +may also be embedded within another domain that may represent common h/w blocks
> +between these CPUs. The idle states of the CPU topology shall be represented as
> +the domain's idle states.
> +
> +In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order to use it,
> +the hierarchical representation must be used.
> +
> +Example 1: Flattened representation of CPU and domain idle states

[...]

> +Example 2: Hierarchical representation of CPU and domain idle states

I understand that this may not be of interest for this series, but do
we need to add any suggestions on how to arrive Flattened representation
of CPU idle states from its hierarchical representation. If the DT has
latter and PSCI call returns as PC mode only for idle. We need to deal
with that case.

--
Regards,
Sudeep
Ulf Hansson Oct. 11, 2018, 2:44 p.m. UTC | #2
+Raju

On 10 October 2018 at 17:03, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Wed, Oct 03, 2018 at 04:38:17PM +0200, Ulf Hansson wrote:
>> From: Lina Iyer <lina.iyer@linaro.org>
>>
>> Update DT bindings to represent hierarchical CPU and CPU PM domain idle
>> states for PSCI. Also update the PSCI examples to clearly show how
>> flattened and hierarchical idle states can be represented in DT.
>>
>> Cc: Lina Iyer <ilina@codeaurora.org>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Co-developed-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>  .../devicetree/bindings/arm/psci.txt          | 156 ++++++++++++++++++
>>  1 file changed, 156 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
>> index a2c4f1d52492..17aa3d3a1c8e 100644
>> --- a/Documentation/devicetree/bindings/arm/psci.txt
>> +++ b/Documentation/devicetree/bindings/arm/psci.txt
>> @@ -105,7 +105,163 @@ Case 3: PSCI v0.2 and PSCI v0.1.
>>               ...
>>       };
>>
>> +ARM systems can have multiple cores sometimes in hierarchical arrangement.
>> +This often, but not always, maps directly to the processor power topology of
>> +the system. Individual nodes in a topology have their own specific power states
>> +and can be better represented in DT hierarchically.
>> +
>> +For these cases, the definitions of the idle states for the CPUs and the CPU
>> +topology, must conform to the domain idle state specification [3]. The domain
>> +idle states themselves, must be compatible with the defined 'domain-idle-state'
>> +binding [1], and also need to specify the arm,psci-suspend-param property for
>> +each idle state.
>> +
>> +DT allows representing CPUs and CPU idle states in two different ways -
>> +
>> +The flattened model as given in Example 1, lists CPU's idle states followed by
>> +the domain idle state that the CPUs may choose. Note that the idle states are
>> +all compatible with "arm,idle-state".
>> +
>> +Example 2 represents the hierarchical model of CPUs and domain idle states.
>> +CPUs define their domain provider in their psci DT node. The domain controls
>> +the power to the CPU and possibly other h/w blocks that would enter an idle
>> +state along with the CPU. The CPU's idle states may therefore be considered as
>> +the domain's idle states and have the compatible "arm,idle-state". Such domains
>> +may also be embedded within another domain that may represent common h/w blocks
>> +between these CPUs. The idle states of the CPU topology shall be represented as
>> +the domain's idle states.
>> +
>> +In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order to use it,
>> +the hierarchical representation must be used.
>> +
>> +Example 1: Flattened representation of CPU and domain idle states
>
> [...]
>
>> +Example 2: Hierarchical representation of CPU and domain idle states
>
> I understand that this may not be of interest for this series, but do
> we need to add any suggestions on how to arrive Flattened representation
> of CPU idle states from its hierarchical representation. If the DT has
> latter and PSCI call returns as PC mode only for idle. We need to deal
> with that case.

For sure, I think this is valid comment for this series (or at least
v8 which contains the hole set).

The approach I have taken, so far, is to closely tie the support for
PSCI OSI mode to the hierarchical representation in DT of the idle
states. Simply because of changing as little as possible, in a first
step, then build on top.

However, in the offlist discussion I had with Lorenzo, he raised a
concern, very similar to what you are bringing up here. There are
indeed platform configurations, using PSCI PC mode, which would
benefit from the using the hierarchical representation. BTW, that is
kind of what Raju just tried to get working for QCOM SDM845 [1], but
let's discuss that separately.

The conclusion I made, is that no matter of we are using the PC mode
or the OSI mode, the hierarchical representation shall just work.

To me, this means that I have to re-work the series, such that the
PSCI driver (and cpuidle), dynamically in runtime, can agree on which
of the idle states that are "shared among a group of CPUs" and which
are CPU specific. Exactly how, I am still exploring a few different
approaches on.

Does it make sense?

So, when it comes to the updated DT bindings in regards to $subject
patch, I think it's good as is. Or do you think there is something
that needs to be clarified?

Thanks for reviewing!

Kind regards
Uffe

[1]
https://lkml.org/lkml/2018/10/11/28
Sudeep Holla Oct. 11, 2018, 4:41 p.m. UTC | #3
On Thu, Oct 11, 2018 at 04:44:07PM +0200, Ulf Hansson wrote:
> +Raju
>
> On 10 October 2018 at 17:03, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On Wed, Oct 03, 2018 at 04:38:17PM +0200, Ulf Hansson wrote:
> >> From: Lina Iyer <lina.iyer@linaro.org>
> >>
> >> Update DT bindings to represent hierarchical CPU and CPU PM domain idle
> >> states for PSCI. Also update the PSCI examples to clearly show how
> >> flattened and hierarchical idle states can be represented in DT.
> >>
> >> Cc: Lina Iyer <ilina@codeaurora.org>
> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> >> Co-developed-by: Ulf Hansson <ulf.hansson@linaro.org>
> >> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> >> Reviewed-by: Rob Herring <robh@kernel.org>
> >> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> >> ---
> >>  .../devicetree/bindings/arm/psci.txt          | 156 ++++++++++++++++++
> >>  1 file changed, 156 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> >> index a2c4f1d52492..17aa3d3a1c8e 100644
> >> --- a/Documentation/devicetree/bindings/arm/psci.txt
> >> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> >> @@ -105,7 +105,163 @@ Case 3: PSCI v0.2 and PSCI v0.1.
> >>               ...
> >>       };
> >>
> >> +ARM systems can have multiple cores sometimes in hierarchical arrangement.
> >> +This often, but not always, maps directly to the processor power topology of
> >> +the system. Individual nodes in a topology have their own specific power states
> >> +and can be better represented in DT hierarchically.
> >> +
> >> +For these cases, the definitions of the idle states for the CPUs and the CPU
> >> +topology, must conform to the domain idle state specification [3]. The domain
> >> +idle states themselves, must be compatible with the defined 'domain-idle-state'
> >> +binding [1], and also need to specify the arm,psci-suspend-param property for
> >> +each idle state.
> >> +
> >> +DT allows representing CPUs and CPU idle states in two different ways -
> >> +
> >> +The flattened model as given in Example 1, lists CPU's idle states followed by
> >> +the domain idle state that the CPUs may choose. Note that the idle states are
> >> +all compatible with "arm,idle-state".
> >> +
> >> +Example 2 represents the hierarchical model of CPUs and domain idle states.
> >> +CPUs define their domain provider in their psci DT node. The domain controls
> >> +the power to the CPU and possibly other h/w blocks that would enter an idle
> >> +state along with the CPU. The CPU's idle states may therefore be considered as
> >> +the domain's idle states and have the compatible "arm,idle-state". Such domains
> >> +may also be embedded within another domain that may represent common h/w blocks
> >> +between these CPUs. The idle states of the CPU topology shall be represented as
> >> +the domain's idle states.
> >> +
> >> +In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order to use it,
> >> +the hierarchical representation must be used.
> >> +
> >> +Example 1: Flattened representation of CPU and domain idle states
> >
> > [...]
> >
> >> +Example 2: Hierarchical representation of CPU and domain idle states
> >
> > I understand that this may not be of interest for this series, but do
> > we need to add any suggestions on how to arrive Flattened representation
> > of CPU idle states from its hierarchical representation. If the DT has
> > latter and PSCI call returns as PC mode only for idle. We need to deal
> > with that case.
>
> For sure, I think this is valid comment for this series (or at least
> v8 which contains the hole set).
>

Thanks.

> The approach I have taken, so far, is to closely tie the support for
> PSCI OSI mode to the hierarchical representation in DT of the idle
> states. Simply because of changing as little as possible, in a first
> step, then build on top.
>

That's fine. I just want a note in the bindings to state that we can use
the hierarchical representation and generate flattened list for PC.

> However, in the offlist discussion I had with Lorenzo, he raised a
> concern, very similar to what you are bringing up here. There are
> indeed platform configurations, using PSCI PC mode, which would
> benefit from the using the hierarchical representation. BTW, that is
> kind of what Raju just tried to get working for QCOM SDM845 [1], but
> let's discuss that separately.
>

OK, we can discuss details in that thread, but I don't even see the PSCI
domains there.

> The conclusion I made, is that no matter of we are using the PC mode
> or the OSI mode, the hierarchical representation shall just work.
>

Indeed.

> To me, this means that I have to re-work the series, such that the
> PSCI driver (and cpuidle), dynamically in runtime, can agree on which
> of the idle states that are "shared among a group of CPUs" and which
> are CPU specific. Exactly how, I am still exploring a few different
> approaches on.
>
> Does it make sense?
>

Yes

> So, when it comes to the updated DT bindings in regards to $subject
> patch, I think it's good as is. Or do you think there is something
> that needs to be clarified?
>

Yes, nearly there. Just thought good to add a note that the representation
has no affinity towards any PSCI idle state mechanism(PC or OSI). So
that it's never assumed or misunderstood.

--
Regards,
Sudeep
Ulf Hansson Oct. 12, 2018, 9:43 a.m. UTC | #4
On 11 October 2018 at 18:41, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Thu, Oct 11, 2018 at 04:44:07PM +0200, Ulf Hansson wrote:
>> +Raju
>>
>> On 10 October 2018 at 17:03, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> > On Wed, Oct 03, 2018 at 04:38:17PM +0200, Ulf Hansson wrote:
>> >> From: Lina Iyer <lina.iyer@linaro.org>
>> >>
>> >> Update DT bindings to represent hierarchical CPU and CPU PM domain idle
>> >> states for PSCI. Also update the PSCI examples to clearly show how
>> >> flattened and hierarchical idle states can be represented in DT.
>> >>
>> >> Cc: Lina Iyer <ilina@codeaurora.org>
>> >> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> >> Co-developed-by: Ulf Hansson <ulf.hansson@linaro.org>
>> >> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> >> Reviewed-by: Rob Herring <robh@kernel.org>
>> >> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>> >> ---
>> >>  .../devicetree/bindings/arm/psci.txt          | 156 ++++++++++++++++++
>> >>  1 file changed, 156 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
>> >> index a2c4f1d52492..17aa3d3a1c8e 100644
>> >> --- a/Documentation/devicetree/bindings/arm/psci.txt
>> >> +++ b/Documentation/devicetree/bindings/arm/psci.txt
>> >> @@ -105,7 +105,163 @@ Case 3: PSCI v0.2 and PSCI v0.1.
>> >>               ...
>> >>       };
>> >>
>> >> +ARM systems can have multiple cores sometimes in hierarchical arrangement.
>> >> +This often, but not always, maps directly to the processor power topology of
>> >> +the system. Individual nodes in a topology have their own specific power states
>> >> +and can be better represented in DT hierarchically.
>> >> +
>> >> +For these cases, the definitions of the idle states for the CPUs and the CPU
>> >> +topology, must conform to the domain idle state specification [3]. The domain
>> >> +idle states themselves, must be compatible with the defined 'domain-idle-state'
>> >> +binding [1], and also need to specify the arm,psci-suspend-param property for
>> >> +each idle state.
>> >> +
>> >> +DT allows representing CPUs and CPU idle states in two different ways -
>> >> +
>> >> +The flattened model as given in Example 1, lists CPU's idle states followed by
>> >> +the domain idle state that the CPUs may choose. Note that the idle states are
>> >> +all compatible with "arm,idle-state".
>> >> +
>> >> +Example 2 represents the hierarchical model of CPUs and domain idle states.
>> >> +CPUs define their domain provider in their psci DT node. The domain controls
>> >> +the power to the CPU and possibly other h/w blocks that would enter an idle
>> >> +state along with the CPU. The CPU's idle states may therefore be considered as
>> >> +the domain's idle states and have the compatible "arm,idle-state". Such domains
>> >> +may also be embedded within another domain that may represent common h/w blocks
>> >> +between these CPUs. The idle states of the CPU topology shall be represented as
>> >> +the domain's idle states.
>> >> +
>> >> +In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order to use it,
>> >> +the hierarchical representation must be used.
>> >> +
>> >> +Example 1: Flattened representation of CPU and domain idle states
>> >
>> > [...]
>> >
>> >> +Example 2: Hierarchical representation of CPU and domain idle states
>> >
>> > I understand that this may not be of interest for this series, but do
>> > we need to add any suggestions on how to arrive Flattened representation
>> > of CPU idle states from its hierarchical representation. If the DT has
>> > latter and PSCI call returns as PC mode only for idle. We need to deal
>> > with that case.
>>
>> For sure, I think this is valid comment for this series (or at least
>> v8 which contains the hole set).
>>
>
> Thanks.
>
>> The approach I have taken, so far, is to closely tie the support for
>> PSCI OSI mode to the hierarchical representation in DT of the idle
>> states. Simply because of changing as little as possible, in a first
>> step, then build on top.
>>
>
> That's fine. I just want a note in the bindings to state that we can use
> the hierarchical representation and generate flattened list for PC.

OK, let's discuss it below.

>
>> However, in the offlist discussion I had with Lorenzo, he raised a
>> concern, very similar to what you are bringing up here. There are
>> indeed platform configurations, using PSCI PC mode, which would
>> benefit from the using the hierarchical representation. BTW, that is
>> kind of what Raju just tried to get working for QCOM SDM845 [1], but
>> let's discuss that separately.
>>
>
> OK, we can discuss details in that thread, but I don't even see the PSCI
> domains there.
>
>> The conclusion I made, is that no matter of we are using the PC mode
>> or the OSI mode, the hierarchical representation shall just work.
>>
>
> Indeed.
>
>> To me, this means that I have to re-work the series, such that the
>> PSCI driver (and cpuidle), dynamically in runtime, can agree on which
>> of the idle states that are "shared among a group of CPUs" and which
>> are CPU specific. Exactly how, I am still exploring a few different
>> approaches on.
>>
>> Does it make sense?
>>
>
> Yes

Great!

>
>> So, when it comes to the updated DT bindings in regards to $subject
>> patch, I think it's good as is. Or do you think there is something
>> that needs to be clarified?
>>
>
> Yes, nearly there. Just thought good to add a note that the representation
> has no affinity towards any PSCI idle state mechanism(PC or OSI). So
> that it's never assumed or misunderstood.

I understand your point. However, I think the following sentence still
makes sense (exist in the suggest change above).

"In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order
to use it, the hierarchical representation must be used."

How about if I add: "For the default platform-coordinated mode, both
representations are viable options."

Kind regards
Uffe
Sudeep Holla Oct. 12, 2018, 10:13 a.m. UTC | #5
On Fri, Oct 12, 2018 at 11:43:11AM +0200, Ulf Hansson wrote:
> On 11 October 2018 at 18:41, Sudeep Holla <sudeep.holla@arm.com> wrote:
[...]

> > Yes, nearly there. Just thought good to add a note that the representation
> > has no affinity towards any PSCI idle state mechanism(PC or OSI). So
> > that it's never assumed or misunderstood.
>
> I understand your point. However, I think the following sentence still
> makes sense (exist in the suggest change above).
>
> "In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order
> to use it, the hierarchical representation must be used."
>
> How about if I add: "For the default platform-coordinated mode, both
> representations are viable options."
>
I would also add couple of things, how about this order:

In PSCI firmware v1.0, the OS-Initiated mode is introduced. However the
flattened vs hierarchical DT representation of power domains is orthogonal
to OS-Initiated vs platform-coordinated PSCI CPU suspend modes and
should be considered independent of each other.

The hierarchical representation helps and makes it easy to implement
OSI mode and OS implementations may choose to mandate it.

For the default platform-coordinated mode, both representations are
viable options.

--
Regards,
Sudeep
Ulf Hansson Oct. 12, 2018, 10:24 a.m. UTC | #6
On 12 October 2018 at 12:13, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Fri, Oct 12, 2018 at 11:43:11AM +0200, Ulf Hansson wrote:
>> On 11 October 2018 at 18:41, Sudeep Holla <sudeep.holla@arm.com> wrote:
> [...]
>
>> > Yes, nearly there. Just thought good to add a note that the representation
>> > has no affinity towards any PSCI idle state mechanism(PC or OSI). So
>> > that it's never assumed or misunderstood.
>>
>> I understand your point. However, I think the following sentence still
>> makes sense (exist in the suggest change above).
>>
>> "In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order
>> to use it, the hierarchical representation must be used."
>>
>> How about if I add: "For the default platform-coordinated mode, both
>> representations are viable options."
>>
> I would also add couple of things, how about this order:
>
> In PSCI firmware v1.0, the OS-Initiated mode is introduced. However the
> flattened vs hierarchical DT representation of power domains is orthogonal
> to OS-Initiated vs platform-coordinated PSCI CPU suspend modes and
> should be considered independent of each other.
>
> The hierarchical representation helps and makes it easy to implement
> OSI mode and OS implementations may choose to mandate it.
>
> For the default platform-coordinated mode, both representations are
> viable options.

This looks great! I am adding it to the next version, thanks!

Kind regards
Uffe

Patch
diff mbox series

diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index a2c4f1d52492..17aa3d3a1c8e 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -105,7 +105,163 @@  Case 3: PSCI v0.2 and PSCI v0.1.
 		...
 	};
 
+ARM systems can have multiple cores sometimes in hierarchical arrangement.
+This often, but not always, maps directly to the processor power topology of
+the system. Individual nodes in a topology have their own specific power states
+and can be better represented in DT hierarchically.
+
+For these cases, the definitions of the idle states for the CPUs and the CPU
+topology, must conform to the domain idle state specification [3]. The domain
+idle states themselves, must be compatible with the defined 'domain-idle-state'
+binding [1], and also need to specify the arm,psci-suspend-param property for
+each idle state.
+
+DT allows representing CPUs and CPU idle states in two different ways -
+
+The flattened model as given in Example 1, lists CPU's idle states followed by
+the domain idle state that the CPUs may choose. Note that the idle states are
+all compatible with "arm,idle-state".
+
+Example 2 represents the hierarchical model of CPUs and domain idle states.
+CPUs define their domain provider in their psci DT node. The domain controls
+the power to the CPU and possibly other h/w blocks that would enter an idle
+state along with the CPU. The CPU's idle states may therefore be considered as
+the domain's idle states and have the compatible "arm,idle-state". Such domains
+may also be embedded within another domain that may represent common h/w blocks
+between these CPUs. The idle states of the CPU topology shall be represented as
+the domain's idle states.
+
+In PSCI firmware v1.0, the OS-Initiated mode is introduced. In order to use it,
+the hierarchical representation must be used.
+
+Example 1: Flattened representation of CPU and domain idle states
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		CPU0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
+					  <&CLUSTER_PWRDN>;
+		};
+
+		CPU1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57", "arm,armv8";
+			reg = <0x100>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
+					  <&CLUSTER_PWRDN>;
+		};
+
+		idle-states {
+			CPU_PWRDN: cpu-power-down {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x000001>;
+				entry-latency-us = <10>;
+				exit-latency-us = <10>;
+				min-residency-us = <100>;
+			};
+
+			CLUSTER_RET: cluster-retention {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x1000010>;
+				entry-latency-us = <500>;
+				exit-latency-us = <500>;
+				min-residency-us = <2000>;
+			};
+
+			CLUSTER_PWRDN: cluster-power-down {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x1000030>;
+				entry-latency-us = <2000>;
+				exit-latency-us = <2000>;
+				min-residency-us = <6000>;
+			};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+Example 2: Hierarchical representation of CPU and domain idle states
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		CPU0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0>;
+			enable-method = "psci";
+			power-domains = <&CPU_PD0>;
+		};
+
+		CPU1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57", "arm,armv8";
+			reg = <0x100>;
+			enable-method = "psci";
+			power-domains = <&CPU_PD1>;
+		};
+
+		idle-states {
+			CPU_PWRDN: cpu-power-down {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x000001>;
+				entry-latency-us = <10>;
+				exit-latency-us = <10>;
+				min-residency-us = <100>;
+			};
+
+			CLUSTER_RET: cluster-retention {
+				compatible = "domain-idle-state";
+				arm,psci-suspend-param = <0x1000010>;
+				entry-latency-us = <500>;
+				exit-latency-us = <500>;
+				min-residency-us = <2000>;
+			};
+
+			CLUSTER_PWRDN: cluster-power-down {
+				compatible = "domain-idle-state";
+				arm,psci-suspend-param = <0x1000030>;
+				entry-latency-us = <2000>;
+				exit-latency-us = <2000>;
+				min-residency-us = <6000>;
+			};
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+
+		CPU_PD0: cpu-pd0 {
+			#power-domain-cells = <0>;
+			domain-idle-states = <&CPU_PWRDN>;
+			power-domains = <&CLUSTER_PD>;
+		};
+
+		CPU_PD1: cpu-pd1 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&CPU_PWRDN>;
+			power-domains = <&CLUSTER_PD>;
+		};
+
+		CLUSTER_PD: cluster-pd {
+			#power-domain-cells = <0>;
+			domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWRDN>;
+		};
+	};
+
 [1] Kernel documentation - ARM idle states bindings
     Documentation/devicetree/bindings/arm/idle-states.txt
 [2] Power State Coordination Interface (PSCI) specification
     http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
+[3]. PM Domains description
+    Documentation/devicetree/bindings/power/power_domain.txt