[PATCH 02/14] dt/bindings: update binding for PM domain idle states

[PATCH 02/14] dt/bindings: update binding for PM domain idle states

[Lina Iyer]

From: Axel Haslam <ahaslam+renesas-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Update DT bindings to describe idle states of PM domains.

Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Signed-off-by: Marc Titinger <mtitinger+renesas-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[Lina: Added state properties, removed state names, wakeup-latency,
added of_pm_genpd_init() API, pruned commit text]
Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[Ulf: Moved around code to make it compile properly, rebased on top of multiple state support]
---
 .../devicetree/bindings/power/power_domain.txt     | 70 ++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7..41e8dda 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,43 @@ Optional properties:
    specified by this binding. More details about power domain specifier are
    available in the next section.
 
+- power-states : A phandle of an idle-state that shall be soaked into a
+                generic domain power state.
+
+==Power state==
+
+A PM domain power state describes an idle state of a domain and must be
+have the following properties -
+
+	- entry-latency-us
+		Usage: Not required if wakeup-latency-us is provided.
+		Value type: <prop-encoded-array>
+		Definition: u32 value representing worst case latency in
+		microseconds required to enter the idle state.
+		The exit-latency-us duration may be guaranteed
+		only after entry-latency-us has passed.
+
+	- exit-latency-us
+		Usage: Not required if wakeup-latency-us is provided.
+		Value type: <prop-encoded-array>
+		Definition: u32 value representing worst case latency
+		in microseconds required to exit the idle state.
+
+	- residency-us:
+		Usage: Optional
+		Value type: <prop-encoded-array>
+		Definition: A u32 value representing the time for which a
+		domain must be idle in the state to reap power saving benefits
+		of entering the state.
+
+	- state-param:
+		Usage: Optional
+		Value type: <prop-encoded-array>
+		Definition: A u32 value as defined by the state. May be used
+		by the driver to hold state related u32 data. In the case of
+		PSCI, an extended state-id for the domain may be encoded in
+		this value.
+
 Example:
 
 	power: power-controller@12340000 {
@@ -55,6 +92,39 @@ Example 2:
 		#power-domain-cells = <1>;
 	};
 
+Example 3:
+
+	pm-domains {
+		a57_pd: a57_pd@ {
+			/* will have a57 platform ARM_PD_METHOD_OF_DECLARE*/
+			compatible = "arm,pd","arm,cortex-a57";
+			#power-domain-cells = <0>;
+			power-states = <&CLUSTER_SLEEP_0>;
+		};
+
+		a53_pd: a53_pd@ {
+			/* will have a a53 platform ARM_PD_METHOD_OF_DECLARE*/
+			compatible = "arm,pd","arm,cortex-a53";
+			#power-domain-cells = <0>;
+			power-states = <&CLUSTER_SLEEP_0>, <&CLUSTER_SLEEP_1>;
+		};
+
+		CLUSTER_SLEEP_0: power-state@0 {
+			entry-latency-us = <1000>;
+			exit-latency-us = <2000>;
+			residency-us = <10000>;
+			state-param = <0x1000010>;
+		};
+
+		CLUSTER_SLEEP_1: power-state@1 {
+			entry-latency-us = <5000>;
+			exit-latency-us = <5000>;
+			residency-us = <100000>;
+			state-param = <0x1000020>;
+		};
+	};
+
+
 The nodes above define two power controllers: 'parent' and 'child'.
 Domains created by the 'child' power controller are subdomains of '0' power
 domain provided by the 'parent' power controller.
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/14] dt/bindings: update binding for PM domain idle states

[Mark Rutland]

Hi,

On Wed, Jun 22, 2016 at 01:36:37PM -0600, Lina Iyer wrote:
> From: Axel Haslam <ahaslam+renesas-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> 
> Update DT bindings to describe idle states of PM domains.
> 
> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Signed-off-by: Marc Titinger <mtitinger+renesas-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> [Lina: Added state properties, removed state names, wakeup-latency,
> added of_pm_genpd_init() API, pruned commit text]
> Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> [Ulf: Moved around code to make it compile properly, rebased on top of multiple state support]
> ---
>  .../devicetree/bindings/power/power_domain.txt     | 70 ++++++++++++++++++++++
>  1 file changed, 70 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 025b5e7..41e8dda 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -29,6 +29,43 @@ Optional properties:
>     specified by this binding. More details about power domain specifier are
>     available in the next section.
>  
> +- power-states : A phandle of an idle-state that shall be soaked into a
> +                generic domain power state.

It's somewhat unfortunate that this gives us two possible locations for
idle state lists (under the /cpus node and in a pm-domains node),
especially as it's not clear what would happen were a DT to have both.

I would prefer that we extend the existing bindings such that states can
refer to the power domains which they affect.

> +==Power state==
> +
> +A PM domain power state describes an idle state of a domain and must be
> +have the following properties -
> +
> +	- entry-latency-us
> +		Usage: Not required if wakeup-latency-us is provided.
> +		Value type: <prop-encoded-array>
> +		Definition: u32 value representing worst case latency in
> +		microseconds required to enter the idle state.
> +		The exit-latency-us duration may be guaranteed
> +		only after entry-latency-us has passed.
> +
> +	- exit-latency-us
> +		Usage: Not required if wakeup-latency-us is provided.
> +		Value type: <prop-encoded-array>
> +		Definition: u32 value representing worst case latency
> +		in microseconds required to exit the idle state.

These are part of the existing idle state binding
(Documentation/devicetree/bindings/arm/idle-states.txt), and I would
prefer that we did not duplicate this nor come up with an independent
set of idle state bindings.

> +
> +	- residency-us:
> +		Usage: Optional
> +		Value type: <prop-encoded-array>
> +		Definition: A u32 value representing the time for which a
> +		domain must be idle in the state to reap power saving benefits
> +		of entering the state.

This is "min-residency-us" per the existing bindings.

> +
> +	- state-param:
> +		Usage: Optional
> +		Value type: <prop-encoded-array>
> +		Definition: A u32 value as defined by the state. May be used
> +		by the driver to hold state related u32 data. In the case of
> +		PSCI, an extended state-id for the domain may be encoded in
> +		this value.

This is "arm,psci-suspend-param", per the existing bindings.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/14] dt/bindings: update binding for PM domain idle states

[Lina Iyer]

Hi Mark,

On Thu, Jun 23 2016 at 11:35 -0600, Mark Rutland wrote:
>Hi,
>
>On Wed, Jun 22, 2016 at 01:36:37PM -0600, Lina Iyer wrote:
>> From: Axel Haslam <ahaslam+renesas@baylibre.com>
>>
>> Update DT bindings to describe idle states of PM domains.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> [Lina: Added state properties, removed state names, wakeup-latency,
>> added of_pm_genpd_init() API, pruned commit text]
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> [Ulf: Moved around code to make it compile properly, rebased on top of multiple state support]
>> ---
>>  .../devicetree/bindings/power/power_domain.txt     | 70 ++++++++++++++++++++++
>>  1 file changed, 70 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>> index 025b5e7..41e8dda 100644
>> --- a/Documentation/devicetree/bindings/power/power_domain.txt
>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>> @@ -29,6 +29,43 @@ Optional properties:
>>     specified by this binding. More details about power domain specifier are
>>     available in the next section.
>>
>> +- power-states : A phandle of an idle-state that shall be soaked into a
>> +                generic domain power state.
>
>It's somewhat unfortunate that this gives us two possible locations for
>idle state lists (under the /cpus node and in a pm-domains node),
>especially as it's not clear what would happen were a DT to have both.
>
>I would prefer that we extend the existing bindings such that states can
>refer to the power domains which they affect.
>
I agree. The CPU idle states have become defined to be specific to CPUs.
PM Domain idle states are generic for any type of domain. I am hoping at
some point, we could converge and use the same idle state, but that
would mean changing the CPU idle states to make it generic. At some
point, during my development, I did use the arm,idle-state for domains
as well, but the binding definitions were too restrictive for a generic
PM domain.

I would be willing to make the change to CPU idle states to make it
generic and then we could just reference domain and CPU idle states
using the same bindings. Are we okay with that, specifically,
arm,psci-suspend-param? This binding is very restrictive in its
description. What we pass to the platform driver upon choosing a domain
state is very platform specific and therefore has to be generic in its
description.

Thanks,
Lina

>> +==Power state==
>> +
>> +A PM domain power state describes an idle state of a domain and must be
>> +have the following properties -
>> +
>> +	- entry-latency-us
>> +		Usage: Not required if wakeup-latency-us is provided.
>> +		Value type: <prop-encoded-array>
>> +		Definition: u32 value representing worst case latency in
>> +		microseconds required to enter the idle state.
>> +		The exit-latency-us duration may be guaranteed
>> +		only after entry-latency-us has passed.
>> +
>> +	- exit-latency-us
>> +		Usage: Not required if wakeup-latency-us is provided.
>> +		Value type: <prop-encoded-array>
>> +		Definition: u32 value representing worst case latency
>> +		in microseconds required to exit the idle state.
>
>These are part of the existing idle state binding
>(Documentation/devicetree/bindings/arm/idle-states.txt), and I would
>prefer that we did not duplicate this nor come up with an independent
>set of idle state bindings.
>
>> +
>> +	- residency-us:
>> +		Usage: Optional
>> +		Value type: <prop-encoded-array>
>> +		Definition: A u32 value representing the time for which a
>> +		domain must be idle in the state to reap power saving benefits
>> +		of entering the state.
>
>This is "min-residency-us" per the existing bindings.
>
>> +
>> +	- state-param:
>> +		Usage: Optional
>> +		Value type: <prop-encoded-array>
>> +		Definition: A u32 value as defined by the state. May be used
>> +		by the driver to hold state related u32 data. In the case of
>> +		PSCI, an extended state-id for the domain may be encoded in
>> +		this value.
>
>This is "arm,psci-suspend-param", per the existing bindings.
>
>Thanks,
>Mark.

Re: [PATCH 02/14] dt/bindings: update binding for PM domain idle states

[Mark Rutland]

On Thu, Jun 23, 2016 at 12:04:51PM -0600, Lina Iyer wrote:
> Hi Mark,
> 
> On Thu, Jun 23 2016 at 11:35 -0600, Mark Rutland wrote:
> >Hi,
> >
> >On Wed, Jun 22, 2016 at 01:36:37PM -0600, Lina Iyer wrote:
> >>From: Axel Haslam <ahaslam+renesas-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >>
> >>Update DT bindings to describe idle states of PM domains.
> >>
> >>Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> >>Signed-off-by: Marc Titinger <mtitinger+renesas-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >>Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>[Lina: Added state properties, removed state names, wakeup-latency,
> >>added of_pm_genpd_init() API, pruned commit text]
> >>Signed-off-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>[Ulf: Moved around code to make it compile properly, rebased on top of multiple state support]
> >>---
> >> .../devicetree/bindings/power/power_domain.txt     | 70 ++++++++++++++++++++++
> >> 1 file changed, 70 insertions(+)
> >>
> >>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> >>index 025b5e7..41e8dda 100644
> >>--- a/Documentation/devicetree/bindings/power/power_domain.txt
> >>+++ b/Documentation/devicetree/bindings/power/power_domain.txt
> >>@@ -29,6 +29,43 @@ Optional properties:
> >>    specified by this binding. More details about power domain specifier are
> >>    available in the next section.
> >>
> >>+- power-states : A phandle of an idle-state that shall be soaked into a
> >>+                generic domain power state.
> >
> >It's somewhat unfortunate that this gives us two possible locations for
> >idle state lists (under the /cpus node and in a pm-domains node),
> >especially as it's not clear what would happen were a DT to have both.
> >
> >I would prefer that we extend the existing bindings such that states can
> >refer to the power domains which they affect.
> >
> I agree. The CPU idle states have become defined to be specific to CPUs.
> PM Domain idle states are generic for any type of domain. I am hoping at
> some point, we could converge and use the same idle state, but that
> would mean changing the CPU idle states to make it generic.

Outside of CPU idling, I don't fully understand how this will be used,
so it's not clear to me what would need to be made generic. Apologies
for my ignorance there.

> At some point, during my development, I did use the arm,idle-state for
> domains as well, but the binding definitions were too restrictive for
> a generic PM domain.
> 
> I would be willing to make the change to CPU idle states to make it
> generic and then we could just reference domain and CPU idle states
> using the same bindings. Are we okay with that, specifically,
> arm,psci-suspend-param? This binding is very restrictive in its
> description. What we pass to the platform driver upon choosing a domain
> state is very platform specific and therefore has to be generic in its
> description.

I was suggesting that for PSCI we should consistently us
arm,psci-suspend-param, not that this should be used for all power
domain state data.

I imagine that mechanisms for powering down power domains will have
varied requirements on data they require (and may require more than can
be encoded in a u32), and I don't think it's best to try to force a
single representation in the DT for that. It would be better to allow
them to define the properties which they require.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/14] dt/bindings: update binding for PM domain idle states

[Lina Iyer]

On Thu, Jun 23 2016 at 12:19 -0600, Mark Rutland wrote:
>On Thu, Jun 23, 2016 at 12:04:51PM -0600, Lina Iyer wrote:
>> Hi Mark,
>>
>> On Thu, Jun 23 2016 at 11:35 -0600, Mark Rutland wrote:
>> >Hi,
>> >
>> >On Wed, Jun 22, 2016 at 01:36:37PM -0600, Lina Iyer wrote:
>> >>From: Axel Haslam <ahaslam+renesas@baylibre.com>
>> >>
>> >>Update DT bindings to describe idle states of PM domains.
>> >>
>> >>Cc: <devicetree@vger.kernel.org>
>> >>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>> >>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> >>[Lina: Added state properties, removed state names, wakeup-latency,
>> >>added of_pm_genpd_init() API, pruned commit text]
>> >>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> >>[Ulf: Moved around code to make it compile properly, rebased on top of multiple state support]
>> >>---
>> >> .../devicetree/bindings/power/power_domain.txt     | 70 ++++++++++++++++++++++
>> >> 1 file changed, 70 insertions(+)
>> >>
>> >>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>> >>index 025b5e7..41e8dda 100644
>> >>--- a/Documentation/devicetree/bindings/power/power_domain.txt
>> >>+++ b/Documentation/devicetree/bindings/power/power_domain.txt
>> >>@@ -29,6 +29,43 @@ Optional properties:
>> >>    specified by this binding. More details about power domain specifier are
>> >>    available in the next section.
>> >>
>> >>+- power-states : A phandle of an idle-state that shall be soaked into a
>> >>+                generic domain power state.
>> >
>> >It's somewhat unfortunate that this gives us two possible locations for
>> >idle state lists (under the /cpus node and in a pm-domains node),
>> >especially as it's not clear what would happen were a DT to have both.
>> >
>> >I would prefer that we extend the existing bindings such that states can
>> >refer to the power domains which they affect.
>> >
>> I agree. The CPU idle states have become defined to be specific to CPUs.
>> PM Domain idle states are generic for any type of domain. I am hoping at
>> some point, we could converge and use the same idle state, but that
>> would mean changing the CPU idle states to make it generic.
>
>Outside of CPU idling, I don't fully understand how this will be used,
>so it's not clear to me what would need to be made generic. Apologies
>for my ignorance there.
>
There may be non-PSCI ARM v7 CPU domains that may have domain controller
drivers in the kernel. They would not hook into the ARM PSCI frameworks.
It is still cpuidle though.

>> At some point, during my development, I did use the arm,idle-state for
>> domains as well, but the binding definitions were too restrictive for
>> a generic PM domain.
>>
>> I would be willing to make the change to CPU idle states to make it
>> generic and then we could just reference domain and CPU idle states
>> using the same bindings. Are we okay with that, specifically,
>> arm,psci-suspend-param? This binding is very restrictive in its
>> description. What we pass to the platform driver upon choosing a domain
>> state is very platform specific and therefore has to be generic in its
>> description.
>
>I was suggesting that for PSCI we should consistently us
>arm,psci-suspend-param, not that this should be used for all power
>domain state data.
>
>I imagine that mechanisms for powering down power domains will have
>varied requirements on data they require (and may require more than can
>be encoded in a u32), and I don't think it's best to try to force a
>single representation in the DT for that. It would be better to allow
>them to define the properties which they require.
>
The only way to do that is to push the DT parsing to the platform
drivers. In the case of CPU domains controlled by PSCI, we could use the
arm,idle-states but any other generic domain, may need to define their
own bindings and fill up the domain states before initiailizing the domain.

While this approach pushes the onus on to the platform code, I am fine
with it. Is that what you were thinking too?

Thanks,
Lina

[PATCH 13/14] ARM64: dts: Add PSCI cpuidle support for MSM8916

[Lina Iyer]

Add device bindings for CPUs to suspend using PSCI as the enable-method.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 9681200..3029773 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -62,6 +62,8 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x0>;
 			next-level-cache = <&L2_0>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
 		};
 
 		CPU1: cpu@1 {
@@ -69,6 +71,8 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x1>;
 			next-level-cache = <&L2_0>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
 		};
 
 		CPU2: cpu@2 {
@@ -76,6 +80,8 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x2>;
 			next-level-cache = <&L2_0>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
 		};
 
 		CPU3: cpu@3 {
@@ -83,12 +89,30 @@
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x3>;
 			next-level-cache = <&L2_0>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
 		};
 
 		L2_0: l2-cache {
 		      compatible = "cache";
 		      cache-level = <2>;
 		};
+
+		idle-states {
+			CPU_SPC: spc {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x40000002>;
+				entry-latency-us = <130>;
+				exit-latency-us = <150>;
+				min-residency-us = <2000>;
+				local-timer-stop;
+			};
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
 	};
 
 	timer {
-- 
2.7.4

[PATCH 14/14] ARM64: dts: Define CPU power domain for MSM8916

[Lina Iyer]

Define power domain and the power states for the domain as defined by
the PSCI firmware. The 8916 firmware supports OS initiated method of
powering off the CPU clusters.

Cc: <devicetree@vger.kernel.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 3029773..208af00 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -64,6 +64,7 @@
 			next-level-cache = <&L2_0>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		CPU1: cpu@1 {
@@ -73,6 +74,7 @@
 			next-level-cache = <&L2_0>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		CPU2: cpu@2 {
@@ -82,6 +84,7 @@
 			next-level-cache = <&L2_0>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		CPU3: cpu@3 {
@@ -91,6 +94,7 @@
 			next-level-cache = <&L2_0>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		L2_0: l2-cache {
@@ -110,6 +114,27 @@
 		};
 	};
 
+	CPU_PD: cpu-pd@0 {
+		#power-domain-cells = <0>;
+		power-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
+	};
+
+	pd-power-states {
+		CLUSTER_RET: power-state@1 {
+			state-param = <0x1000010>;
+			entry-latency-us = <500>;
+			exit-latency-us = <500>;
+			residency-us = <2000>;
+		 };
+
+		CLUSTER_PWR_DWN: power-state@2 {
+			state-param = <0x1000030>;
+			entry-latency-us = <2000>;
+			exit-latency-us = <2000>;
+			residency-us = <6000>;
+		};
+	};
+
 	psci {
 		compatible = "arm,psci-1.0";
 		method = "smc";
-- 
2.7.4