Re: [RFC v2 3/6] PM / Domains: introduce power-states consistent with c-states.
On 08/10/2015 18:27, Lina Iyer wrote:
On Tue, Oct 06 2015 at 08:27 -0600, Marc Titinger wrote:
This patch allows cluster-level C-states to being soaked in as generic
domain power states, in order for the domain governor to chose the most
efficient power state compatible with the device constraints. Similarly,
devices can register power-states into the cluster domain, in a manner
consistent with c-states.
A domain power state as depicted in the DT is no different than the CPU
idle state. I think you can achieve this without adding another
compatible - arm,power-state.
yes, thats'a bit hacky, I was facing the genpd_lock'ing issue I believe
you mentioned recently and lead to your simplification work in the case
of CPUs. the power-state discrimination was to allow cpu-idle to call
runtime_put/get only for those states where genpd is to call the
platform code and select the optimal c-state. Eventually this
discrimination would be useless. Alternatively I've been wondering if we
could have one domain (and one lock) per CPU, and have a parent domain
for the cluster.
I think I am still at loss trying to understand why a device is
populating the domain's power states.
With Juno, in this example the c-state 'cluster-sleep-0 ' is known from
each cluster generic domain, as the deepest sate.
cat /sys/kernel/debug/pm_genpd/*
Domain State nameEnter (ns) / Exit (ns)
-
a53_pd cluster-sleep-0 150 / 80
a57_pd cluster-sleep-0 150 / 80
domain status pstate slaves
/device runtime status
---
a53_pd on
/devices/system/cpu/cpu0active
/devices/system/cpu/cpu3suspended
/devices/system/cpu/cpu4suspended
/devices/system/cpu/cpu5suspended
/devices/platform/D1suspended
a57_pd cluster-sleep-0
/devices/system/cpu/cpu1suspended
/devices/system/cpu/cpu2suspended
Signed-off-by: Marc Titinger
---
.../devicetree/bindings/arm/idle-states.txt| 21 -
.../devicetree/bindings/power/power_domain.txt | 29 ++
arch/arm64/boot/dts/arm/juno.dts | 10 ++-
drivers/base/power/cpu-pd.c| 5 ++
drivers/base/power/domain.c| 100
+
include/linux/pm_domain.h | 3 +
6 files changed, 163 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
b/Documentation/devicetree/bindings/arm/idle-states.txt
index a8274ea..18fdeaf 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -270,7 +270,8 @@ follows:
- compatible
Usage: Required
Value type:
-Definition: Must be "arm,idle-state".
+Definition: Must be "arm,idle-state",
+or "arm,power-state" (see section 5)
- local-timer-stop
Usage: See definition
@@ -680,7 +681,23 @@ cpus {
};
===
-5 - References
+5 - power state
+===
+
+Device in a generic power domain may expose an intermediate retention
+state that can be opted to by the domain governor when the last-man
+CPU is powered off. Those power-states will not be entered by the
+cpuidle.ops based on a state index, but instead can be elected by the
+domain governor and entered to by the generic domain.
+
Agreed.
+ - compatible
+Usage: Required
+Value type:
+Definition: Must be "arm,power-state".
+
+
+===
+6 - References
===
[1] ARM Linux Kernel documentation - CPUs bindings
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
index 0f8ed37..d437385 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,16 @@ 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.
+ CPU domains: Deep c-states that match a cluster power-off can be
delegated to the
+ generic power domain. Device other than CPUs may have register
intermediate
+ power states in the same domain. The domain governor can do a good
job in
+ electing a power state when the last cpu i
Re: [RFC v2 3/6] PM / Domains: introduce power-states consistent with c-states.
On Tue, Oct 06 2015 at 08:27 -0600, Marc Titinger wrote:
This patch allows cluster-level C-states to being soaked in as generic
domain power states, in order for the domain governor to chose the most
efficient power state compatible with the device constraints. Similarly,
devices can register power-states into the cluster domain, in a manner
consistent with c-states.
A domain power state as depicted in the DT is no different than the CPU
idle state. I think you can achieve this without adding another
compatible - arm,power-state.
I think I am still at loss trying to understand why a device is
populating the domain's power states.
With Juno, in this example the c-state 'cluster-sleep-0 ' is known from
each cluster generic domain, as the deepest sate.
cat /sys/kernel/debug/pm_genpd/*
Domain State nameEnter (ns) / Exit (ns)
-
a53_pd cluster-sleep-0 150 / 80
a57_pd cluster-sleep-0 150 / 80
domain status pstate slaves
/device runtime status
---
a53_pd on
/devices/system/cpu/cpu0active
/devices/system/cpu/cpu3suspended
/devices/system/cpu/cpu4suspended
/devices/system/cpu/cpu5suspended
/devices/platform/D1suspended
a57_pd cluster-sleep-0
/devices/system/cpu/cpu1suspended
/devices/system/cpu/cpu2suspended
Signed-off-by: Marc Titinger
---
.../devicetree/bindings/arm/idle-states.txt| 21 -
.../devicetree/bindings/power/power_domain.txt | 29 ++
arch/arm64/boot/dts/arm/juno.dts | 10 ++-
drivers/base/power/cpu-pd.c| 5 ++
drivers/base/power/domain.c| 100 +
include/linux/pm_domain.h | 3 +
6 files changed, 163 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
b/Documentation/devicetree/bindings/arm/idle-states.txt
index a8274ea..18fdeaf 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -270,7 +270,8 @@ follows:
- compatible
Usage: Required
Value type:
- Definition: Must be "arm,idle-state".
+ Definition: Must be "arm,idle-state",
+ or "arm,power-state" (see section 5)
- local-timer-stop
Usage: See definition
@@ -680,7 +681,23 @@ cpus {
};
===
-5 - References
+5 - power state
+===
+
+Device in a generic power domain may expose an intermediate retention
+state that can be opted to by the domain governor when the last-man
+CPU is powered off. Those power-states will not be entered by the
+cpuidle.ops based on a state index, but instead can be elected by the
+domain governor and entered to by the generic domain.
+
Agreed.
+ - compatible
+Usage: Required
+Value type:
+Definition: Must be "arm,power-state".
+
+
+===
+6 - References
===
[1] ARM Linux Kernel documentation - CPUs bindings
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
index 0f8ed37..d437385 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,16 @@ 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.
+ CPU domains: Deep c-states that match a cluster power-off can be delegated
to the
+ generic power domain. Device other than CPUs may have register intermediate
+ power states in the same domain. The domain governor can do a good job in
+ electing a power state when the last cpu is powered off as devices in the
+ same genpd may register intermediate states.
Devices may enable a certain domain state, but should not be defining
the domain state. The domain its state and the domain governor may
choose to enter that state on a vote from its devices.
+ Devices : a device may register an intermediate c-state matching a memory
+ retention feature for instance.
This point onwards is where I need clarity.
Thanks,
Lina
+
Example:
power: powe
