* [PATCH v3 00/15] PM: SoC idle support using PM domains
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer
Hi all,
Changes since v2 [5]:
- Update PSCI documentation to define OS-Initiated PM domains.
- Nifty updates and bug fixes. Thanks Brendan!
- Define PSCI PM domains under psci node in 8916 DT.
- Documentation updates for domain definitions.
- Updated series is at [4].
Changes since v1 [6]:
- Use arm,idle-state as the DT binding for domain idle state.
- OS-Initated changes to support that and to read arm,psci-suspend-param
(Thanks Mark Rutland and Kevin Hilman)
- tick_nohz_get_next_wakeup() - suggestions from Thomas Gleixner.
- The updated series is at [3].
Changes since RFC-v3 [1]:
- Reorganize the patches. Documentations have their own patch.
- Moved code around with PSCI OS initiated so they would not have compiler
errors in other configuration.
- Minor bug fixes with genpd power_on functionality.
- Rebased on top of 4.7-rc1
This is the submission of the SoC idle support in the kernel for CPU domains
using genpd. The patches were submitted as RFC's earlier, the last of them is
[1]. Since the RFC, multiple discussions have happened around making the
patches generic across all architectures. For now, the patches address the
needs of the ARM community, but sure enough can be extended to support other
architectures. Some of the limitations in making this patch generic is the lack
of device idle state description in the DT, but that in itself is a bigger
topic for a future discussion.
The patch has been tested on the 410c Dragonboard and the MTK EVB boards. Both
show good power savings when used with OS Initiated PSCI f/w.
Ulf is maintaining a branch tracking the PM/genpd changes that are in
pipleline. This series sits well on his branch. You may find the entire series
at [2].
Thanks,
Lina
[1]. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/412934.html
[2]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-psci-v1
[3]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-psci-v2
[4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-psci-v3
[5]. https://lwn.net/Articles/695987/
[6]. https://lwn.net/Articles/675674/
Axel Haslam (2):
PM / Domains: Allow domain power states to be read from DT
dt/bindings: Update binding for PM domain idle states
Lina Iyer (13):
PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains
PM / cpu_domains: Setup PM domains for CPUs/clusters
ARM: cpuidle: Add runtime PM support for CPUs
timer: Export next wake up of a CPU
PM / cpu_domains: Add PM Domain governor for CPUs
doc / cpu_domains: Describe CPU PM domains setup and governor
drivers: firmware: psci: Allow OS Initiated suspend mode
drivers: firmware: psci: Support cluster idle states for OS-Initiated
dt/bindings: Add PSCI OS-Initiated PM Domains bindings
ARM64: dts: Add PSCI cpuidle support for MSM8916
ARM64: dts: Define CPU power domain for MSM8916
Documentation/devicetree/bindings/arm/psci.txt | 64 ++++
.../devicetree/bindings/power/power_domain.txt | 57 +++
Documentation/power/cpu_domains.txt | 109 ++++++
Documentation/power/devices.txt | 12 +-
arch/arm64/boot/dts/qcom/msm8916.dtsi | 51 +++
drivers/base/power/Makefile | 1 +
drivers/base/power/cpu_domains.c | 388 +++++++++++++++++++++
drivers/base/power/domain.c | 308 +++++++++++++---
drivers/cpuidle/cpuidle-arm.c | 55 +++
drivers/firmware/psci.c | 111 +++++-
include/linux/cpu_domains.h | 39 +++
include/linux/pm_domain.h | 24 +-
include/linux/tick.h | 7 +
include/uapi/linux/psci.h | 5 +
kernel/time/tick-sched.c | 11 +
15 files changed, 1190 insertions(+), 52 deletions(-)
create mode 100644 Documentation/power/cpu_domains.txt
create mode 100644 drivers/base/power/cpu_domains.c
create mode 100644 include/linux/cpu_domains.h
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 00/15] PM: SoC idle support using PM domains
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Changes since v2 [5]:
- Update PSCI documentation to define OS-Initiated PM domains.
- Nifty updates and bug fixes. Thanks Brendan!
- Define PSCI PM domains under psci node in 8916 DT.
- Documentation updates for domain definitions.
- Updated series is at [4].
Changes since v1 [6]:
- Use arm,idle-state as the DT binding for domain idle state.
- OS-Initated changes to support that and to read arm,psci-suspend-param
(Thanks Mark Rutland and Kevin Hilman)
- tick_nohz_get_next_wakeup() - suggestions from Thomas Gleixner.
- The updated series is at [3].
Changes since RFC-v3 [1]:
- Reorganize the patches. Documentations have their own patch.
- Moved code around with PSCI OS initiated so they would not have compiler
errors in other configuration.
- Minor bug fixes with genpd power_on functionality.
- Rebased on top of 4.7-rc1
This is the submission of the SoC idle support in the kernel for CPU domains
using genpd. The patches were submitted as RFC's earlier, the last of them is
[1]. Since the RFC, multiple discussions have happened around making the
patches generic across all architectures. For now, the patches address the
needs of the ARM community, but sure enough can be extended to support other
architectures. Some of the limitations in making this patch generic is the lack
of device idle state description in the DT, but that in itself is a bigger
topic for a future discussion.
The patch has been tested on the 410c Dragonboard and the MTK EVB boards. Both
show good power savings when used with OS Initiated PSCI f/w.
Ulf is maintaining a branch tracking the PM/genpd changes that are in
pipleline. This series sits well on his branch. You may find the entire series
at [2].
Thanks,
Lina
[1]. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/412934.html
[2]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-psci-v1
[3]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-psci-v2
[4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-psci-v3
[5]. https://lwn.net/Articles/695987/
[6]. https://lwn.net/Articles/675674/
Axel Haslam (2):
PM / Domains: Allow domain power states to be read from DT
dt/bindings: Update binding for PM domain idle states
Lina Iyer (13):
PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains
PM / cpu_domains: Setup PM domains for CPUs/clusters
ARM: cpuidle: Add runtime PM support for CPUs
timer: Export next wake up of a CPU
PM / cpu_domains: Add PM Domain governor for CPUs
doc / cpu_domains: Describe CPU PM domains setup and governor
drivers: firmware: psci: Allow OS Initiated suspend mode
drivers: firmware: psci: Support cluster idle states for OS-Initiated
dt/bindings: Add PSCI OS-Initiated PM Domains bindings
ARM64: dts: Add PSCI cpuidle support for MSM8916
ARM64: dts: Define CPU power domain for MSM8916
Documentation/devicetree/bindings/arm/psci.txt | 64 ++++
.../devicetree/bindings/power/power_domain.txt | 57 +++
Documentation/power/cpu_domains.txt | 109 ++++++
Documentation/power/devices.txt | 12 +-
arch/arm64/boot/dts/qcom/msm8916.dtsi | 51 +++
drivers/base/power/Makefile | 1 +
drivers/base/power/cpu_domains.c | 388 +++++++++++++++++++++
drivers/base/power/domain.c | 308 +++++++++++++---
drivers/cpuidle/cpuidle-arm.c | 55 +++
drivers/firmware/psci.c | 111 +++++-
include/linux/cpu_domains.h | 39 +++
include/linux/pm_domain.h | 24 +-
include/linux/tick.h | 7 +
include/uapi/linux/psci.h | 5 +
kernel/time/tick-sched.c | 11 +
15 files changed, 1190 insertions(+), 52 deletions(-)
create mode 100644 Documentation/power/cpu_domains.txt
create mode 100644 drivers/base/power/cpu_domains.c
create mode 100644 include/linux/cpu_domains.h
--
2.7.4
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 01/15] PM / Domains: Allow domain power states to be read from DT
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Axel Haslam, Marc Titinger, Lina Iyer
From: Axel Haslam <ahaslam+renesas@baylibre.com>
This patch allows domains to define idle states in the DT. SoC's can
define domain idle states in DT using the "domain-idle-states" property
of the domain provider. Calling of_pm_genpd_init() will read the idle
states and initialize the genpd for the domain.
In addition to the entry and exit latency for idle state, also add
residency_ns, param and of_node property to each state. A domain idling
in a state is only power effecient if it stays idle for a certain period
in that state. The residency provides this minimum time for the idle
state to provide power benefits. The param is a state specific u32 value
that the platform may use for that idle state.
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,changed to use pm_genpd_init()]
---
drivers/base/power/domain.c | 92 ++++++++++++++++++++++++++++++++++++++++++++-
include/linux/pm_domain.h | 11 +++++-
2 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index a1f2aff..3aecac3 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1253,6 +1253,90 @@ out:
}
EXPORT_SYMBOL_GPL(pm_genpd_remove_subdomain);
+static const struct of_device_id arm_idle_state_match[] = {
+ { .compatible = "arm,idle-state", },
+ { }
+};
+
+static int genpd_of_get_power_state(struct genpd_power_state *genpd_state,
+ struct device_node *state_node)
+{
+ int err = 0;
+ u32 latency;
+ u32 residency;
+ u32 entry_latency, exit_latency;
+ const struct of_device_id *match_id;
+
+ match_id = of_match_node(arm_idle_state_match, state_node);
+ if (!match_id)
+ return -EINVAL;
+
+ err = of_property_read_u32(state_node, "entry-latency-us",
+ &entry_latency);
+ if (err) {
+ pr_debug(" * %s missing entry-latency-us property\n",
+ state_node->full_name);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32(state_node, "exit-latency-us",
+ &exit_latency);
+ if (err) {
+ pr_debug(" * %s missing exit-latency-us property\n",
+ state_node->full_name);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32(state_node, "min-residency-us", &residency);
+ if (!err)
+ genpd_state->residency_ns = 1000 * residency;
+
+ latency = entry_latency + exit_latency;
+ genpd_state->power_on_latency_ns = 1000 * latency;
+ genpd_state->power_off_latency_ns = 1000 * entry_latency;
+ genpd_state->of_node = state_node;
+
+ return 0;
+}
+
+int pm_genpd_of_parse_power_states(struct generic_pm_domain *genpd)
+{
+ struct device_node *np;
+ int i, err = 0;
+
+ for (i = 0; i < GENPD_MAX_NUM_STATES; i++) {
+ np = of_parse_phandle(genpd->of_node, "domain-idle-states", i);
+ if (!np)
+ break;
+
+ err = genpd_of_get_power_state(&genpd->states[i], np);
+ if (err) {
+ pr_err
+ ("Parsing idle state node %s failed with err %d\n",
+ np->full_name, err);
+ err = -EINVAL;
+ of_node_put(np);
+ break;
+ }
+ of_node_put(np);
+ }
+
+ if (err)
+ return err;
+
+ genpd->state_count = i;
+ return 0;
+}
+EXPORT_SYMBOL(pm_genpd_of_parse_power_states);
+
+static int genpd_of_parse(struct generic_pm_domain *genpd)
+{
+ if (!genpd->of_node || (genpd->state_count > 0))
+ return 0;
+
+ return pm_genpd_of_parse_power_states(genpd);
+}
+
/**
* pm_genpd_init - Initialize a generic I/O PM domain object.
* @genpd: PM domain object to initialize.
@@ -1262,8 +1346,10 @@ EXPORT_SYMBOL_GPL(pm_genpd_remove_subdomain);
* Returns 0 on successful initialization, else a negative error code.
*/
int pm_genpd_init(struct generic_pm_domain *genpd,
- struct dev_power_governor *gov, bool is_off)
+ struct dev_power_governor *gov, bool is_off)
{
+ int ret;
+
if (IS_ERR_OR_NULL(genpd))
return -EINVAL;
@@ -1306,6 +1392,10 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
genpd->dev_ops.start = pm_clk_resume;
}
+ ret = genpd_of_parse(genpd);
+ if (ret)
+ return ret;
+
if (genpd->state_idx >= GENPD_MAX_NUM_STATES) {
pr_warn("Initial state index out of bounds.\n");
genpd->state_idx = GENPD_MAX_NUM_STATES - 1;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 31fec85..c5d14b9 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -40,6 +40,9 @@ struct gpd_dev_ops {
struct genpd_power_state {
s64 power_off_latency_ns;
s64 power_on_latency_ns;
+ s64 residency_ns;
+ u32 param;
+ struct device_node *of_node;
};
struct generic_pm_domain {
@@ -51,6 +54,7 @@ struct generic_pm_domain {
struct mutex lock;
struct dev_power_governor *gov;
struct work_struct power_off_work;
+ struct device_node *of_node; /* Device node of the PM domain */
const char *name;
atomic_t sd_count; /* Number of subdomains with power "on" */
enum gpd_status status; /* Current state of the domain */
@@ -129,7 +133,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
struct generic_pm_domain *target);
extern int pm_genpd_init(struct generic_pm_domain *genpd,
struct dev_power_governor *gov, bool is_off);
-
+extern int pm_genpd_of_parse_power_states(struct generic_pm_domain *genpd);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
#else
@@ -168,6 +172,11 @@ static inline int pm_genpd_init(struct generic_pm_domain *genpd,
{
return -ENOSYS;
}
+static inline int pm_genpd_of_parse_power_states(
+ struct generic_pm_domain *genpd)
+{
+ return -ENODEV;
+}
#endif
static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 01/15] PM / Domains: Allow domain power states to be read from DT
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Axel Haslam <ahaslam+renesas@baylibre.com>
This patch allows domains to define idle states in the DT. SoC's can
define domain idle states in DT using the "domain-idle-states" property
of the domain provider. Calling of_pm_genpd_init() will read the idle
states and initialize the genpd for the domain.
In addition to the entry and exit latency for idle state, also add
residency_ns, param and of_node property to each state. A domain idling
in a state is only power effecient if it stays idle for a certain period
in that state. The residency provides this minimum time for the idle
state to provide power benefits. The param is a state specific u32 value
that the platform may use for that idle state.
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,changed to use pm_genpd_init()]
---
drivers/base/power/domain.c | 92 ++++++++++++++++++++++++++++++++++++++++++++-
include/linux/pm_domain.h | 11 +++++-
2 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index a1f2aff..3aecac3 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1253,6 +1253,90 @@ out:
}
EXPORT_SYMBOL_GPL(pm_genpd_remove_subdomain);
+static const struct of_device_id arm_idle_state_match[] = {
+ { .compatible = "arm,idle-state", },
+ { }
+};
+
+static int genpd_of_get_power_state(struct genpd_power_state *genpd_state,
+ struct device_node *state_node)
+{
+ int err = 0;
+ u32 latency;
+ u32 residency;
+ u32 entry_latency, exit_latency;
+ const struct of_device_id *match_id;
+
+ match_id = of_match_node(arm_idle_state_match, state_node);
+ if (!match_id)
+ return -EINVAL;
+
+ err = of_property_read_u32(state_node, "entry-latency-us",
+ &entry_latency);
+ if (err) {
+ pr_debug(" * %s missing entry-latency-us property\n",
+ state_node->full_name);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32(state_node, "exit-latency-us",
+ &exit_latency);
+ if (err) {
+ pr_debug(" * %s missing exit-latency-us property\n",
+ state_node->full_name);
+ return -EINVAL;
+ }
+
+ err = of_property_read_u32(state_node, "min-residency-us", &residency);
+ if (!err)
+ genpd_state->residency_ns = 1000 * residency;
+
+ latency = entry_latency + exit_latency;
+ genpd_state->power_on_latency_ns = 1000 * latency;
+ genpd_state->power_off_latency_ns = 1000 * entry_latency;
+ genpd_state->of_node = state_node;
+
+ return 0;
+}
+
+int pm_genpd_of_parse_power_states(struct generic_pm_domain *genpd)
+{
+ struct device_node *np;
+ int i, err = 0;
+
+ for (i = 0; i < GENPD_MAX_NUM_STATES; i++) {
+ np = of_parse_phandle(genpd->of_node, "domain-idle-states", i);
+ if (!np)
+ break;
+
+ err = genpd_of_get_power_state(&genpd->states[i], np);
+ if (err) {
+ pr_err
+ ("Parsing idle state node %s failed with err %d\n",
+ np->full_name, err);
+ err = -EINVAL;
+ of_node_put(np);
+ break;
+ }
+ of_node_put(np);
+ }
+
+ if (err)
+ return err;
+
+ genpd->state_count = i;
+ return 0;
+}
+EXPORT_SYMBOL(pm_genpd_of_parse_power_states);
+
+static int genpd_of_parse(struct generic_pm_domain *genpd)
+{
+ if (!genpd->of_node || (genpd->state_count > 0))
+ return 0;
+
+ return pm_genpd_of_parse_power_states(genpd);
+}
+
/**
* pm_genpd_init - Initialize a generic I/O PM domain object.
* @genpd: PM domain object to initialize.
@@ -1262,8 +1346,10 @@ EXPORT_SYMBOL_GPL(pm_genpd_remove_subdomain);
* Returns 0 on successful initialization, else a negative error code.
*/
int pm_genpd_init(struct generic_pm_domain *genpd,
- struct dev_power_governor *gov, bool is_off)
+ struct dev_power_governor *gov, bool is_off)
{
+ int ret;
+
if (IS_ERR_OR_NULL(genpd))
return -EINVAL;
@@ -1306,6 +1392,10 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
genpd->dev_ops.start = pm_clk_resume;
}
+ ret = genpd_of_parse(genpd);
+ if (ret)
+ return ret;
+
if (genpd->state_idx >= GENPD_MAX_NUM_STATES) {
pr_warn("Initial state index out of bounds.\n");
genpd->state_idx = GENPD_MAX_NUM_STATES - 1;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 31fec85..c5d14b9 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -40,6 +40,9 @@ struct gpd_dev_ops {
struct genpd_power_state {
s64 power_off_latency_ns;
s64 power_on_latency_ns;
+ s64 residency_ns;
+ u32 param;
+ struct device_node *of_node;
};
struct generic_pm_domain {
@@ -51,6 +54,7 @@ struct generic_pm_domain {
struct mutex lock;
struct dev_power_governor *gov;
struct work_struct power_off_work;
+ struct device_node *of_node; /* Device node of the PM domain */
const char *name;
atomic_t sd_count; /* Number of subdomains with power "on" */
enum gpd_status status; /* Current state of the domain */
@@ -129,7 +133,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
struct generic_pm_domain *target);
extern int pm_genpd_init(struct generic_pm_domain *genpd,
struct dev_power_governor *gov, bool is_off);
-
+extern int pm_genpd_of_parse_power_states(struct generic_pm_domain *genpd);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
#else
@@ -168,6 +172,11 @@ static inline int pm_genpd_init(struct generic_pm_domain *genpd,
{
return -ENOSYS;
}
+static inline int pm_genpd_of_parse_power_states(
+ struct generic_pm_domain *genpd)
+{
+ return -ENODEV;
+}
#endif
static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lina Iyer
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 | 57 ++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7..4960486 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,10 @@ Optional properties:
specified by this binding. More details about power domain specifier are
available in the next section.
+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
+ generic domain power state. The idle state definitions are
+ compatible with arm,idle-state specified in [1].
+
Example:
power: power-controller@12340000 {
@@ -59,6 +63,57 @@ 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.
+Example 3: ARM v7 style CPU PM domains (Linux domain controller)
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7", "arm,armv7";
+ reg = <0x0>;
+ power-domains = <&a7_pd>;
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15", "arm,armv7";
+ reg = <0x0>;
+ power-domains = <&a15_pd>;
+ };
+ };
+
+ pm-domains {
+ a15_pd: a15_pd {
+ /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/
+ compatible = "arm,cortex-a15";
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_SLEEP_0>;
+ };
+
+ a7_pd: a7_pd {
+ /* will have a A7 platform ARM_PD_METHOD_OF_DECLARE*/
+ compatible = "arm,cortex-a7";
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_SLEEP_0>, <&CLUSTER_SLEEP_1>;
+ };
+
+ CLUSTER_SLEEP_0: state0 {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <10000>;
+ };
+
+ CLUSTER_SLEEP_1: state1 {
+ compatible = "arm,idle-state";
+ entry-latency-us = <5000>;
+ exit-latency-us = <5000>;
+ min-residency-us = <100000>;
+ };
+ };
+
==PM domain consumers==
Required properties:
@@ -76,3 +131,5 @@ Example:
The node above defines a typical PM domain consumer device, which is located
inside a PM domain with index 0 of a power controller represented by a node
with the label "power".
+
+[1]. Documentation/devicetree/bindings/arm/idle-states.txt
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
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 | 57 ++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7..4960486 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,10 @@ Optional properties:
specified by this binding. More details about power domain specifier are
available in the next section.
+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
+ generic domain power state. The idle state definitions are
+ compatible with arm,idle-state specified in [1].
+
Example:
power: power-controller at 12340000 {
@@ -59,6 +63,57 @@ 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.
+Example 3: ARM v7 style CPU PM domains (Linux domain controller)
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7", "arm,armv7";
+ reg = <0x0>;
+ power-domains = <&a7_pd>;
+ };
+
+ CPU1: cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15", "arm,armv7";
+ reg = <0x0>;
+ power-domains = <&a15_pd>;
+ };
+ };
+
+ pm-domains {
+ a15_pd: a15_pd {
+ /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/
+ compatible = "arm,cortex-a15";
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_SLEEP_0>;
+ };
+
+ a7_pd: a7_pd {
+ /* will have a A7 platform ARM_PD_METHOD_OF_DECLARE*/
+ compatible = "arm,cortex-a7";
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_SLEEP_0>, <&CLUSTER_SLEEP_1>;
+ };
+
+ CLUSTER_SLEEP_0: state0 {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <10000>;
+ };
+
+ CLUSTER_SLEEP_1: state1 {
+ compatible = "arm,idle-state";
+ entry-latency-us = <5000>;
+ exit-latency-us = <5000>;
+ min-residency-us = <100000>;
+ };
+ };
+
==PM domain consumers==
Required properties:
@@ -76,3 +131,5 @@ Example:
The node above defines a typical PM domain consumer device, which is located
inside a PM domain with index 0 of a power controller represented by a node
with the label "power".
+
+[1]. Documentation/devicetree/bindings/arm/idle-states.txt
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 03/15] PM / Domains: Abstract genpd locking
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, Kevin Hilman,
Geert Uytterhoeven, Krzysztof Kozłowski
Abstract genpd lock/unlock calls, in preparation for domain specific
locks added in the following patches.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Krzysztof Kozłowski <k.kozlowski@samsung.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
[Ulf: Rebased as additional mutex_lock|unlock has been added]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/base/power/domain.c | 113 ++++++++++++++++++++++++++++++--------------
include/linux/pm_domain.h | 5 +-
2 files changed, 81 insertions(+), 37 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 3aecac3..ce1dbfdd 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -39,6 +39,46 @@
static LIST_HEAD(gpd_list);
static DEFINE_MUTEX(gpd_list_lock);
+struct genpd_lock_fns {
+ void (*lock)(struct generic_pm_domain *genpd);
+ void (*lock_nested)(struct generic_pm_domain *genpd, int depth);
+ int (*lock_interruptible)(struct generic_pm_domain *genpd);
+ void (*unlock)(struct generic_pm_domain *genpd);
+};
+
+static void genpd_lock_mtx(struct generic_pm_domain *genpd)
+{
+ mutex_lock(&genpd->mlock);
+}
+
+static void genpd_lock_nested_mtx(struct generic_pm_domain *genpd,
+ int depth)
+{
+ mutex_lock_nested(&genpd->mlock, depth);
+}
+
+static int genpd_lock_interruptible_mtx(struct generic_pm_domain *genpd)
+{
+ return mutex_lock_interruptible(&genpd->mlock);
+}
+
+static void genpd_unlock_mtx(struct generic_pm_domain *genpd)
+{
+ return mutex_unlock(&genpd->mlock);
+}
+
+static const struct genpd_lock_fns genpd_mtx_fns = {
+ .lock = genpd_lock_mtx,
+ .lock_nested = genpd_lock_nested_mtx,
+ .lock_interruptible = genpd_lock_interruptible_mtx,
+ .unlock = genpd_unlock_mtx,
+};
+
+#define genpd_lock(p) p->lock_fns->lock(p)
+#define genpd_lock_nested(p, d) p->lock_fns->lock_nested(p, d)
+#define genpd_lock_interruptible(p) p->lock_fns->lock_interruptible(p)
+#define genpd_unlock(p) p->lock_fns->unlock(p)
+
/*
* Get the generic PM domain for a particular struct device.
* This validates the struct device pointer, the PM domain pointer,
@@ -200,9 +240,9 @@ static int genpd_poweron(struct generic_pm_domain *genpd, unsigned int depth)
genpd_sd_counter_inc(master);
- mutex_lock_nested(&master->lock, depth + 1);
+ genpd_lock_nested(master, depth + 1);
ret = genpd_poweron(master, depth + 1);
- mutex_unlock(&master->lock);
+ genpd_unlock(master);
if (ret) {
genpd_sd_counter_dec(master);
@@ -255,9 +295,9 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block *nb,
spin_unlock_irq(&dev->power.lock);
if (!IS_ERR(genpd)) {
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd->max_off_time_changed = true;
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
dev = dev->parent;
@@ -354,9 +394,9 @@ static void genpd_power_off_work_fn(struct work_struct *work)
genpd = container_of(work, struct generic_pm_domain, power_off_work);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd_poweroff(genpd, true);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
/**
@@ -472,9 +512,9 @@ static int genpd_runtime_suspend(struct device *dev)
if (dev->power.irq_safe)
return 0;
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd_poweroff(genpd, false);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
return 0;
}
@@ -509,9 +549,9 @@ static int genpd_runtime_resume(struct device *dev)
goto out;
}
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
ret = genpd_poweron(genpd, 0);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
if (ret)
return ret;
@@ -547,9 +587,9 @@ err_stop:
genpd_stop_dev(genpd, dev);
err_poweroff:
if (!dev->power.irq_safe) {
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd_poweroff(genpd, 0);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
return ret;
@@ -732,20 +772,20 @@ static int pm_genpd_prepare(struct device *dev)
if (resume_needed(dev, genpd))
pm_runtime_resume(dev);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
if (genpd->prepared_count++ == 0)
genpd->suspended_count = 0;
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
ret = pm_generic_prepare(dev);
if (ret) {
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd->prepared_count--;
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
return ret;
@@ -936,13 +976,13 @@ static void pm_genpd_complete(struct device *dev)
pm_generic_complete(dev);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd->prepared_count--;
if (!genpd->prepared_count)
genpd_queue_power_off_work(genpd);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
/**
@@ -1077,7 +1117,7 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
if (IS_ERR(gpd_data))
return PTR_ERR(gpd_data);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
if (genpd->prepared_count > 0) {
ret = -EAGAIN;
@@ -1094,7 +1134,7 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
list_add_tail(&gpd_data->base.list_node, &genpd->dev_list);
out:
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
if (ret)
genpd_free_dev_data(dev, gpd_data);
@@ -1127,7 +1167,7 @@ int pm_genpd_remove_device(struct generic_pm_domain *genpd,
gpd_data = to_gpd_data(pdd);
dev_pm_qos_remove_notifier(dev, &gpd_data->nb);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
if (genpd->prepared_count > 0) {
ret = -EAGAIN;
@@ -1142,14 +1182,14 @@ int pm_genpd_remove_device(struct generic_pm_domain *genpd,
list_del_init(&pdd->list_node);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
genpd_free_dev_data(dev, gpd_data);
return 0;
out:
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
dev_pm_qos_add_notifier(dev, &gpd_data->nb);
return ret;
@@ -1175,8 +1215,8 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
if (!link)
return -ENOMEM;
- mutex_lock(&subdomain->lock);
- mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
+ genpd_lock(subdomain);
+ genpd_lock_nested(genpd, SINGLE_DEPTH_NESTING);
if (genpd->status == GPD_STATE_POWER_OFF
&& subdomain->status != GPD_STATE_POWER_OFF) {
@@ -1199,8 +1239,8 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
genpd_sd_counter_inc(genpd);
out:
- mutex_unlock(&genpd->lock);
- mutex_unlock(&subdomain->lock);
+ genpd_unlock(genpd);
+ genpd_unlock(subdomain);
if (ret)
kfree(link);
return ret;
@@ -1221,8 +1261,8 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(subdomain))
return -EINVAL;
- mutex_lock(&subdomain->lock);
- mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
+ genpd_lock(subdomain);
+ genpd_lock_nested(genpd, SINGLE_DEPTH_NESTING);
if (!list_empty(&subdomain->master_links) || subdomain->device_count) {
pr_warn("%s: unable to remove subdomain %s\n", genpd->name,
@@ -1246,8 +1286,8 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
}
out:
- mutex_unlock(&genpd->lock);
- mutex_unlock(&subdomain->lock);
+ genpd_unlock(genpd);
+ genpd_unlock(subdomain);
return ret;
}
@@ -1356,7 +1396,8 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
INIT_LIST_HEAD(&genpd->master_links);
INIT_LIST_HEAD(&genpd->slave_links);
INIT_LIST_HEAD(&genpd->dev_list);
- mutex_init(&genpd->lock);
+ mutex_init(&genpd->mlock);
+ genpd->lock_fns = &genpd_mtx_fns;
genpd->gov = gov;
INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
atomic_set(&genpd->sd_count, 0);
@@ -1714,9 +1755,9 @@ int genpd_dev_pm_attach(struct device *dev)
dev->pm_domain->detach = genpd_dev_pm_detach;
dev->pm_domain->sync = genpd_dev_pm_sync;
- mutex_lock(&pd->lock);
+ genpd_lock(pd);
ret = genpd_poweron(pd, 0);
- mutex_unlock(&pd->lock);
+ genpd_unlock(pd);
out:
return ret ? -EPROBE_DEFER : 0;
}
@@ -1774,7 +1815,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
char state[16];
int ret;
- ret = mutex_lock_interruptible(&genpd->lock);
+ ret = genpd_lock_interruptible(genpd);
if (ret)
return -ERESTARTSYS;
@@ -1811,7 +1852,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
seq_puts(s, "\n");
exit:
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
return 0;
}
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index c5d14b9..d37bf11 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -45,13 +45,14 @@ struct genpd_power_state {
struct device_node *of_node;
};
+struct genpd_lock_fns;
+
struct generic_pm_domain {
struct dev_pm_domain domain; /* PM domain operations */
struct list_head gpd_list_node; /* Node in the global PM domains list */
struct list_head master_links; /* Links with PM domain as a master */
struct list_head slave_links; /* Links with PM domain as a slave */
struct list_head dev_list; /* List of devices */
- struct mutex lock;
struct dev_power_governor *gov;
struct work_struct power_off_work;
struct device_node *of_node; /* Device node of the PM domain */
@@ -75,6 +76,8 @@ struct generic_pm_domain {
struct genpd_power_state states[GENPD_MAX_NUM_STATES];
unsigned int state_count; /* number of states */
unsigned int state_idx; /* state that genpd will go to when off */
+ const struct genpd_lock_fns *lock_fns;
+ struct mutex mlock;
};
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 03/15] PM / Domains: Abstract genpd locking
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Abstract genpd lock/unlock calls, in preparation for domain specific
locks added in the following patches.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Krzysztof Koz?owski <k.kozlowski@samsung.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
[Ulf: Rebased as additional mutex_lock|unlock has been added]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/base/power/domain.c | 113 ++++++++++++++++++++++++++++++--------------
include/linux/pm_domain.h | 5 +-
2 files changed, 81 insertions(+), 37 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 3aecac3..ce1dbfdd 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -39,6 +39,46 @@
static LIST_HEAD(gpd_list);
static DEFINE_MUTEX(gpd_list_lock);
+struct genpd_lock_fns {
+ void (*lock)(struct generic_pm_domain *genpd);
+ void (*lock_nested)(struct generic_pm_domain *genpd, int depth);
+ int (*lock_interruptible)(struct generic_pm_domain *genpd);
+ void (*unlock)(struct generic_pm_domain *genpd);
+};
+
+static void genpd_lock_mtx(struct generic_pm_domain *genpd)
+{
+ mutex_lock(&genpd->mlock);
+}
+
+static void genpd_lock_nested_mtx(struct generic_pm_domain *genpd,
+ int depth)
+{
+ mutex_lock_nested(&genpd->mlock, depth);
+}
+
+static int genpd_lock_interruptible_mtx(struct generic_pm_domain *genpd)
+{
+ return mutex_lock_interruptible(&genpd->mlock);
+}
+
+static void genpd_unlock_mtx(struct generic_pm_domain *genpd)
+{
+ return mutex_unlock(&genpd->mlock);
+}
+
+static const struct genpd_lock_fns genpd_mtx_fns = {
+ .lock = genpd_lock_mtx,
+ .lock_nested = genpd_lock_nested_mtx,
+ .lock_interruptible = genpd_lock_interruptible_mtx,
+ .unlock = genpd_unlock_mtx,
+};
+
+#define genpd_lock(p) p->lock_fns->lock(p)
+#define genpd_lock_nested(p, d) p->lock_fns->lock_nested(p, d)
+#define genpd_lock_interruptible(p) p->lock_fns->lock_interruptible(p)
+#define genpd_unlock(p) p->lock_fns->unlock(p)
+
/*
* Get the generic PM domain for a particular struct device.
* This validates the struct device pointer, the PM domain pointer,
@@ -200,9 +240,9 @@ static int genpd_poweron(struct generic_pm_domain *genpd, unsigned int depth)
genpd_sd_counter_inc(master);
- mutex_lock_nested(&master->lock, depth + 1);
+ genpd_lock_nested(master, depth + 1);
ret = genpd_poweron(master, depth + 1);
- mutex_unlock(&master->lock);
+ genpd_unlock(master);
if (ret) {
genpd_sd_counter_dec(master);
@@ -255,9 +295,9 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block *nb,
spin_unlock_irq(&dev->power.lock);
if (!IS_ERR(genpd)) {
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd->max_off_time_changed = true;
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
dev = dev->parent;
@@ -354,9 +394,9 @@ static void genpd_power_off_work_fn(struct work_struct *work)
genpd = container_of(work, struct generic_pm_domain, power_off_work);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd_poweroff(genpd, true);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
/**
@@ -472,9 +512,9 @@ static int genpd_runtime_suspend(struct device *dev)
if (dev->power.irq_safe)
return 0;
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd_poweroff(genpd, false);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
return 0;
}
@@ -509,9 +549,9 @@ static int genpd_runtime_resume(struct device *dev)
goto out;
}
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
ret = genpd_poweron(genpd, 0);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
if (ret)
return ret;
@@ -547,9 +587,9 @@ err_stop:
genpd_stop_dev(genpd, dev);
err_poweroff:
if (!dev->power.irq_safe) {
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd_poweroff(genpd, 0);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
return ret;
@@ -732,20 +772,20 @@ static int pm_genpd_prepare(struct device *dev)
if (resume_needed(dev, genpd))
pm_runtime_resume(dev);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
if (genpd->prepared_count++ == 0)
genpd->suspended_count = 0;
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
ret = pm_generic_prepare(dev);
if (ret) {
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd->prepared_count--;
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
return ret;
@@ -936,13 +976,13 @@ static void pm_genpd_complete(struct device *dev)
pm_generic_complete(dev);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
genpd->prepared_count--;
if (!genpd->prepared_count)
genpd_queue_power_off_work(genpd);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
}
/**
@@ -1077,7 +1117,7 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
if (IS_ERR(gpd_data))
return PTR_ERR(gpd_data);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
if (genpd->prepared_count > 0) {
ret = -EAGAIN;
@@ -1094,7 +1134,7 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
list_add_tail(&gpd_data->base.list_node, &genpd->dev_list);
out:
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
if (ret)
genpd_free_dev_data(dev, gpd_data);
@@ -1127,7 +1167,7 @@ int pm_genpd_remove_device(struct generic_pm_domain *genpd,
gpd_data = to_gpd_data(pdd);
dev_pm_qos_remove_notifier(dev, &gpd_data->nb);
- mutex_lock(&genpd->lock);
+ genpd_lock(genpd);
if (genpd->prepared_count > 0) {
ret = -EAGAIN;
@@ -1142,14 +1182,14 @@ int pm_genpd_remove_device(struct generic_pm_domain *genpd,
list_del_init(&pdd->list_node);
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
genpd_free_dev_data(dev, gpd_data);
return 0;
out:
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
dev_pm_qos_add_notifier(dev, &gpd_data->nb);
return ret;
@@ -1175,8 +1215,8 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
if (!link)
return -ENOMEM;
- mutex_lock(&subdomain->lock);
- mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
+ genpd_lock(subdomain);
+ genpd_lock_nested(genpd, SINGLE_DEPTH_NESTING);
if (genpd->status == GPD_STATE_POWER_OFF
&& subdomain->status != GPD_STATE_POWER_OFF) {
@@ -1199,8 +1239,8 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
genpd_sd_counter_inc(genpd);
out:
- mutex_unlock(&genpd->lock);
- mutex_unlock(&subdomain->lock);
+ genpd_unlock(genpd);
+ genpd_unlock(subdomain);
if (ret)
kfree(link);
return ret;
@@ -1221,8 +1261,8 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(subdomain))
return -EINVAL;
- mutex_lock(&subdomain->lock);
- mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
+ genpd_lock(subdomain);
+ genpd_lock_nested(genpd, SINGLE_DEPTH_NESTING);
if (!list_empty(&subdomain->master_links) || subdomain->device_count) {
pr_warn("%s: unable to remove subdomain %s\n", genpd->name,
@@ -1246,8 +1286,8 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
}
out:
- mutex_unlock(&genpd->lock);
- mutex_unlock(&subdomain->lock);
+ genpd_unlock(genpd);
+ genpd_unlock(subdomain);
return ret;
}
@@ -1356,7 +1396,8 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
INIT_LIST_HEAD(&genpd->master_links);
INIT_LIST_HEAD(&genpd->slave_links);
INIT_LIST_HEAD(&genpd->dev_list);
- mutex_init(&genpd->lock);
+ mutex_init(&genpd->mlock);
+ genpd->lock_fns = &genpd_mtx_fns;
genpd->gov = gov;
INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
atomic_set(&genpd->sd_count, 0);
@@ -1714,9 +1755,9 @@ int genpd_dev_pm_attach(struct device *dev)
dev->pm_domain->detach = genpd_dev_pm_detach;
dev->pm_domain->sync = genpd_dev_pm_sync;
- mutex_lock(&pd->lock);
+ genpd_lock(pd);
ret = genpd_poweron(pd, 0);
- mutex_unlock(&pd->lock);
+ genpd_unlock(pd);
out:
return ret ? -EPROBE_DEFER : 0;
}
@@ -1774,7 +1815,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
char state[16];
int ret;
- ret = mutex_lock_interruptible(&genpd->lock);
+ ret = genpd_lock_interruptible(genpd);
if (ret)
return -ERESTARTSYS;
@@ -1811,7 +1852,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
seq_puts(s, "\n");
exit:
- mutex_unlock(&genpd->lock);
+ genpd_unlock(genpd);
return 0;
}
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index c5d14b9..d37bf11 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -45,13 +45,14 @@ struct genpd_power_state {
struct device_node *of_node;
};
+struct genpd_lock_fns;
+
struct generic_pm_domain {
struct dev_pm_domain domain; /* PM domain operations */
struct list_head gpd_list_node; /* Node in the global PM domains list */
struct list_head master_links; /* Links with PM domain as a master */
struct list_head slave_links; /* Links with PM domain as a slave */
struct list_head dev_list; /* List of devices */
- struct mutex lock;
struct dev_power_governor *gov;
struct work_struct power_off_work;
struct device_node *of_node; /* Device node of the PM domain */
@@ -75,6 +76,8 @@ struct generic_pm_domain {
struct genpd_power_state states[GENPD_MAX_NUM_STATES];
unsigned int state_count; /* number of states */
unsigned int state_idx; /* state that genpd will go to when off */
+ const struct genpd_lock_fns *lock_fns;
+ struct mutex mlock;
};
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 04/15] PM / Domains: Support IRQ safe PM domains
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, Kevin Hilman,
Geert Uytterhoeven, Krzysztof Kozłowski
Generic Power Domains currently support turning on/off only in process
context. This prevents the usage of PM domains for domains that could be
powered on/off in a context where IRQs are disabled. Many such domains
exist today and do not get powered off, when the IRQ safe devices in
that domain are powered off, because of this limitation.
However, not all domains can operate in IRQ safe contexts. Genpd
therefore, has to support both cases where the domain may or may not
operate in IRQ safe contexts. Configuring genpd to use an appropriate
lock for that domain, would allow domains that have IRQ safe devices to
runtime suspend and resume, in atomic context.
To achieve domain specific locking, set the domain's ->flag to
GENPD_FLAG_IRQ_SAFE while defining the domain. This indicates that genpd
should use a spinlock instead of a mutex for locking the domain. Locking
is abstracted through genpd_lock() and genpd_unlock() functions that use
the flag to determine the appropriate lock to be used for that domain.
Domains that have lower latency to suspend and resume and can operate
with IRQs disabled may now be able to save power, when the component
devices and sub-domains are idle at runtime.
The restriction this imposes on the domain hierarchy is that non-IRQ
safe domains may not have IRQ-safe subdomains, but IRQ safe domains may
have IRQ safe and non-IRQ safe subdomains and devices.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Krzysztof Kozłowski <k.kozlowski@samsung.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
[Ulf: Rebased and solved a conflict]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/base/power/domain.c | 107 +++++++++++++++++++++++++++++++++++++++-----
include/linux/pm_domain.h | 10 ++++-
2 files changed, 106 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index ce1dbfdd..4fc5688 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -74,11 +74,61 @@ static const struct genpd_lock_fns genpd_mtx_fns = {
.unlock = genpd_unlock_mtx,
};
+static void genpd_lock_spin(struct generic_pm_domain *genpd)
+ __acquires(&genpd->slock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&genpd->slock, flags);
+ genpd->lock_flags = flags;
+}
+
+static void genpd_lock_nested_spin(struct generic_pm_domain *genpd,
+ int depth)
+ __acquires(&genpd->slock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave_nested(&genpd->slock, flags, depth);
+ genpd->lock_flags = flags;
+}
+
+static int genpd_lock_interruptible_spin(struct generic_pm_domain *genpd)
+ __acquires(&genpd->slock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&genpd->slock, flags);
+ genpd->lock_flags = flags;
+ return 0;
+}
+
+static void genpd_unlock_spin(struct generic_pm_domain *genpd)
+ __releases(&genpd->slock)
+{
+ spin_unlock_irqrestore(&genpd->slock, genpd->lock_flags);
+}
+
+static const struct genpd_lock_fns genpd_spin_fns = {
+ .lock = genpd_lock_spin,
+ .lock_nested = genpd_lock_nested_spin,
+ .lock_interruptible = genpd_lock_interruptible_spin,
+ .unlock = genpd_unlock_spin,
+};
+
#define genpd_lock(p) p->lock_fns->lock(p)
#define genpd_lock_nested(p, d) p->lock_fns->lock_nested(p, d)
#define genpd_lock_interruptible(p) p->lock_fns->lock_interruptible(p)
#define genpd_unlock(p) p->lock_fns->unlock(p)
+#define genpd_is_irq_safe(genpd) (genpd->flags & GENPD_FLAG_IRQ_SAFE)
+
+static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
+ struct generic_pm_domain *genpd)
+{
+ return pm_runtime_is_irq_safe(dev) && !genpd_is_irq_safe(genpd);
+}
+
/*
* Get the generic PM domain for a particular struct device.
* This validates the struct device pointer, the PM domain pointer,
@@ -343,7 +393,12 @@ static int genpd_poweroff(struct generic_pm_domain *genpd, bool is_async)
if (stat > PM_QOS_FLAGS_NONE)
return -EBUSY;
- if (!pm_runtime_suspended(pdd->dev) || pdd->dev->power.irq_safe)
+ /*
+ * Do not allow PM domain to be powered off, when an IRQ safe
+ * device is part of a non-IRQ safe domain.
+ */
+ if (!pm_runtime_suspended(pdd->dev) ||
+ irq_safe_dev_in_no_sleep_domain(pdd->dev, genpd))
not_suspended++;
}
@@ -506,10 +561,10 @@ static int genpd_runtime_suspend(struct device *dev)
}
/*
- * If power.irq_safe is set, this routine will be run with interrupts
- * off, so it can't use mutexes.
+ * If power.irq_safe is set, this routine may be run with
+ * IRQs disabled, so suspend only if the PM domain also is irq_safe.
*/
- if (dev->power.irq_safe)
+ if (irq_safe_dev_in_no_sleep_domain(dev, genpd))
return 0;
genpd_lock(genpd);
@@ -543,8 +598,11 @@ static int genpd_runtime_resume(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- /* If power.irq_safe, the PM domain is never powered off. */
- if (dev->power.irq_safe) {
+ /*
+ * As we don't power off a non IRQ safe domain, which holds
+ * an IRQ safe device, we don't need to restore power to it.
+ */
+ if (irq_safe_dev_in_no_sleep_domain(dev, genpd)) {
timed = false;
goto out;
}
@@ -586,7 +644,8 @@ static int genpd_runtime_resume(struct device *dev)
err_stop:
genpd_stop_dev(genpd, dev);
err_poweroff:
- if (!dev->power.irq_safe) {
+ if (!dev->power.irq_safe ||
+ (dev->power.irq_safe && genpd_is_irq_safe(genpd))) {
genpd_lock(genpd);
genpd_poweroff(genpd, 0);
genpd_unlock(genpd);
@@ -1117,6 +1176,11 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
if (IS_ERR(gpd_data))
return PTR_ERR(gpd_data);
+ /* Check if we are adding an IRQ safe device to non-IRQ safe domain */
+ if (irq_safe_dev_in_no_sleep_domain(dev, genpd))
+ dev_warn_once(dev, "PM domain %s will not be powered off\n",
+ genpd->name);
+
genpd_lock(genpd);
if (genpd->prepared_count > 0) {
@@ -1211,6 +1275,17 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
|| genpd == subdomain)
return -EINVAL;
+ /*
+ * If the domain can be powered on/off in an IRQ safe
+ * context, ensure that the subdomain can also be
+ * powered on/off in that context.
+ */
+ if (!genpd_is_irq_safe(genpd) && genpd_is_irq_safe(subdomain)) {
+ WARN("Parent %s of subdomain %s must be IRQ safe\n",
+ genpd->name, subdomain->name);
+ return -EINVAL;
+ }
+
link = kzalloc(sizeof(*link), GFP_KERNEL);
if (!link)
return -ENOMEM;
@@ -1377,6 +1452,17 @@ static int genpd_of_parse(struct generic_pm_domain *genpd)
return pm_genpd_of_parse_power_states(genpd);
}
+static void genpd_lock_init(struct generic_pm_domain *genpd)
+{
+ if (genpd->flags & GENPD_FLAG_IRQ_SAFE) {
+ spin_lock_init(&genpd->slock);
+ genpd->lock_fns = &genpd_spin_fns;
+ } else {
+ mutex_init(&genpd->mlock);
+ genpd->lock_fns = &genpd_mtx_fns;
+ }
+}
+
/**
* pm_genpd_init - Initialize a generic I/O PM domain object.
* @genpd: PM domain object to initialize.
@@ -1396,8 +1482,7 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
INIT_LIST_HEAD(&genpd->master_links);
INIT_LIST_HEAD(&genpd->slave_links);
INIT_LIST_HEAD(&genpd->dev_list);
- mutex_init(&genpd->mlock);
- genpd->lock_fns = &genpd_mtx_fns;
+ genpd_lock_init(genpd);
genpd->gov = gov;
INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
atomic_set(&genpd->sd_count, 0);
@@ -1841,7 +1926,9 @@ static int pm_genpd_summary_one(struct seq_file *s,
}
list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
- kobj_path = kobject_get_path(&pm_data->dev->kobj, GFP_KERNEL);
+ kobj_path = kobject_get_path(&pm_data->dev->kobj,
+ genpd_is_irq_safe(genpd) ?
+ GFP_ATOMIC : GFP_KERNEL);
if (kobj_path == NULL)
continue;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index d37bf11..688dc57 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -15,9 +15,11 @@
#include <linux/err.h>
#include <linux/of.h>
#include <linux/notifier.h>
+#include <linux/spinlock.h>
/* Defines used for the flags field in the struct generic_pm_domain */
#define GENPD_FLAG_PM_CLK (1U << 0) /* PM domain uses PM clk */
+#define GENPD_FLAG_IRQ_SAFE (1U << 1) /* PM domain operates in atomic */
#define GENPD_MAX_NUM_STATES 8 /* Number of possible low power states */
@@ -77,7 +79,13 @@ struct generic_pm_domain {
unsigned int state_count; /* number of states */
unsigned int state_idx; /* state that genpd will go to when off */
const struct genpd_lock_fns *lock_fns;
- struct mutex mlock;
+ union {
+ struct mutex mlock;
+ struct {
+ spinlock_t slock;
+ unsigned long lock_flags;
+ };
+ };
};
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 04/15] PM / Domains: Support IRQ safe PM domains
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Generic Power Domains currently support turning on/off only in process
context. This prevents the usage of PM domains for domains that could be
powered on/off in a context where IRQs are disabled. Many such domains
exist today and do not get powered off, when the IRQ safe devices in
that domain are powered off, because of this limitation.
However, not all domains can operate in IRQ safe contexts. Genpd
therefore, has to support both cases where the domain may or may not
operate in IRQ safe contexts. Configuring genpd to use an appropriate
lock for that domain, would allow domains that have IRQ safe devices to
runtime suspend and resume, in atomic context.
To achieve domain specific locking, set the domain's ->flag to
GENPD_FLAG_IRQ_SAFE while defining the domain. This indicates that genpd
should use a spinlock instead of a mutex for locking the domain. Locking
is abstracted through genpd_lock() and genpd_unlock() functions that use
the flag to determine the appropriate lock to be used for that domain.
Domains that have lower latency to suspend and resume and can operate
with IRQs disabled may now be able to save power, when the component
devices and sub-domains are idle at runtime.
The restriction this imposes on the domain hierarchy is that non-IRQ
safe domains may not have IRQ-safe subdomains, but IRQ safe domains may
have IRQ safe and non-IRQ safe subdomains and devices.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Krzysztof Koz?owski <k.kozlowski@samsung.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
[Ulf: Rebased and solved a conflict]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/base/power/domain.c | 107 +++++++++++++++++++++++++++++++++++++++-----
include/linux/pm_domain.h | 10 ++++-
2 files changed, 106 insertions(+), 11 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index ce1dbfdd..4fc5688 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -74,11 +74,61 @@ static const struct genpd_lock_fns genpd_mtx_fns = {
.unlock = genpd_unlock_mtx,
};
+static void genpd_lock_spin(struct generic_pm_domain *genpd)
+ __acquires(&genpd->slock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&genpd->slock, flags);
+ genpd->lock_flags = flags;
+}
+
+static void genpd_lock_nested_spin(struct generic_pm_domain *genpd,
+ int depth)
+ __acquires(&genpd->slock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave_nested(&genpd->slock, flags, depth);
+ genpd->lock_flags = flags;
+}
+
+static int genpd_lock_interruptible_spin(struct generic_pm_domain *genpd)
+ __acquires(&genpd->slock)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&genpd->slock, flags);
+ genpd->lock_flags = flags;
+ return 0;
+}
+
+static void genpd_unlock_spin(struct generic_pm_domain *genpd)
+ __releases(&genpd->slock)
+{
+ spin_unlock_irqrestore(&genpd->slock, genpd->lock_flags);
+}
+
+static const struct genpd_lock_fns genpd_spin_fns = {
+ .lock = genpd_lock_spin,
+ .lock_nested = genpd_lock_nested_spin,
+ .lock_interruptible = genpd_lock_interruptible_spin,
+ .unlock = genpd_unlock_spin,
+};
+
#define genpd_lock(p) p->lock_fns->lock(p)
#define genpd_lock_nested(p, d) p->lock_fns->lock_nested(p, d)
#define genpd_lock_interruptible(p) p->lock_fns->lock_interruptible(p)
#define genpd_unlock(p) p->lock_fns->unlock(p)
+#define genpd_is_irq_safe(genpd) (genpd->flags & GENPD_FLAG_IRQ_SAFE)
+
+static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
+ struct generic_pm_domain *genpd)
+{
+ return pm_runtime_is_irq_safe(dev) && !genpd_is_irq_safe(genpd);
+}
+
/*
* Get the generic PM domain for a particular struct device.
* This validates the struct device pointer, the PM domain pointer,
@@ -343,7 +393,12 @@ static int genpd_poweroff(struct generic_pm_domain *genpd, bool is_async)
if (stat > PM_QOS_FLAGS_NONE)
return -EBUSY;
- if (!pm_runtime_suspended(pdd->dev) || pdd->dev->power.irq_safe)
+ /*
+ * Do not allow PM domain to be powered off, when an IRQ safe
+ * device is part of a non-IRQ safe domain.
+ */
+ if (!pm_runtime_suspended(pdd->dev) ||
+ irq_safe_dev_in_no_sleep_domain(pdd->dev, genpd))
not_suspended++;
}
@@ -506,10 +561,10 @@ static int genpd_runtime_suspend(struct device *dev)
}
/*
- * If power.irq_safe is set, this routine will be run with interrupts
- * off, so it can't use mutexes.
+ * If power.irq_safe is set, this routine may be run with
+ * IRQs disabled, so suspend only if the PM domain also is irq_safe.
*/
- if (dev->power.irq_safe)
+ if (irq_safe_dev_in_no_sleep_domain(dev, genpd))
return 0;
genpd_lock(genpd);
@@ -543,8 +598,11 @@ static int genpd_runtime_resume(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
- /* If power.irq_safe, the PM domain is never powered off. */
- if (dev->power.irq_safe) {
+ /*
+ * As we don't power off a non IRQ safe domain, which holds
+ * an IRQ safe device, we don't need to restore power to it.
+ */
+ if (irq_safe_dev_in_no_sleep_domain(dev, genpd)) {
timed = false;
goto out;
}
@@ -586,7 +644,8 @@ static int genpd_runtime_resume(struct device *dev)
err_stop:
genpd_stop_dev(genpd, dev);
err_poweroff:
- if (!dev->power.irq_safe) {
+ if (!dev->power.irq_safe ||
+ (dev->power.irq_safe && genpd_is_irq_safe(genpd))) {
genpd_lock(genpd);
genpd_poweroff(genpd, 0);
genpd_unlock(genpd);
@@ -1117,6 +1176,11 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
if (IS_ERR(gpd_data))
return PTR_ERR(gpd_data);
+ /* Check if we are adding an IRQ safe device to non-IRQ safe domain */
+ if (irq_safe_dev_in_no_sleep_domain(dev, genpd))
+ dev_warn_once(dev, "PM domain %s will not be powered off\n",
+ genpd->name);
+
genpd_lock(genpd);
if (genpd->prepared_count > 0) {
@@ -1211,6 +1275,17 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
|| genpd == subdomain)
return -EINVAL;
+ /*
+ * If the domain can be powered on/off in an IRQ safe
+ * context, ensure that the subdomain can also be
+ * powered on/off in that context.
+ */
+ if (!genpd_is_irq_safe(genpd) && genpd_is_irq_safe(subdomain)) {
+ WARN("Parent %s of subdomain %s must be IRQ safe\n",
+ genpd->name, subdomain->name);
+ return -EINVAL;
+ }
+
link = kzalloc(sizeof(*link), GFP_KERNEL);
if (!link)
return -ENOMEM;
@@ -1377,6 +1452,17 @@ static int genpd_of_parse(struct generic_pm_domain *genpd)
return pm_genpd_of_parse_power_states(genpd);
}
+static void genpd_lock_init(struct generic_pm_domain *genpd)
+{
+ if (genpd->flags & GENPD_FLAG_IRQ_SAFE) {
+ spin_lock_init(&genpd->slock);
+ genpd->lock_fns = &genpd_spin_fns;
+ } else {
+ mutex_init(&genpd->mlock);
+ genpd->lock_fns = &genpd_mtx_fns;
+ }
+}
+
/**
* pm_genpd_init - Initialize a generic I/O PM domain object.
* @genpd: PM domain object to initialize.
@@ -1396,8 +1482,7 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
INIT_LIST_HEAD(&genpd->master_links);
INIT_LIST_HEAD(&genpd->slave_links);
INIT_LIST_HEAD(&genpd->dev_list);
- mutex_init(&genpd->mlock);
- genpd->lock_fns = &genpd_mtx_fns;
+ genpd_lock_init(genpd);
genpd->gov = gov;
INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
atomic_set(&genpd->sd_count, 0);
@@ -1841,7 +1926,9 @@ static int pm_genpd_summary_one(struct seq_file *s,
}
list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
- kobj_path = kobject_get_path(&pm_data->dev->kobj, GFP_KERNEL);
+ kobj_path = kobject_get_path(&pm_data->dev->kobj,
+ genpd_is_irq_safe(genpd) ?
+ GFP_ATOMIC : GFP_KERNEL);
if (kobj_path == NULL)
continue;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index d37bf11..688dc57 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -15,9 +15,11 @@
#include <linux/err.h>
#include <linux/of.h>
#include <linux/notifier.h>
+#include <linux/spinlock.h>
/* Defines used for the flags field in the struct generic_pm_domain */
#define GENPD_FLAG_PM_CLK (1U << 0) /* PM domain uses PM clk */
+#define GENPD_FLAG_IRQ_SAFE (1U << 1) /* PM domain operates in atomic */
#define GENPD_MAX_NUM_STATES 8 /* Number of possible low power states */
@@ -77,7 +79,13 @@ struct generic_pm_domain {
unsigned int state_count; /* number of states */
unsigned int state_idx; /* state that genpd will go to when off */
const struct genpd_lock_fns *lock_fns;
- struct mutex mlock;
+ union {
+ struct mutex mlock;
+ struct {
+ spinlock_t slock;
+ unsigned long lock_flags;
+ };
+ };
};
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 05/15] PM / doc: Update device documentation for devices in IRQ safe PM domains
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer
Update documentation to reflect the changes made to support IRQ safe PM
domains.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
Documentation/power/devices.txt | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 8ba6625..a622136 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -607,7 +607,17 @@ individually. Instead, a set of devices sharing a power resource can be put
into a low-power state together at the same time by turning off the shared
power resource. Of course, they also need to be put into the full-power state
together, by turning the shared power resource on. A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain.
+
+Devices, by default, operate in process context. If a device can operate in
+IRQ safe context that has to be explicitly indicated by setting the irq_safe
+boolean inside struct generic_pm_domain to be true. Power domains by default,
+operate in process context but could have devices that are IRQ safe. Such
+power domains cannot be powered on/off during runtime PM. On the other hand,
+IRQ safe PM domains that have IRQ safe devices may be powered off when all
+the devices are in idle. An IRQ safe domain may only be attached as a
+subdomain to another IRQ safe domain.
Support for power domains is provided through the pm_domain field of struct
device. This field is a pointer to an object of type struct dev_pm_domain,
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 05/15] PM / doc: Update device documentation for devices in IRQ safe PM domains
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Update documentation to reflect the changes made to support IRQ safe PM
domains.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
Documentation/power/devices.txt | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 8ba6625..a622136 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -607,7 +607,17 @@ individually. Instead, a set of devices sharing a power resource can be put
into a low-power state together at the same time by turning off the shared
power resource. Of course, they also need to be put into the full-power state
together, by turning the shared power resource on. A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain.
+
+Devices, by default, operate in process context. If a device can operate in
+IRQ safe context that has to be explicitly indicated by setting the irq_safe
+boolean inside struct generic_pm_domain to be true. Power domains by default,
+operate in process context but could have devices that are IRQ safe. Such
+power domains cannot be powered on/off during runtime PM. On the other hand,
+IRQ safe PM domains that have IRQ safe devices may be powered off when all
+the devices are in idle. An IRQ safe domain may only be attached as a
+subdomain to another IRQ safe domain.
Support for power domains is provided through the pm_domain field of struct
device. This field is a pointer to an object of type struct dev_pm_domain,
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 06/15] PM / cpu_domains: Setup PM domains for CPUs/clusters
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, Daniel Lezcano,
Lorenzo Pieralisi
Define and add Generic PM domains (genpd) for CPU clusters. Many new
SoCs group CPUs as clusters. Clusters share common resources like power
rails, caches, VFP, Coresight etc. When all CPUs in the cluster are
idle, these shared resources may also be put in their idle state.
CPUs may be associated with their domain providers in DT. The domains in
turn may be associated with their providers. This is clean way to model
the cluster hierarchy like that of ARM's big.little architecture. The
current patch expects OF support to initialize and setup CPU PM domains.
For each CPU in the DT, we identify the domain provider; initialize and
register the PM domain if isn't already registered and attach all the
CPU devices to the domain. Usually, when there are multiple clusters of
CPUs, there is a top level coherency domain that is dependent on these
individual domains. All domains thus created are marked IRQ safe
automatically and therefore may be powered down when the CPUs in the
domain are powered down by cpuidle.
Reading DT, initializing Generic PM domains, attaching CPUs to it
domains are common functionalities across ARM SoCs. Provide a common set
of APIs to setup PM domains for CPU clusters and its parents. The
platform drivers may just call of_setup_cpu_pd() to do a single step
setup of CPU domains.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Suggested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/base/power/Makefile | 1 +
drivers/base/power/cpu_domains.c | 310 +++++++++++++++++++++++++++++++++++++++
include/linux/cpu_domains.h | 39 +++++
3 files changed, 350 insertions(+)
create mode 100644 drivers/base/power/cpu_domains.c
create mode 100644 include/linux/cpu_domains.h
diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 5998c53..9883e89 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o
obj-$(CONFIG_PM_TRACE_RTC) += trace.o
obj-$(CONFIG_PM_OPP) += opp/
obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o domain_governor.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS_OF) += cpu_domains.o
obj-$(CONFIG_HAVE_CLK) += clock_ops.o
ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
new file mode 100644
index 0000000..a25a77e
--- /dev/null
+++ b/drivers/base/power/cpu_domains.c
@@ -0,0 +1,310 @@
+/*
+ * drivers/base/power/cpu_domains.c - Helper functions to create CPU PM domains.
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/cpu.h>
+#include <linux/cpumask.h>
+#include <linux/cpu_domains.h>
+#include <linux/cpu_pm.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/pm_domain.h>
+#include <linux/rculist.h>
+#include <linux/rcupdate.h>
+#include <linux/slab.h>
+
+#define CPU_PD_NAME_MAX 36
+
+struct cpu_pm_domain {
+ struct list_head link;
+ struct cpu_pd_ops ops;
+ struct generic_pm_domain *genpd;
+ struct cpu_pm_domain *parent;
+ cpumask_var_t cpus;
+};
+
+/* List of CPU PM domains we care about */
+static LIST_HEAD(of_cpu_pd_list);
+static DEFINE_MUTEX(cpu_pd_list_lock);
+
+static inline
+struct cpu_pm_domain *to_cpu_pd(struct generic_pm_domain *d)
+{
+ struct cpu_pm_domain *pd;
+ struct cpu_pm_domain *res = NULL;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(pd, &of_cpu_pd_list, link)
+ if (pd->genpd == d) {
+ res = pd;
+ break;
+ }
+ rcu_read_unlock();
+
+ return res;
+}
+
+static int cpu_pd_attach_cpu(struct cpu_pm_domain *cpu_pd, int cpu)
+{
+ int ret;
+ struct device *cpu_dev;
+
+ cpu_dev = get_cpu_device(cpu);
+ if (!cpu_dev) {
+ pr_warn("%s: Unable to get device for CPU%d\n",
+ __func__, cpu);
+ return -ENODEV;
+ }
+
+ ret = genpd_dev_pm_attach(cpu_dev);
+ if (ret)
+ dev_warn(cpu_dev,
+ "%s: Unable to attach to power-domain: %d\n",
+ __func__, ret);
+ else
+ dev_dbg(cpu_dev, "Attached to domain\n");
+
+ while (!ret && cpu_pd) {
+ cpumask_set_cpu(cpu, cpu_pd->cpus);
+ cpu_pd = cpu_pd->parent;
+ };
+
+ return ret;
+}
+
+static int cpu_pd_power_on(struct generic_pm_domain *genpd)
+{
+ struct cpu_pm_domain *pd = to_cpu_pd(genpd);
+
+ return pd->ops.power_on ? pd->ops.power_on() : 0;
+}
+
+static int cpu_pd_power_off(struct generic_pm_domain *genpd)
+{
+ struct cpu_pm_domain *pd = to_cpu_pd(genpd);
+
+ return pd->ops.power_off ? pd->ops.power_off(genpd->state_idx,
+ genpd->states[genpd->state_idx].param,
+ pd->cpus) : 0;
+}
+
+/**
+ * of_init_cpu_pm_domain() - Initialize a CPU PM domain from a device node
+ *
+ * @dn: The domain provider's device node
+ * @ops: The power_on/_off callbacks for the domain
+ *
+ * Returns the generic_pm_domain (genpd) pointer to the domain on success
+ */
+static struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
+ const struct cpu_pd_ops *ops)
+{
+ struct cpu_pm_domain *pd = NULL;
+ struct generic_pm_domain *genpd = NULL;
+ int ret = -ENOMEM;
+
+ if (!of_device_is_available(dn))
+ return ERR_PTR(-ENODEV);
+
+ genpd = kzalloc(sizeof(*genpd), GFP_KERNEL);
+ if (!genpd)
+ goto fail;
+
+ genpd->name = kstrndup(dn->full_name, CPU_PD_NAME_MAX, GFP_KERNEL);
+ if (!genpd->name)
+ goto fail;
+
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ goto fail;
+
+ if (!zalloc_cpumask_var(&pd->cpus, GFP_KERNEL))
+ goto fail;
+
+ genpd->power_off = cpu_pd_power_off;
+ genpd->power_on = cpu_pd_power_on;
+ genpd->flags |= GENPD_FLAG_IRQ_SAFE;
+ genpd->of_node = dn;
+ pd->genpd = genpd;
+ pd->ops.power_on = ops->power_on;
+ pd->ops.power_off = ops->power_off;
+
+ INIT_LIST_HEAD_RCU(&pd->link);
+ mutex_lock(&cpu_pd_list_lock);
+ list_add_rcu(&pd->link, &of_cpu_pd_list);
+ mutex_unlock(&cpu_pd_list_lock);
+
+ /* Populate platform specific states from DT */
+ if (ops->populate_state_data) {
+ struct device_node *np;
+ int i;
+
+ /* Initialize the arm,idle-state properties */
+ ret = pm_genpd_of_parse_power_states(genpd);
+ if (ret) {
+ pr_warn("%s domain states not initialized (%d)\n",
+ dn->full_name, ret);
+ goto fail;
+ }
+ for (i = 0; i < genpd->state_count; i++) {
+ ret = ops->populate_state_data(genpd->states[i].of_node,
+ &genpd->states[i].param);
+ of_node_put(np);
+ if (ret)
+ goto fail;
+ }
+ }
+
+ /* Register the CPU genpd */
+ pr_debug("adding %s as CPU PM domain\n", pd->genpd->name);
+ ret = pm_genpd_init(pd->genpd, &simple_qos_governor, false);
+ if (ret) {
+ pr_err("Unable to initialize domain %s\n", dn->full_name);
+ goto fail;
+ }
+
+ ret = of_genpd_add_provider_simple(dn, pd->genpd);
+ if (ret)
+ pr_warn("Unable to add genpd %s as provider\n",
+ pd->genpd->name);
+
+ return pd->genpd;
+fail:
+
+ kfree(genpd->name);
+ kfree(genpd);
+ if (pd)
+ kfree(pd->cpus);
+ kfree(pd);
+ return ERR_PTR(ret);
+}
+
+static struct generic_pm_domain *of_get_cpu_domain(struct device_node *dn,
+ const struct cpu_pd_ops *ops, int cpu)
+{
+ struct of_phandle_args args;
+ struct generic_pm_domain *genpd, *parent;
+ struct cpu_pm_domain *cpu_pd, *parent_cpu_pd;
+ int ret;
+
+ /* Do we have this domain? If not, create the domain */
+ args.np = dn;
+ args.args_count = 0;
+
+ genpd = of_genpd_get_from_provider(&args);
+ if (!IS_ERR(genpd))
+ return genpd;
+
+ genpd = of_init_cpu_pm_domain(dn, ops);
+ if (IS_ERR(genpd))
+ return genpd;
+
+ /* Is there a domain provider for this domain? */
+ ret = of_parse_phandle_with_args(dn, "power-domains",
+ "#power-domain-cells", 0, &args);
+ if (ret < 0)
+ goto skip_parent;
+
+ /* Find its parent and attach this domain to it, recursively */
+ parent = of_get_cpu_domain(args.np, ops, cpu);
+ if (IS_ERR(parent))
+ goto skip_parent;
+
+ ret = pm_genpd_add_subdomain(parent, genpd);
+ if (ret) {
+ pr_err("%s: Unable to add sub-domain (%s)\n err: %d",
+ __func__, genpd->name, ret);
+ return ERR_PTR(ret);
+ }
+
+ /*
+ * Reference parent domain for easy access.
+ * Note: We could be attached to a domain that is not a
+ * CPU PM domain in that case don't reference the parent.
+ */
+ cpu_pd = to_cpu_pd(genpd);
+ parent_cpu_pd = to_cpu_pd(parent);
+
+ if (cpu_pd && parent_cpu_pd)
+ cpu_pd->parent = parent_cpu_pd;
+
+skip_parent:
+ of_node_put(dn);
+ return genpd;
+}
+
+/**
+ * of_setup_cpu_pd_single() - Setup the PM domains for a CPU
+ *
+ * @cpu: The CPU for which the PM domain is to be set up.
+ * @ops: The PM domain suspend/resume ops for the CPU's domain
+ *
+ * If the CPU PM domain exists already, then the CPU is attached to
+ * that CPU PD. If it doesn't, the domain is created, the @ops are
+ * set for power_on/power_off callbacks and then the CPU is attached
+ * to that domain. If the domain was created outside this framework,
+ * then we do not attach the CPU to the domain.
+ */
+int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
+{
+
+ struct device_node *dn, *np;
+ struct generic_pm_domain *genpd;
+ struct cpu_pm_domain *cpu_pd;
+
+ np = of_get_cpu_node(cpu, NULL);
+ if (!np)
+ return -ENODEV;
+
+ dn = of_parse_phandle(np, "power-domains", 0);
+ of_node_put(np);
+ if (!dn)
+ return -ENODEV;
+
+ /* Find the genpd for this CPU, create if not found */
+ genpd = of_get_cpu_domain(dn, ops, cpu);
+ of_node_put(dn);
+ if (IS_ERR(genpd))
+ return PTR_ERR(genpd);
+
+ cpu_pd = to_cpu_pd(genpd);
+ if (!cpu_pd) {
+ pr_err("%s: Genpd was created outside CPU PM domains\n",
+ __func__);
+ return -ENOENT;
+ }
+
+ return cpu_pd_attach_cpu(cpu_pd, cpu);
+}
+EXPORT_SYMBOL(of_setup_cpu_pd_single);
+
+/**
+ * of_setup_cpu_pd() - Setup the PM domains for all CPUs
+ *
+ * @ops: The PM domain suspend/resume ops for all the domains
+ *
+ * Setup the CPU PM domain and attach all possible CPUs to their respective
+ * domains. The domains are created if not already and then attached.
+ */
+int of_setup_cpu_pd(const struct cpu_pd_ops *ops)
+{
+ int cpu;
+ int ret;
+
+ for_each_possible_cpu(cpu) {
+ ret = of_setup_cpu_pd_single(cpu, ops);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(of_setup_cpu_pd);
diff --git a/include/linux/cpu_domains.h b/include/linux/cpu_domains.h
new file mode 100644
index 0000000..de17f80
--- /dev/null
+++ b/include/linux/cpu_domains.h
@@ -0,0 +1,39 @@
+/*
+ * include/linux/cpu_domains.h
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __CPU_DOMAINS_H__
+#define __CPU_DOMAINS_H__
+
+#include <linux/types.h>
+
+struct cpumask;
+struct device_node;
+
+struct cpu_pd_ops {
+ int (*populate_state_data)(struct device_node *n, u32 *param);
+ int (*power_off)(u32 state_idx, u32 param, const struct cpumask *mask);
+ int (*power_on)(void);
+};
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops);
+int of_setup_cpu_pd(const struct cpu_pd_ops *ops);
+#else
+static inline int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
+{
+ return -ENODEV;
+}
+static inline int of_setup_cpu_pd(const struct cpu_pd_ops *ops)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
+
+#endif /* __CPU_DOMAINS_H__ */
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 06/15] PM / cpu_domains: Setup PM domains for CPUs/clusters
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Define and add Generic PM domains (genpd) for CPU clusters. Many new
SoCs group CPUs as clusters. Clusters share common resources like power
rails, caches, VFP, Coresight etc. When all CPUs in the cluster are
idle, these shared resources may also be put in their idle state.
CPUs may be associated with their domain providers in DT. The domains in
turn may be associated with their providers. This is clean way to model
the cluster hierarchy like that of ARM's big.little architecture. The
current patch expects OF support to initialize and setup CPU PM domains.
For each CPU in the DT, we identify the domain provider; initialize and
register the PM domain if isn't already registered and attach all the
CPU devices to the domain. Usually, when there are multiple clusters of
CPUs, there is a top level coherency domain that is dependent on these
individual domains. All domains thus created are marked IRQ safe
automatically and therefore may be powered down when the CPUs in the
domain are powered down by cpuidle.
Reading DT, initializing Generic PM domains, attaching CPUs to it
domains are common functionalities across ARM SoCs. Provide a common set
of APIs to setup PM domains for CPU clusters and its parents. The
platform drivers may just call of_setup_cpu_pd() to do a single step
setup of CPU domains.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Suggested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/base/power/Makefile | 1 +
drivers/base/power/cpu_domains.c | 310 +++++++++++++++++++++++++++++++++++++++
include/linux/cpu_domains.h | 39 +++++
3 files changed, 350 insertions(+)
create mode 100644 drivers/base/power/cpu_domains.c
create mode 100644 include/linux/cpu_domains.h
diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 5998c53..9883e89 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o
obj-$(CONFIG_PM_TRACE_RTC) += trace.o
obj-$(CONFIG_PM_OPP) += opp/
obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o domain_governor.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS_OF) += cpu_domains.o
obj-$(CONFIG_HAVE_CLK) += clock_ops.o
ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
new file mode 100644
index 0000000..a25a77e
--- /dev/null
+++ b/drivers/base/power/cpu_domains.c
@@ -0,0 +1,310 @@
+/*
+ * drivers/base/power/cpu_domains.c - Helper functions to create CPU PM domains.
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/cpu.h>
+#include <linux/cpumask.h>
+#include <linux/cpu_domains.h>
+#include <linux/cpu_pm.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/pm_domain.h>
+#include <linux/rculist.h>
+#include <linux/rcupdate.h>
+#include <linux/slab.h>
+
+#define CPU_PD_NAME_MAX 36
+
+struct cpu_pm_domain {
+ struct list_head link;
+ struct cpu_pd_ops ops;
+ struct generic_pm_domain *genpd;
+ struct cpu_pm_domain *parent;
+ cpumask_var_t cpus;
+};
+
+/* List of CPU PM domains we care about */
+static LIST_HEAD(of_cpu_pd_list);
+static DEFINE_MUTEX(cpu_pd_list_lock);
+
+static inline
+struct cpu_pm_domain *to_cpu_pd(struct generic_pm_domain *d)
+{
+ struct cpu_pm_domain *pd;
+ struct cpu_pm_domain *res = NULL;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(pd, &of_cpu_pd_list, link)
+ if (pd->genpd == d) {
+ res = pd;
+ break;
+ }
+ rcu_read_unlock();
+
+ return res;
+}
+
+static int cpu_pd_attach_cpu(struct cpu_pm_domain *cpu_pd, int cpu)
+{
+ int ret;
+ struct device *cpu_dev;
+
+ cpu_dev = get_cpu_device(cpu);
+ if (!cpu_dev) {
+ pr_warn("%s: Unable to get device for CPU%d\n",
+ __func__, cpu);
+ return -ENODEV;
+ }
+
+ ret = genpd_dev_pm_attach(cpu_dev);
+ if (ret)
+ dev_warn(cpu_dev,
+ "%s: Unable to attach to power-domain: %d\n",
+ __func__, ret);
+ else
+ dev_dbg(cpu_dev, "Attached to domain\n");
+
+ while (!ret && cpu_pd) {
+ cpumask_set_cpu(cpu, cpu_pd->cpus);
+ cpu_pd = cpu_pd->parent;
+ };
+
+ return ret;
+}
+
+static int cpu_pd_power_on(struct generic_pm_domain *genpd)
+{
+ struct cpu_pm_domain *pd = to_cpu_pd(genpd);
+
+ return pd->ops.power_on ? pd->ops.power_on() : 0;
+}
+
+static int cpu_pd_power_off(struct generic_pm_domain *genpd)
+{
+ struct cpu_pm_domain *pd = to_cpu_pd(genpd);
+
+ return pd->ops.power_off ? pd->ops.power_off(genpd->state_idx,
+ genpd->states[genpd->state_idx].param,
+ pd->cpus) : 0;
+}
+
+/**
+ * of_init_cpu_pm_domain() - Initialize a CPU PM domain from a device node
+ *
+ * @dn: The domain provider's device node
+ * @ops: The power_on/_off callbacks for the domain
+ *
+ * Returns the generic_pm_domain (genpd) pointer to the domain on success
+ */
+static struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
+ const struct cpu_pd_ops *ops)
+{
+ struct cpu_pm_domain *pd = NULL;
+ struct generic_pm_domain *genpd = NULL;
+ int ret = -ENOMEM;
+
+ if (!of_device_is_available(dn))
+ return ERR_PTR(-ENODEV);
+
+ genpd = kzalloc(sizeof(*genpd), GFP_KERNEL);
+ if (!genpd)
+ goto fail;
+
+ genpd->name = kstrndup(dn->full_name, CPU_PD_NAME_MAX, GFP_KERNEL);
+ if (!genpd->name)
+ goto fail;
+
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ goto fail;
+
+ if (!zalloc_cpumask_var(&pd->cpus, GFP_KERNEL))
+ goto fail;
+
+ genpd->power_off = cpu_pd_power_off;
+ genpd->power_on = cpu_pd_power_on;
+ genpd->flags |= GENPD_FLAG_IRQ_SAFE;
+ genpd->of_node = dn;
+ pd->genpd = genpd;
+ pd->ops.power_on = ops->power_on;
+ pd->ops.power_off = ops->power_off;
+
+ INIT_LIST_HEAD_RCU(&pd->link);
+ mutex_lock(&cpu_pd_list_lock);
+ list_add_rcu(&pd->link, &of_cpu_pd_list);
+ mutex_unlock(&cpu_pd_list_lock);
+
+ /* Populate platform specific states from DT */
+ if (ops->populate_state_data) {
+ struct device_node *np;
+ int i;
+
+ /* Initialize the arm,idle-state properties */
+ ret = pm_genpd_of_parse_power_states(genpd);
+ if (ret) {
+ pr_warn("%s domain states not initialized (%d)\n",
+ dn->full_name, ret);
+ goto fail;
+ }
+ for (i = 0; i < genpd->state_count; i++) {
+ ret = ops->populate_state_data(genpd->states[i].of_node,
+ &genpd->states[i].param);
+ of_node_put(np);
+ if (ret)
+ goto fail;
+ }
+ }
+
+ /* Register the CPU genpd */
+ pr_debug("adding %s as CPU PM domain\n", pd->genpd->name);
+ ret = pm_genpd_init(pd->genpd, &simple_qos_governor, false);
+ if (ret) {
+ pr_err("Unable to initialize domain %s\n", dn->full_name);
+ goto fail;
+ }
+
+ ret = of_genpd_add_provider_simple(dn, pd->genpd);
+ if (ret)
+ pr_warn("Unable to add genpd %s as provider\n",
+ pd->genpd->name);
+
+ return pd->genpd;
+fail:
+
+ kfree(genpd->name);
+ kfree(genpd);
+ if (pd)
+ kfree(pd->cpus);
+ kfree(pd);
+ return ERR_PTR(ret);
+}
+
+static struct generic_pm_domain *of_get_cpu_domain(struct device_node *dn,
+ const struct cpu_pd_ops *ops, int cpu)
+{
+ struct of_phandle_args args;
+ struct generic_pm_domain *genpd, *parent;
+ struct cpu_pm_domain *cpu_pd, *parent_cpu_pd;
+ int ret;
+
+ /* Do we have this domain? If not, create the domain */
+ args.np = dn;
+ args.args_count = 0;
+
+ genpd = of_genpd_get_from_provider(&args);
+ if (!IS_ERR(genpd))
+ return genpd;
+
+ genpd = of_init_cpu_pm_domain(dn, ops);
+ if (IS_ERR(genpd))
+ return genpd;
+
+ /* Is there a domain provider for this domain? */
+ ret = of_parse_phandle_with_args(dn, "power-domains",
+ "#power-domain-cells", 0, &args);
+ if (ret < 0)
+ goto skip_parent;
+
+ /* Find its parent and attach this domain to it, recursively */
+ parent = of_get_cpu_domain(args.np, ops, cpu);
+ if (IS_ERR(parent))
+ goto skip_parent;
+
+ ret = pm_genpd_add_subdomain(parent, genpd);
+ if (ret) {
+ pr_err("%s: Unable to add sub-domain (%s)\n err: %d",
+ __func__, genpd->name, ret);
+ return ERR_PTR(ret);
+ }
+
+ /*
+ * Reference parent domain for easy access.
+ * Note: We could be attached to a domain that is not a
+ * CPU PM domain in that case don't reference the parent.
+ */
+ cpu_pd = to_cpu_pd(genpd);
+ parent_cpu_pd = to_cpu_pd(parent);
+
+ if (cpu_pd && parent_cpu_pd)
+ cpu_pd->parent = parent_cpu_pd;
+
+skip_parent:
+ of_node_put(dn);
+ return genpd;
+}
+
+/**
+ * of_setup_cpu_pd_single() - Setup the PM domains for a CPU
+ *
+ * @cpu: The CPU for which the PM domain is to be set up.
+ * @ops: The PM domain suspend/resume ops for the CPU's domain
+ *
+ * If the CPU PM domain exists already, then the CPU is attached to
+ * that CPU PD. If it doesn't, the domain is created, the @ops are
+ * set for power_on/power_off callbacks and then the CPU is attached
+ * to that domain. If the domain was created outside this framework,
+ * then we do not attach the CPU to the domain.
+ */
+int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
+{
+
+ struct device_node *dn, *np;
+ struct generic_pm_domain *genpd;
+ struct cpu_pm_domain *cpu_pd;
+
+ np = of_get_cpu_node(cpu, NULL);
+ if (!np)
+ return -ENODEV;
+
+ dn = of_parse_phandle(np, "power-domains", 0);
+ of_node_put(np);
+ if (!dn)
+ return -ENODEV;
+
+ /* Find the genpd for this CPU, create if not found */
+ genpd = of_get_cpu_domain(dn, ops, cpu);
+ of_node_put(dn);
+ if (IS_ERR(genpd))
+ return PTR_ERR(genpd);
+
+ cpu_pd = to_cpu_pd(genpd);
+ if (!cpu_pd) {
+ pr_err("%s: Genpd was created outside CPU PM domains\n",
+ __func__);
+ return -ENOENT;
+ }
+
+ return cpu_pd_attach_cpu(cpu_pd, cpu);
+}
+EXPORT_SYMBOL(of_setup_cpu_pd_single);
+
+/**
+ * of_setup_cpu_pd() - Setup the PM domains for all CPUs
+ *
+ * @ops: The PM domain suspend/resume ops for all the domains
+ *
+ * Setup the CPU PM domain and attach all possible CPUs to their respective
+ * domains. The domains are created if not already and then attached.
+ */
+int of_setup_cpu_pd(const struct cpu_pd_ops *ops)
+{
+ int cpu;
+ int ret;
+
+ for_each_possible_cpu(cpu) {
+ ret = of_setup_cpu_pd_single(cpu, ops);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(of_setup_cpu_pd);
diff --git a/include/linux/cpu_domains.h b/include/linux/cpu_domains.h
new file mode 100644
index 0000000..de17f80
--- /dev/null
+++ b/include/linux/cpu_domains.h
@@ -0,0 +1,39 @@
+/*
+ * include/linux/cpu_domains.h
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __CPU_DOMAINS_H__
+#define __CPU_DOMAINS_H__
+
+#include <linux/types.h>
+
+struct cpumask;
+struct device_node;
+
+struct cpu_pd_ops {
+ int (*populate_state_data)(struct device_node *n, u32 *param);
+ int (*power_off)(u32 state_idx, u32 param, const struct cpumask *mask);
+ int (*power_on)(void);
+};
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops);
+int of_setup_cpu_pd(const struct cpu_pd_ops *ops);
+#else
+static inline int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
+{
+ return -ENODEV;
+}
+static inline int of_setup_cpu_pd(const struct cpu_pd_ops *ops)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
+
+#endif /* __CPU_DOMAINS_H__ */
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 07/15] ARM: cpuidle: Add runtime PM support for CPUs
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, Daniel Lezcano,
Lorenzo Pieralisi
Notify runtime PM when the CPU is going to be powered off in the idle
state. This allows for runtime PM suspend/resume of the CPU as well as
its PM domain.
We do not call into runtime PM for ARM WFI to keep the default state
simple and faster.
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/cpuidle/cpuidle-arm.c | 55 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index e342565e..3abd145 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -11,12 +11,14 @@
#define pr_fmt(fmt) "CPUidle arm: " fmt
+#include <linux/cpu.h>
#include <linux/cpuidle.h>
#include <linux/cpumask.h>
#include <linux/cpu_pm.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include <asm/cpuidle.h>
@@ -37,6 +39,7 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int idx)
{
int ret;
+ struct device *cpu_dev = get_cpu_device(dev->cpu);
if (!idx) {
cpu_do_idle();
@@ -46,12 +49,20 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
ret = cpu_pm_enter();
if (!ret) {
/*
+ * Call runtime PM suspend on our device
+ * Notify RCU to pay attention to critical sections
+ * called from within runtime PM.
+ */
+ RCU_NONIDLE(pm_runtime_put_sync_suspend(cpu_dev));
+
+ /*
* Pass idle state index to cpu_suspend which in turn will
* call the CPU ops suspend protocol with idle index as a
* parameter.
*/
ret = arm_cpuidle_suspend(idx);
+ RCU_NONIDLE(pm_runtime_get_sync(cpu_dev));
cpu_pm_exit();
}
@@ -84,6 +95,34 @@ static const struct of_device_id arm_idle_state_match[] __initconst = {
{ },
};
+#ifdef CONFIG_HOTPLUG_CPU
+static int arm_idle_cpu_hotplug(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *cpu_dev = get_cpu_device(smp_processor_id());
+
+ /* Execute CPU runtime PM on that CPU */
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_DYING:
+ pm_runtime_put_sync_suspend(cpu_dev);
+ break;
+ case CPU_STARTING:
+ pm_runtime_get_sync(cpu_dev);
+ break;
+ default:
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+#else
+static int arm_idle_cpu_hotplug(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ return NOTIFY_OK;
+}
+#endif
+
/*
* arm_idle_init
*
@@ -96,6 +135,7 @@ static int __init arm_idle_init(void)
int cpu, ret;
struct cpuidle_driver *drv = &arm_idle_driver;
struct cpuidle_device *dev;
+ struct device *cpu_dev;
/*
* Initialize idle states data, starting at index 1.
@@ -118,6 +158,16 @@ static int __init arm_idle_init(void)
* idle states suspend back-end specific data
*/
for_each_possible_cpu(cpu) {
+
+ /* Initialize Runtime PM for the CPU */
+ cpu_dev = get_cpu_device(cpu);
+ pm_runtime_irq_safe(cpu_dev);
+ pm_runtime_enable(cpu_dev);
+ if (cpu_online(cpu)) {
+ pm_runtime_get_noresume(cpu_dev);
+ pm_runtime_set_active(cpu_dev);
+ }
+
ret = arm_cpuidle_init(cpu);
/*
@@ -148,10 +198,15 @@ static int __init arm_idle_init(void)
}
}
+ /* Register for hotplug notifications for runtime PM */
+ hotcpu_notifier(arm_idle_cpu_hotplug, 0);
+
return 0;
out_fail:
while (--cpu >= 0) {
dev = per_cpu(cpuidle_devices, cpu);
+ cpu_dev = get_cpu_device(cpu);
+ __pm_runtime_disable(cpu_dev, false);
cpuidle_unregister_device(dev);
kfree(dev);
}
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 07/15] ARM: cpuidle: Add runtime PM support for CPUs
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Notify runtime PM when the CPU is going to be powered off in the idle
state. This allows for runtime PM suspend/resume of the CPU as well as
its PM domain.
We do not call into runtime PM for ARM WFI to keep the default state
simple and faster.
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/cpuidle/cpuidle-arm.c | 55 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index e342565e..3abd145 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -11,12 +11,14 @@
#define pr_fmt(fmt) "CPUidle arm: " fmt
+#include <linux/cpu.h>
#include <linux/cpuidle.h>
#include <linux/cpumask.h>
#include <linux/cpu_pm.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include <asm/cpuidle.h>
@@ -37,6 +39,7 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int idx)
{
int ret;
+ struct device *cpu_dev = get_cpu_device(dev->cpu);
if (!idx) {
cpu_do_idle();
@@ -46,12 +49,20 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
ret = cpu_pm_enter();
if (!ret) {
/*
+ * Call runtime PM suspend on our device
+ * Notify RCU to pay attention to critical sections
+ * called from within runtime PM.
+ */
+ RCU_NONIDLE(pm_runtime_put_sync_suspend(cpu_dev));
+
+ /*
* Pass idle state index to cpu_suspend which in turn will
* call the CPU ops suspend protocol with idle index as a
* parameter.
*/
ret = arm_cpuidle_suspend(idx);
+ RCU_NONIDLE(pm_runtime_get_sync(cpu_dev));
cpu_pm_exit();
}
@@ -84,6 +95,34 @@ static const struct of_device_id arm_idle_state_match[] __initconst = {
{ },
};
+#ifdef CONFIG_HOTPLUG_CPU
+static int arm_idle_cpu_hotplug(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *cpu_dev = get_cpu_device(smp_processor_id());
+
+ /* Execute CPU runtime PM on that CPU */
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_DYING:
+ pm_runtime_put_sync_suspend(cpu_dev);
+ break;
+ case CPU_STARTING:
+ pm_runtime_get_sync(cpu_dev);
+ break;
+ default:
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+#else
+static int arm_idle_cpu_hotplug(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ return NOTIFY_OK;
+}
+#endif
+
/*
* arm_idle_init
*
@@ -96,6 +135,7 @@ static int __init arm_idle_init(void)
int cpu, ret;
struct cpuidle_driver *drv = &arm_idle_driver;
struct cpuidle_device *dev;
+ struct device *cpu_dev;
/*
* Initialize idle states data, starting at index 1.
@@ -118,6 +158,16 @@ static int __init arm_idle_init(void)
* idle states suspend back-end specific data
*/
for_each_possible_cpu(cpu) {
+
+ /* Initialize Runtime PM for the CPU */
+ cpu_dev = get_cpu_device(cpu);
+ pm_runtime_irq_safe(cpu_dev);
+ pm_runtime_enable(cpu_dev);
+ if (cpu_online(cpu)) {
+ pm_runtime_get_noresume(cpu_dev);
+ pm_runtime_set_active(cpu_dev);
+ }
+
ret = arm_cpuidle_init(cpu);
/*
@@ -148,10 +198,15 @@ static int __init arm_idle_init(void)
}
}
+ /* Register for hotplug notifications for runtime PM */
+ hotcpu_notifier(arm_idle_cpu_hotplug, 0);
+
return 0;
out_fail:
while (--cpu >= 0) {
dev = per_cpu(cpuidle_devices, cpu);
+ cpu_dev = get_cpu_device(cpu);
+ __pm_runtime_disable(cpu_dev, false);
cpuidle_unregister_device(dev);
kfree(dev);
}
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 08/15] timer: Export next wake up of a CPU
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, Thomas Gleixner
Knowing the sleep length of the CPU is useful for the power state
determination on idle. The value is relative to the time when the call
was invoked by the CPU. This doesn't work well when there is a need to
know when the actual wakeup is.
By reading the next wake up event of a CPU, governors can determine the
first CPU to wake up (due to timer) amongst a cluster of CPUs and the
sleep time available between the last CPU to idle and the first CPU to
resume. This information is useful to determine if the caches and other
common hardware blocks can also be put in idle during this common period
of inactivity.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
include/linux/tick.h | 7 +++++++
kernel/time/tick-sched.c | 11 +++++++++++
2 files changed, 18 insertions(+)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 62be0786..92fa4b0 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -117,6 +117,7 @@ extern void tick_nohz_idle_enter(void);
extern void tick_nohz_idle_exit(void);
extern void tick_nohz_irq_exit(void);
extern ktime_t tick_nohz_get_sleep_length(void);
+extern ktime_t tick_nohz_get_next_wakeup(int cpu);
extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
#else /* !CONFIG_NO_HZ_COMMON */
@@ -131,6 +132,12 @@ static inline ktime_t tick_nohz_get_sleep_length(void)
return len;
}
+
+static inline ktime_t tick_nohz_get_next_wakeup(int cpu)
+{
+ return tick_next_period;
+}
+
static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
#endif /* !CONFIG_NO_HZ_COMMON */
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 536ada8..5c7ac17 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -979,6 +979,17 @@ ktime_t tick_nohz_get_sleep_length(void)
return ts->sleep_length;
}
+/**
+ * tick_nohz_get_next_wakeup - return the next wake up of the CPU
+ */
+ktime_t tick_nohz_get_next_wakeup(int cpu)
+{
+ struct clock_event_device *dev =
+ per_cpu(tick_cpu_device.evtdev, cpu);
+
+ return dev->next_event;
+}
+
static void tick_nohz_account_idle_ticks(struct tick_sched *ts)
{
#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 08/15] timer: Export next wake up of a CPU
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
Knowing the sleep length of the CPU is useful for the power state
determination on idle. The value is relative to the time when the call
was invoked by the CPU. This doesn't work well when there is a need to
know when the actual wakeup is.
By reading the next wake up event of a CPU, governors can determine the
first CPU to wake up (due to timer) amongst a cluster of CPUs and the
sleep time available between the last CPU to idle and the first CPU to
resume. This information is useful to determine if the caches and other
common hardware blocks can also be put in idle during this common period
of inactivity.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
include/linux/tick.h | 7 +++++++
kernel/time/tick-sched.c | 11 +++++++++++
2 files changed, 18 insertions(+)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 62be0786..92fa4b0 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -117,6 +117,7 @@ extern void tick_nohz_idle_enter(void);
extern void tick_nohz_idle_exit(void);
extern void tick_nohz_irq_exit(void);
extern ktime_t tick_nohz_get_sleep_length(void);
+extern ktime_t tick_nohz_get_next_wakeup(int cpu);
extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
#else /* !CONFIG_NO_HZ_COMMON */
@@ -131,6 +132,12 @@ static inline ktime_t tick_nohz_get_sleep_length(void)
return len;
}
+
+static inline ktime_t tick_nohz_get_next_wakeup(int cpu)
+{
+ return tick_next_period;
+}
+
static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
#endif /* !CONFIG_NO_HZ_COMMON */
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 536ada8..5c7ac17 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -979,6 +979,17 @@ ktime_t tick_nohz_get_sleep_length(void)
return ts->sleep_length;
}
+/**
+ * tick_nohz_get_next_wakeup - return the next wake up of the CPU
+ */
+ktime_t tick_nohz_get_next_wakeup(int cpu)
+{
+ struct clock_event_device *dev =
+ per_cpu(tick_cpu_device.evtdev, cpu);
+
+ return dev->next_event;
+}
+
static void tick_nohz_account_idle_ticks(struct tick_sched *ts)
{
#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 09/15] PM / cpu_domains: Add PM Domain governor for CPUs
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer
A PM domain comprising of CPUs may be powered off when all the CPUs in
the domain are powered down. Powering down a CPU domain is generally a
expensive operation and therefore the power performance trade offs
should be considered. The time between the last CPU powering down and
the first CPU powering up in a domain, is the time available for the
domain to sleep. Ideally, the sleep time of the domain should fulfill
the residency requirement of the domains' idle state.
To do this effectively, read the time before the wakeup of the cluster's
CPUs and ensure that the domain's idle state sleep time guarantees the
QoS requirements of each of the CPU, the PM QoS CPU_DMA_LATENCY and the
state's residency.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/base/power/cpu_domains.c | 80 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
index a25a77e..5dd28fd 100644
--- a/drivers/base/power/cpu_domains.c
+++ b/drivers/base/power/cpu_domains.c
@@ -17,9 +17,12 @@
#include <linux/list.h>
#include <linux/of.h>
#include <linux/pm_domain.h>
+#include <linux/pm_qos.h>
+#include <linux/pm_runtime.h>
#include <linux/rculist.h>
#include <linux/rcupdate.h>
#include <linux/slab.h>
+#include <linux/tick.h>
#define CPU_PD_NAME_MAX 36
@@ -52,6 +55,81 @@ struct cpu_pm_domain *to_cpu_pd(struct generic_pm_domain *d)
return res;
}
+static bool cpu_pd_down_ok(struct dev_pm_domain *pd)
+{
+ struct generic_pm_domain *genpd = pd_to_genpd(pd);
+ struct cpu_pm_domain *cpu_pd = to_cpu_pd(genpd);
+ int qos_ns = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
+ u64 sleep_ns;
+ ktime_t earliest, next_wakeup;
+ int cpu;
+ int i;
+
+ /* Reset the last set genpd state, default to index 0 */
+ genpd->state_idx = 0;
+
+ /* We don't want to power down, if QoS is 0 */
+ if (!qos_ns)
+ return false;
+
+ /*
+ * Find the sleep time for the cluster.
+ * The time between now and the first wake up of any CPU that
+ * are in this domain hierarchy is the time available for the
+ * domain to be idle.
+ *
+ * We only care about the next wakeup for any online CPU in that
+ * cluster. Hotplug off any of the CPUs that we care about will
+ * wait on the genpd lock, until we are done. Any other CPU hotplug
+ * is not of consequence to our sleep time.
+ */
+ earliest = ktime_set(KTIME_SEC_MAX, 0);
+ for_each_cpu_and(cpu, cpu_pd->cpus, cpu_online_mask) {
+ next_wakeup = tick_nohz_get_next_wakeup(cpu);
+ if (earliest.tv64 > next_wakeup.tv64)
+ earliest = next_wakeup;
+ }
+
+ sleep_ns = ktime_to_ns(ktime_sub(earliest, ktime_get()));
+ if (sleep_ns <= 0)
+ return false;
+
+ /*
+ * Find the deepest sleep state that satisfies the residency
+ * requirement and the QoS constraint
+ */
+ for (i = genpd->state_count - 1; i >= 0; i--) {
+ u64 state_sleep_ns;
+
+ state_sleep_ns = genpd->states[i].power_off_latency_ns +
+ genpd->states[i].power_on_latency_ns +
+ genpd->states[i].residency_ns;
+
+ /*
+ * If we can't sleep to save power in the state, move on
+ * to the next lower idle state.
+ */
+ if (state_sleep_ns > sleep_ns)
+ continue;
+
+ /*
+ * We also don't want to sleep more than we should to
+ * gaurantee QoS.
+ */
+ if (state_sleep_ns < (qos_ns * NSEC_PER_USEC))
+ break;
+ }
+
+ if (i >= 0)
+ genpd->state_idx = i;
+
+ return (i >= 0);
+}
+
+static struct dev_power_governor cpu_pd_gov = {
+ .power_down_ok = cpu_pd_down_ok,
+};
+
static int cpu_pd_attach_cpu(struct cpu_pm_domain *cpu_pd, int cpu)
{
int ret;
@@ -165,7 +243,7 @@ static struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
/* Register the CPU genpd */
pr_debug("adding %s as CPU PM domain\n", pd->genpd->name);
- ret = pm_genpd_init(pd->genpd, &simple_qos_governor, false);
+ ret = pm_genpd_init(pd->genpd, &cpu_pd_gov, false);
if (ret) {
pr_err("Unable to initialize domain %s\n", dn->full_name);
goto fail;
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 09/15] PM / cpu_domains: Add PM Domain governor for CPUs
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
A PM domain comprising of CPUs may be powered off when all the CPUs in
the domain are powered down. Powering down a CPU domain is generally a
expensive operation and therefore the power performance trade offs
should be considered. The time between the last CPU powering down and
the first CPU powering up in a domain, is the time available for the
domain to sleep. Ideally, the sleep time of the domain should fulfill
the residency requirement of the domains' idle state.
To do this effectively, read the time before the wakeup of the cluster's
CPUs and ensure that the domain's idle state sleep time guarantees the
QoS requirements of each of the CPU, the PM QoS CPU_DMA_LATENCY and the
state's residency.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/base/power/cpu_domains.c | 80 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
index a25a77e..5dd28fd 100644
--- a/drivers/base/power/cpu_domains.c
+++ b/drivers/base/power/cpu_domains.c
@@ -17,9 +17,12 @@
#include <linux/list.h>
#include <linux/of.h>
#include <linux/pm_domain.h>
+#include <linux/pm_qos.h>
+#include <linux/pm_runtime.h>
#include <linux/rculist.h>
#include <linux/rcupdate.h>
#include <linux/slab.h>
+#include <linux/tick.h>
#define CPU_PD_NAME_MAX 36
@@ -52,6 +55,81 @@ struct cpu_pm_domain *to_cpu_pd(struct generic_pm_domain *d)
return res;
}
+static bool cpu_pd_down_ok(struct dev_pm_domain *pd)
+{
+ struct generic_pm_domain *genpd = pd_to_genpd(pd);
+ struct cpu_pm_domain *cpu_pd = to_cpu_pd(genpd);
+ int qos_ns = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
+ u64 sleep_ns;
+ ktime_t earliest, next_wakeup;
+ int cpu;
+ int i;
+
+ /* Reset the last set genpd state, default to index 0 */
+ genpd->state_idx = 0;
+
+ /* We don't want to power down, if QoS is 0 */
+ if (!qos_ns)
+ return false;
+
+ /*
+ * Find the sleep time for the cluster.
+ * The time between now and the first wake up of any CPU that
+ * are in this domain hierarchy is the time available for the
+ * domain to be idle.
+ *
+ * We only care about the next wakeup for any online CPU in that
+ * cluster. Hotplug off any of the CPUs that we care about will
+ * wait on the genpd lock, until we are done. Any other CPU hotplug
+ * is not of consequence to our sleep time.
+ */
+ earliest = ktime_set(KTIME_SEC_MAX, 0);
+ for_each_cpu_and(cpu, cpu_pd->cpus, cpu_online_mask) {
+ next_wakeup = tick_nohz_get_next_wakeup(cpu);
+ if (earliest.tv64 > next_wakeup.tv64)
+ earliest = next_wakeup;
+ }
+
+ sleep_ns = ktime_to_ns(ktime_sub(earliest, ktime_get()));
+ if (sleep_ns <= 0)
+ return false;
+
+ /*
+ * Find the deepest sleep state that satisfies the residency
+ * requirement and the QoS constraint
+ */
+ for (i = genpd->state_count - 1; i >= 0; i--) {
+ u64 state_sleep_ns;
+
+ state_sleep_ns = genpd->states[i].power_off_latency_ns +
+ genpd->states[i].power_on_latency_ns +
+ genpd->states[i].residency_ns;
+
+ /*
+ * If we can't sleep to save power in the state, move on
+ * to the next lower idle state.
+ */
+ if (state_sleep_ns > sleep_ns)
+ continue;
+
+ /*
+ * We also don't want to sleep more than we should to
+ * gaurantee QoS.
+ */
+ if (state_sleep_ns < (qos_ns * NSEC_PER_USEC))
+ break;
+ }
+
+ if (i >= 0)
+ genpd->state_idx = i;
+
+ return (i >= 0);
+}
+
+static struct dev_power_governor cpu_pd_gov = {
+ .power_down_ok = cpu_pd_down_ok,
+};
+
static int cpu_pd_attach_cpu(struct cpu_pm_domain *cpu_pd, int cpu)
{
int ret;
@@ -165,7 +243,7 @@ static struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
/* Register the CPU genpd */
pr_debug("adding %s as CPU PM domain\n", pd->genpd->name);
- ret = pm_genpd_init(pd->genpd, &simple_qos_governor, false);
+ ret = pm_genpd_init(pd->genpd, &cpu_pd_gov, false);
if (ret) {
pr_err("Unable to initialize domain %s\n", dn->full_name);
goto fail;
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 10/15] doc / cpu_domains: Describe CPU PM domains setup and governor
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer
A generic CPU PM domain functionality is provided by
drivers/base/power/cpu_domains.c. This document describes the generic
usecase of CPU's PM domains, the setup of such domains and a CPU
specific genpd governor.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
Documentation/power/cpu_domains.txt | 109 ++++++++++++++++++++++++++++++++++++
1 file changed, 109 insertions(+)
create mode 100644 Documentation/power/cpu_domains.txt
diff --git a/Documentation/power/cpu_domains.txt b/Documentation/power/cpu_domains.txt
new file mode 100644
index 0000000..6a39a64
--- /dev/null
+++ b/Documentation/power/cpu_domains.txt
@@ -0,0 +1,109 @@
+CPU PM domains
+==============
+
+Newer CPUs are grouped in SoCs as clusters. A cluster in addition to the CPUs
+may have caches, floating point units and other architecture specific power
+controller that share resources when any of the CPUs are active. When the CPUs
+are in idle, some of these cluster components may also idle. A cluster may
+also be nested inside another cluster that provides common coherency
+interfaces to share data between the clusters. The organization of such
+clusters and CPU may be descibed in DT, since they are SoC specific.
+
+CPUIdle framework enables the CPUs to determine the sleep time and enter low
+power state to save power during periods of idle. CPUs in a cluster may enter
+and exit idle state independently of each other. During the time when all the
+CPUs are in idle state, the cluster may safely put some of the shared
+resources in their idle state. The time between the last CPU to enter idle and
+the first CPU to wake up is the time available for the cluster to enter its
+idle state.
+
+When SoCs power down the CPU during cpuidle, they generally have supplemental
+hardware that can handshake with the CPU with a signal that indicates that the
+CPU has stopped execution. The hardware is also responsible for warm booting
+the CPU on receiving an interrupt. In a cluster architecture, common resources
+that are shared by a cluster may also be powered down by an external
+microcontroller or a processor. The microcontroller may be programmed in
+advance to put the hardware blocks in a low power state, when the last active
+CPU sends the idle signal. When the signal is received, the microcontroller
+may trigger the hardware blocks to enter their low power state. When an
+interrupt to wakeup the processor is received, the microcontroller is
+responsible for bringing up the hardware blocks to its active state, before
+waking up the CPU. The timelines for such operations should be in the
+acceptable range for for CPU idle to get power benefits.
+
+CPU PM Domain Setup
+-------------------
+
+PM domains are represented in the DT as domain consumers and providers. A
+device may have a domain provider and a domain provider may support multiple
+domain consumers. Domains like clusters, may also be nested inside one
+another. A domain that has no active consumer, may be powered off and any
+resuming consumer would trigger the domain back to active. Parent domains may
+be powered off when the child domains are powered off. The CPU cluster can be
+fashioned as a PM domain. When the CPU devices are powered off, the PM domain
+may be powered off.
+
+Device idle is reference counted by runtime PM. When there is no active need
+for the device, runtime PM invokes callbacks to suspend the parent domain.
+Generic PM domain (genpd) handles the hierarchy of devices, domains and the
+reference counting of objects leading to last man down and first man up in the
+domain. The CPU domains helper functions defines PM domains for each CPU
+cluster and attaches the CPU devices to the respective PM domains.
+
+Platform drivers may use the following API to register their CPU PM domains.
+
+of_setup_cpu_pd() -
+Provides a single step registration of the CPU PM domain and attach CPUs to
+the genpd. Platform drivers may additionally register callbacks for power_on
+and power_off operations for the PM domain.
+
+of_setup_cpu_pd_single() -
+Define PM domain for a single CPU and attach the CPU to its domain.
+
+
+CPU PM Domain governor
+----------------------
+
+CPUs have a unique ability to determine their next wakeup. CPUs may wake up
+for known timer interrupts and unknown interrupts from idle. Prediction
+algorithms and heuristic based algorithms like the Menu governor for cpuidle
+can determine the next wakeup of the CPU. However, determining the wakeup
+across a group of CPUs is a tough problem to solve.
+
+A simplistic approach would be to resort to known wakeups of the CPUs in
+determining the next wakeup of any CPU in the cluster. The CPU PM domain
+governor does just that. By looking into the tick device of the CPUs, the
+governor can determine the sleep time between the last CPU and the first
+scheduled wakeup of any CPU in that domain. This combined with the PM QoS
+requirement for CPU_DMA_LATENCY can be used to determine the deepest possible
+idle state of the CPU domain.
+
+
+PSCI based CPU PM Domains
+-------------------------
+
+ARM PSCI v1.0 supports PM domains for CPU clusters like in big.Little
+architecture. It is supported as part of the OS-Initiated (OSI) mode of the
+PSCI firmware. Since the control of domains is abstracted in the firmware,
+Linux does not need even a driver to control these domains. The complexity of
+determining the idle state of the PM domain is handled by the CPU PM domains.
+
+Every PSCI CPU PM domain idle state has a unique PSCI state id. The state id
+is read from the DT and specified using the arm,psci-suspend-param property.
+This makes it easy for big.Little SoCs to just specify the PM domain idle
+states for the CPU along with the psci-suspend-param and everything else is
+handled by the PSCI fimrware drivers and the firmware.
+
+
+DT definitions for PSCI CPU PM Domains
+--------------------------------------
+
+A PM domain's idle state can be defined in DT, the description of which is
+available in [1]. PSCI based CPU PM domains may define their idle states as
+part of the psci node. The additional parameter arm,psci-suspend-param is used
+to indicate to the firmwware the addition cluster state that would be achieved
+after the last CPU makes the PSCI call to suspend the CPU. The description of
+PSCI domain states is available in [2].
+
+[1]. Documentation/devicetree/bindings/arm/idle-states.txt
+[2]. Documentation/devicetree/bindings/arm/psci.txt
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 10/15] doc / cpu_domains: Describe CPU PM domains setup and governor
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
A generic CPU PM domain functionality is provided by
drivers/base/power/cpu_domains.c. This document describes the generic
usecase of CPU's PM domains, the setup of such domains and a CPU
specific genpd governor.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
Documentation/power/cpu_domains.txt | 109 ++++++++++++++++++++++++++++++++++++
1 file changed, 109 insertions(+)
create mode 100644 Documentation/power/cpu_domains.txt
diff --git a/Documentation/power/cpu_domains.txt b/Documentation/power/cpu_domains.txt
new file mode 100644
index 0000000..6a39a64
--- /dev/null
+++ b/Documentation/power/cpu_domains.txt
@@ -0,0 +1,109 @@
+CPU PM domains
+==============
+
+Newer CPUs are grouped in SoCs as clusters. A cluster in addition to the CPUs
+may have caches, floating point units and other architecture specific power
+controller that share resources when any of the CPUs are active. When the CPUs
+are in idle, some of these cluster components may also idle. A cluster may
+also be nested inside another cluster that provides common coherency
+interfaces to share data between the clusters. The organization of such
+clusters and CPU may be descibed in DT, since they are SoC specific.
+
+CPUIdle framework enables the CPUs to determine the sleep time and enter low
+power state to save power during periods of idle. CPUs in a cluster may enter
+and exit idle state independently of each other. During the time when all the
+CPUs are in idle state, the cluster may safely put some of the shared
+resources in their idle state. The time between the last CPU to enter idle and
+the first CPU to wake up is the time available for the cluster to enter its
+idle state.
+
+When SoCs power down the CPU during cpuidle, they generally have supplemental
+hardware that can handshake with the CPU with a signal that indicates that the
+CPU has stopped execution. The hardware is also responsible for warm booting
+the CPU on receiving an interrupt. In a cluster architecture, common resources
+that are shared by a cluster may also be powered down by an external
+microcontroller or a processor. The microcontroller may be programmed in
+advance to put the hardware blocks in a low power state, when the last active
+CPU sends the idle signal. When the signal is received, the microcontroller
+may trigger the hardware blocks to enter their low power state. When an
+interrupt to wakeup the processor is received, the microcontroller is
+responsible for bringing up the hardware blocks to its active state, before
+waking up the CPU. The timelines for such operations should be in the
+acceptable range for for CPU idle to get power benefits.
+
+CPU PM Domain Setup
+-------------------
+
+PM domains are represented in the DT as domain consumers and providers. A
+device may have a domain provider and a domain provider may support multiple
+domain consumers. Domains like clusters, may also be nested inside one
+another. A domain that has no active consumer, may be powered off and any
+resuming consumer would trigger the domain back to active. Parent domains may
+be powered off when the child domains are powered off. The CPU cluster can be
+fashioned as a PM domain. When the CPU devices are powered off, the PM domain
+may be powered off.
+
+Device idle is reference counted by runtime PM. When there is no active need
+for the device, runtime PM invokes callbacks to suspend the parent domain.
+Generic PM domain (genpd) handles the hierarchy of devices, domains and the
+reference counting of objects leading to last man down and first man up in the
+domain. The CPU domains helper functions defines PM domains for each CPU
+cluster and attaches the CPU devices to the respective PM domains.
+
+Platform drivers may use the following API to register their CPU PM domains.
+
+of_setup_cpu_pd() -
+Provides a single step registration of the CPU PM domain and attach CPUs to
+the genpd. Platform drivers may additionally register callbacks for power_on
+and power_off operations for the PM domain.
+
+of_setup_cpu_pd_single() -
+Define PM domain for a single CPU and attach the CPU to its domain.
+
+
+CPU PM Domain governor
+----------------------
+
+CPUs have a unique ability to determine their next wakeup. CPUs may wake up
+for known timer interrupts and unknown interrupts from idle. Prediction
+algorithms and heuristic based algorithms like the Menu governor for cpuidle
+can determine the next wakeup of the CPU. However, determining the wakeup
+across a group of CPUs is a tough problem to solve.
+
+A simplistic approach would be to resort to known wakeups of the CPUs in
+determining the next wakeup of any CPU in the cluster. The CPU PM domain
+governor does just that. By looking into the tick device of the CPUs, the
+governor can determine the sleep time between the last CPU and the first
+scheduled wakeup of any CPU in that domain. This combined with the PM QoS
+requirement for CPU_DMA_LATENCY can be used to determine the deepest possible
+idle state of the CPU domain.
+
+
+PSCI based CPU PM Domains
+-------------------------
+
+ARM PSCI v1.0 supports PM domains for CPU clusters like in big.Little
+architecture. It is supported as part of the OS-Initiated (OSI) mode of the
+PSCI firmware. Since the control of domains is abstracted in the firmware,
+Linux does not need even a driver to control these domains. The complexity of
+determining the idle state of the PM domain is handled by the CPU PM domains.
+
+Every PSCI CPU PM domain idle state has a unique PSCI state id. The state id
+is read from the DT and specified using the arm,psci-suspend-param property.
+This makes it easy for big.Little SoCs to just specify the PM domain idle
+states for the CPU along with the psci-suspend-param and everything else is
+handled by the PSCI fimrware drivers and the firmware.
+
+
+DT definitions for PSCI CPU PM Domains
+--------------------------------------
+
+A PM domain's idle state can be defined in DT, the description of which is
+available in [1]. PSCI based CPU PM domains may define their idle states as
+part of the psci node. The additional parameter arm,psci-suspend-param is used
+to indicate to the firmwware the addition cluster state that would be achieved
+after the last CPU makes the PSCI call to suspend the CPU. The description of
+PSCI domain states is available in [2].
+
+[1]. Documentation/devicetree/bindings/arm/idle-states.txt
+[2]. Documentation/devicetree/bindings/arm/psci.txt
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 11/15] drivers: firmware: psci: Allow OS Initiated suspend mode
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, Lorenzo Pieralisi,
Mark Rutland
PSCI firmware v1.0 onwards may support 2 different modes for
CPU_SUSPEND. Platform coordinated mode is the default and every firmware
should support it. OS Initiated mode is optional for the firmware to
implement and allow Linux to make an better decision on the state of
the CPU cluster heirarchy.
With the kernel capable of deciding the state for CPU cluster and
coherency domains, the OS Initiated mode may now be used by the kernel,
provided the firmware supports it. SET_SUSPEND_MODE is a PSCI function
available on v1.0 onwards and can be used to set the mode in the
firmware.
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
[Ulf: Rebased on 4.7 rc1]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/firmware/psci.c | 22 +++++++++++++++++++++-
include/uapi/linux/psci.h | 5 +++++
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 03e0458..3920aba 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -52,6 +52,7 @@
* require cooperation with a Trusted OS driver.
*/
static int resident_cpu = -1;
+static bool psci_has_osi_pd;
bool psci_tos_resident_on(int cpu)
{
@@ -563,10 +564,29 @@ out_put_node:
return err;
}
+static int __init psci_1_0_init(struct device_node *np)
+{
+ int ret;
+
+ ret = psci_0_2_init(np);
+ if (ret)
+ return ret;
+
+ /* Check if PSCI OSI mode is available */
+ ret = psci_features(psci_function_id[PSCI_FN_CPU_SUSPEND]);
+ if (ret & PSCI_1_0_OS_INITIATED) {
+ ret = psci_features(PSCI_1_0_FN_SET_SUSPEND_MODE);
+ if (!ret)
+ psci_has_osi_pd = true;
+ }
+
+ return 0;
+}
+
static const struct of_device_id psci_of_match[] __initconst = {
{ .compatible = "arm,psci", .data = psci_0_1_init},
{ .compatible = "arm,psci-0.2", .data = psci_0_2_init},
- { .compatible = "arm,psci-1.0", .data = psci_0_2_init},
+ { .compatible = "arm,psci-1.0", .data = psci_1_0_init},
{},
};
diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
index 3d7a0fc..7dd778e 100644
--- a/include/uapi/linux/psci.h
+++ b/include/uapi/linux/psci.h
@@ -48,6 +48,7 @@
#define PSCI_1_0_FN_PSCI_FEATURES PSCI_0_2_FN(10)
#define PSCI_1_0_FN_SYSTEM_SUSPEND PSCI_0_2_FN(14)
+#define PSCI_1_0_FN_SET_SUSPEND_MODE PSCI_0_2_FN(15)
#define PSCI_1_0_FN64_SYSTEM_SUSPEND PSCI_0_2_FN64(14)
@@ -93,6 +94,10 @@
#define PSCI_1_0_FEATURES_CPU_SUSPEND_PF_MASK \
(0x1 << PSCI_1_0_FEATURES_CPU_SUSPEND_PF_SHIFT)
+#define PSCI_1_0_OS_INITIATED BIT(0)
+#define PSCI_1_0_SUSPEND_MODE_PC 0
+#define PSCI_1_0_SUSPEND_MODE_OSI 1
+
/* PSCI return values (inclusive of all PSCI versions) */
#define PSCI_RET_SUCCESS 0
#define PSCI_RET_NOT_SUPPORTED -1
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 11/15] drivers: firmware: psci: Allow OS Initiated suspend mode
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
PSCI firmware v1.0 onwards may support 2 different modes for
CPU_SUSPEND. Platform coordinated mode is the default and every firmware
should support it. OS Initiated mode is optional for the firmware to
implement and allow Linux to make an better decision on the state of
the CPU cluster heirarchy.
With the kernel capable of deciding the state for CPU cluster and
coherency domains, the OS Initiated mode may now be used by the kernel,
provided the firmware supports it. SET_SUSPEND_MODE is a PSCI function
available on v1.0 onwards and can be used to set the mode in the
firmware.
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
[Ulf: Rebased on 4.7 rc1]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/firmware/psci.c | 22 +++++++++++++++++++++-
include/uapi/linux/psci.h | 5 +++++
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 03e0458..3920aba 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -52,6 +52,7 @@
* require cooperation with a Trusted OS driver.
*/
static int resident_cpu = -1;
+static bool psci_has_osi_pd;
bool psci_tos_resident_on(int cpu)
{
@@ -563,10 +564,29 @@ out_put_node:
return err;
}
+static int __init psci_1_0_init(struct device_node *np)
+{
+ int ret;
+
+ ret = psci_0_2_init(np);
+ if (ret)
+ return ret;
+
+ /* Check if PSCI OSI mode is available */
+ ret = psci_features(psci_function_id[PSCI_FN_CPU_SUSPEND]);
+ if (ret & PSCI_1_0_OS_INITIATED) {
+ ret = psci_features(PSCI_1_0_FN_SET_SUSPEND_MODE);
+ if (!ret)
+ psci_has_osi_pd = true;
+ }
+
+ return 0;
+}
+
static const struct of_device_id psci_of_match[] __initconst = {
{ .compatible = "arm,psci", .data = psci_0_1_init},
{ .compatible = "arm,psci-0.2", .data = psci_0_2_init},
- { .compatible = "arm,psci-1.0", .data = psci_0_2_init},
+ { .compatible = "arm,psci-1.0", .data = psci_1_0_init},
{},
};
diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
index 3d7a0fc..7dd778e 100644
--- a/include/uapi/linux/psci.h
+++ b/include/uapi/linux/psci.h
@@ -48,6 +48,7 @@
#define PSCI_1_0_FN_PSCI_FEATURES PSCI_0_2_FN(10)
#define PSCI_1_0_FN_SYSTEM_SUSPEND PSCI_0_2_FN(14)
+#define PSCI_1_0_FN_SET_SUSPEND_MODE PSCI_0_2_FN(15)
#define PSCI_1_0_FN64_SYSTEM_SUSPEND PSCI_0_2_FN64(14)
@@ -93,6 +94,10 @@
#define PSCI_1_0_FEATURES_CPU_SUSPEND_PF_MASK \
(0x1 << PSCI_1_0_FEATURES_CPU_SUSPEND_PF_SHIFT)
+#define PSCI_1_0_OS_INITIATED BIT(0)
+#define PSCI_1_0_SUSPEND_MODE_PC 0
+#define PSCI_1_0_SUSPEND_MODE_OSI 1
+
/* PSCI return values (inclusive of all PSCI versions) */
#define PSCI_RET_SUCCESS 0
#define PSCI_RET_NOT_SUPPORTED -1
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 12/15] drivers: firmware: psci: Support cluster idle states for OS-Initiated
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:04 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, Lorenzo Pieralisi,
Mark Rutland
PSCI OS initiated firmware may allow Linux to determine the state of the
CPU cluster and the cluster at coherency level to enter idle states when
there are no active CPUs. Since Linux has a better idea of the QoS and
the wakeup pattern of the CPUs, the cluster idle states may be better
determined by the OS instead of the firmware.
The last CPU entering idle in a cluster, is responsible for selecting
the state of the cluster. Only one CPU in a cluster may provide the
cluster idle state to the firmware. Similarly, the last CPU in the
system may provide the state of the coherency domain along with the
cluster and the CPU state IDs.
Utilize the CPU PM domain framework's helper functions to build up the
hierarchy of cluster topology using Generic PM domains. We provide
callbacks for domain power_on and power_off. By appending the state IDs
at each domain level in the -power_off() callbacks, we build up a
composite state ID that can be passed onto the firmware to idle the CPU,
the cluster and the coherency interface.
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/firmware/psci.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 86 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 3920aba..3a1e5a7 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -15,6 +15,7 @@
#include <linux/arm-smccc.h>
#include <linux/cpuidle.h>
+#include <linux/cpu_domains.h>
#include <linux/errno.h>
#include <linux/linkage.h>
#include <linux/of.h>
@@ -53,6 +54,17 @@
*/
static int resident_cpu = -1;
static bool psci_has_osi_pd;
+static DEFINE_PER_CPU(u32, cluster_state_id);
+
+static inline u32 psci_get_composite_state_id(u32 cpu_state)
+{
+ return cpu_state | this_cpu_read(cluster_state_id);
+}
+
+static inline void psci_reset_composite_state_id(void)
+{
+ this_cpu_write(cluster_state_id, 0);
+}
bool psci_tos_resident_on(int cpu)
{
@@ -179,6 +191,8 @@ static int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)
fn = psci_function_id[PSCI_FN_CPU_ON];
err = invoke_psci_fn(fn, cpuid, entry_point, 0);
+ /* Reset CPU cluster states */
+ psci_reset_composite_state_id();
return psci_to_linux_errno(err);
}
@@ -250,6 +264,52 @@ static int __init psci_features(u32 psci_func_id)
#ifdef CONFIG_CPU_IDLE
static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
+static bool psci_suspend_mode_is_osi;
+
+static int psci_set_suspend_mode_osi(bool enable)
+{
+ int ret;
+ int mode;
+
+ if (enable && !psci_has_osi_pd)
+ return -ENODEV;
+
+ if (enable == psci_suspend_mode_is_osi)
+ return 0;
+
+ mode = enable ? PSCI_1_0_SUSPEND_MODE_OSI : PSCI_1_0_SUSPEND_MODE_PC;
+ ret = invoke_psci_fn(PSCI_1_0_FN_SET_SUSPEND_MODE,
+ mode, 0, 0);
+ if (!ret)
+ psci_suspend_mode_is_osi = enable;
+
+ return psci_to_linux_errno(ret);
+}
+
+static const struct of_device_id psci_osi_match[] = {
+ { .compatible = "arm,psci-1.0", },
+ {},
+};
+
+static int psci_pd_populate_state_data(struct device_node *np, u32 *param)
+{
+ struct device_node *dn = of_get_next_parent(np);
+
+ /* Check if we are inside in the psci node */
+ for (; dn; dn = of_get_next_parent(dn))
+ if (of_match_node(psci_osi_match, dn))
+ return of_property_read_u32(np,
+ "arm,psci-suspend-param", param);
+
+ return -EINVAL;
+}
+
+static int psci_pd_power_off(u32 state_idx, u32 param,
+ const struct cpumask *mask)
+{
+ __this_cpu_add(cluster_state_id, param);
+ return 0;
+}
static int psci_dt_cpu_init_idle(struct device_node *cpu_node, int cpu)
{
@@ -304,6 +364,21 @@ static int psci_dt_cpu_init_idle(struct device_node *cpu_node, int cpu)
}
/* Idle states parsed correctly, initialize per-cpu pointer */
per_cpu(psci_power_state, cpu) = psci_states;
+
+ if (psci_has_osi_pd) {
+ int ret;
+ const struct cpu_pd_ops psci_pd_ops = {
+ .populate_state_data = psci_pd_populate_state_data,
+ .power_off = psci_pd_power_off,
+ };
+
+ ret = of_setup_cpu_pd_single(cpu, &psci_pd_ops);
+ if (!ret)
+ ret = psci_set_suspend_mode_osi(true);
+ if (ret)
+ pr_warn("CPU%d: Error setting PSCI OSI mode\n", cpu);
+ }
+
return 0;
free_mem:
@@ -330,15 +405,17 @@ int psci_cpu_init_idle(unsigned int cpu)
static int psci_suspend_finisher(unsigned long index)
{
u32 *state = __this_cpu_read(psci_power_state);
+ u32 ext_state = psci_get_composite_state_id(state[index - 1]);
- return psci_ops.cpu_suspend(state[index - 1],
- virt_to_phys(cpu_resume));
+ return psci_ops.cpu_suspend(ext_state, virt_to_phys(cpu_resume));
}
int psci_cpu_suspend_enter(unsigned long index)
{
int ret;
u32 *state = __this_cpu_read(psci_power_state);
+ u32 ext_state = psci_get_composite_state_id(state[index - 1]);
+
/*
* idle state index 0 corresponds to wfi, should never be called
* from the cpu_suspend operations
@@ -347,10 +424,16 @@ int psci_cpu_suspend_enter(unsigned long index)
return -EINVAL;
if (!psci_power_state_loses_context(state[index - 1]))
- ret = psci_ops.cpu_suspend(state[index - 1], 0);
+ ret = psci_ops.cpu_suspend(ext_state, 0);
else
ret = cpu_suspend(index, psci_suspend_finisher);
+ /*
+ * Clear the CPU's cluster states, we start afresh after coming
+ * out of idle.
+ */
+ psci_reset_composite_state_id();
+
return ret;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 12/15] drivers: firmware: psci: Support cluster idle states for OS-Initiated
@ 2016-08-04 23:04 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:04 UTC (permalink / raw)
To: linux-arm-kernel
PSCI OS initiated firmware may allow Linux to determine the state of the
CPU cluster and the cluster at coherency level to enter idle states when
there are no active CPUs. Since Linux has a better idea of the QoS and
the wakeup pattern of the CPUs, the cluster idle states may be better
determined by the OS instead of the firmware.
The last CPU entering idle in a cluster, is responsible for selecting
the state of the cluster. Only one CPU in a cluster may provide the
cluster idle state to the firmware. Similarly, the last CPU in the
system may provide the state of the coherency domain along with the
cluster and the CPU state IDs.
Utilize the CPU PM domain framework's helper functions to build up the
hierarchy of cluster topology using Generic PM domains. We provide
callbacks for domain power_on and power_off. By appending the state IDs
at each domain level in the -power_off() callbacks, we build up a
composite state ID that can be passed onto the firmware to idle the CPU,
the cluster and the coherency interface.
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
drivers/firmware/psci.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 86 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 3920aba..3a1e5a7 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -15,6 +15,7 @@
#include <linux/arm-smccc.h>
#include <linux/cpuidle.h>
+#include <linux/cpu_domains.h>
#include <linux/errno.h>
#include <linux/linkage.h>
#include <linux/of.h>
@@ -53,6 +54,17 @@
*/
static int resident_cpu = -1;
static bool psci_has_osi_pd;
+static DEFINE_PER_CPU(u32, cluster_state_id);
+
+static inline u32 psci_get_composite_state_id(u32 cpu_state)
+{
+ return cpu_state | this_cpu_read(cluster_state_id);
+}
+
+static inline void psci_reset_composite_state_id(void)
+{
+ this_cpu_write(cluster_state_id, 0);
+}
bool psci_tos_resident_on(int cpu)
{
@@ -179,6 +191,8 @@ static int psci_cpu_on(unsigned long cpuid, unsigned long entry_point)
fn = psci_function_id[PSCI_FN_CPU_ON];
err = invoke_psci_fn(fn, cpuid, entry_point, 0);
+ /* Reset CPU cluster states */
+ psci_reset_composite_state_id();
return psci_to_linux_errno(err);
}
@@ -250,6 +264,52 @@ static int __init psci_features(u32 psci_func_id)
#ifdef CONFIG_CPU_IDLE
static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
+static bool psci_suspend_mode_is_osi;
+
+static int psci_set_suspend_mode_osi(bool enable)
+{
+ int ret;
+ int mode;
+
+ if (enable && !psci_has_osi_pd)
+ return -ENODEV;
+
+ if (enable == psci_suspend_mode_is_osi)
+ return 0;
+
+ mode = enable ? PSCI_1_0_SUSPEND_MODE_OSI : PSCI_1_0_SUSPEND_MODE_PC;
+ ret = invoke_psci_fn(PSCI_1_0_FN_SET_SUSPEND_MODE,
+ mode, 0, 0);
+ if (!ret)
+ psci_suspend_mode_is_osi = enable;
+
+ return psci_to_linux_errno(ret);
+}
+
+static const struct of_device_id psci_osi_match[] = {
+ { .compatible = "arm,psci-1.0", },
+ {},
+};
+
+static int psci_pd_populate_state_data(struct device_node *np, u32 *param)
+{
+ struct device_node *dn = of_get_next_parent(np);
+
+ /* Check if we are inside in the psci node */
+ for (; dn; dn = of_get_next_parent(dn))
+ if (of_match_node(psci_osi_match, dn))
+ return of_property_read_u32(np,
+ "arm,psci-suspend-param", param);
+
+ return -EINVAL;
+}
+
+static int psci_pd_power_off(u32 state_idx, u32 param,
+ const struct cpumask *mask)
+{
+ __this_cpu_add(cluster_state_id, param);
+ return 0;
+}
static int psci_dt_cpu_init_idle(struct device_node *cpu_node, int cpu)
{
@@ -304,6 +364,21 @@ static int psci_dt_cpu_init_idle(struct device_node *cpu_node, int cpu)
}
/* Idle states parsed correctly, initialize per-cpu pointer */
per_cpu(psci_power_state, cpu) = psci_states;
+
+ if (psci_has_osi_pd) {
+ int ret;
+ const struct cpu_pd_ops psci_pd_ops = {
+ .populate_state_data = psci_pd_populate_state_data,
+ .power_off = psci_pd_power_off,
+ };
+
+ ret = of_setup_cpu_pd_single(cpu, &psci_pd_ops);
+ if (!ret)
+ ret = psci_set_suspend_mode_osi(true);
+ if (ret)
+ pr_warn("CPU%d: Error setting PSCI OSI mode\n", cpu);
+ }
+
return 0;
free_mem:
@@ -330,15 +405,17 @@ int psci_cpu_init_idle(unsigned int cpu)
static int psci_suspend_finisher(unsigned long index)
{
u32 *state = __this_cpu_read(psci_power_state);
+ u32 ext_state = psci_get_composite_state_id(state[index - 1]);
- return psci_ops.cpu_suspend(state[index - 1],
- virt_to_phys(cpu_resume));
+ return psci_ops.cpu_suspend(ext_state, virt_to_phys(cpu_resume));
}
int psci_cpu_suspend_enter(unsigned long index)
{
int ret;
u32 *state = __this_cpu_read(psci_power_state);
+ u32 ext_state = psci_get_composite_state_id(state[index - 1]);
+
/*
* idle state index 0 corresponds to wfi, should never be called
* from the cpu_suspend operations
@@ -347,10 +424,16 @@ int psci_cpu_suspend_enter(unsigned long index)
return -EINVAL;
if (!psci_power_state_loses_context(state[index - 1]))
- ret = psci_ops.cpu_suspend(state[index - 1], 0);
+ ret = psci_ops.cpu_suspend(ext_state, 0);
else
ret = cpu_suspend(index, psci_suspend_finisher);
+ /*
+ * Clear the CPU's cluster states, we start afresh after coming
+ * out of idle.
+ */
+ psci_reset_composite_state_id();
+
return ret;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:05 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:05 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer
Add bindings for defining a OS-Initiated based CPU PM domain.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
Documentation/devicetree/bindings/arm/psci.txt | 64 ++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index a2c4f1d..e1b2926 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -105,7 +105,71 @@ Case 3: PSCI v0.2 and PSCI v0.1.
...
};
+PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPU domains
+from the firmware. Such PM domains for which the PSCI firmware driver acts
+as pseudo-controller, may also be specified in the DT along with the domain
+idle states.
+
+The domain definitions must follow the domain idle state specifications per
+[3].
+
+The domain idle states must be specified using the optional node -
+
+- domain-states
+
+The domain states themselves must be compatible with 'arm,idle-state' defined
+in [1] and need to specify the arm,psci-suspend-param property for each idle
+state. More information on defining CPU PM domains is available in [4].
+
+Example: OS-Iniated PSCI based PM domains
+
+ 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_PD>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+
+ CPU_PD: cpu-pd@0 {
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
+ };
+
+ domain-states {
+ CLUSTER_RET: domain_ret {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000010>;
+ entry-latency-us = <500>;
+ exit-latency-us = <500>;
+ min-residency-us = <2000>;
+ };
+
+ CLUSTER_PWR_DWN: domain_gdhs {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000030>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
+ };
+
+
[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
+[4]. CPU PM Domains description
+ Documentation/power/cpu_domains.txt
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings
@ 2016-08-04 23:05 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:05 UTC (permalink / raw)
To: linux-arm-kernel
Add bindings for defining a OS-Initiated based CPU PM domain.
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
Documentation/devicetree/bindings/arm/psci.txt | 64 ++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index a2c4f1d..e1b2926 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -105,7 +105,71 @@ Case 3: PSCI v0.2 and PSCI v0.1.
...
};
+PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPU domains
+from the firmware. Such PM domains for which the PSCI firmware driver acts
+as pseudo-controller, may also be specified in the DT along with the domain
+idle states.
+
+The domain definitions must follow the domain idle state specifications per
+[3].
+
+The domain idle states must be specified using the optional node -
+
+- domain-states
+
+The domain states themselves must be compatible with 'arm,idle-state' defined
+in [1] and need to specify the arm,psci-suspend-param property for each idle
+state. More information on defining CPU PM domains is available in [4].
+
+Example: OS-Iniated PSCI based PM domains
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0>;
+ enable-method = "psci";
+ power-domains = <&CPU_PD>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+
+ CPU_PD: cpu-pd at 0 {
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
+ };
+
+ domain-states {
+ CLUSTER_RET: domain_ret {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000010>;
+ entry-latency-us = <500>;
+ exit-latency-us = <500>;
+ min-residency-us = <2000>;
+ };
+
+ CLUSTER_PWR_DWN: domain_gdhs {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000030>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
+ };
+
+
[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
+[4]. CPU PM Domains description
+ Documentation/power/cpu_domains.txt
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 14/15] ARM64: dts: Add PSCI cpuidle support for MSM8916
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:05 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:05 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Lina Iyer, devicetree
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 14/15] ARM64: dts: Add PSCI cpuidle support for MSM8916
@ 2016-08-04 23:05 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:05 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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 at 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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-04 23:05 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:05 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Lina Iyer,
devicetree-u79uwXL29TY76Z2rM5mHXA
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 3029773..eb0aaed 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 {
@@ -113,6 +117,29 @@
psci {
compatible = "arm,psci-1.0";
method = "smc";
+
+ CPU_PD: cpu-pd@0 {
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
+ };
+
+ domain-states {
+ CLUSTER_RET: domain_ret {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000010>;
+ entry-latency-us = <500>;
+ exit-latency-us = <500>;
+ min-residency-us = <2000>;
+ };
+
+ CLUSTER_PWR_DWN: domain_gdhs {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000030>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
};
timer {
--
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
@ 2016-08-04 23:05 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-04 23:05 UTC (permalink / raw)
To: linux-arm-kernel
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 | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 3029773..eb0aaed 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 at 1 {
@@ -73,6 +74,7 @@
next-level-cache = <&L2_0>;
enable-method = "psci";
cpu-idle-states = <&CPU_SPC>;
+ power-domains = <&CPU_PD>;
};
CPU2: cpu at 2 {
@@ -82,6 +84,7 @@
next-level-cache = <&L2_0>;
enable-method = "psci";
cpu-idle-states = <&CPU_SPC>;
+ power-domains = <&CPU_PD>;
};
CPU3: cpu at 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 {
@@ -113,6 +117,29 @@
psci {
compatible = "arm,psci-1.0";
method = "smc";
+
+ CPU_PD: cpu-pd at 0 {
+ #power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
+ };
+
+ domain-states {
+ CLUSTER_RET: domain_ret {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000010>;
+ entry-latency-us = <500>;
+ exit-latency-us = <500>;
+ min-residency-us = <2000>;
+ };
+
+ CLUSTER_PWR_DWN: domain_gdhs {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1000030>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
};
timer {
--
2.7.4
^ permalink raw reply related [flat|nested] 83+ messages in thread
* Re: [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings
2016-08-04 23:05 ` Lina Iyer
@ 2016-08-05 14:44 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-05 14:44 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, Device Tree
+devicetree
On Thu, Aug 04 2016 at 17:06 -0600, Lina Iyer wrote:
>Add bindings for defining a OS-Initiated based CPU PM domain.
>
>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>---
> Documentation/devicetree/bindings/arm/psci.txt | 64 ++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
>diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
>index a2c4f1d..e1b2926 100644
>--- a/Documentation/devicetree/bindings/arm/psci.txt
>+++ b/Documentation/devicetree/bindings/arm/psci.txt
>@@ -105,7 +105,71 @@ Case 3: PSCI v0.2 and PSCI v0.1.
> ...
> };
>
>+PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPU domains
>+from the firmware. Such PM domains for which the PSCI firmware driver acts
>+as pseudo-controller, may also be specified in the DT along with the domain
>+idle states.
>+
>+The domain definitions must follow the domain idle state specifications per
>+[3].
>+
>+The domain idle states must be specified using the optional node -
>+
>+- domain-states
>+
>+The domain states themselves must be compatible with 'arm,idle-state' defined
>+in [1] and need to specify the arm,psci-suspend-param property for each idle
>+state. More information on defining CPU PM domains is available in [4].
>+
>+Example: OS-Iniated PSCI based PM domains
>+
>+ 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_PD>;
>+ };
>+ };
>+
>+ psci {
>+ compatible = "arm,psci-1.0";
>+ method = "smc";
>+
>+ CPU_PD: cpu-pd@0 {
>+ #power-domain-cells = <0>;
>+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>+ };
>+
>+ domain-states {
>+ CLUSTER_RET: domain_ret {
>+ compatible = "arm,idle-state";
>+ arm,psci-suspend-param = <0x1000010>;
>+ entry-latency-us = <500>;
>+ exit-latency-us = <500>;
>+ min-residency-us = <2000>;
>+ };
>+
>+ CLUSTER_PWR_DWN: domain_gdhs {
>+ compatible = "arm,idle-state";
>+ arm,psci-suspend-param = <0x1000030>;
>+ entry-latency-us = <2000>;
>+ exit-latency-us = <2000>;
>+ min-residency-us = <6000>;
>+ };
>+ };
>+ };
>+
>+
> [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
>+[4]. CPU PM Domains description
>+ Documentation/power/cpu_domains.txt
>--
>2.7.4
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings
@ 2016-08-05 14:44 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-05 14:44 UTC (permalink / raw)
To: linux-arm-kernel
+devicetree
On Thu, Aug 04 2016 at 17:06 -0600, Lina Iyer wrote:
>Add bindings for defining a OS-Initiated based CPU PM domain.
>
>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>---
> Documentation/devicetree/bindings/arm/psci.txt | 64 ++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
>diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
>index a2c4f1d..e1b2926 100644
>--- a/Documentation/devicetree/bindings/arm/psci.txt
>+++ b/Documentation/devicetree/bindings/arm/psci.txt
>@@ -105,7 +105,71 @@ Case 3: PSCI v0.2 and PSCI v0.1.
> ...
> };
>
>+PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPU domains
>+from the firmware. Such PM domains for which the PSCI firmware driver acts
>+as pseudo-controller, may also be specified in the DT along with the domain
>+idle states.
>+
>+The domain definitions must follow the domain idle state specifications per
>+[3].
>+
>+The domain idle states must be specified using the optional node -
>+
>+- domain-states
>+
>+The domain states themselves must be compatible with 'arm,idle-state' defined
>+in [1] and need to specify the arm,psci-suspend-param property for each idle
>+state. More information on defining CPU PM domains is available in [4].
>+
>+Example: OS-Iniated PSCI based PM domains
>+
>+ cpus {
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+
>+ CPU0: cpu at 0 {
>+ device_type = "cpu";
>+ compatible = "arm,cortex-a53", "arm,armv8";
>+ reg = <0x0>;
>+ enable-method = "psci";
>+ power-domains = <&CPU_PD>;
>+ };
>+ };
>+
>+ psci {
>+ compatible = "arm,psci-1.0";
>+ method = "smc";
>+
>+ CPU_PD: cpu-pd at 0 {
>+ #power-domain-cells = <0>;
>+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>+ };
>+
>+ domain-states {
>+ CLUSTER_RET: domain_ret {
>+ compatible = "arm,idle-state";
>+ arm,psci-suspend-param = <0x1000010>;
>+ entry-latency-us = <500>;
>+ exit-latency-us = <500>;
>+ min-residency-us = <2000>;
>+ };
>+
>+ CLUSTER_PWR_DWN: domain_gdhs {
>+ compatible = "arm,idle-state";
>+ arm,psci-suspend-param = <0x1000030>;
>+ entry-latency-us = <2000>;
>+ exit-latency-us = <2000>;
>+ min-residency-us = <6000>;
>+ };
>+ };
>+ };
>+
>+
> [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
>+[4]. CPU PM Domains description
>+ Documentation/power/cpu_domains.txt
>--
>2.7.4
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-09 23:55 ` Rob Herring
-1 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2016-08-09 23:55 UTC (permalink / raw)
To: Lina Iyer
Cc: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel,
andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger
On Thu, Aug 04, 2016 at 05:04:49PM -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]
This change doesn't make sense given this is just a binding doc.
> ---
> .../devicetree/bindings/power/power_domain.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-09 23:55 ` Rob Herring
0 siblings, 0 replies; 83+ messages in thread
From: Rob Herring @ 2016-08-09 23:55 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Aug 04, 2016 at 05:04:49PM -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]
This change doesn't make sense given this is just a binding doc.
> ---
> .../devicetree/bindings/power/power_domain.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-04 23:04 ` Lina Iyer
@ 2016-08-10 15:14 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 15:14 UTC (permalink / raw)
To: Lina Iyer, linux-pm, linux-arm-kernel
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, khilman,
rjw, linux-arm-msm, sboyd, Axel Haslam, Marc Titinger,
Brendan Jackman, Sudeep Holla, andy.gross
Hi Lina,
I have few concerns mainly due to the lack of description and not the
binding per say.
On 05/08/16 00:04, 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 | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 025b5e7..4960486 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -29,6 +29,10 @@ Optional properties:
> specified by this binding. More details about power domain specifier are
> available in the next section.
>
> +- domain-idle-states : A phandle of an idle-state that shall be soaked into a
> + generic domain power state. The idle state definitions are
> + compatible with arm,idle-state specified in [1].
> +
So I assume these can be used for the genpd states. Either we rename it
domain-power-states or make it clear that these domain-idle-states can
also represent the power-states for normal devices.
> Example:
>
> power: power-controller@12340000 {
> @@ -59,6 +63,57 @@ 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.
>
> +Example 3: ARM v7 style CPU PM domains (Linux domain controller)
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + CPU0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7", "arm,armv7";
> + reg = <0x0>;
> + power-domains = <&a7_pd>;
This example doesn't consider how do we deal with the presence off
cpu-idle-states property in CPU nodes.
IMO we need move even the cpu/core level idle states into its own power
domain. It also helps to solve other usecases like PMU, debug/coresight
devices attached to the core power domain(in most of the cases) while
they may be in separate PD like PMUs on OMAP. That will help OS whether
to save/restore the states on idle-entry.
In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the
idle-states are split across the cpu cpu-idle-states and pd
domain-idle-states property. That looks like a really mess to me.
We need to have all the idle state information at one place and in this
case PD seems more appropriate instead of splitting them across.
We can also keep the code clean and not break compatibility. Whenever
both PD and CPU contains idle-states, PD must take precedence.
Also these needs to be documented clearly in the binding.
> + };
> +
> + CPU1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15", "arm,armv7";
> + reg = <0x0>;
> + power-domains = <&a15_pd>;
> + };
> + };
> +
> + pm-domains {
> + a15_pd: a15_pd {
> + /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/
the above comment make no sense in the binding document, remove it
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-10 15:14 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lina,
I have few concerns mainly due to the lack of description and not the
binding per say.
On 05/08/16 00:04, 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 | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 025b5e7..4960486 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -29,6 +29,10 @@ Optional properties:
> specified by this binding. More details about power domain specifier are
> available in the next section.
>
> +- domain-idle-states : A phandle of an idle-state that shall be soaked into a
> + generic domain power state. The idle state definitions are
> + compatible with arm,idle-state specified in [1].
> +
So I assume these can be used for the genpd states. Either we rename it
domain-power-states or make it clear that these domain-idle-states can
also represent the power-states for normal devices.
> Example:
>
> power: power-controller at 12340000 {
> @@ -59,6 +63,57 @@ 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.
>
> +Example 3: ARM v7 style CPU PM domains (Linux domain controller)
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7", "arm,armv7";
> + reg = <0x0>;
> + power-domains = <&a7_pd>;
This example doesn't consider how do we deal with the presence off
cpu-idle-states property in CPU nodes.
IMO we need move even the cpu/core level idle states into its own power
domain. It also helps to solve other usecases like PMU, debug/coresight
devices attached to the core power domain(in most of the cases) while
they may be in separate PD like PMUs on OMAP. That will help OS whether
to save/restore the states on idle-entry.
In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the
idle-states are split across the cpu cpu-idle-states and pd
domain-idle-states property. That looks like a really mess to me.
We need to have all the idle state information at one place and in this
case PD seems more appropriate instead of splitting them across.
We can also keep the code clean and not break compatibility. Whenever
both PD and CPU contains idle-states, PD must take precedence.
Also these needs to be documented clearly in the binding.
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15", "arm,armv7";
> + reg = <0x0>;
> + power-domains = <&a15_pd>;
> + };
> + };
> +
> + pm-domains {
> + a15_pd: a15_pd {
> + /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/
the above comment make no sense in the binding document, remove it
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
2016-08-04 23:05 ` Lina Iyer
@ 2016-08-10 15:27 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 15:27 UTC (permalink / raw)
To: Lina Iyer, linux-pm, linux-arm-kernel
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, khilman,
rjw, linux-arm-msm, sboyd, Brendan Jackman, Sudeep Holla,
andy.gross
On 05/08/16 00:05, Lina Iyer wrote:
> 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.
How is that related to the this DTS change, more details below ?
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 3029773..eb0aaed 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>;
This is really messy. We need to have idle state information at one
place. I prefer to have a hierarchal representation of power-domains
for CPU with idle-states at each level.
> };
>
> 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 {
> @@ -113,6 +117,29 @@
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
Why is it inside PSCI node ? I don't see a need for that.
If it needs to be here, then amend the binding document.
> +
> + CPU_PD: cpu-pd@0 {
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
> + };
> +
> + domain-states {
> + CLUSTER_RET: domain_ret {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000010>;
> + entry-latency-us = <500>;
> + exit-latency-us = <500>;
> + min-residency-us = <2000>;
> + };
> +
> + CLUSTER_PWR_DWN: domain_gdhs {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000030>;
> + entry-latency-us = <2000>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6000>;
> + };
> + };
So how do you collapse these states into the cpu level states ?
We should be able to cope up with platform co-ordinated mode of idle.
For me, this binding and the representation here is designed only to
address OS co-ordinated mode of idle support but it should be other way
around. Design the bindings that can cater any mode (platform and OS
co-ordinated)
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
@ 2016-08-10 15:27 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 15:27 UTC (permalink / raw)
To: linux-arm-kernel
On 05/08/16 00:05, Lina Iyer wrote:
> 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.
How is that related to the this DTS change, more details below ?
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 3029773..eb0aaed 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>;
This is really messy. We need to have idle state information at one
place. I prefer to have a hierarchal representation of power-domains
for CPU with idle-states at each level.
> };
>
> CPU1: cpu at 1 {
> @@ -73,6 +74,7 @@
> next-level-cache = <&L2_0>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SPC>;
> + power-domains = <&CPU_PD>;
> };
>
> CPU2: cpu at 2 {
> @@ -82,6 +84,7 @@
> next-level-cache = <&L2_0>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SPC>;
> + power-domains = <&CPU_PD>;
> };
>
> CPU3: cpu at 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 {
> @@ -113,6 +117,29 @@
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
Why is it inside PSCI node ? I don't see a need for that.
If it needs to be here, then amend the binding document.
> +
> + CPU_PD: cpu-pd at 0 {
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
> + };
> +
> + domain-states {
> + CLUSTER_RET: domain_ret {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000010>;
> + entry-latency-us = <500>;
> + exit-latency-us = <500>;
> + min-residency-us = <2000>;
> + };
> +
> + CLUSTER_PWR_DWN: domain_gdhs {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000030>;
> + entry-latency-us = <2000>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6000>;
> + };
> + };
So how do you collapse these states into the cpu level states ?
We should be able to cope up with platform co-ordinated mode of idle.
For me, this binding and the representation here is designed only to
address OS co-ordinated mode of idle support but it should be other way
around. Design the bindings that can cater any mode (platform and OS
co-ordinated)
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-10 15:14 ` Sudeep Holla
@ 2016-08-10 16:40 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-10 16:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, khilman,
sboyd, linux-pm, rjw, Axel Haslam, Marc Titinger,
Brendan Jackman, linux-arm-msm, andy.gross, linux-arm-kernel
Hi Sudeep,
On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>Hi Lina,
>
>I have few concerns mainly due to the lack of description and not the
>binding per say.
>
>On 05/08/16 00:04, 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 | 57 ++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>>
>>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>>index 025b5e7..4960486 100644
>>--- a/Documentation/devicetree/bindings/power/power_domain.txt
>>+++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>@@ -29,6 +29,10 @@ Optional properties:
>> specified by this binding. More details about power domain specifier are
>> available in the next section.
>>
>>+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
>>+ generic domain power state. The idle state definitions are
>>+ compatible with arm,idle-state specified in [1].
>>+
>
>So I assume these can be used for the genpd states. Either we rename
>it domain-power-states or make it clear that these domain-idle-states
>can also represent the power-states for normal devices.
>
These are the domains' idle states. These states are only used when the
domain goes into idle, not when the domain is active. These are not
power states that the domain can operate on either. Hence the idle-state
moniker.
Also, the bindings to describe the state are the same as arm,idle-state.
It made sense to call these domain idle states instead of
domain-power-states.
>> Example:
>>
>> power: power-controller@12340000 {
>>@@ -59,6 +63,57 @@ 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.
>>
>>+Example 3: ARM v7 style CPU PM domains (Linux domain controller)
>>+
>>+ cpus {
>>+ #address-cells = <1>;
>>+ #size-cells = <0>;
>>+
>>+ CPU0: cpu@0 {
>>+ device_type = "cpu";
>>+ compatible = "arm,cortex-a7", "arm,armv7";
>>+ reg = <0x0>;
>>+ power-domains = <&a7_pd>;
>
>This example doesn't consider how do we deal with the presence off
>cpu-idle-states property in CPU nodes.
>
I can amend the example. But to answer your underlying question, they
will exist as separate properties.
>IMO we need move even the cpu/core level idle states into its own power
>domain. It also helps to solve other usecases like PMU, debug/coresight
>devices attached to the core power domain(in most of the cases) while
>they may be in separate PD like PMUs on OMAP. That will help OS whether
>to save/restore the states on idle-entry.
>
This idea was brought up by Kevin earlier in the discussions, but we
shelved it for a later date.
>In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the
>idle-states are split across the cpu cpu-idle-states and pd
>domain-idle-states property. That looks like a really mess to me.
>
It is pretty clear that CPUs cannot not define the domain idle states.
Domains define their own idle states. Just as you mention above. CPU is
just a single component in its domain. There may be other devices like
PMUs, Coresights etc that also may have a say in the idle state the
domain may be put in, when the devices are idle. As such, adding domain
idle states to the CPU's idle state property is not appropriate.
Our kernel has runtime PM for devices and then there is CPUidle, both
are diverging without one knowing about the other. We have to start
unifying them inorder to have better holistic power management in the
SoC. To that regard, we have to start imagining CPUs as just another
device, albeit a special device. But for our purposes in determining
domain idle state, it will just be a device attached to the domain.
>We need to have all the idle state information at one place and in this
>case PD seems more appropriate instead of splitting them across.
>
That approach isn't correct. Where will we put the idle states of other
devices that are also part of the domain? We are thinking about a model,
where every device defines its own idle states and we define
relationships between those idle states and their parents' idle states.
Ofcourse, devices don't have idle states today, but that is something we
have been pondering over.
>We can also keep the code clean and not break compatibility. Whenever
>both PD and CPU contains idle-states, PD must take precedence.
>
Why?
The CPU and PD states are orthogonal. While the PD state is dependent on
the CPU state, the latter is not true. Devices determine their own
states. Based on the individual device states, we then determine the
state of the parent and bubble up on the hierarchy.
>Also these needs to be documented clearly in the binding.
>
>>+ };
>>+
>>+ CPU1: cpu@1 {
>>+ device_type = "cpu";
>>+ compatible = "arm,cortex-a15", "arm,armv7";
>>+ reg = <0x0>;
>>+ power-domains = <&a15_pd>;
>>+ };
>>+ };
>>+
>>+ pm-domains {
>>+ a15_pd: a15_pd {
>>+ /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/
>
>the above comment make no sense in the binding document, remove it
>
Yup. Will remove.
Thanks,
Lina
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-10 16:40 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-10 16:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sudeep,
On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>Hi Lina,
>
>I have few concerns mainly due to the lack of description and not the
>binding per say.
>
>On 05/08/16 00:04, 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 | 57 ++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>>
>>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>>index 025b5e7..4960486 100644
>>--- a/Documentation/devicetree/bindings/power/power_domain.txt
>>+++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>@@ -29,6 +29,10 @@ Optional properties:
>> specified by this binding. More details about power domain specifier are
>> available in the next section.
>>
>>+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
>>+ generic domain power state. The idle state definitions are
>>+ compatible with arm,idle-state specified in [1].
>>+
>
>So I assume these can be used for the genpd states. Either we rename
>it domain-power-states or make it clear that these domain-idle-states
>can also represent the power-states for normal devices.
>
These are the domains' idle states. These states are only used when the
domain goes into idle, not when the domain is active. These are not
power states that the domain can operate on either. Hence the idle-state
moniker.
Also, the bindings to describe the state are the same as arm,idle-state.
It made sense to call these domain idle states instead of
domain-power-states.
>> Example:
>>
>> power: power-controller at 12340000 {
>>@@ -59,6 +63,57 @@ 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.
>>
>>+Example 3: ARM v7 style CPU PM domains (Linux domain controller)
>>+
>>+ cpus {
>>+ #address-cells = <1>;
>>+ #size-cells = <0>;
>>+
>>+ CPU0: cpu at 0 {
>>+ device_type = "cpu";
>>+ compatible = "arm,cortex-a7", "arm,armv7";
>>+ reg = <0x0>;
>>+ power-domains = <&a7_pd>;
>
>This example doesn't consider how do we deal with the presence off
>cpu-idle-states property in CPU nodes.
>
I can amend the example. But to answer your underlying question, they
will exist as separate properties.
>IMO we need move even the cpu/core level idle states into its own power
>domain. It also helps to solve other usecases like PMU, debug/coresight
>devices attached to the core power domain(in most of the cases) while
>they may be in separate PD like PMUs on OMAP. That will help OS whether
>to save/restore the states on idle-entry.
>
This idea was brought up by Kevin earlier in the discussions, but we
shelved it for a later date.
>In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the
>idle-states are split across the cpu cpu-idle-states and pd
>domain-idle-states property. That looks like a really mess to me.
>
It is pretty clear that CPUs cannot not define the domain idle states.
Domains define their own idle states. Just as you mention above. CPU is
just a single component in its domain. There may be other devices like
PMUs, Coresights etc that also may have a say in the idle state the
domain may be put in, when the devices are idle. As such, adding domain
idle states to the CPU's idle state property is not appropriate.
Our kernel has runtime PM for devices and then there is CPUidle, both
are diverging without one knowing about the other. We have to start
unifying them inorder to have better holistic power management in the
SoC. To that regard, we have to start imagining CPUs as just another
device, albeit a special device. But for our purposes in determining
domain idle state, it will just be a device attached to the domain.
>We need to have all the idle state information at one place and in this
>case PD seems more appropriate instead of splitting them across.
>
That approach isn't correct. Where will we put the idle states of other
devices that are also part of the domain? We are thinking about a model,
where every device defines its own idle states and we define
relationships between those idle states and their parents' idle states.
Ofcourse, devices don't have idle states today, but that is something we
have been pondering over.
>We can also keep the code clean and not break compatibility. Whenever
>both PD and CPU contains idle-states, PD must take precedence.
>
Why?
The CPU and PD states are orthogonal. While the PD state is dependent on
the CPU state, the latter is not true. Devices determine their own
states. Based on the individual device states, we then determine the
state of the parent and bubble up on the hierarchy.
>Also these needs to be documented clearly in the binding.
>
>>+ };
>>+
>>+ CPU1: cpu at 1 {
>>+ device_type = "cpu";
>>+ compatible = "arm,cortex-a15", "arm,armv7";
>>+ reg = <0x0>;
>>+ power-domains = <&a15_pd>;
>>+ };
>>+ };
>>+
>>+ pm-domains {
>>+ a15_pd: a15_pd {
>>+ /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/
>
>the above comment make no sense in the binding document, remove it
>
Yup. Will remove.
Thanks,
Lina
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
2016-08-10 15:27 ` Sudeep Holla
@ 2016-08-10 17:35 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-10 17:35 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, khilman,
sboyd, linux-pm, rjw, Brendan Jackman, linux-arm-msm, andy.gross,
linux-arm-kernel
On Wed, Aug 10 2016 at 09:27 -0600, Sudeep Holla wrote:
>
>
>On 05/08/16 00:05, Lina Iyer wrote:
>>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.
>
>How is that related to the this DTS change, more details below ?
>
>>
>>Cc: <devicetree@vger.kernel.org>
>>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>---
>> arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>>diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
>>index 3029773..eb0aaed 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>;
>
>This is really messy. We need to have idle state information at one
>place. I prefer to have a hierarchal representation of power-domains
>for CPU with idle-states at each level.
>
>> };
I see where are going with that. We need to then isolate idle states
from all devices (including CPU) and put them under the umberella of the
domain/parent idle states.
We also need to remember that domain idle states are not just for CPU
domains. There are generic PM domains that also define their idle
states. For some, that hierarchy may not make sense. So forcing it on
all domains is not correct as well.
>>
>> 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 {
>>@@ -113,6 +117,29 @@
>> psci {
>> compatible = "arm,psci-1.0";
>> method = "smc";
>
>Why is it inside PSCI node ? I don't see a need for that.
>If it needs to be here, then amend the binding document.
>
It is described in patch 13/15.
It is inside PSCI node, because PSCI has the domain controller.
>>+
>>+ CPU_PD: cpu-pd@0 {
>>+ #power-domain-cells = <0>;
>>+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>>+ };
>>+
>>+ domain-states {
>>+ CLUSTER_RET: domain_ret {
>>+ compatible = "arm,idle-state";
>>+ arm,psci-suspend-param = <0x1000010>;
>>+ entry-latency-us = <500>;
>>+ exit-latency-us = <500>;
>>+ min-residency-us = <2000>;
>>+ };
>>+
>>+ CLUSTER_PWR_DWN: domain_gdhs {
>>+ compatible = "arm,idle-state";
>>+ arm,psci-suspend-param = <0x1000030>;
>>+ entry-latency-us = <2000>;
>>+ exit-latency-us = <2000>;
>>+ min-residency-us = <6000>;
>>+ };
>>+ };
>
>So how do you collapse these states into the cpu level states ?
Why do you have to collapse?
>We should be able to cope up with platform co-ordinated mode of idle.
>For me, this binding and the representation here is designed only to
>address OS co-ordinated mode of idle support but it should be other way
>around. Design the bindings that can cater any mode (platform and OS
>co-ordinated)
As explained to Brendan on the version2 of the series, OSI and PC are
orthagonal to each other. The idle state definition in the devicetree
exactly matches the unique approaches of these 2 modes.
In platform coordinated, the CPU determines the idle state of the domain
and selects the state, hence it makes sense to extend the
cpu-idle-states to cover those domain states.
In OSI, the CPUs only determine their idle states. When they are done
with their idle state, they bubble up and let the domain choose its idle
state and therefore the domain-idle-states is part of the domain
controller.
With this addition platform coordinated representation is not broken. If
your SoC supports both platform and os modes, then you can specify the
idle states of both of them in the DT. The clause in firmware/psci.c
will however, choose OSI if its available. I am not sure we want to
dynamically switch betweeen OSI and PC at runtime.
Thanks,
Lina
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
@ 2016-08-10 17:35 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-10 17:35 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 10 2016 at 09:27 -0600, Sudeep Holla wrote:
>
>
>On 05/08/16 00:05, Lina Iyer wrote:
>>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.
>
>How is that related to the this DTS change, more details below ?
>
>>
>>Cc: <devicetree@vger.kernel.org>
>>Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>---
>> arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>>diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
>>index 3029773..eb0aaed 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>;
>
>This is really messy. We need to have idle state information at one
>place. I prefer to have a hierarchal representation of power-domains
>for CPU with idle-states at each level.
>
>> };
I see where are going with that. We need to then isolate idle states
from all devices (including CPU) and put them under the umberella of the
domain/parent idle states.
We also need to remember that domain idle states are not just for CPU
domains. There are generic PM domains that also define their idle
states. For some, that hierarchy may not make sense. So forcing it on
all domains is not correct as well.
>>
>> CPU1: cpu at 1 {
>>@@ -73,6 +74,7 @@
>> next-level-cache = <&L2_0>;
>> enable-method = "psci";
>> cpu-idle-states = <&CPU_SPC>;
>>+ power-domains = <&CPU_PD>;
>> };
>>
>> CPU2: cpu at 2 {
>>@@ -82,6 +84,7 @@
>> next-level-cache = <&L2_0>;
>> enable-method = "psci";
>> cpu-idle-states = <&CPU_SPC>;
>>+ power-domains = <&CPU_PD>;
>> };
>>
>> CPU3: cpu at 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 {
>>@@ -113,6 +117,29 @@
>> psci {
>> compatible = "arm,psci-1.0";
>> method = "smc";
>
>Why is it inside PSCI node ? I don't see a need for that.
>If it needs to be here, then amend the binding document.
>
It is described in patch 13/15.
It is inside PSCI node, because PSCI has the domain controller.
>>+
>>+ CPU_PD: cpu-pd at 0 {
>>+ #power-domain-cells = <0>;
>>+ domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>>+ };
>>+
>>+ domain-states {
>>+ CLUSTER_RET: domain_ret {
>>+ compatible = "arm,idle-state";
>>+ arm,psci-suspend-param = <0x1000010>;
>>+ entry-latency-us = <500>;
>>+ exit-latency-us = <500>;
>>+ min-residency-us = <2000>;
>>+ };
>>+
>>+ CLUSTER_PWR_DWN: domain_gdhs {
>>+ compatible = "arm,idle-state";
>>+ arm,psci-suspend-param = <0x1000030>;
>>+ entry-latency-us = <2000>;
>>+ exit-latency-us = <2000>;
>>+ min-residency-us = <6000>;
>>+ };
>>+ };
>
>So how do you collapse these states into the cpu level states ?
Why do you have to collapse?
>We should be able to cope up with platform co-ordinated mode of idle.
>For me, this binding and the representation here is designed only to
>address OS co-ordinated mode of idle support but it should be other way
>around. Design the bindings that can cater any mode (platform and OS
>co-ordinated)
As explained to Brendan on the version2 of the series, OSI and PC are
orthagonal to each other. The idle state definition in the devicetree
exactly matches the unique approaches of these 2 modes.
In platform coordinated, the CPU determines the idle state of the domain
and selects the state, hence it makes sense to extend the
cpu-idle-states to cover those domain states.
In OSI, the CPUs only determine their idle states. When they are done
with their idle state, they bubble up and let the domain choose its idle
state and therefore the domain-idle-states is part of the domain
controller.
With this addition platform coordinated representation is not broken. If
your SoC supports both platform and os modes, then you can specify the
idle states of both of them in the DT. The clause in firmware/psci.c
will however, choose OSI if its available. I am not sure we want to
dynamically switch betweeen OSI and PC at runtime.
Thanks,
Lina
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-10 16:40 ` Lina Iyer
@ 2016-08-10 18:09 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 18:09 UTC (permalink / raw)
To: Lina Iyer
Cc: Sudeep Holla, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Titinger,
Lorenzo Pieralisi, Brendan Jackman, Juri Lelli
On 10/08/16 17:40, Lina Iyer wrote:
> Hi Sudeep,
>
> On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>> Hi Lina,
>>
>> I have few concerns mainly due to the lack of description and not the
>> binding per say.
[...]
>>> +- domain-idle-states : A phandle of an idle-state that shall be
>>> soaked into a
>>> + generic domain power state. The idle state
>>> definitions are
>>> + compatible with arm,idle-state specified in [1].
>>> +
>>
>> So I assume these can be used for the genpd states. Either we rename
>> it domain-power-states or make it clear that these domain-idle-states
>> can also represent the power-states for normal devices.
>>
> These are the domains' idle states. These states are only used when the
> domain goes into idle, not when the domain is active. These are not
> power states that the domain can operate on either. Hence the idle-state
> moniker.
I am not sure if we can tell that the device is running in all it's
power states. E.g. in ACPI IIUC, only D0 state represent running state,
while D{1,2,3} are power states which consume less power than D0/running
state. I think genpd is designed on those lines.
So I was thinking if these idle-states can also if use from non-CPU
devices w.r.t binding, it will serve as D-state equivalent in ACPI
> Also, the bindings to describe the state are the same as arm,idle-state.
> It made sense to call these domain idle states instead of
> domain-power-states.
>
I am fine with that, but we have idle states compatible to distinguish
it from normal device idle/power states.
>>> Example:
>>>
>>> power: power-controller@12340000 {
>>> @@ -59,6 +63,57 @@ 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.
>>>
>>> +Example 3: ARM v7 style CPU PM domains (Linux domain controller)
>>> +
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + CPU0: cpu@0 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7", "arm,armv7";
>>> + reg = <0x0>;
>>> + power-domains = <&a7_pd>;
>>
>> This example doesn't consider how do we deal with the presence off
>> cpu-idle-states property in CPU nodes.
>>
> I can amend the example. But to answer your underlying question, they
> will exist as separate properties.
>
Which is asking for trouble IMO. One should take precedence over other
if both are present. Ideally new DTs can just have PD, we will continue
to support cpu-idle-states for old DT.
>> IMO we need move even the cpu/core level idle states into its own power
>> domain. It also helps to solve other usecases like PMU, debug/coresight
>> devices attached to the core power domain(in most of the cases) while
>> they may be in separate PD like PMUs on OMAP. That will help OS whether
>> to save/restore the states on idle-entry.
>>
> This idea was brought up by Kevin earlier in the discussions, but we
> shelved it for a later date.
>
Any particular reasons ? I will try to dig up. I would do in one shot
especially with respect to bindings. Implementation wise, it's fine we
can take up in stages. I don't see any issue adding it in first go. This
binding is good, you just make it hierarchical and add more description.
>> In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the
>> idle-states are split across the cpu cpu-idle-states and pd
>> domain-idle-states property. That looks like a really mess to me.
>>
> It is pretty clear that CPUs cannot not define the domain idle states.
> Domains define their own idle states. Just as you mention above. CPU is
> just a single component in its domain. There may be other devices like
> PMUs, Coresights etc that also may have a say in the idle state the
> domain may be put in, when the devices are idle. As such, adding domain
> idle states to the CPU's idle state property is not appropriate.
>
No I am not saying we need to add domain idle states to the CPU's idle
state property. I am saying we need to remove cpu-idle-states or ignore
it when PD is present. And get all the idle state information for PD.
I am objecting the split we are creating across CPU and higher level
power domains. And this binding document is incomplete as it skips all
those details. We just need PD handle in CPU and no idle state
information there. Create PD hierarchy and have all idle state
information at one place.
> Our kernel has runtime PM for devices and then there is CPUidle, both
> are diverging without one knowing about the other. We have to start
> unifying them inorder to have better holistic power management in the
> SoC. To that regard, we have to start imagining CPUs as just another
> device, albeit a special device. But for our purposes in determining
> domain idle state, it will just be a device attached to the domain.
>
Absolutely agree on that. No arguments. I am asking to go a step ahead
to include even cpu/core level power domains not just cluster/higher
level domains.
>> We need to have all the idle state information at one place and in this
>> case PD seems more appropriate instead of splitting them across.
>>
> That approach isn't correct. Where will we put the idle states of other
> devices that are also part of the domain? We are thinking about a model,
> where every device defines its own idle states and we define
> relationships between those idle states and their parents' idle states.
Yes I understand. You confused me here. Won't that be one-to-one
relationship ? If not, how is that dealt in the current bindings ?
> Ofcourse, devices don't have idle states today, but that is something we
> have been pondering over.
>
Yes we these binding should be easily extensible, I don't see any issue.
>> We can also keep the code clean and not break compatibility. Whenever
>> both PD and CPU contains idle-states, PD must take precedence.
>>
> Why?
> The CPU and PD states are orthogonal. While the PD state is dependent on
> the CPU state, the latter is not true. Devices determine their own
> states. Based on the individual device states, we then determine the
> state of the parent and bubble up on the hierarchy.
>
I may be missing something. Now with your example in the binding, if
another device shares the cluster PD, can it have different idle states?
If so how does it map ?
In general whatever binding we come up must not just address OS
coordinated mode. Also I was thinking to have better coverage in the
description by having a bit more complex system like:
cluster0
CLUSTER_RET(Retention)
CLUSTER_PG(Power Gate)
core0
CORE_RET
CORE_PG
core1
CORE_RET
CORE_PG
cluster1
CLUSTER_RET
CLUSTER_PG
core0
CORE_RET
CORE_PG
core1
CORE_RET
CORE_PG
Platform Co-ordinate supports the following states and we should be able
to determine that from the binding:
CORE_RET
CORE_PG
CORE_RET + CLUSTER_RET
CORE_PG + CLUSTER_RET
CORE_PG + CLUSTER_PG
--
Regards,
Sudeep
--
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-10 18:09 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 18:09 UTC (permalink / raw)
To: linux-arm-kernel
On 10/08/16 17:40, Lina Iyer wrote:
> Hi Sudeep,
>
> On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>> Hi Lina,
>>
>> I have few concerns mainly due to the lack of description and not the
>> binding per say.
[...]
>>> +- domain-idle-states : A phandle of an idle-state that shall be
>>> soaked into a
>>> + generic domain power state. The idle state
>>> definitions are
>>> + compatible with arm,idle-state specified in [1].
>>> +
>>
>> So I assume these can be used for the genpd states. Either we rename
>> it domain-power-states or make it clear that these domain-idle-states
>> can also represent the power-states for normal devices.
>>
> These are the domains' idle states. These states are only used when the
> domain goes into idle, not when the domain is active. These are not
> power states that the domain can operate on either. Hence the idle-state
> moniker.
I am not sure if we can tell that the device is running in all it's
power states. E.g. in ACPI IIUC, only D0 state represent running state,
while D{1,2,3} are power states which consume less power than D0/running
state. I think genpd is designed on those lines.
So I was thinking if these idle-states can also if use from non-CPU
devices w.r.t binding, it will serve as D-state equivalent in ACPI
> Also, the bindings to describe the state are the same as arm,idle-state.
> It made sense to call these domain idle states instead of
> domain-power-states.
>
I am fine with that, but we have idle states compatible to distinguish
it from normal device idle/power states.
>>> Example:
>>>
>>> power: power-controller at 12340000 {
>>> @@ -59,6 +63,57 @@ 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.
>>>
>>> +Example 3: ARM v7 style CPU PM domains (Linux domain controller)
>>> +
>>> + cpus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + CPU0: cpu at 0 {
>>> + device_type = "cpu";
>>> + compatible = "arm,cortex-a7", "arm,armv7";
>>> + reg = <0x0>;
>>> + power-domains = <&a7_pd>;
>>
>> This example doesn't consider how do we deal with the presence off
>> cpu-idle-states property in CPU nodes.
>>
> I can amend the example. But to answer your underlying question, they
> will exist as separate properties.
>
Which is asking for trouble IMO. One should take precedence over other
if both are present. Ideally new DTs can just have PD, we will continue
to support cpu-idle-states for old DT.
>> IMO we need move even the cpu/core level idle states into its own power
>> domain. It also helps to solve other usecases like PMU, debug/coresight
>> devices attached to the core power domain(in most of the cases) while
>> they may be in separate PD like PMUs on OMAP. That will help OS whether
>> to save/restore the states on idle-entry.
>>
> This idea was brought up by Kevin earlier in the discussions, but we
> shelved it for a later date.
>
Any particular reasons ? I will try to dig up. I would do in one shot
especially with respect to bindings. Implementation wise, it's fine we
can take up in stages. I don't see any issue adding it in first go. This
binding is good, you just make it hierarchical and add more description.
>> In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the
>> idle-states are split across the cpu cpu-idle-states and pd
>> domain-idle-states property. That looks like a really mess to me.
>>
> It is pretty clear that CPUs cannot not define the domain idle states.
> Domains define their own idle states. Just as you mention above. CPU is
> just a single component in its domain. There may be other devices like
> PMUs, Coresights etc that also may have a say in the idle state the
> domain may be put in, when the devices are idle. As such, adding domain
> idle states to the CPU's idle state property is not appropriate.
>
No I am not saying we need to add domain idle states to the CPU's idle
state property. I am saying we need to remove cpu-idle-states or ignore
it when PD is present. And get all the idle state information for PD.
I am objecting the split we are creating across CPU and higher level
power domains. And this binding document is incomplete as it skips all
those details. We just need PD handle in CPU and no idle state
information there. Create PD hierarchy and have all idle state
information at one place.
> Our kernel has runtime PM for devices and then there is CPUidle, both
> are diverging without one knowing about the other. We have to start
> unifying them inorder to have better holistic power management in the
> SoC. To that regard, we have to start imagining CPUs as just another
> device, albeit a special device. But for our purposes in determining
> domain idle state, it will just be a device attached to the domain.
>
Absolutely agree on that. No arguments. I am asking to go a step ahead
to include even cpu/core level power domains not just cluster/higher
level domains.
>> We need to have all the idle state information at one place and in this
>> case PD seems more appropriate instead of splitting them across.
>>
> That approach isn't correct. Where will we put the idle states of other
> devices that are also part of the domain? We are thinking about a model,
> where every device defines its own idle states and we define
> relationships between those idle states and their parents' idle states.
Yes I understand. You confused me here. Won't that be one-to-one
relationship ? If not, how is that dealt in the current bindings ?
> Ofcourse, devices don't have idle states today, but that is something we
> have been pondering over.
>
Yes we these binding should be easily extensible, I don't see any issue.
>> We can also keep the code clean and not break compatibility. Whenever
>> both PD and CPU contains idle-states, PD must take precedence.
>>
> Why?
> The CPU and PD states are orthogonal. While the PD state is dependent on
> the CPU state, the latter is not true. Devices determine their own
> states. Based on the individual device states, we then determine the
> state of the parent and bubble up on the hierarchy.
>
I may be missing something. Now with your example in the binding, if
another device shares the cluster PD, can it have different idle states?
If so how does it map ?
In general whatever binding we come up must not just address OS
coordinated mode. Also I was thinking to have better coverage in the
description by having a bit more complex system like:
cluster0
CLUSTER_RET(Retention)
CLUSTER_PG(Power Gate)
core0
CORE_RET
CORE_PG
core1
CORE_RET
CORE_PG
cluster1
CLUSTER_RET
CLUSTER_PG
core0
CORE_RET
CORE_PG
core1
CORE_RET
CORE_PG
Platform Co-ordinate supports the following states and we should be able
to determine that from the binding:
CORE_RET
CORE_PG
CORE_RET + CLUSTER_RET
CORE_PG + CLUSTER_RET
CORE_PG + CLUSTER_PG
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-10 18:09 ` Sudeep Holla
@ 2016-08-10 18:13 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 18:13 UTC (permalink / raw)
To: Lina Iyer
Cc: Sudeep Holla, linux-pm, linux-arm-kernel, ulf.hansson, khilman,
rjw, andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Brendan Jackman, Juri Lelli
On 10/08/16 19:09, Sudeep Holla wrote:
>
>
> On 10/08/16 17:40, Lina Iyer wrote:
>> Hi Sudeep,
>>
>> On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>>> Hi Lina,
>>>
>>> I have few concerns mainly due to the lack of description and not the
>>> binding per say.
>
> [...]
>
>>>> +- domain-idle-states : A phandle of an idle-state that shall be
>>>> soaked into a
>>>> + generic domain power state. The idle state
>>>> definitions are
>>>> + compatible with arm,idle-state specified in [1].
>>>> +
>>>
>>> So I assume these can be used for the genpd states. Either we rename
>>> it domain-power-states or make it clear that these domain-idle-states
>>> can also represent the power-states for normal devices.
>>>
>> These are the domains' idle states. These states are only used when the
>> domain goes into idle, not when the domain is active. These are not
>> power states that the domain can operate on either. Hence the idle-state
>> moniker.
>
> I am not sure if we can tell that the device is running in all it's
> power states. E.g. in ACPI IIUC, only D0 state represent running state,
> while D{1,2,3} are power states which consume less power than D0/running
> state. I think genpd is designed on those lines.
>
I didn't complete this section earlier.
Just to clarify we can label them as idle states or whatever. Strictly
speaking today even cpu-idle-states have power off state, so the term is
not important.
What I intended to say is that it should be able to describe even device
idle(power states minus the active running) states.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-10 18:13 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-10 18:13 UTC (permalink / raw)
To: linux-arm-kernel
On 10/08/16 19:09, Sudeep Holla wrote:
>
>
> On 10/08/16 17:40, Lina Iyer wrote:
>> Hi Sudeep,
>>
>> On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>>> Hi Lina,
>>>
>>> I have few concerns mainly due to the lack of description and not the
>>> binding per say.
>
> [...]
>
>>>> +- domain-idle-states : A phandle of an idle-state that shall be
>>>> soaked into a
>>>> + generic domain power state. The idle state
>>>> definitions are
>>>> + compatible with arm,idle-state specified in [1].
>>>> +
>>>
>>> So I assume these can be used for the genpd states. Either we rename
>>> it domain-power-states or make it clear that these domain-idle-states
>>> can also represent the power-states for normal devices.
>>>
>> These are the domains' idle states. These states are only used when the
>> domain goes into idle, not when the domain is active. These are not
>> power states that the domain can operate on either. Hence the idle-state
>> moniker.
>
> I am not sure if we can tell that the device is running in all it's
> power states. E.g. in ACPI IIUC, only D0 state represent running state,
> while D{1,2,3} are power states which consume less power than D0/running
> state. I think genpd is designed on those lines.
>
I didn't complete this section earlier.
Just to clarify we can label them as idle states or whatever. Strictly
speaking today even cpu-idle-states have power off state, so the term is
not important.
What I intended to say is that it should be able to describe even device
idle(power states minus the active running) states.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
2016-08-10 17:35 ` Lina Iyer
@ 2016-08-11 9:30 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-11 9:30 UTC (permalink / raw)
To: Lina Iyer
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, khilman,
sboyd, linux-arm-msm, linux-pm, rjw, Brendan Jackman,
Sudeep Holla, andy.gross, linux-arm-kernel
On 10/08/16 18:35, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 09:27 -0600, Sudeep Holla wrote:
>>
>>
>> On 05/08/16 00:05, Lina Iyer wrote:
>>> 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.
>>
>> How is that related to the this DTS change, more details below ?
>>
>>>
>>> Cc: <devicetree@vger.kernel.org>
>>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
>>> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
>>> index 3029773..eb0aaed 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>;
>>
>> This is really messy. We need to have idle state information at one
>> place. I prefer to have a hierarchal representation of power-domains
>> for CPU with idle-states at each level.
>>
>>> };
> I see where are going with that. We need to then isolate idle states
> from all devices (including CPU) and put them under the umberella of the
> domain/parent idle states.
>
> We also need to remember that domain idle states are not just for CPU
> domains. There are generic PM domains that also define their idle
> states. For some, that hierarchy may not make sense. So forcing it on
> all domains is not correct as well.
>
Yes again I absolutely agree with that. But just represent the hierarchy
present in the hardware in the DT. If it doesn't exist in the hardware
for some device, then it won't be represented.
>>>
>>> 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 {
>>> @@ -113,6 +117,29 @@
>>> psci {
>>> compatible = "arm,psci-1.0";
>>> method = "smc";
>>
>> Why is it inside PSCI node ? I don't see a need for that.
>> If it needs to be here, then amend the binding document.
>>
> It is described in patch 13/15.
>
> It is inside PSCI node, because PSCI has the domain controller.
>
OK, I haven't gone through all the patches, I was just interested in
the binding. Sorry for that.
>>> +
>>> + CPU_PD: cpu-pd@0 {
>>> + #power-domain-cells = <0>;
>>> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>>> + };
>>> +
>>> + domain-states {
>>> + CLUSTER_RET: domain_ret {
>>> + compatible = "arm,idle-state";
>>> + arm,psci-suspend-param = <0x1000010>;
>>> + entry-latency-us = <500>;
>>> + exit-latency-us = <500>;
>>> + min-residency-us = <2000>;
>>> + };
>>> +
>>> + CLUSTER_PWR_DWN: domain_gdhs {
>>> + compatible = "arm,idle-state";
>>> + arm,psci-suspend-param = <0x1000030>;
>>> + entry-latency-us = <2000>;
>>> + exit-latency-us = <2000>;
>>> + min-residency-us = <6000>;
>>> + };
>>> + };
>>
>> So how do you collapse these states into the cpu level states ?
> Why do you have to collapse?
>
To deal with platform co-ordinated mode of cpu idle support. I think I
gave an example in the other email.
>> We should be able to cope up with platform co-ordinated mode of idle.
>> For me, this binding and the representation here is designed only to
>> address OS co-ordinated mode of idle support but it should be other way
>> around. Design the bindings that can cater any mode (platform and OS
>> co-ordinated)
> As explained to Brendan on the version2 of the series, OSI and PC are
> orthagonal to each other. The idle state definition in the devicetree
> exactly matches the unique approaches of these 2 modes.
>
We don't design bindings that depend on the software approaches or
configurations. It should represent the hardware.
> In platform coordinated, the CPU determines the idle state of the domain
> and selects the state, hence it makes sense to extend the
> cpu-idle-states to cover those domain states.
>
So, are you saying that old bindings are for platform co-ordinated mode
and these new ones are for OS co-ordinated mode. Make it clear in the
binding document and get explicit approval from the DT maintainers for
that. I really don't like that approach.
> In OSI, the CPUs only determine their idle states. When they are done
> with their idle state, they bubble up and let the domain choose its idle
> state and therefore the domain-idle-states is part of the domain
> controller.
>
I understand that, but I don't like the approach taken to define the DT
bindings. DT should have one or the other form and any mode can be used
as long as firmware is queried and put into appropriate mode of operation.
> With this addition platform coordinated representation is not broken. If
> your SoC supports both platform and os modes, then you can specify the
> idle states of both of them in the DT. The clause in firmware/psci.c
> will however, choose OSI if its available. I am not sure we want to
> dynamically switch betweeen OSI and PC at runtime.
>
How ? cpu-idle-states in CPU node can't have both:
1. just it's idles states, and
2. complete list of flattened idle states as it' is present today.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916
@ 2016-08-11 9:30 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-11 9:30 UTC (permalink / raw)
To: linux-arm-kernel
On 10/08/16 18:35, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 09:27 -0600, Sudeep Holla wrote:
>>
>>
>> On 05/08/16 00:05, Lina Iyer wrote:
>>> 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.
>>
>> How is that related to the this DTS change, more details below ?
>>
>>>
>>> Cc: <devicetree@vger.kernel.org>
>>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++++++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
>>> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
>>> index 3029773..eb0aaed 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>;
>>
>> This is really messy. We need to have idle state information at one
>> place. I prefer to have a hierarchal representation of power-domains
>> for CPU with idle-states at each level.
>>
>>> };
> I see where are going with that. We need to then isolate idle states
> from all devices (including CPU) and put them under the umberella of the
> domain/parent idle states.
>
> We also need to remember that domain idle states are not just for CPU
> domains. There are generic PM domains that also define their idle
> states. For some, that hierarchy may not make sense. So forcing it on
> all domains is not correct as well.
>
Yes again I absolutely agree with that. But just represent the hierarchy
present in the hardware in the DT. If it doesn't exist in the hardware
for some device, then it won't be represented.
>>>
>>> CPU1: cpu at 1 {
>>> @@ -73,6 +74,7 @@
>>> next-level-cache = <&L2_0>;
>>> enable-method = "psci";
>>> cpu-idle-states = <&CPU_SPC>;
>>> + power-domains = <&CPU_PD>;
>>> };
>>>
>>> CPU2: cpu at 2 {
>>> @@ -82,6 +84,7 @@
>>> next-level-cache = <&L2_0>;
>>> enable-method = "psci";
>>> cpu-idle-states = <&CPU_SPC>;
>>> + power-domains = <&CPU_PD>;
>>> };
>>>
>>> CPU3: cpu at 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 {
>>> @@ -113,6 +117,29 @@
>>> psci {
>>> compatible = "arm,psci-1.0";
>>> method = "smc";
>>
>> Why is it inside PSCI node ? I don't see a need for that.
>> If it needs to be here, then amend the binding document.
>>
> It is described in patch 13/15.
>
> It is inside PSCI node, because PSCI has the domain controller.
>
OK, I haven't gone through all the patches, I was just interested in
the binding. Sorry for that.
>>> +
>>> + CPU_PD: cpu-pd at 0 {
>>> + #power-domain-cells = <0>;
>>> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
>>> + };
>>> +
>>> + domain-states {
>>> + CLUSTER_RET: domain_ret {
>>> + compatible = "arm,idle-state";
>>> + arm,psci-suspend-param = <0x1000010>;
>>> + entry-latency-us = <500>;
>>> + exit-latency-us = <500>;
>>> + min-residency-us = <2000>;
>>> + };
>>> +
>>> + CLUSTER_PWR_DWN: domain_gdhs {
>>> + compatible = "arm,idle-state";
>>> + arm,psci-suspend-param = <0x1000030>;
>>> + entry-latency-us = <2000>;
>>> + exit-latency-us = <2000>;
>>> + min-residency-us = <6000>;
>>> + };
>>> + };
>>
>> So how do you collapse these states into the cpu level states ?
> Why do you have to collapse?
>
To deal with platform co-ordinated mode of cpu idle support. I think I
gave an example in the other email.
>> We should be able to cope up with platform co-ordinated mode of idle.
>> For me, this binding and the representation here is designed only to
>> address OS co-ordinated mode of idle support but it should be other way
>> around. Design the bindings that can cater any mode (platform and OS
>> co-ordinated)
> As explained to Brendan on the version2 of the series, OSI and PC are
> orthagonal to each other. The idle state definition in the devicetree
> exactly matches the unique approaches of these 2 modes.
>
We don't design bindings that depend on the software approaches or
configurations. It should represent the hardware.
> In platform coordinated, the CPU determines the idle state of the domain
> and selects the state, hence it makes sense to extend the
> cpu-idle-states to cover those domain states.
>
So, are you saying that old bindings are for platform co-ordinated mode
and these new ones are for OS co-ordinated mode. Make it clear in the
binding document and get explicit approval from the DT maintainers for
that. I really don't like that approach.
> In OSI, the CPUs only determine their idle states. When they are done
> with their idle state, they bubble up and let the domain choose its idle
> state and therefore the domain-idle-states is part of the domain
> controller.
>
I understand that, but I don't like the approach taken to define the DT
bindings. DT should have one or the other form and any mode can be used
as long as firmware is queried and put into appropriate mode of operation.
> With this addition platform coordinated representation is not broken. If
> your SoC supports both platform and os modes, then you can specify the
> idle states of both of them in the DT. The clause in firmware/psci.c
> will however, choose OSI if its available. I am not sure we want to
> dynamically switch betweeen OSI and PC at runtime.
>
How ? cpu-idle-states in CPU node can't have both:
1. just it's idles states, and
2. complete list of flattened idle states as it' is present today.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-10 18:09 ` Sudeep Holla
@ 2016-08-11 21:10 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-11 21:10 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Titinger,
Lorenzo Pieralisi, Brendan Jackman, Juri Lelli
On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>
>
>On 10/08/16 17:40, Lina Iyer wrote:
>>Hi Sudeep,
>>
>>On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>>>Hi Lina,
>>>
>>>I have few concerns mainly due to the lack of description and not the
>>>binding per say.
>
>[...]
>
>>It is pretty clear that CPUs cannot not define the domain idle states.
>>Domains define their own idle states. Just as you mention above. CPU is
>>just a single component in its domain. There may be other devices like
>>PMUs, Coresights etc that also may have a say in the idle state the
>>domain may be put in, when the devices are idle. As such, adding domain
>>idle states to the CPU's idle state property is not appropriate.
>>
>
>No I am not saying we need to add domain idle states to the CPU's idle
>state property. I am saying we need to remove cpu-idle-states or ignore
>it when PD is present. And get all the idle state information for PD.
>
>I am objecting the split we are creating across CPU and higher level
>power domains. And this binding document is incomplete as it skips all
>those details. We just need PD handle in CPU and no idle state
>information there. Create PD hierarchy and have all idle state
>information at one place.
>
Let me think about this a bit and see what I can come up with.
>>Our kernel has runtime PM for devices and then there is CPUidle, both
>>are diverging without one knowing about the other. We have to start
>>unifying them inorder to have better holistic power management in the
>>SoC. To that regard, we have to start imagining CPUs as just another
>>device, albeit a special device. But for our purposes in determining
>>domain idle state, it will just be a device attached to the domain.
>>
>
>Absolutely agree on that. No arguments. I am asking to go a step ahead
>to include even cpu/core level power domains not just cluster/higher
>level domains.
>
>>>We need to have all the idle state information at one place and in this
>>>case PD seems more appropriate instead of splitting them across.
>>>
>>That approach isn't correct. Where will we put the idle states of other
>>devices that are also part of the domain? We are thinking about a model,
>>where every device defines its own idle states and we define
>>relationships between those idle states and their parents' idle states.
>
>Yes I understand. You confused me here. Won't that be one-to-one
>relationship ? If not, how is that dealt in the current bindings ?
>
>>Ofcourse, devices don't have idle states today, but that is something we
>>have been pondering over.
>>
>
>Yes we these binding should be easily extensible, I don't see any issue.
>
>>>We can also keep the code clean and not break compatibility. Whenever
>>>both PD and CPU contains idle-states, PD must take precedence.
>>>
>>Why?
>>The CPU and PD states are orthogonal. While the PD state is dependent on
>>the CPU state, the latter is not true. Devices determine their own
>>states. Based on the individual device states, we then determine the
>>state of the parent and bubble up on the hierarchy.
>>
>
>I may be missing something. Now with your example in the binding, if
>another device shares the cluster PD, can it have different idle states?
>If so how does it map ?
>
>
>In general whatever binding we come up must not just address OS
>coordinated mode. Also I was thinking to have better coverage in the
>description by having a bit more complex system like:
>
>cluster0
> CLUSTER_RET(Retention)
> CLUSTER_PG(Power Gate)
> core0
> CORE_RET
> CORE_PG
> core1
> CORE_RET
> CORE_PG
>
>cluster1
> CLUSTER_RET
> CLUSTER_PG
> core0
> CORE_RET
> CORE_PG
> core1
> CORE_RET
> CORE_PG
>
>Platform Co-ordinate supports the following states and we should be
>able to determine that from the binding:
>
>CORE_RET
>CORE_PG
>CORE_RET + CLUSTER_RET
The problem that we have to sove here is knowing that
CORE_RET + CLUSTER_PG (hypothetically) an invalid combination. Kevin and
I debated it in the earlier RFC and we dont have a good way to solve
this generically for all devices.
>CORE_PG + CLUSTER_RET
>CORE_PG + CLUSTER_PG
>
>
Thanks,
Lina
--
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-11 21:10 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-11 21:10 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>
>
>On 10/08/16 17:40, Lina Iyer wrote:
>>Hi Sudeep,
>>
>>On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>>>Hi Lina,
>>>
>>>I have few concerns mainly due to the lack of description and not the
>>>binding per say.
>
>[...]
>
>>It is pretty clear that CPUs cannot not define the domain idle states.
>>Domains define their own idle states. Just as you mention above. CPU is
>>just a single component in its domain. There may be other devices like
>>PMUs, Coresights etc that also may have a say in the idle state the
>>domain may be put in, when the devices are idle. As such, adding domain
>>idle states to the CPU's idle state property is not appropriate.
>>
>
>No I am not saying we need to add domain idle states to the CPU's idle
>state property. I am saying we need to remove cpu-idle-states or ignore
>it when PD is present. And get all the idle state information for PD.
>
>I am objecting the split we are creating across CPU and higher level
>power domains. And this binding document is incomplete as it skips all
>those details. We just need PD handle in CPU and no idle state
>information there. Create PD hierarchy and have all idle state
>information at one place.
>
Let me think about this a bit and see what I can come up with.
>>Our kernel has runtime PM for devices and then there is CPUidle, both
>>are diverging without one knowing about the other. We have to start
>>unifying them inorder to have better holistic power management in the
>>SoC. To that regard, we have to start imagining CPUs as just another
>>device, albeit a special device. But for our purposes in determining
>>domain idle state, it will just be a device attached to the domain.
>>
>
>Absolutely agree on that. No arguments. I am asking to go a step ahead
>to include even cpu/core level power domains not just cluster/higher
>level domains.
>
>>>We need to have all the idle state information at one place and in this
>>>case PD seems more appropriate instead of splitting them across.
>>>
>>That approach isn't correct. Where will we put the idle states of other
>>devices that are also part of the domain? We are thinking about a model,
>>where every device defines its own idle states and we define
>>relationships between those idle states and their parents' idle states.
>
>Yes I understand. You confused me here. Won't that be one-to-one
>relationship ? If not, how is that dealt in the current bindings ?
>
>>Ofcourse, devices don't have idle states today, but that is something we
>>have been pondering over.
>>
>
>Yes we these binding should be easily extensible, I don't see any issue.
>
>>>We can also keep the code clean and not break compatibility. Whenever
>>>both PD and CPU contains idle-states, PD must take precedence.
>>>
>>Why?
>>The CPU and PD states are orthogonal. While the PD state is dependent on
>>the CPU state, the latter is not true. Devices determine their own
>>states. Based on the individual device states, we then determine the
>>state of the parent and bubble up on the hierarchy.
>>
>
>I may be missing something. Now with your example in the binding, if
>another device shares the cluster PD, can it have different idle states?
>If so how does it map ?
>
>
>In general whatever binding we come up must not just address OS
>coordinated mode. Also I was thinking to have better coverage in the
>description by having a bit more complex system like:
>
>cluster0
> CLUSTER_RET(Retention)
> CLUSTER_PG(Power Gate)
> core0
> CORE_RET
> CORE_PG
> core1
> CORE_RET
> CORE_PG
>
>cluster1
> CLUSTER_RET
> CLUSTER_PG
> core0
> CORE_RET
> CORE_PG
> core1
> CORE_RET
> CORE_PG
>
>Platform Co-ordinate supports the following states and we should be
>able to determine that from the binding:
>
>CORE_RET
>CORE_PG
>CORE_RET + CLUSTER_RET
The problem that we have to sove here is knowing that
CORE_RET + CLUSTER_PG (hypothetically) an invalid combination. Kevin and
I debated it in the earlier RFC and we dont have a good way to solve
this generically for all devices.
>CORE_PG + CLUSTER_RET
>CORE_PG + CLUSTER_PG
>
>
Thanks,
Lina
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-11 21:10 ` Lina Iyer
@ 2016-08-12 9:47 ` Brendan Jackman
-1 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-12 9:47 UTC (permalink / raw)
To: Lina Iyer, Sudeep Holla
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Titinger,
Lorenzo Pieralisi, Juri Lelli
Hi Lina
On 11/08/16 22:10, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>
>>
>> On 10/08/16 17:40, Lina Iyer wrote:
>>> Hi Sudeep,
>>>
>>> On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>>>> Hi Lina,
>>>>
>>>> I have few concerns mainly due to the lack of description and not the
>>>> binding per say.
>>
>> [...]
>>
>>> It is pretty clear that CPUs cannot not define the domain idle states.
>>> Domains define their own idle states. Just as you mention above. CPU is
>>> just a single component in its domain. There may be other devices like
>>> PMUs, Coresights etc that also may have a say in the idle state the
>>> domain may be put in, when the devices are idle. As such, adding domain
>>> idle states to the CPU's idle state property is not appropriate.
>>>
>>
>> No I am not saying we need to add domain idle states to the CPU's idle
>> state property. I am saying we need to remove cpu-idle-states or ignore
>> it when PD is present. And get all the idle state information for PD.
>>
>> I am objecting the split we are creating across CPU and higher level
>> power domains. And this binding document is incomplete as it skips all
>> those details. We just need PD handle in CPU and no idle state
>> information there. Create PD hierarchy and have all idle state
>> information at one place.
>>
> Let me think about this a bit and see what I can come up with.
>
>>> Our kernel has runtime PM for devices and then there is CPUidle, both
>>> are diverging without one knowing about the other. We have to start
>>> unifying them inorder to have better holistic power management in the
>>> SoC. To that regard, we have to start imagining CPUs as just another
>>> device, albeit a special device. But for our purposes in determining
>>> domain idle state, it will just be a device attached to the domain.
>>>
>>
>> Absolutely agree on that. No arguments. I am asking to go a step ahead
>> to include even cpu/core level power domains not just cluster/higher
>> level domains.
>>
>>>> We need to have all the idle state information at one place and in this
>>>> case PD seems more appropriate instead of splitting them across.
>>>>
>>> That approach isn't correct. Where will we put the idle states of other
>>> devices that are also part of the domain? We are thinking about a model,
>>> where every device defines its own idle states and we define
>>> relationships between those idle states and their parents' idle states.
>>
>> Yes I understand. You confused me here. Won't that be one-to-one
>> relationship ? If not, how is that dealt in the current bindings ?
>>
>>> Ofcourse, devices don't have idle states today, but that is something we
>>> have been pondering over.
>>>
>>
>> Yes we these binding should be easily extensible, I don't see any issue.
>>
>>>> We can also keep the code clean and not break compatibility. Whenever
>>>> both PD and CPU contains idle-states, PD must take precedence.
>>>>
>>> Why?
>>> The CPU and PD states are orthogonal. While the PD state is dependent on
>>> the CPU state, the latter is not true. Devices determine their own
>>> states. Based on the individual device states, we then determine the
>>> state of the parent and bubble up on the hierarchy.
>>>
>>
>> I may be missing something. Now with your example in the binding, if
>> another device shares the cluster PD, can it have different idle states?
>> If so how does it map ?
>>
>>
>> In general whatever binding we come up must not just address OS
>> coordinated mode. Also I was thinking to have better coverage in the
>> description by having a bit more complex system like:
>>
>> cluster0
>> CLUSTER_RET(Retention)
>> CLUSTER_PG(Power Gate)
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> cluster1
>> CLUSTER_RET
>> CLUSTER_PG
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> Platform Co-ordinate supports the following states and we should be
>> able to determine that from the binding:
>>
>> CORE_RET
>> CORE_PG
>> CORE_RET + CLUSTER_RET
>
> The problem that we have to sove here is knowing that CORE_RET +
> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> I debated it in the earlier RFC and we dont have a good way to solve
> this generically for all devices.
>
This is interesting. I had been working on the assumption that a parent
power domain cannot enter any idle state until its children were all in
their deepest idle state. I now realise that it's easy to imagine
platforms where this isn't the case.
However, I don't understand how your current bindings solve this issue
and why using domain-power-states for all states (i.e. ignoring
cpu-idle-states and putting CPU idle states in the domain-idle-states of
a per-CPU power domain - I believe this is what Sudeep is suggesting)
makes it any more difficult.
Could you link to this previous discussion you mentioned? I'm having
trouble finding it (R.I.P Gmane).
>> CORE_PG + CLUSTER_RET
>> CORE_PG + CLUSTER_PG
>>
>>
> Thanks,
> Lina
>
Cheers,
Brendan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-12 9:47 ` Brendan Jackman
0 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-12 9:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lina
On 11/08/16 22:10, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>
>>
>> On 10/08/16 17:40, Lina Iyer wrote:
>>> Hi Sudeep,
>>>
>>> On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
>>>> Hi Lina,
>>>>
>>>> I have few concerns mainly due to the lack of description and not the
>>>> binding per say.
>>
>> [...]
>>
>>> It is pretty clear that CPUs cannot not define the domain idle states.
>>> Domains define their own idle states. Just as you mention above. CPU is
>>> just a single component in its domain. There may be other devices like
>>> PMUs, Coresights etc that also may have a say in the idle state the
>>> domain may be put in, when the devices are idle. As such, adding domain
>>> idle states to the CPU's idle state property is not appropriate.
>>>
>>
>> No I am not saying we need to add domain idle states to the CPU's idle
>> state property. I am saying we need to remove cpu-idle-states or ignore
>> it when PD is present. And get all the idle state information for PD.
>>
>> I am objecting the split we are creating across CPU and higher level
>> power domains. And this binding document is incomplete as it skips all
>> those details. We just need PD handle in CPU and no idle state
>> information there. Create PD hierarchy and have all idle state
>> information at one place.
>>
> Let me think about this a bit and see what I can come up with.
>
>>> Our kernel has runtime PM for devices and then there is CPUidle, both
>>> are diverging without one knowing about the other. We have to start
>>> unifying them inorder to have better holistic power management in the
>>> SoC. To that regard, we have to start imagining CPUs as just another
>>> device, albeit a special device. But for our purposes in determining
>>> domain idle state, it will just be a device attached to the domain.
>>>
>>
>> Absolutely agree on that. No arguments. I am asking to go a step ahead
>> to include even cpu/core level power domains not just cluster/higher
>> level domains.
>>
>>>> We need to have all the idle state information at one place and in this
>>>> case PD seems more appropriate instead of splitting them across.
>>>>
>>> That approach isn't correct. Where will we put the idle states of other
>>> devices that are also part of the domain? We are thinking about a model,
>>> where every device defines its own idle states and we define
>>> relationships between those idle states and their parents' idle states.
>>
>> Yes I understand. You confused me here. Won't that be one-to-one
>> relationship ? If not, how is that dealt in the current bindings ?
>>
>>> Ofcourse, devices don't have idle states today, but that is something we
>>> have been pondering over.
>>>
>>
>> Yes we these binding should be easily extensible, I don't see any issue.
>>
>>>> We can also keep the code clean and not break compatibility. Whenever
>>>> both PD and CPU contains idle-states, PD must take precedence.
>>>>
>>> Why?
>>> The CPU and PD states are orthogonal. While the PD state is dependent on
>>> the CPU state, the latter is not true. Devices determine their own
>>> states. Based on the individual device states, we then determine the
>>> state of the parent and bubble up on the hierarchy.
>>>
>>
>> I may be missing something. Now with your example in the binding, if
>> another device shares the cluster PD, can it have different idle states?
>> If so how does it map ?
>>
>>
>> In general whatever binding we come up must not just address OS
>> coordinated mode. Also I was thinking to have better coverage in the
>> description by having a bit more complex system like:
>>
>> cluster0
>> CLUSTER_RET(Retention)
>> CLUSTER_PG(Power Gate)
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> cluster1
>> CLUSTER_RET
>> CLUSTER_PG
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> Platform Co-ordinate supports the following states and we should be
>> able to determine that from the binding:
>>
>> CORE_RET
>> CORE_PG
>> CORE_RET + CLUSTER_RET
>
> The problem that we have to sove here is knowing that CORE_RET +
> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> I debated it in the earlier RFC and we dont have a good way to solve
> this generically for all devices.
>
This is interesting. I had been working on the assumption that a parent
power domain cannot enter any idle state until its children were all in
their deepest idle state. I now realise that it's easy to imagine
platforms where this isn't the case.
However, I don't understand how your current bindings solve this issue
and why using domain-power-states for all states (i.e. ignoring
cpu-idle-states and putting CPU idle states in the domain-idle-states of
a per-CPU power domain - I believe this is what Sudeep is suggesting)
makes it any more difficult.
Could you link to this previous discussion you mentioned? I'm having
trouble finding it (R.I.P Gmane).
>> CORE_PG + CLUSTER_RET
>> CORE_PG + CLUSTER_PG
>>
>>
> Thanks,
> Lina
>
Cheers,
Brendan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-11 21:10 ` Lina Iyer
@ 2016-08-12 10:08 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-12 10:08 UTC (permalink / raw)
To: Lina Iyer
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, khilman,
sboyd, linux-arm-msm, linux-pm, rjw, Axel Haslam, Marc Titinger,
Brendan Jackman, Sudeep Holla, andy.gross, linux-arm-kernel
On 11/08/16 22:10, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>
[...]
>> cluster0
>> CLUSTER_RET(Retention)
>> CLUSTER_PG(Power Gate)
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> cluster1
>> CLUSTER_RET
>> CLUSTER_PG
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> Platform Co-ordinate supports the following states and we should be
>> able to determine that from the binding:
>>
>> CORE_RET
>> CORE_PG
>> CORE_RET + CLUSTER_RET
>
> The problem that we have to sove here is knowing that CORE_RET +
> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> I debated it in the earlier RFC and we dont have a good way to solve
> this generically for all devices.
>
Yes, I agree it's complex. But that needs to be solved IMO.
I can think of 2 possible solutions:
1. Index the states(which people have not liked, but as along as we
don't use it in the code as it for any other purpose, it should be
fine) and then have each state mentioning what parent state can be
entered at this child state(i.e. starting index and all states below
it)
2. Something similar to (1) but without index instead phandles.
Again these are just thoughts, others may think of some better
solution(s). Sorry I haven't followed all the previous threads in detail.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-12 10:08 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-12 10:08 UTC (permalink / raw)
To: linux-arm-kernel
On 11/08/16 22:10, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>
[...]
>> cluster0
>> CLUSTER_RET(Retention)
>> CLUSTER_PG(Power Gate)
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> cluster1
>> CLUSTER_RET
>> CLUSTER_PG
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>>
>> Platform Co-ordinate supports the following states and we should be
>> able to determine that from the binding:
>>
>> CORE_RET
>> CORE_PG
>> CORE_RET + CLUSTER_RET
>
> The problem that we have to sove here is knowing that CORE_RET +
> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> I debated it in the earlier RFC and we dont have a good way to solve
> this generically for all devices.
>
Yes, I agree it's complex. But that needs to be solved IMO.
I can think of 2 possible solutions:
1. Index the states(which people have not liked, but as along as we
don't use it in the code as it for any other purpose, it should be
fine) and then have each state mentioning what parent state can be
entered at this child state(i.e. starting index and all states below
it)
2. Something similar to (1) but without index instead phandles.
Again these are just thoughts, others may think of some better
solution(s). Sorry I haven't followed all the previous threads in detail.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-11 21:10 ` Lina Iyer
@ 2016-08-12 12:35 ` Brendan Jackman
-1 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-12 12:35 UTC (permalink / raw)
To: Lina Iyer
Cc: Sudeep Holla, linux-pm, linux-arm-kernel, ulf.hansson, khilman,
rjw, andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Juri Lelli
Hi Lina,
Apologies, I sent this reply before and automatically included an "IMPORTANT
NOTICE" footer, please disregard that email, here's the same thing without the
footer.
On Thu, Aug 11, 2016 at 03:10:23PM -0600, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
> >
> >
> >On 10/08/16 17:40, Lina Iyer wrote:
> >>Hi Sudeep,
> >>
> >>On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
> >>>Hi Lina,
> >>>
> >>>I have few concerns mainly due to the lack of description and not the
> >>>binding per say.
> >
> >[...]
> >
> >>It is pretty clear that CPUs cannot not define the domain idle states.
> >>Domains define their own idle states. Just as you mention above. CPU is
> >>just a single component in its domain. There may be other devices like
> >>PMUs, Coresights etc that also may have a say in the idle state the
> >>domain may be put in, when the devices are idle. As such, adding domain
> >>idle states to the CPU's idle state property is not appropriate.
> >>
> >
> >No I am not saying we need to add domain idle states to the CPU's idle
> >state property. I am saying we need to remove cpu-idle-states or ignore
> >it when PD is present. And get all the idle state information for PD.
> >
> >I am objecting the split we are creating across CPU and higher level
> >power domains. And this binding document is incomplete as it skips all
> >those details. We just need PD handle in CPU and no idle state
> >information there. Create PD hierarchy and have all idle state
> >information at one place.
> >
> Let me think about this a bit and see what I can come up with.
>
> >>Our kernel has runtime PM for devices and then there is CPUidle, both
> >>are diverging without one knowing about the other. We have to start
> >>unifying them inorder to have better holistic power management in the
> >>SoC. To that regard, we have to start imagining CPUs as just another
> >>device, albeit a special device. But for our purposes in determining
> >>domain idle state, it will just be a device attached to the domain.
> >>
> >
> >Absolutely agree on that. No arguments. I am asking to go a step ahead
> >to include even cpu/core level power domains not just cluster/higher
> >level domains.
> >
> >>>We need to have all the idle state information at one place and in this
> >>>case PD seems more appropriate instead of splitting them across.
> >>>
> >>That approach isn't correct. Where will we put the idle states of other
> >>devices that are also part of the domain? We are thinking about a model,
> >>where every device defines its own idle states and we define
> >>relationships between those idle states and their parents' idle states.
> >
> >Yes I understand. You confused me here. Won't that be one-to-one
> >relationship ? If not, how is that dealt in the current bindings ?
> >
> >>Ofcourse, devices don't have idle states today, but that is something we
> >>have been pondering over.
> >>
> >
> >Yes we these binding should be easily extensible, I don't see any issue.
> >
> >>>We can also keep the code clean and not break compatibility. Whenever
> >>>both PD and CPU contains idle-states, PD must take precedence.
> >>>
> >>Why?
> >>The CPU and PD states are orthogonal. While the PD state is dependent on
> >>the CPU state, the latter is not true. Devices determine their own
> >>states. Based on the individual device states, we then determine the
> >>state of the parent and bubble up on the hierarchy.
> >>
> >
> >I may be missing something. Now with your example in the binding, if
> >another device shares the cluster PD, can it have different idle states?
> >If so how does it map ?
> >
> >
> >In general whatever binding we come up must not just address OS
> >coordinated mode. Also I was thinking to have better coverage in
> >the description by having a bit more complex system like:
> >
> >cluster0
> > CLUSTER_RET(Retention)
> > CLUSTER_PG(Power Gate)
> > core0
> > CORE_RET
> > CORE_PG
> > core1
> > CORE_RET
> > CORE_PG
> >
> >cluster1
> > CLUSTER_RET
> > CLUSTER_PG
> > core0
> > CORE_RET
> > CORE_PG
> > core1
> > CORE_RET
> > CORE_PG
> >
> >Platform Co-ordinate supports the following states and we should
> >be able to determine that from the binding:
> >
> >CORE_RET
> >CORE_PG
> >CORE_RET + CLUSTER_RET
>
> The problem that we have to sove here is knowing that CORE_RET +
> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> I debated it in the earlier RFC and we dont have a good way to solve
> this generically for all devices.
>
This is interesting. I had been working on the assumption that a parent
power domain cannot enter any idle state until its children were all in
their deepest idle state. I now realise that it's easy to imagine
platforms where this isn't the case.
However, I don't understand how your current bindings solve this issue
and why using domain-power-states for all states (i.e. ignoring
cpu-idle-states and putting CPU idle states in the domain-idle-states of
a per-CPU power domain - I believe this is what Sudeep is suggesting)
makes it any more difficult.
Could you link to this previous discussion you mentioned? I'm having
trouble finding it (R.I.P Gmane).
> >CORE_PG + CLUSTER_RET
> >CORE_PG + CLUSTER_PG
> >
Cheers,
Brendan
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-12 12:35 ` Brendan Jackman
0 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lina,
Apologies, I sent this reply before and automatically included an "IMPORTANT
NOTICE" footer, please disregard that email, here's the same thing without the
footer.
On Thu, Aug 11, 2016 at 03:10:23PM -0600, Lina Iyer wrote:
> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
> >
> >
> >On 10/08/16 17:40, Lina Iyer wrote:
> >>Hi Sudeep,
> >>
> >>On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote:
> >>>Hi Lina,
> >>>
> >>>I have few concerns mainly due to the lack of description and not the
> >>>binding per say.
> >
> >[...]
> >
> >>It is pretty clear that CPUs cannot not define the domain idle states.
> >>Domains define their own idle states. Just as you mention above. CPU is
> >>just a single component in its domain. There may be other devices like
> >>PMUs, Coresights etc that also may have a say in the idle state the
> >>domain may be put in, when the devices are idle. As such, adding domain
> >>idle states to the CPU's idle state property is not appropriate.
> >>
> >
> >No I am not saying we need to add domain idle states to the CPU's idle
> >state property. I am saying we need to remove cpu-idle-states or ignore
> >it when PD is present. And get all the idle state information for PD.
> >
> >I am objecting the split we are creating across CPU and higher level
> >power domains. And this binding document is incomplete as it skips all
> >those details. We just need PD handle in CPU and no idle state
> >information there. Create PD hierarchy and have all idle state
> >information at one place.
> >
> Let me think about this a bit and see what I can come up with.
>
> >>Our kernel has runtime PM for devices and then there is CPUidle, both
> >>are diverging without one knowing about the other. We have to start
> >>unifying them inorder to have better holistic power management in the
> >>SoC. To that regard, we have to start imagining CPUs as just another
> >>device, albeit a special device. But for our purposes in determining
> >>domain idle state, it will just be a device attached to the domain.
> >>
> >
> >Absolutely agree on that. No arguments. I am asking to go a step ahead
> >to include even cpu/core level power domains not just cluster/higher
> >level domains.
> >
> >>>We need to have all the idle state information at one place and in this
> >>>case PD seems more appropriate instead of splitting them across.
> >>>
> >>That approach isn't correct. Where will we put the idle states of other
> >>devices that are also part of the domain? We are thinking about a model,
> >>where every device defines its own idle states and we define
> >>relationships between those idle states and their parents' idle states.
> >
> >Yes I understand. You confused me here. Won't that be one-to-one
> >relationship ? If not, how is that dealt in the current bindings ?
> >
> >>Ofcourse, devices don't have idle states today, but that is something we
> >>have been pondering over.
> >>
> >
> >Yes we these binding should be easily extensible, I don't see any issue.
> >
> >>>We can also keep the code clean and not break compatibility. Whenever
> >>>both PD and CPU contains idle-states, PD must take precedence.
> >>>
> >>Why?
> >>The CPU and PD states are orthogonal. While the PD state is dependent on
> >>the CPU state, the latter is not true. Devices determine their own
> >>states. Based on the individual device states, we then determine the
> >>state of the parent and bubble up on the hierarchy.
> >>
> >
> >I may be missing something. Now with your example in the binding, if
> >another device shares the cluster PD, can it have different idle states?
> >If so how does it map ?
> >
> >
> >In general whatever binding we come up must not just address OS
> >coordinated mode. Also I was thinking to have better coverage in
> >the description by having a bit more complex system like:
> >
> >cluster0
> > CLUSTER_RET(Retention)
> > CLUSTER_PG(Power Gate)
> > core0
> > CORE_RET
> > CORE_PG
> > core1
> > CORE_RET
> > CORE_PG
> >
> >cluster1
> > CLUSTER_RET
> > CLUSTER_PG
> > core0
> > CORE_RET
> > CORE_PG
> > core1
> > CORE_RET
> > CORE_PG
> >
> >Platform Co-ordinate supports the following states and we should
> >be able to determine that from the binding:
> >
> >CORE_RET
> >CORE_PG
> >CORE_RET + CLUSTER_RET
>
> The problem that we have to sove here is knowing that CORE_RET +
> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> I debated it in the earlier RFC and we dont have a good way to solve
> this generically for all devices.
>
This is interesting. I had been working on the assumption that a parent
power domain cannot enter any idle state until its children were all in
their deepest idle state. I now realise that it's easy to imagine
platforms where this isn't the case.
However, I don't understand how your current bindings solve this issue
and why using domain-power-states for all states (i.e. ignoring
cpu-idle-states and putting CPU idle states in the domain-idle-states of
a per-CPU power domain - I believe this is what Sudeep is suggesting)
makes it any more difficult.
Could you link to this previous discussion you mentioned? I'm having
trouble finding it (R.I.P Gmane).
> >CORE_PG + CLUSTER_RET
> >CORE_PG + CLUSTER_PG
> >
Cheers,
Brendan
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-12 12:35 ` Brendan Jackman
@ 2016-08-15 16:06 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-15 16:06 UTC (permalink / raw)
To: Brendan Jackman
Cc: Sudeep Holla, linux-pm, linux-arm-kernel, ulf.hansson, khilman,
rjw, andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Juri Lelli
On Fri, Aug 12 2016 at 06:35 -0600, Brendan Jackman wrote:
>> >In general whatever binding we come up must not just address OS
>> >coordinated mode. Also I was thinking to have better coverage in
>> >the description by having a bit more complex system like:
>> >
>> >cluster0
>> > CLUSTER_RET(Retention)
>> > CLUSTER_PG(Power Gate)
>> > core0
>> > CORE_RET
>> > CORE_PG
>> > core1
>> > CORE_RET
>> > CORE_PG
>> >
>> >cluster1
>> > CLUSTER_RET
>> > CLUSTER_PG
>> > core0
>> > CORE_RET
>> > CORE_PG
>> > core1
>> > CORE_RET
>> > CORE_PG
>> >
>> >Platform Co-ordinate supports the following states and we should
>> >be able to determine that from the binding:
>> >
>> >CORE_RET
>> >CORE_PG
>> >CORE_RET + CLUSTER_RET
>>
>> The problem that we have to sove here is knowing that CORE_RET +
>> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>> I debated it in the earlier RFC and we dont have a good way to solve
>> this generically for all devices.
>>
>
>
>This is interesting. I had been working on the assumption that a parent
>power domain cannot enter any idle state until its children were all in
>their deepest idle state. I now realise that it's easy to imagine
>platforms where this isn't the case.
>
>However, I don't understand how your current bindings solve this issue
>and why using domain-power-states for all states (i.e. ignoring
>cpu-idle-states and putting CPU idle states in the domain-idle-states of
>a per-CPU power domain - I believe this is what Sudeep is suggesting)
>makes it any more difficult.
>
You are right, my current bindings don't solve it. I imagined one would
solve it by writing their own CPU PM Domain governor. In the context of
platform coordinated, we dont have a choice in Linux. May be the
firmware can assert that intelligence in not choosing those states. So,
we may have states added to cpuidle that are invalid and never get
chosen by the firmware. I am not sure, but may be that is acceptable.
>Could you link to this previous discussion you mentioned? I'm having
>trouble finding it (R.I.P Gmane).
>
Sigh. So hard to search. Let me see where it is, if it in mail or IRC
communication.
Thanks,
Lina
>> >CORE_PG + CLUSTER_RET
>> >CORE_PG + CLUSTER_PG
>> >
>
>Cheers,
>Brendan
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-15 16:06 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-15 16:06 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Aug 12 2016 at 06:35 -0600, Brendan Jackman wrote:
>> >In general whatever binding we come up must not just address OS
>> >coordinated mode. Also I was thinking to have better coverage in
>> >the description by having a bit more complex system like:
>> >
>> >cluster0
>> > CLUSTER_RET(Retention)
>> > CLUSTER_PG(Power Gate)
>> > core0
>> > CORE_RET
>> > CORE_PG
>> > core1
>> > CORE_RET
>> > CORE_PG
>> >
>> >cluster1
>> > CLUSTER_RET
>> > CLUSTER_PG
>> > core0
>> > CORE_RET
>> > CORE_PG
>> > core1
>> > CORE_RET
>> > CORE_PG
>> >
>> >Platform Co-ordinate supports the following states and we should
>> >be able to determine that from the binding:
>> >
>> >CORE_RET
>> >CORE_PG
>> >CORE_RET + CLUSTER_RET
>>
>> The problem that we have to sove here is knowing that CORE_RET +
>> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>> I debated it in the earlier RFC and we dont have a good way to solve
>> this generically for all devices.
>>
>
>
>This is interesting. I had been working on the assumption that a parent
>power domain cannot enter any idle state until its children were all in
>their deepest idle state. I now realise that it's easy to imagine
>platforms where this isn't the case.
>
>However, I don't understand how your current bindings solve this issue
>and why using domain-power-states for all states (i.e. ignoring
>cpu-idle-states and putting CPU idle states in the domain-idle-states of
>a per-CPU power domain - I believe this is what Sudeep is suggesting)
>makes it any more difficult.
>
You are right, my current bindings don't solve it. I imagined one would
solve it by writing their own CPU PM Domain governor. In the context of
platform coordinated, we dont have a choice in Linux. May be the
firmware can assert that intelligence in not choosing those states. So,
we may have states added to cpuidle that are invalid and never get
chosen by the firmware. I am not sure, but may be that is acceptable.
>Could you link to this previous discussion you mentioned? I'm having
>trouble finding it (R.I.P Gmane).
>
Sigh. So hard to search. Let me see where it is, if it in mail or IRC
communication.
Thanks,
Lina
>> >CORE_PG + CLUSTER_RET
>> >CORE_PG + CLUSTER_PG
>> >
>
>Cheers,
>Brendan
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-12 10:08 ` Sudeep Holla
@ 2016-08-15 16:08 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-15 16:08 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-pm, linux-arm-kernel, ulf.hansson, khilman, rjw,
andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Brendan Jackman, Juri Lelli
On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>
>
>On 11/08/16 22:10, Lina Iyer wrote:
>>On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>
>
>[...]
>
>>>cluster0
>>> CLUSTER_RET(Retention)
>>> CLUSTER_PG(Power Gate)
>>> core0
>>> CORE_RET
>>> CORE_PG
>>> core1
>>> CORE_RET
>>> CORE_PG
>>>
>>>cluster1
>>> CLUSTER_RET
>>> CLUSTER_PG
>>> core0
>>> CORE_RET
>>> CORE_PG
>>> core1
>>> CORE_RET
>>> CORE_PG
>>>
>>>Platform Co-ordinate supports the following states and we should be
>>>able to determine that from the binding:
>>>
>>>CORE_RET
>>>CORE_PG
>>>CORE_RET + CLUSTER_RET
>>
>>The problem that we have to sove here is knowing that CORE_RET +
>>CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>I debated it in the earlier RFC and we dont have a good way to solve
>>this generically for all devices.
>>
>
>Yes, I agree it's complex. But that needs to be solved IMO.
>
>I can think of 2 possible solutions:
>
>1. Index the states(which people have not liked, but as along as we
> don't use it in the code as it for any other purpose, it should be
> fine) and then have each state mentioning what parent state can be
> entered at this child state(i.e. starting index and all states below
> it)
>
This is how QCOM solved it downstream.
>2. Something similar to (1) but without index instead phandles.
>
The problem is when you have non-CPU devices in the device tree and
since they do not have a way to represent states like CPU, we did not
have a clear path to that. Hence we punted that to later. Whatever we
do, we should solve it for a generic PM domain, not just CPU domains.
Thanks,
Lina
>Again these are just thoughts, others may think of some better
>solution(s). Sorry I haven't followed all the previous threads in detail.
>
>--
>Regards,
>Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-15 16:08 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-15 16:08 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>
>
>On 11/08/16 22:10, Lina Iyer wrote:
>>On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>
>
>[...]
>
>>>cluster0
>>> CLUSTER_RET(Retention)
>>> CLUSTER_PG(Power Gate)
>>> core0
>>> CORE_RET
>>> CORE_PG
>>> core1
>>> CORE_RET
>>> CORE_PG
>>>
>>>cluster1
>>> CLUSTER_RET
>>> CLUSTER_PG
>>> core0
>>> CORE_RET
>>> CORE_PG
>>> core1
>>> CORE_RET
>>> CORE_PG
>>>
>>>Platform Co-ordinate supports the following states and we should be
>>>able to determine that from the binding:
>>>
>>>CORE_RET
>>>CORE_PG
>>>CORE_RET + CLUSTER_RET
>>
>>The problem that we have to sove here is knowing that CORE_RET +
>>CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>I debated it in the earlier RFC and we dont have a good way to solve
>>this generically for all devices.
>>
>
>Yes, I agree it's complex. But that needs to be solved IMO.
>
>I can think of 2 possible solutions:
>
>1. Index the states(which people have not liked, but as along as we
> don't use it in the code as it for any other purpose, it should be
> fine) and then have each state mentioning what parent state can be
> entered at this child state(i.e. starting index and all states below
> it)
>
This is how QCOM solved it downstream.
>2. Something similar to (1) but without index instead phandles.
>
The problem is when you have non-CPU devices in the device tree and
since they do not have a way to represent states like CPU, we did not
have a clear path to that. Hence we punted that to later. Whatever we
do, we should solve it for a generic PM domain, not just CPU domains.
Thanks,
Lina
>Again these are just thoughts, others may think of some better
>solution(s). Sorry I haven't followed all the previous threads in detail.
>
>--
>Regards,
>Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-15 16:08 ` Lina Iyer
@ 2016-08-15 16:14 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-15 16:14 UTC (permalink / raw)
To: Lina Iyer
Cc: Sudeep Holla, linux-pm, linux-arm-kernel, ulf.hansson, khilman,
rjw, andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Brendan Jackman, Juri Lelli
On 15/08/16 17:08, Lina Iyer wrote:
> On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>>
>>
>> On 11/08/16 22:10, Lina Iyer wrote:
>>> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>>
>>
>> [...]
>>
>>>> cluster0
>>>> CLUSTER_RET(Retention)
>>>> CLUSTER_PG(Power Gate)
>>>> core0
>>>> CORE_RET
>>>> CORE_PG
>>>> core1
>>>> CORE_RET
>>>> CORE_PG
>>>>
>>>> cluster1
>>>> CLUSTER_RET
>>>> CLUSTER_PG
>>>> core0
>>>> CORE_RET
>>>> CORE_PG
>>>> core1
>>>> CORE_RET
>>>> CORE_PG
>>>>
>>>> Platform Co-ordinate supports the following states and we should be
>>>> able to determine that from the binding:
>>>>
>>>> CORE_RET
>>>> CORE_PG
>>>> CORE_RET + CLUSTER_RET
>>>
>>> The problem that we have to sove here is knowing that CORE_RET +
>>> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>> I debated it in the earlier RFC and we dont have a good way to solve
>>> this generically for all devices.
>>>
>>
>> Yes, I agree it's complex. But that needs to be solved IMO.
>>
>> I can think of 2 possible solutions:
>>
>> 1. Index the states(which people have not liked, but as along as we
>> don't use it in the code as it for any other purpose, it should be
>> fine) and then have each state mentioning what parent state can be
>> entered at this child state(i.e. starting index and all states below
>> it)
>>
> This is how QCOM solved it downstream.
>
Yes even ACPI has indices to solve this.
>> 2. Something similar to (1) but without index instead phandles.
>>
>
> The problem is when you have non-CPU devices in the device tree and
> since they do not have a way to represent states like CPU, we did not
> have a clear path to that. Hence we punted that to later. Whatever we
> do, we should solve it for a generic PM domain, not just CPU domains.
>
Yes bindings defined here should be applicable for devices to, but only
CPU's will have this hierarchy while the devices need not bother about
hierarchy. However the parent power domain can ever the state which is
least common denominator of all it's children power domain. That's my
understanding. No ?
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-15 16:14 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-15 16:14 UTC (permalink / raw)
To: linux-arm-kernel
On 15/08/16 17:08, Lina Iyer wrote:
> On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>>
>>
>> On 11/08/16 22:10, Lina Iyer wrote:
>>> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>>
>>
>> [...]
>>
>>>> cluster0
>>>> CLUSTER_RET(Retention)
>>>> CLUSTER_PG(Power Gate)
>>>> core0
>>>> CORE_RET
>>>> CORE_PG
>>>> core1
>>>> CORE_RET
>>>> CORE_PG
>>>>
>>>> cluster1
>>>> CLUSTER_RET
>>>> CLUSTER_PG
>>>> core0
>>>> CORE_RET
>>>> CORE_PG
>>>> core1
>>>> CORE_RET
>>>> CORE_PG
>>>>
>>>> Platform Co-ordinate supports the following states and we should be
>>>> able to determine that from the binding:
>>>>
>>>> CORE_RET
>>>> CORE_PG
>>>> CORE_RET + CLUSTER_RET
>>>
>>> The problem that we have to sove here is knowing that CORE_RET +
>>> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>> I debated it in the earlier RFC and we dont have a good way to solve
>>> this generically for all devices.
>>>
>>
>> Yes, I agree it's complex. But that needs to be solved IMO.
>>
>> I can think of 2 possible solutions:
>>
>> 1. Index the states(which people have not liked, but as along as we
>> don't use it in the code as it for any other purpose, it should be
>> fine) and then have each state mentioning what parent state can be
>> entered at this child state(i.e. starting index and all states below
>> it)
>>
> This is how QCOM solved it downstream.
>
Yes even ACPI has indices to solve this.
>> 2. Something similar to (1) but without index instead phandles.
>>
>
> The problem is when you have non-CPU devices in the device tree and
> since they do not have a way to represent states like CPU, we did not
> have a clear path to that. Hence we punted that to later. Whatever we
> do, we should solve it for a generic PM domain, not just CPU domains.
>
Yes bindings defined here should be applicable for devices to, but only
CPU's will have this hierarchy while the devices need not bother about
hierarchy. However the parent power domain can ever the state which is
least common denominator of all it's children power domain. That's my
understanding. No ?
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-15 16:14 ` Sudeep Holla
@ 2016-08-15 22:40 ` Lina Iyer
-1 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-15 22:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-pm, linux-arm-kernel, ulf.hansson, khilman, rjw,
andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Brendan Jackman, Juri Lelli
On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
>
>
>On 15/08/16 17:08, Lina Iyer wrote:
>>On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>>>
>>>
>>>On 11/08/16 22:10, Lina Iyer wrote:
>>>>On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>>>
>>>
>>>[...]
>>>
>>>>>cluster0
>>>>> CLUSTER_RET(Retention)
>>>>> CLUSTER_PG(Power Gate)
>>>>> core0
>>>>> CORE_RET
>>>>> CORE_PG
>>>>> core1
>>>>> CORE_RET
>>>>> CORE_PG
>>>>>
>>>>>cluster1
>>>>> CLUSTER_RET
>>>>> CLUSTER_PG
>>>>> core0
>>>>> CORE_RET
>>>>> CORE_PG
>>>>> core1
>>>>> CORE_RET
>>>>> CORE_PG
>>>>>
>>>>>Platform Co-ordinate supports the following states and we should be
>>>>>able to determine that from the binding:
>>>>>
>>>>>CORE_RET
>>>>>CORE_PG
>>>>>CORE_RET + CLUSTER_RET
>>>>
>>>>The problem that we have to sove here is knowing that CORE_RET +
>>>>CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>>>I debated it in the earlier RFC and we dont have a good way to solve
>>>>this generically for all devices.
>>>>
>>>
>>>Yes, I agree it's complex. But that needs to be solved IMO.
>>>
>>>I can think of 2 possible solutions:
>>>
>>>1. Index the states(which people have not liked, but as along as we
>>> don't use it in the code as it for any other purpose, it should be
>>> fine) and then have each state mentioning what parent state can be
>>> entered at this child state(i.e. starting index and all states below
>>> it)
>>>
>>This is how QCOM solved it downstream.
>>
>
>Yes even ACPI has indices to solve this.
>
>>>2. Something similar to (1) but without index instead phandles.
>>>
>>
>>The problem is when you have non-CPU devices in the device tree and
>>since they do not have a way to represent states like CPU, we did not
>>have a clear path to that. Hence we punted that to later. Whatever we
>>do, we should solve it for a generic PM domain, not just CPU domains.
>>
>
>Yes bindings defined here should be applicable for devices to, but only
>CPU's will have this hierarchy while the devices need not bother about
>hierarchy. However the parent power domain can ever the state which is
>least common denominator of all it's children power domain. That's my
>understanding. No ?
>
That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
which is invalid and the firmware has to ignore it and does CORE_RET +
CLUSTER_RET instead, then Linux may have an inconsistent view of the
state selection.
Thanks,
Lina
>--
>Regards,
>Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-15 22:40 ` Lina Iyer
0 siblings, 0 replies; 83+ messages in thread
From: Lina Iyer @ 2016-08-15 22:40 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
>
>
>On 15/08/16 17:08, Lina Iyer wrote:
>>On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>>>
>>>
>>>On 11/08/16 22:10, Lina Iyer wrote:
>>>>On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>>>
>>>
>>>[...]
>>>
>>>>>cluster0
>>>>> CLUSTER_RET(Retention)
>>>>> CLUSTER_PG(Power Gate)
>>>>> core0
>>>>> CORE_RET
>>>>> CORE_PG
>>>>> core1
>>>>> CORE_RET
>>>>> CORE_PG
>>>>>
>>>>>cluster1
>>>>> CLUSTER_RET
>>>>> CLUSTER_PG
>>>>> core0
>>>>> CORE_RET
>>>>> CORE_PG
>>>>> core1
>>>>> CORE_RET
>>>>> CORE_PG
>>>>>
>>>>>Platform Co-ordinate supports the following states and we should be
>>>>>able to determine that from the binding:
>>>>>
>>>>>CORE_RET
>>>>>CORE_PG
>>>>>CORE_RET + CLUSTER_RET
>>>>
>>>>The problem that we have to sove here is knowing that CORE_RET +
>>>>CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>>>I debated it in the earlier RFC and we dont have a good way to solve
>>>>this generically for all devices.
>>>>
>>>
>>>Yes, I agree it's complex. But that needs to be solved IMO.
>>>
>>>I can think of 2 possible solutions:
>>>
>>>1. Index the states(which people have not liked, but as along as we
>>> don't use it in the code as it for any other purpose, it should be
>>> fine) and then have each state mentioning what parent state can be
>>> entered at this child state(i.e. starting index and all states below
>>> it)
>>>
>>This is how QCOM solved it downstream.
>>
>
>Yes even ACPI has indices to solve this.
>
>>>2. Something similar to (1) but without index instead phandles.
>>>
>>
>>The problem is when you have non-CPU devices in the device tree and
>>since they do not have a way to represent states like CPU, we did not
>>have a clear path to that. Hence we punted that to later. Whatever we
>>do, we should solve it for a generic PM domain, not just CPU domains.
>>
>
>Yes bindings defined here should be applicable for devices to, but only
>CPU's will have this hierarchy while the devices need not bother about
>hierarchy. However the parent power domain can ever the state which is
>least common denominator of all it's children power domain. That's my
>understanding. No ?
>
That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
which is invalid and the firmware has to ignore it and does CORE_RET +
CLUSTER_RET instead, then Linux may have an inconsistent view of the
state selection.
Thanks,
Lina
>--
>Regards,
>Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-15 22:40 ` Lina Iyer
@ 2016-08-16 8:34 ` Brendan Jackman
-1 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-16 8:34 UTC (permalink / raw)
To: Lina Iyer, Sudeep Holla
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Titinger,
Lorenzo Pieralisi, Juri Lelli
On 15/08/16 23:40, Lina Iyer wrote:
> On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
>>
>>
>> On 15/08/16 17:08, Lina Iyer wrote:
>>> On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 11/08/16 22:10, Lina Iyer wrote:
>>>>> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>>>>
>>>>
>>>> [...]
>>>>
>>>>>> cluster0
>>>>>> CLUSTER_RET(Retention)
>>>>>> CLUSTER_PG(Power Gate)
>>>>>> core0
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>> core1
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>>
>>>>>> cluster1
>>>>>> CLUSTER_RET
>>>>>> CLUSTER_PG
>>>>>> core0
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>> core1
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>>
>>>>>> Platform Co-ordinate supports the following states and we should be
>>>>>> able to determine that from the binding:
>>>>>>
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>> CORE_RET + CLUSTER_RET
>>>>>
>>>>> The problem that we have to sove here is knowing that CORE_RET +
>>>>> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>>>> I debated it in the earlier RFC and we dont have a good way to solve
>>>>> this generically for all devices.
>>>>>
>>>>
>>>> Yes, I agree it's complex. But that needs to be solved IMO.
>>>>
>>>> I can think of 2 possible solutions:
>>>>
>>>> 1. Index the states(which people have not liked, but as along as we
>>>> don't use it in the code as it for any other purpose, it should be
>>>> fine) and then have each state mentioning what parent state can be
>>>> entered at this child state(i.e. starting index and all states below
>>>> it)
>>>>
>>> This is how QCOM solved it downstream.
>>>
>>
>> Yes even ACPI has indices to solve this.
>>
>>>> 2. Something similar to (1) but without index instead phandles.
>>>>
>>>
>>> The problem is when you have non-CPU devices in the device tree and
>>> since they do not have a way to represent states like CPU, we did not
>>> have a clear path to that. Hence we punted that to later. Whatever we
>>> do, we should solve it for a generic PM domain, not just CPU domains.
>>>
>>
>> Yes bindings defined here should be applicable for devices to, but only
>> CPU's will have this hierarchy while the devices need not bother about
>> hierarchy. However the parent power domain can ever the state which is
>> least common denominator of all it's children power domain. That's my
>> understanding. No ?
>>
Are you saying that the parent can enter the shallowest idle state that
all its children are in (I.e if all its children are in "retention" then
it can enter "retention")? I don't know what the reality is on existing
platforms but it doesn't sound like 100% safe assumption to make. Also I
don't think you can necessarily correlate idle states at different
domain levels - i.e. here we've matched up the idea of "retention" at
core level with that of "retention" at cluster level. I may have
misunderstood you there..
> That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
> which is invalid and the firmware has to ignore it and does CORE_RET +
> CLUSTER_RET instead, then Linux may have an inconsistent view of the
> state selection.
>
Perhaps a better starting point would be to go with the assumption that
a parent PD can only enter any idle state once its children are in their
deepest idle states.
That is, we'd miss out on CORE_RET + CLUSTER_RET but have no invalid ones.
Then a later addition to the bindings as discussed above could enable
the possibility of those combinations to be expressed.
> Thanks,
> Lina
>
>> --
>> Regards,
>> Sudeep
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-16 8:34 ` Brendan Jackman
0 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-16 8:34 UTC (permalink / raw)
To: linux-arm-kernel
On 15/08/16 23:40, Lina Iyer wrote:
> On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
>>
>>
>> On 15/08/16 17:08, Lina Iyer wrote:
>>> On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 11/08/16 22:10, Lina Iyer wrote:
>>>>> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>>>>
>>>>
>>>> [...]
>>>>
>>>>>> cluster0
>>>>>> CLUSTER_RET(Retention)
>>>>>> CLUSTER_PG(Power Gate)
>>>>>> core0
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>> core1
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>>
>>>>>> cluster1
>>>>>> CLUSTER_RET
>>>>>> CLUSTER_PG
>>>>>> core0
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>> core1
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>>
>>>>>> Platform Co-ordinate supports the following states and we should be
>>>>>> able to determine that from the binding:
>>>>>>
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>> CORE_RET + CLUSTER_RET
>>>>>
>>>>> The problem that we have to sove here is knowing that CORE_RET +
>>>>> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>>>> I debated it in the earlier RFC and we dont have a good way to solve
>>>>> this generically for all devices.
>>>>>
>>>>
>>>> Yes, I agree it's complex. But that needs to be solved IMO.
>>>>
>>>> I can think of 2 possible solutions:
>>>>
>>>> 1. Index the states(which people have not liked, but as along as we
>>>> don't use it in the code as it for any other purpose, it should be
>>>> fine) and then have each state mentioning what parent state can be
>>>> entered at this child state(i.e. starting index and all states below
>>>> it)
>>>>
>>> This is how QCOM solved it downstream.
>>>
>>
>> Yes even ACPI has indices to solve this.
>>
>>>> 2. Something similar to (1) but without index instead phandles.
>>>>
>>>
>>> The problem is when you have non-CPU devices in the device tree and
>>> since they do not have a way to represent states like CPU, we did not
>>> have a clear path to that. Hence we punted that to later. Whatever we
>>> do, we should solve it for a generic PM domain, not just CPU domains.
>>>
>>
>> Yes bindings defined here should be applicable for devices to, but only
>> CPU's will have this hierarchy while the devices need not bother about
>> hierarchy. However the parent power domain can ever the state which is
>> least common denominator of all it's children power domain. That's my
>> understanding. No ?
>>
Are you saying that the parent can enter the shallowest idle state that
all its children are in (I.e if all its children are in "retention" then
it can enter "retention")? I don't know what the reality is on existing
platforms but it doesn't sound like 100% safe assumption to make. Also I
don't think you can necessarily correlate idle states at different
domain levels - i.e. here we've matched up the idea of "retention" at
core level with that of "retention" at cluster level. I may have
misunderstood you there..
> That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
> which is invalid and the firmware has to ignore it and does CORE_RET +
> CLUSTER_RET instead, then Linux may have an inconsistent view of the
> state selection.
>
Perhaps a better starting point would be to go with the assumption that
a parent PD can only enter any idle state once its children are in their
deepest idle states.
That is, we'd miss out on CORE_RET + CLUSTER_RET but have no invalid ones.
Then a later addition to the bindings as discussed above could enable
the possibility of those combinations to be expressed.
> Thanks,
> Lina
>
>> --
>> Regards,
>> Sudeep
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-15 22:40 ` Lina Iyer
@ 2016-08-16 8:41 ` Brendan Jackman
-1 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-16 8:41 UTC (permalink / raw)
To: Lina Iyer
Cc: Sudeep Holla, linux-pm, linux-arm-kernel, ulf.hansson, khilman,
rjw, andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Juri Lelli
Hi Lina,
Agh, sorry, sent with the "IMPORTANT NOTICE" again, still getting used to
mailing lists.. here's the message again without it.
On Mon, Aug 15, 2016 at 04:40:14PM -0600, Lina Iyer wrote:
> On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
> >
> >
> >On 15/08/16 17:08, Lina Iyer wrote:
> >>On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
> >>>
> >>>
> >>>On 11/08/16 22:10, Lina Iyer wrote:
> >>>>On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
> >>>>>
> >>>
> >>>[...]
> >>>
> >>>>>cluster0
> >>>>> CLUSTER_RET(Retention)
> >>>>> CLUSTER_PG(Power Gate)
> >>>>> core0
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>> core1
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>>
> >>>>>cluster1
> >>>>> CLUSTER_RET
> >>>>> CLUSTER_PG
> >>>>> core0
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>> core1
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>>
> >>>>>Platform Co-ordinate supports the following states and we should be
> >>>>>able to determine that from the binding:
> >>>>>
> >>>>>CORE_RET
> >>>>>CORE_PG
> >>>>>CORE_RET + CLUSTER_RET
> >>>>
> >>>>The problem that we have to sove here is knowing that CORE_RET +
> >>>>CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> >>>>I debated it in the earlier RFC and we dont have a good way to solve
> >>>>this generically for all devices.
> >>>>
> >>>
> >>>Yes, I agree it's complex. But that needs to be solved IMO.
> >>>
> >>>I can think of 2 possible solutions:
> >>>
> >>>1. Index the states(which people have not liked, but as along as we
> >>> don't use it in the code as it for any other purpose, it should be
> >>> fine) and then have each state mentioning what parent state can be
> >>> entered at this child state(i.e. starting index and all states below
> >>> it)
> >>>
> >>This is how QCOM solved it downstream.
> >>
> >
> >Yes even ACPI has indices to solve this.
> >
> >>>2. Something similar to (1) but without index instead phandles.
> >>>
> >>
> >>The problem is when you have non-CPU devices in the device tree and
> >>since they do not have a way to represent states like CPU, we did not
> >>have a clear path to that. Hence we punted that to later. Whatever we
> >>do, we should solve it for a generic PM domain, not just CPU domains.
> >>
> >
> >Yes bindings defined here should be applicable for devices to, but only
> >CPU's will have this hierarchy while the devices need not bother about
> >hierarchy. However the parent power domain can ever the state which is
> >least common denominator of all it's children power domain. That's my
> >understanding. No?
> >
Are you saying that the parent can enter the shallowest idle state that all its
children are in (I.e if all its children are in "retention" then it can enter
"retention")? I don't know what the reality is on existing platforms but it
doesn't sound like 100% safe assumption to make. Also I don't think you can
necessarily correlate idle states at different domain levels - i.e. here we've
matched up the idea of "retention" at core level with that of "retention" at
cluster level. I may have misunderstood you there..
> That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
> which is invalid and the firmware has to ignore it and does CORE_RET +
> CLUSTER_RET instead, then Linux may have an inconsistent view of the
> state selection.
>
Perhaps a better starting point would be to go with the assumption that a parent
PD can only enter any idle state once its children are in their deepest idle
states.
So in the example above we'd end up with
CORE_RET
CORE_PG
CORE_PG + CLUSTER_RET
CORE_PG + CLUSTER_PG
(Missing out on CORE_RET + CLUSTER_RET, even though that's a valid combination
from the hardware's perspective)
Then a later addition to the bindings as discussed above could enable the
possibility of those combinations to be expressed.
> Thanks,
> Lina
>
> >--
> >Regards,
> >Sudeep
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-16 8:41 ` Brendan Jackman
0 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-16 8:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lina,
Agh, sorry, sent with the "IMPORTANT NOTICE" again, still getting used to
mailing lists.. here's the message again without it.
On Mon, Aug 15, 2016 at 04:40:14PM -0600, Lina Iyer wrote:
> On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
> >
> >
> >On 15/08/16 17:08, Lina Iyer wrote:
> >>On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
> >>>
> >>>
> >>>On 11/08/16 22:10, Lina Iyer wrote:
> >>>>On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
> >>>>>
> >>>
> >>>[...]
> >>>
> >>>>>cluster0
> >>>>> CLUSTER_RET(Retention)
> >>>>> CLUSTER_PG(Power Gate)
> >>>>> core0
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>> core1
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>>
> >>>>>cluster1
> >>>>> CLUSTER_RET
> >>>>> CLUSTER_PG
> >>>>> core0
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>> core1
> >>>>> CORE_RET
> >>>>> CORE_PG
> >>>>>
> >>>>>Platform Co-ordinate supports the following states and we should be
> >>>>>able to determine that from the binding:
> >>>>>
> >>>>>CORE_RET
> >>>>>CORE_PG
> >>>>>CORE_RET + CLUSTER_RET
> >>>>
> >>>>The problem that we have to sove here is knowing that CORE_RET +
> >>>>CLUSTER_PG (hypothetically) an invalid combination. Kevin and
> >>>>I debated it in the earlier RFC and we dont have a good way to solve
> >>>>this generically for all devices.
> >>>>
> >>>
> >>>Yes, I agree it's complex. But that needs to be solved IMO.
> >>>
> >>>I can think of 2 possible solutions:
> >>>
> >>>1. Index the states(which people have not liked, but as along as we
> >>> don't use it in the code as it for any other purpose, it should be
> >>> fine) and then have each state mentioning what parent state can be
> >>> entered at this child state(i.e. starting index and all states below
> >>> it)
> >>>
> >>This is how QCOM solved it downstream.
> >>
> >
> >Yes even ACPI has indices to solve this.
> >
> >>>2. Something similar to (1) but without index instead phandles.
> >>>
> >>
> >>The problem is when you have non-CPU devices in the device tree and
> >>since they do not have a way to represent states like CPU, we did not
> >>have a clear path to that. Hence we punted that to later. Whatever we
> >>do, we should solve it for a generic PM domain, not just CPU domains.
> >>
> >
> >Yes bindings defined here should be applicable for devices to, but only
> >CPU's will have this hierarchy while the devices need not bother about
> >hierarchy. However the parent power domain can ever the state which is
> >least common denominator of all it's children power domain. That's my
> >understanding. No?
> >
Are you saying that the parent can enter the shallowest idle state that all its
children are in (I.e if all its children are in "retention" then it can enter
"retention")? I don't know what the reality is on existing platforms but it
doesn't sound like 100% safe assumption to make. Also I don't think you can
necessarily correlate idle states at different domain levels - i.e. here we've
matched up the idea of "retention" at core level with that of "retention" at
cluster level. I may have misunderstood you there..
> That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
> which is invalid and the firmware has to ignore it and does CORE_RET +
> CLUSTER_RET instead, then Linux may have an inconsistent view of the
> state selection.
>
Perhaps a better starting point would be to go with the assumption that a parent
PD can only enter any idle state once its children are in their deepest idle
states.
So in the example above we'd end up with
CORE_RET
CORE_PG
CORE_PG + CLUSTER_RET
CORE_PG + CLUSTER_PG
(Missing out on CORE_RET + CLUSTER_RET, even though that's a valid combination
from the hardware's perspective)
Then a later addition to the bindings as discussed above could enable the
possibility of those combinations to be expressed.
> Thanks,
> Lina
>
> >--
> >Regards,
> >Sudeep
>
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-16 8:41 ` Brendan Jackman
@ 2016-08-16 9:19 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-16 9:19 UTC (permalink / raw)
To: Brendan Jackman, Lina Iyer
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, khilman,
sboyd, linux-arm-msm, linux-pm, rjw, Axel Haslam, Marc Titinger,
Sudeep Holla, andy.gross, linux-arm-kernel
On 16/08/16 09:41, Brendan Jackman wrote:
> Hi Lina,
> On Mon, Aug 15, 2016 at 04:40:14PM -0600, Lina Iyer wrote:
>> On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
[,,,]
>>>
>>> Yes even ACPI has indices to solve this.
>>>
>>>>> 2. Something similar to (1) but without index instead phandles.
>>>>>
>>>>
>>>> The problem is when you have non-CPU devices in the device tree and
>>>> since they do not have a way to represent states like CPU, we did not
>>>> have a clear path to that. Hence we punted that to later. Whatever we
>>>> do, we should solve it for a generic PM domain, not just CPU domains.
>>>>
>>>
>>> Yes bindings defined here should be applicable for devices to, but only
>>> CPU's will have this hierarchy while the devices need not bother about
>>> hierarchy. However the parent power domain can ever the state which is
>>> least common denominator of all it's children power domain. That's my
>>> understanding. No?
>>>
>
>
> Are you saying that the parent can enter the shallowest idle state that all its
> children are in (I.e if all its children are in "retention" then it can enter
> "retention")? I don't know what the reality is on existing platforms but it
> doesn't sound like 100% safe assumption to make.
I was referring to non-CPU/device power states above. For CPU we do need
a mechanism in place to indicate the dependency.
> Also I don't think you can
> necessarily correlate idle states at different domain levels - i.e. here we've
> matched up the idea of "retention" at core level with that of "retention" at
> cluster level. I may have misunderstood you there..
>
Correct for CPUs. For normal devices and their power domains, it could
straight forward. E.g if many devices are at-least at state D1(few may
be at state D2 or above), the parent can enter D1.(D0-runnning and D1-D3
are low power states in the above example)
>> That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
>> which is invalid and the firmware has to ignore it and does CORE_RET +
>> CLUSTER_RET instead, then Linux may have an inconsistent view of the
>> state selection.
>>
1. First, CORE_RET + CLUSTER_PG should not be registered as valid idle
state.
2. We do have inconsistent view already for platform co-ordinated idle
In-fact it could happen even with OSC mode I believe. Platform can
always demote the state, so OS can never get the exact view unless it
queries the firmware for that explicitly(e.g. PSCI_STATS)
>
> Perhaps a better starting point would be to go with the assumption that a parent
> PD can only enter any idle state once its children are in their deepest idle
> states.
>
> So in the example above we'd end up with
>
> CORE_RET
> CORE_PG
> CORE_PG + CLUSTER_RET
> CORE_PG + CLUSTER_PG
>
Yes this assumption seems good enough to me. At-least no invalid
combination is ensured.
> (Missing out on CORE_RET + CLUSTER_RET, even though that's a valid combination
> from the hardware's perspective)
>
Yes, if it's a real issue then we need proper bindings to deal with
that. Otherwise we can manage without the extra information.
> Then a later addition to the bindings as discussed above could enable the
> possibility of those combinations to be expressed.
>
Seems feasible solution to me, but better to make this explicit in the
binding and check with few others. It looks fair enough assumption IMO.
--
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-16 9:19 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-16 9:19 UTC (permalink / raw)
To: linux-arm-kernel
On 16/08/16 09:41, Brendan Jackman wrote:
> Hi Lina,
> On Mon, Aug 15, 2016 at 04:40:14PM -0600, Lina Iyer wrote:
>> On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
[,,,]
>>>
>>> Yes even ACPI has indices to solve this.
>>>
>>>>> 2. Something similar to (1) but without index instead phandles.
>>>>>
>>>>
>>>> The problem is when you have non-CPU devices in the device tree and
>>>> since they do not have a way to represent states like CPU, we did not
>>>> have a clear path to that. Hence we punted that to later. Whatever we
>>>> do, we should solve it for a generic PM domain, not just CPU domains.
>>>>
>>>
>>> Yes bindings defined here should be applicable for devices to, but only
>>> CPU's will have this hierarchy while the devices need not bother about
>>> hierarchy. However the parent power domain can ever the state which is
>>> least common denominator of all it's children power domain. That's my
>>> understanding. No?
>>>
>
>
> Are you saying that the parent can enter the shallowest idle state that all its
> children are in (I.e if all its children are in "retention" then it can enter
> "retention")? I don't know what the reality is on existing platforms but it
> doesn't sound like 100% safe assumption to make.
I was referring to non-CPU/device power states above. For CPU we do need
a mechanism in place to indicate the dependency.
> Also I don't think you can
> necessarily correlate idle states at different domain levels - i.e. here we've
> matched up the idea of "retention" at core level with that of "retention" at
> cluster level. I may have misunderstood you there..
>
Correct for CPUs. For normal devices and their power domains, it could
straight forward. E.g if many devices are at-least at state D1(few may
be at state D2 or above), the parent can enter D1.(D0-runnning and D1-D3
are low power states in the above example)
>> That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
>> which is invalid and the firmware has to ignore it and does CORE_RET +
>> CLUSTER_RET instead, then Linux may have an inconsistent view of the
>> state selection.
>>
1. First, CORE_RET + CLUSTER_PG should not be registered as valid idle
state.
2. We do have inconsistent view already for platform co-ordinated idle
In-fact it could happen even with OSC mode I believe. Platform can
always demote the state, so OS can never get the exact view unless it
queries the firmware for that explicitly(e.g. PSCI_STATS)
>
> Perhaps a better starting point would be to go with the assumption that a parent
> PD can only enter any idle state once its children are in their deepest idle
> states.
>
> So in the example above we'd end up with
>
> CORE_RET
> CORE_PG
> CORE_PG + CLUSTER_RET
> CORE_PG + CLUSTER_PG
>
Yes this assumption seems good enough to me. At-least no invalid
combination is ensured.
> (Missing out on CORE_RET + CLUSTER_RET, even though that's a valid combination
> from the hardware's perspective)
>
Yes, if it's a real issue then we need proper bindings to deal with
that. Otherwise we can manage without the extra information.
> Then a later addition to the bindings as discussed above could enable the
> possibility of those combinations to be expressed.
>
Seems feasible solution to me, but better to make this explicit in the
binding and check with few others. It looks fair enough assumption IMO.
--
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-10 18:09 ` Sudeep Holla
@ 2016-08-19 18:10 ` Kevin Hilman
-1 siblings, 0 replies; 83+ messages in thread
From: Kevin Hilman @ 2016-08-19 18:10 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lina Iyer, linux-pm, linux-arm-kernel, ulf.hansson, rjw,
andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lorenzo Pieralisi, Brendan Jackman, Juri Lelli
Sudeep Holla <sudeep.holla@arm.com> writes:
[...]
> In general whatever binding we come up must not just address OS
> coordinated mode. Also I was thinking to have better coverage in the
> description by having a bit more complex system like:
>
> cluster0
> CLUSTER_RET(Retention)
> CLUSTER_PG(Power Gate)
> core0
> CORE_RET
> CORE_PG
> core1
> CORE_RET
> CORE_PG
Also, remember that a power domain may contain more than just CPUs, so
this will also need to handle things like:
device0..N
DEV_CLK_GATE
DEV_RET
DEV_PG
So, as (I think) Lina was trying to say, including CPU idle states
inside domain idles states doesn't really scale well because it would
also imply domain states would also include device idle states.
IMO, the device-specific states belong in the device nodes, and that
includes CPUs.
It's up to the domain (genpd) governor to look at *all* devices in the
domain, check their state and make a domain-wide decision.
The tricky part remains, IMO, the mapping between device/CPU states and
allowable domain states.
As was suggested earlier, a good potential starting point would be that
all devices/CPUs would need to be in their deepest state before the
domain would make any decisions. While that leaves soem power savings
on the table, it maps well to how genpd works today with only on/off
states and could be extended with more complicated governors down the
road.
Kevin
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-19 18:10 ` Kevin Hilman
0 siblings, 0 replies; 83+ messages in thread
From: Kevin Hilman @ 2016-08-19 18:10 UTC (permalink / raw)
To: linux-arm-kernel
Sudeep Holla <sudeep.holla@arm.com> writes:
[...]
> In general whatever binding we come up must not just address OS
> coordinated mode. Also I was thinking to have better coverage in the
> description by having a bit more complex system like:
>
> cluster0
> CLUSTER_RET(Retention)
> CLUSTER_PG(Power Gate)
> core0
> CORE_RET
> CORE_PG
> core1
> CORE_RET
> CORE_PG
Also, remember that a power domain may contain more than just CPUs, so
this will also need to handle things like:
device0..N
DEV_CLK_GATE
DEV_RET
DEV_PG
So, as (I think) Lina was trying to say, including CPU idle states
inside domain idles states doesn't really scale well because it would
also imply domain states would also include device idle states.
IMO, the device-specific states belong in the device nodes, and that
includes CPUs.
It's up to the domain (genpd) governor to look at *all* devices in the
domain, check their state and make a domain-wide decision.
The tricky part remains, IMO, the mapping between device/CPU states and
allowable domain states.
As was suggested earlier, a good potential starting point would be that
all devices/CPUs would need to be in their deepest state before the
domain would make any decisions. While that leaves soem power savings
on the table, it maps well to how genpd works today with only on/off
states and could be extended with more complicated governors down the
road.
Kevin
^ permalink raw reply [flat|nested] 83+ messages in thread
* [RFC 0/6] Illustration of using domain-idle-states for CPU idle states
[not found] ` <1470351902-43103-3-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
@ 2016-08-24 13:48 ` Brendan Jackman
2016-08-24 13:48 ` [RFC 1/6] cpuidle: Rename cpuidle_get_{cpu->dev}_driver Brendan Jackman
` (4 more replies)
0 siblings, 5 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-24 13:48 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Titinger, Lina Iyer,
Lorenzo Pieralisi, Sudeep Holla
Hi,
I've proposed before that, in order to avoid splitting idle state information
between cpu-idle-states (or a hypothetical device-idle-states for devices) and
domain-idle-states, we use domain-idle-states for everything. If a device or CPU
has an idle state, we declare that it's in a power (sub)domain of its own, and
add the idle state as a property of that (sub)domain.
I'm just posting these patches to illustrate the idea. With these patches,
cpu-idle-states is totally ignored when a cpu node has a power-domains property
and instead the power-domains tree is walked to find states. The states are
linearised under the assumption that no parent domain can enter an idle state
until its children are in their deepest possible state.
This _doesn't_ include OSI suspend so not much of the work is done. In order to
extend this for OSI suspend, we'd need to detect whether OSI is supported by the
FW (as in Lina's patch [1]). If it is not supported, we'd add all the states to
cpuidle as in these patches. If it _is_, we'd add only the CPU-level states to
cpuidle, and the remaining states to the CPU PM domains. I'm not clear on how
that would be architected so my next step is to investigate that.
[1] drivers: firmware: psci: Allow OS Initiated suspend mode
https://patchwork.kernel.org/patch/9264543/
Brendan Jackman (6):
These three are just awkward implementation details for the proof-of-concept:
cpuidle: Rename cpuidle_get_{cpu->dev}_driver
cpuidle: Add public funcion to get driver from CPU index
cpuidle: Add device_node pointer in cpuidle_state
This is the important one that demonstrates the behaviour I'm talking about:
cpuidle: dt: Add support for reading states from power domains
These two illustrate how the DT would look with this model; ARM Juno r0 is the
only platform I have for the moment.
arm64: dts: Add Juno r0 CPU power domain tree
arm64: dts: Add domain-idle-states for Juno r0 power domains
arch/arm64/boot/dts/arm/juno.dts | 61 +++++++++++
drivers/cpuidle/cpuidle.c | 10 +-
drivers/cpuidle/driver.c | 22 ++--
drivers/cpuidle/dt_idle_states.c | 220 ++++++++++++++++++++++++++++++++-------
drivers/cpuidle/sysfs.c | 6 +-
drivers/firmware/psci.c | 38 +++----
include/linux/cpuidle.h | 23 ++--
kernel/sched/idle.c | 2 +-
8 files changed, 297 insertions(+), 85 deletions(-)
--
2.9.3
--
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
^ permalink raw reply [flat|nested] 83+ messages in thread
* [RFC 1/6] cpuidle: Rename cpuidle_get_{cpu->dev}_driver
2016-08-24 13:48 ` [RFC 0/6] Illustration of using domain-idle-states for CPU " Brendan Jackman
@ 2016-08-24 13:48 ` Brendan Jackman
2016-08-24 13:48 ` [RFC 2/6] cpuidle: Add public funcion to get driver from CPU index Brendan Jackman
` (3 subsequent siblings)
4 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-24 13:48 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw
Cc: andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lina Iyer, Lorenzo Pieralisi, Sudeep Holla
The current cpuidle_get_cpu_driver takes a cpuidle_device. Rename this
function to cpuidle_get_dev_driver, so that we can create a public
cpuidle_get_cpu_driver that takes a logcal CPU number.
---
drivers/cpuidle/cpuidle.c | 10 +++++-----
drivers/cpuidle/driver.c | 8 ++++----
drivers/cpuidle/sysfs.c | 6 +++---
include/linux/cpuidle.h | 4 ++--
kernel/sched/idle.c | 2 +-
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index c73207a..3027a35 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -58,7 +58,7 @@ bool cpuidle_not_available(struct cpuidle_driver *drv,
int cpuidle_play_dead(void)
{
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(dev);
int i;
if (!drv)
@@ -367,7 +367,7 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
if (dev->enabled)
return 0;
- drv = cpuidle_get_cpu_driver(dev);
+ drv = cpuidle_get_dev_driver(dev);
if (!drv || !cpuidle_curr_governor)
return -EIO;
@@ -407,7 +407,7 @@ EXPORT_SYMBOL_GPL(cpuidle_enable_device);
*/
void cpuidle_disable_device(struct cpuidle_device *dev)
{
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(dev);
if (!dev || !dev->enabled)
return;
@@ -428,7 +428,7 @@ EXPORT_SYMBOL_GPL(cpuidle_disable_device);
static void __cpuidle_unregister_device(struct cpuidle_device *dev)
{
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(dev);
list_del(&dev->device_list);
per_cpu(cpuidle_devices, dev->cpu) = NULL;
@@ -453,7 +453,7 @@ static void __cpuidle_device_init(struct cpuidle_device *dev)
static int __cpuidle_register_device(struct cpuidle_device *dev)
{
int ret;
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(dev);
if (!try_module_get(drv->owner))
return -EINVAL;
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 389ade4..9e0ec15 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -329,20 +329,20 @@ struct cpuidle_driver *cpuidle_get_driver(void)
EXPORT_SYMBOL_GPL(cpuidle_get_driver);
/**
- * cpuidle_get_cpu_driver - return the driver registered for a CPU.
+ * cpuidle_get_dev_driver - return the driver registered for a cpuidle device.
* @dev: a valid pointer to a struct cpuidle_device
*
* Returns a struct cpuidle_driver pointer, or NULL if no driver is registered
* for the CPU associated with @dev.
*/
-struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev)
+struct cpuidle_driver *cpuidle_get_dev_driver(struct cpuidle_device *dev)
{
if (!dev)
return NULL;
- return __cpuidle_get_cpu_driver(dev->cpu);
+ return cpuidle_get_cpu_driver(dev->cpu);
}
-EXPORT_SYMBOL_GPL(cpuidle_get_cpu_driver);
+EXPORT_SYMBOL_GPL(cpuidle_get_dev_driver);
/**
* cpuidle_driver_ref - get a reference to the driver.
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 832a2c3..9c35bdd 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -398,7 +398,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device *device)
int i, ret = -ENOMEM;
struct cpuidle_state_kobj *kobj;
struct cpuidle_device_kobj *kdev = device->kobj_dev;
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(device);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(device);
/* state statistics */
for (i = 0; i < drv->state_count; i++) {
@@ -433,7 +433,7 @@ error_state:
*/
static void cpuidle_remove_state_sysfs(struct cpuidle_device *device)
{
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(device);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(device);
int i;
for (i = 0; i < drv->state_count; i++)
@@ -529,7 +529,7 @@ static int cpuidle_add_driver_sysfs(struct cpuidle_device *dev)
{
struct cpuidle_driver_kobj *kdrv;
struct cpuidle_device_kobj *kdev = dev->kobj_dev;
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(dev);
int ret;
kdrv = kzalloc(sizeof(*kdrv), GFP_KERNEL);
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index bb31373..e32c72b 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -151,7 +151,7 @@ extern int cpuidle_enable_device(struct cpuidle_device *dev);
extern void cpuidle_disable_device(struct cpuidle_device *dev);
extern int cpuidle_play_dead(void);
-extern struct cpuidle_driver *cpuidle_get_cpu_driver(struct cpuidle_device *dev);
+extern struct cpuidle_driver *cpuidle_get_dev_driver(struct cpuidle_device *dev);
static inline struct cpuidle_device *cpuidle_get_device(void)
{return __this_cpu_read(cpuidle_devices); }
#else
@@ -187,7 +187,7 @@ static inline int cpuidle_enable_device(struct cpuidle_device *dev)
{return -ENODEV; }
static inline void cpuidle_disable_device(struct cpuidle_device *dev) { }
static inline int cpuidle_play_dead(void) {return -ENODEV; }
-static inline struct cpuidle_driver *cpuidle_get_cpu_driver(
+static inline struct cpuidle_driver *cpuidle_get_dev_driver(
struct cpuidle_device *dev) {return NULL; }
static inline struct cpuidle_device *cpuidle_get_device(void) {return NULL; }
#endif
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 9fb873c..bb34461 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -128,7 +128,7 @@ static int call_cpuidle(struct cpuidle_driver *drv, struct cpuidle_device *dev,
static void cpuidle_idle_call(void)
{
struct cpuidle_device *dev = cpuidle_get_device();
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ struct cpuidle_driver *drv = cpuidle_get_dev_driver(dev);
int next_state, entered_state;
/*
--
2.9.3
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [RFC 2/6] cpuidle: Add public funcion to get driver from CPU index
2016-08-24 13:48 ` [RFC 0/6] Illustration of using domain-idle-states for CPU " Brendan Jackman
2016-08-24 13:48 ` [RFC 1/6] cpuidle: Rename cpuidle_get_{cpu->dev}_driver Brendan Jackman
@ 2016-08-24 13:48 ` Brendan Jackman
[not found] ` <20160824134822.3591-1-brendan.jackman-5wv7dgnIgG8@public.gmane.org>
` (2 subsequent siblings)
4 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-24 13:48 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw
Cc: andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lina Iyer, Lorenzo Pieralisi, Sudeep Holla
This will be used to enable the PSCI driver to get a reference to the
cpuidle driver, in absence of a registered cpuidle_device, in order to
get the idle states that the cpuidle driver init discovered.
---
drivers/cpuidle/driver.c | 14 +++++++-------
include/linux/cpuidle.h | 3 +++
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 9e0ec15..9cb4300 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -24,13 +24,13 @@ DEFINE_SPINLOCK(cpuidle_driver_lock);
static DEFINE_PER_CPU(struct cpuidle_driver *, cpuidle_drivers);
/**
- * __cpuidle_get_cpu_driver - return the cpuidle driver tied to a CPU.
+ * cpuidle_get_cpu_driver - return the cpuidle driver tied to a CPU.
* @cpu: the CPU handled by the driver
*
* Returns a pointer to struct cpuidle_driver or NULL if no driver has been
* registered for @cpu.
*/
-static struct cpuidle_driver *__cpuidle_get_cpu_driver(int cpu)
+struct cpuidle_driver *cpuidle_get_cpu_driver(int cpu)
{
return per_cpu(cpuidle_drivers, cpu);
}
@@ -49,7 +49,7 @@ static inline void __cpuidle_unset_driver(struct cpuidle_driver *drv)
for_each_cpu(cpu, drv->cpumask) {
- if (drv != __cpuidle_get_cpu_driver(cpu))
+ if (drv != cpuidle_get_cpu_driver(cpu))
continue;
per_cpu(cpuidle_drivers, cpu) = NULL;
@@ -71,7 +71,7 @@ static inline int __cpuidle_set_driver(struct cpuidle_driver *drv)
for_each_cpu(cpu, drv->cpumask) {
- if (__cpuidle_get_cpu_driver(cpu)) {
+ if (cpuidle_get_cpu_driver(cpu)) {
__cpuidle_unset_driver(drv);
return -EBUSY;
}
@@ -87,13 +87,13 @@ static inline int __cpuidle_set_driver(struct cpuidle_driver *drv)
static struct cpuidle_driver *cpuidle_curr_driver;
/**
- * __cpuidle_get_cpu_driver - return the global cpuidle driver pointer.
+ * cpuidle_get_cpu_driver - return the global cpuidle driver pointer.
* @cpu: ignored without the multiple driver support
*
* Return a pointer to a struct cpuidle_driver object or NULL if no driver was
* previously registered.
*/
-static inline struct cpuidle_driver *__cpuidle_get_cpu_driver(int cpu)
+inline struct cpuidle_driver *cpuidle_get_cpu_driver(int cpu)
{
return cpuidle_curr_driver;
}
@@ -321,7 +321,7 @@ struct cpuidle_driver *cpuidle_get_driver(void)
int cpu;
cpu = get_cpu();
- drv = __cpuidle_get_cpu_driver(cpu);
+ drv = cpuidle_get_cpu_driver(cpu);
put_cpu();
return drv;
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index e32c72b..8435577 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -134,6 +134,7 @@ extern int cpuidle_enter(struct cpuidle_driver *drv,
extern void cpuidle_reflect(struct cpuidle_device *dev, int index);
extern int cpuidle_register_driver(struct cpuidle_driver *drv);
+extern struct cpuidle_driver *cpuidle_get_cpu_driver(int cpu);
extern struct cpuidle_driver *cpuidle_get_driver(void);
extern struct cpuidle_driver *cpuidle_driver_ref(void);
extern void cpuidle_driver_unref(void);
@@ -168,6 +169,8 @@ static inline int cpuidle_enter(struct cpuidle_driver *drv,
static inline void cpuidle_reflect(struct cpuidle_device *dev, int index) { }
static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
{return -ENODEV; }
+static inline struct cpuidle_driver *cpuidle_get_cpu_driver(int cpu)
+{return NULL; }
static inline struct cpuidle_driver *cpuidle_get_driver(void) {return NULL; }
static inline struct cpuidle_driver *cpuidle_driver_ref(void) {return NULL; }
static inline void cpuidle_driver_unref(void) {}
--
2.9.3
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [RFC 3/6] cpuidle: Add device_node pointer in cpuidle_state
[not found] ` <20160824134822.3591-1-brendan.jackman-5wv7dgnIgG8@public.gmane.org>
@ 2016-08-24 13:48 ` Brendan Jackman
2016-08-24 13:48 ` [RFC 6/6] arm64: dts: Add domain-idle-states for Juno r0 power domains Brendan Jackman
1 sibling, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-24 13:48 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Titinger, Lina Iyer,
Lorenzo Pieralisi, Sudeep Holla
Store a pointer in the cpuidle_state structure to the Device Tree node
from which that state originated, if such a node exists.
This will allow plaform-specific components to extract extra idle state
information without duplicating the logic that finds the idle state
nodes.
---
drivers/cpuidle/dt_idle_states.c | 3 +++
include/linux/cpuidle.h | 18 ++++++++++--------
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/cpuidle/dt_idle_states.c b/drivers/cpuidle/dt_idle_states.c
index a5c111b..61a70ec 100644
--- a/drivers/cpuidle/dt_idle_states.c
+++ b/drivers/cpuidle/dt_idle_states.c
@@ -88,6 +88,9 @@ static int init_state_node(struct cpuidle_state *idle_state,
*/
strncpy(idle_state->name, state_node->name, CPUIDLE_NAME_LEN - 1);
strncpy(idle_state->desc, desc, CPUIDLE_DESC_LEN - 1);
+
+ idle_state->of_node = state_node;
+
return 0;
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 8435577..d4ea1e4 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -14,6 +14,7 @@
#include <linux/percpu.h>
#include <linux/list.h>
#include <linux/hrtimer.h>
+#include <linux/of.h>
#define CPUIDLE_STATE_MAX 10
#define CPUIDLE_NAME_LEN 16
@@ -36,14 +37,15 @@ struct cpuidle_state_usage {
};
struct cpuidle_state {
- char name[CPUIDLE_NAME_LEN];
- char desc[CPUIDLE_DESC_LEN];
-
- unsigned int flags;
- unsigned int exit_latency; /* in US */
- int power_usage; /* in mW */
- unsigned int target_residency; /* in US */
- bool disabled; /* disabled on all CPUs */
+ char name[CPUIDLE_NAME_LEN];
+ char desc[CPUIDLE_DESC_LEN];
+
+ unsigned int flags;
+ unsigned int exit_latency; /* in US */
+ int power_usage; /* in mW */
+ unsigned int target_residency; /* in US */
+ bool disabled; /* disabled on all CPUs */
+ struct device_node *of_node;
int (*enter) (struct cpuidle_device *dev,
struct cpuidle_driver *drv,
--
2.9.3
--
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [RFC 4/6] cpuidle: dt: Add support for reading states from power domains
2016-08-24 13:48 ` [RFC 0/6] Illustration of using domain-idle-states for CPU " Brendan Jackman
` (2 preceding siblings ...)
[not found] ` <20160824134822.3591-1-brendan.jackman-5wv7dgnIgG8@public.gmane.org>
@ 2016-08-24 13:48 ` Brendan Jackman
2016-08-24 13:48 ` [RFC 5/6] arm64: dts: Add Juno r0 CPU power domain tree Brendan Jackman
4 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-24 13:48 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw
Cc: andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lina Iyer, Lorenzo Pieralisi, Sudeep Holla
This commit allows the list of phandles to idle state nodes for a CPU to
be read from its hierarchy of power domain nodes, in preference to its
cpu-idle-states property. Each CPU's power domain hierarchy is walked,
and at each power domain topology level, all idle states discovered are
appended to the list for that CPU. If a CPU node does not contain a
power-domains property (i.e. has no power domain hierarchy), we fall
back to cpu-idle-states.
This will later be used for the derivation of idle state energy cost
data for Energy Aware Scheduling, for which we need to know the power
domain topology level to which an idle state applies in hardware.
The logic for locating idle state nodes was previously trivial (simply
read the cpu-idle-states property), so was duplicated between
dt_idle_states.c and the PSCI driver. To avoid duplicating the new
logic, the PSCI driver is modified to locate the idle state nodes via
the cpuidle driver's states list.
---
NB This assumes that #power-domain-cells is always 0. I'm not sure how we'd
work this out for platforms where multiple power domains share a controller
and are therefore represented by the same node. I'm guessing in those cases
all of those power domains would share idle states, and if not we'd add
intermediary subdomains in which we could point to the states.
drivers/cpuidle/dt_idle_states.c | 205 ++++++++++++++++++++++++++++++++-------
drivers/firmware/psci.c | 38 ++++----
2 files changed, 187 insertions(+), 56 deletions(-)
diff --git a/drivers/cpuidle/dt_idle_states.c b/drivers/cpuidle/dt_idle_states.c
index 61a70ec..c2b590f 100644
--- a/drivers/cpuidle/dt_idle_states.c
+++ b/drivers/cpuidle/dt_idle_states.c
@@ -18,9 +18,128 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/slab.h>
#include "dt_idle_states.h"
+struct {
+ unsigned int count;
+ struct device_node *nodes[CPUIDLE_STATE_MAX + 1];
+} *state_node_arrays;
+
+static unsigned int __init parse_phandles(struct device_node *np,
+ const char *prop_name,
+ struct device_node **nodes_out,
+ int nodes_out_len)
+{
+ unsigned int i;
+
+ for (i = 0; i < nodes_out_len; i++) {
+ struct device_node *state_node;
+
+ state_node = of_parse_phandle(np, prop_name, i);
+ if (!state_node)
+ break;
+
+ nodes_out[i] = state_node;
+
+ of_node_put(state_node);
+ }
+
+ return i;
+}
+
+static unsigned int __init find_cpu_state_nodes(struct device_node *cpu_node,
+ struct device_node **nodes_out,
+ int nodes_out_len)
+{
+ struct device_node *consumer_node;
+ unsigned int i, state_idx;
+
+ if (!of_property_read_bool(cpu_node, "power-domains")) {
+ return parse_phandles(cpu_node, "cpu-idle-states",
+ nodes_out, nodes_out_len);
+ }
+
+ consumer_node = of_node_get(cpu_node);
+
+ /*
+ * Use a loop counter, i, so we don't infiniloop if there's a cycle in
+ * the power-domains graph (i.e. the DT is borken).
+ */
+ for (i = 0, state_idx = 0;
+ (i < 8) && (state_idx < nodes_out_len);
+ i++) {
+ /*
+ * TODO
+ * - Make this work with parent PDs that are parent DT nodes too
+ * (i.e. see if parent node has #power-domain-cells)
+ */
+ struct device_node *pd_node = of_parse_phandle(
+ consumer_node, "power-domains", 0);
+ if (!pd_node) {
+ of_node_put(consumer_node);
+ break;
+ }
+
+ state_idx += parse_phandles(pd_node, "domain-idle-states",
+ &nodes_out[state_idx],
+ nodes_out_len - state_idx);
+
+ of_node_put(consumer_node);
+ consumer_node = pd_node;
+ }
+
+ if (i == 8) {
+ pr_warn("%s: DT CPU power-domains graph too deep.\n", __func__);
+ pr_warn("%s: Some idle states will be ignored\n", __func__);
+ }
+ if (state_idx == nodes_out_len)
+ pr_warn("%s: Too many idle state phandles in DT, ignoring some",
+ __func__);
+
+ return state_idx;
+}
+
+static int __init find_state_nodes(void)
+{
+ int cpu;
+
+ if (state_node_arrays)
+ return 0;
+
+ state_node_arrays = kmalloc_array(nr_cpu_ids,
+ sizeof(state_node_arrays[0]),
+ GFP_KERNEL);
+ if (!state_node_arrays)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu) {
+ struct device_node *cpu_node;
+
+ cpu_node = of_node_get(get_cpu_device(cpu)->of_node);
+
+ if (WARN_ON(!cpu_node))
+ return -EINVAL;
+
+ state_node_arrays[cpu].count = find_cpu_state_nodes(
+ cpu_node, state_node_arrays[cpu].nodes,
+ ARRAY_SIZE(state_node_arrays[cpu].nodes));
+
+ of_node_put(cpu_node);
+ }
+
+ return 0;
+}
+
+static int __init free_state_node_arrays(void)
+{
+ kfree(state_node_arrays);
+ state_node_arrays = NULL;
+ return 0;
+}
+late_initcall(free_state_node_arrays);
+
static int init_state_node(struct cpuidle_state *idle_state,
const struct of_device_id *matches,
struct device_node *state_node)
@@ -95,38 +214,40 @@ static int init_state_node(struct cpuidle_state *idle_state,
}
/*
- * Check that the idle state is uniform across all CPUs in the CPUidle driver
+ * Check that the idle states are uniform across all CPUs in the CPUidle driver
* cpumask
*/
-static bool idle_state_valid(struct device_node *state_node, unsigned int idx,
- const cpumask_t *cpumask)
+static bool idle_states_valid(struct device_node **state_nodes,
+ unsigned int count, const cpumask_t *cpumask)
{
int cpu;
- struct device_node *cpu_node, *curr_state_node;
- bool valid = true;
+ struct device_node **curr_state_nodes;
+ unsigned int curr_count;
+ unsigned int i;
/*
- * Compare idle state phandles for index idx on all CPUs in the
+ * Compare idle states on all CPUs in the
* CPUidle driver cpumask. Start from next logical cpu following
- * cpumask_first(cpumask) since that's the CPU state_node was
+ * cpumask_first(cpumask) since that's the CPU state_nodes were
* retrieved from. If a mismatch is found bail out straight
* away since we certainly hit a firmware misconfiguration.
*/
for (cpu = cpumask_next(cpumask_first(cpumask), cpumask);
cpu < nr_cpu_ids; cpu = cpumask_next(cpu, cpumask)) {
- cpu_node = of_cpu_device_node_get(cpu);
- curr_state_node = of_parse_phandle(cpu_node, "cpu-idle-states",
- idx);
- if (state_node != curr_state_node)
- valid = false;
- of_node_put(curr_state_node);
- of_node_put(cpu_node);
- if (!valid)
- break;
+ curr_state_nodes = state_node_arrays[cpu].nodes;
+ curr_count = state_node_arrays[cpu].count;
+
+ if (curr_count != count)
+ return false;
+
+ for (i = 0; i < count; i++) {
+ if (state_nodes[i] != curr_state_nodes[i])
+ return false;
+ }
}
- return valid;
+ return true;
}
/**
@@ -156,13 +277,21 @@ int dt_init_idle_driver(struct cpuidle_driver *drv,
unsigned int start_idx)
{
struct cpuidle_state *idle_state;
- struct device_node *state_node, *cpu_node;
+ struct device_node *state_node;
int i, err = 0;
const cpumask_t *cpumask;
+ int cpu;
unsigned int state_idx = start_idx;
+ struct device_node **state_nodes;
+ unsigned int state_nodes_count;
if (state_idx >= CPUIDLE_STATE_MAX)
return -EINVAL;
+
+ err = find_state_nodes();
+ if (err)
+ return err;
+
/*
* We get the idle states for the first logical cpu in the
* driver mask (or cpu_possible_mask if the driver cpumask is not set)
@@ -170,27 +299,28 @@ int dt_init_idle_driver(struct cpuidle_driver *drv,
* across CPUs, otherwise we hit a firmware misconfiguration.
*/
cpumask = drv->cpumask ? : cpu_possible_mask;
- cpu_node = of_cpu_device_node_get(cpumask_first(cpumask));
+ cpu = cpumask_first(cpumask);
+ state_nodes = state_node_arrays[cpu].nodes;
+ state_nodes_count = state_node_arrays[cpu].count;
- for (i = 0; ; i++) {
- state_node = of_parse_phandle(cpu_node, "cpu-idle-states", i);
- if (!state_node)
- break;
+ if (start_idx + state_nodes_count > CPUIDLE_STATE_MAX) {
+ pr_warn("%s: Too many idle state nodes, ignoring some\n",
+ __func__);
+ state_nodes_count = (CPUIDLE_STATE_MAX - start_idx);
+ }
- if (!of_device_is_available(state_node))
- continue;
+ if (!idle_states_valid(state_nodes, state_nodes_count, cpumask)) {
+ pr_warn("CPU%d idle states not valid, bailing out\n", cpu);
+ return -EINVAL;
+ }
- if (!idle_state_valid(state_node, i, cpumask)) {
- pr_warn("%s idle state not valid, bailing out\n",
- state_node->full_name);
- err = -EINVAL;
- break;
- }
+ for (i = 0; i < state_nodes_count; i++) {
+ state_node = of_node_get(state_nodes[i]);
+ if (WARN_ON(!state_node))
+ return -EINVAL;
- if (state_idx == CPUIDLE_STATE_MAX) {
- pr_warn("State index reached static CPU idle driver states array size\n");
- break;
- }
+ if (!of_device_is_available(state_node))
+ goto next;
idle_state = &drv->states[state_idx++];
err = init_state_node(idle_state, matches, state_node);
@@ -198,13 +328,14 @@ int dt_init_idle_driver(struct cpuidle_driver *drv,
pr_err("Parsing idle state node %s failed with err %d\n",
state_node->full_name, err);
err = -EINVAL;
+ of_node_put(state_node);
break;
}
+
+next:
of_node_put(state_node);
}
- of_node_put(state_node);
- of_node_put(cpu_node);
if (err)
return err;
/*
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 8263429..4bdf0f2 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -25,6 +25,7 @@
#include <linux/reboot.h>
#include <linux/slab.h>
#include <linux/suspend.h>
+#include <linux/cpuidle.h>
#include <uapi/linux/psci.h>
@@ -251,21 +252,21 @@ static int __init psci_features(u32 psci_func_id)
#ifdef CONFIG_CPU_IDLE
static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
-static int psci_dt_cpu_init_idle(struct device_node *cpu_node, int cpu)
+static int psci_dt_cpu_init_idle(int cpu)
{
- int i, ret, count = 0;
+ int i, ret, count;
u32 *psci_states;
- struct device_node *state_node;
+ struct cpuidle_driver *cpuidle_drv;
+ struct device_node *state_node = NULL;
- /* Count idle states */
- while ((state_node = of_parse_phandle(cpu_node, "cpu-idle-states",
- count))) {
- count++;
- of_node_put(state_node);
+ cpuidle_drv = cpuidle_get_cpu_driver(cpu);
+ if (!cpuidle_drv) {
+ pr_warn("%s: Couldn't get cpuidle driver for CPU%d\n",
+ __func__, cpu);
+ return -ENODEV;
}
- if (!count)
- return -ENODEV;
+ count = cpuidle_drv->state_count - 1;
psci_states = kcalloc(count, sizeof(*psci_states), GFP_KERNEL);
if (!psci_states)
@@ -274,7 +275,13 @@ static int psci_dt_cpu_init_idle(struct device_node *cpu_node, int cpu)
for (i = 0; i < count; i++) {
u32 state;
- state_node = of_parse_phandle(cpu_node, "cpu-idle-states", i);
+ state_node = of_node_get(cpuidle_drv->states[i + 1].of_node);
+ if (!state_node) {
+ pr_warn("%s: No DT node for cpuidle state %d on CPU%d\n",
+ __func__, i, cpu);
+ ret = -ENODEV;
+ goto free_mem;
+ }
ret = of_property_read_u32(state_node,
"arm,psci-suspend-param",
@@ -354,7 +361,6 @@ static int __maybe_unused psci_acpi_cpu_init_idle(unsigned int cpu)
int psci_cpu_init_idle(unsigned int cpu)
{
- struct device_node *cpu_node;
int ret;
/*
@@ -367,13 +373,7 @@ int psci_cpu_init_idle(unsigned int cpu)
if (!acpi_disabled)
return psci_acpi_cpu_init_idle(cpu);
- cpu_node = of_get_cpu_node(cpu, NULL);
- if (!cpu_node)
- return -ENODEV;
-
- ret = psci_dt_cpu_init_idle(cpu_node, cpu);
-
- of_node_put(cpu_node);
+ ret = psci_dt_cpu_init_idle(cpu);
return ret;
}
--
2.9.3
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [RFC 5/6] arm64: dts: Add Juno r0 CPU power domain tree
2016-08-24 13:48 ` [RFC 0/6] Illustration of using domain-idle-states for CPU " Brendan Jackman
` (3 preceding siblings ...)
2016-08-24 13:48 ` [RFC 4/6] cpuidle: dt: Add support for reading states from " Brendan Jackman
@ 2016-08-24 13:48 ` Brendan Jackman
4 siblings, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-24 13:48 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw
Cc: andy.gross, sboyd, linux-arm-msm, Axel Haslam, devicetree,
Marc Titinger, Lina Iyer, Lorenzo Pieralisi, Sudeep Holla
---
arch/arm64/boot/dts/arm/juno.dts | 47 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index a7270ef..4e086ec 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -90,6 +90,7 @@
next-level-cache = <&A57_L2>;
clocks = <&scpi_dvfs 0>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ power-domains = <&A57_0_PD>;
};
A57_1: cpu@1 {
@@ -100,6 +101,7 @@
next-level-cache = <&A57_L2>;
clocks = <&scpi_dvfs 0>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ power-domains = <&A57_1_PD>;
};
A53_0: cpu@100 {
@@ -110,6 +112,7 @@
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ power-domains = <&A53_0_PD>;
};
A53_1: cpu@101 {
@@ -120,6 +123,7 @@
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ power-domains = <&A53_1_PD>;
};
A53_2: cpu@102 {
@@ -130,6 +134,7 @@
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ power-domains = <&A53_2_PD>;
};
A53_3: cpu@103 {
@@ -140,6 +145,7 @@
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
+ power-domains = <&A53_3_PD>;
};
A57_L2: l2-cache0 {
@@ -151,6 +157,47 @@
};
};
+ power-domains {
+ CLUSTER_A57_PD: cluster-a57-pd {
+ #power-domain-cells = <0>;
+ };
+
+ A57_0_PD: a57-pd@0 {
+ #power-domain-cells = <0>;
+ power-domains = <&CLUSTER_A57_PD>;
+ };
+
+ A57_1_PD: a57-pd@1 {
+ #power-domain-cells = <0>;
+ power-domains = <&CLUSTER_A57_PD>;
+ };
+
+
+ CLUSTER_A53_PD: cluster-a53-pd {
+ #power-domain-cells = <0>;
+ };
+
+ A53_0_PD: a53-pd@0 {
+ #power-domain-cells = <0>;
+ power-domains = <&CLUSTER_A53_PD>;
+ };
+
+ A53_1_PD: a53-pd@1 {
+ #power-domain-cells = <0>;
+ power-domains = <&CLUSTER_A53_PD>;
+ };
+
+ A53_2_PD: a53-pd@2 {
+ #power-domain-cells = <0>;
+ power-domains = <&CLUSTER_A53_PD>;
+ };
+
+ A53_3_PD: a53-pd@3 {
+ #power-domain-cells = <0>;
+ power-domains = <&CLUSTER_A53_PD>;
+ };
+ };
+
pmu_a57 {
compatible = "arm,cortex-a57-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
--
2.9.3
^ permalink raw reply related [flat|nested] 83+ messages in thread
* [RFC 6/6] arm64: dts: Add domain-idle-states for Juno r0 power domains
[not found] ` <20160824134822.3591-1-brendan.jackman-5wv7dgnIgG8@public.gmane.org>
2016-08-24 13:48 ` [RFC 3/6] cpuidle: Add device_node pointer in cpuidle_state Brendan Jackman
@ 2016-08-24 13:48 ` Brendan Jackman
1 sibling, 0 replies; 83+ messages in thread
From: Brendan Jackman @ 2016-08-24 13:48 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Titinger, Lina Iyer,
Lorenzo Pieralisi, Sudeep Holla
---
arch/arm64/boot/dts/arm/juno.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 4e086ec..d2bc4e3 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -160,40 +160,48 @@
power-domains {
CLUSTER_A57_PD: cluster-a57-pd {
#power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_SLEEP_0>;
};
A57_0_PD: a57-pd@0 {
#power-domain-cells = <0>;
+ domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_A57_PD>;
};
A57_1_PD: a57-pd@1 {
#power-domain-cells = <0>;
+ domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_A57_PD>;
};
CLUSTER_A53_PD: cluster-a53-pd {
#power-domain-cells = <0>;
+ domain-idle-states = <&CLUSTER_SLEEP_0>;
};
A53_0_PD: a53-pd@0 {
#power-domain-cells = <0>;
+ domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_A53_PD>;
};
A53_1_PD: a53-pd@1 {
#power-domain-cells = <0>;
+ domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_A53_PD>;
};
A53_2_PD: a53-pd@2 {
#power-domain-cells = <0>;
+ domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_A53_PD>;
};
A53_3_PD: a53-pd@3 {
#power-domain-cells = <0>;
+ domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_A53_PD>;
};
};
--
2.9.3
--
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
^ permalink raw reply related [flat|nested] 83+ messages in thread
* Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
2016-08-19 18:10 ` Kevin Hilman
@ 2016-08-24 14:07 ` Sudeep Holla
-1 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-24 14:07 UTC (permalink / raw)
To: Kevin Hilman
Cc: devicetree, ulf.hansson, Lorenzo Pieralisi, Juri Lelli, linux-pm,
sboyd, linux-arm-msm, rjw, Axel Haslam, Marc Titinger,
Brendan Jackman, Lina Iyer, Sudeep Holla, andy.gross,
linux-arm-kernel
On 19/08/16 19:10, Kevin Hilman wrote:
> Sudeep Holla <sudeep.holla@arm.com> writes:
>
> [...]
>
>> In general whatever binding we come up must not just address OS
>> coordinated mode. Also I was thinking to have better coverage in the
>> description by having a bit more complex system like:
>>
>> cluster0
>> CLUSTER_RET(Retention)
>> CLUSTER_PG(Power Gate)
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>
> Also, remember that a power domain may contain more than just CPUs, so
> this will also need to handle things like:
>
> device0..N
> DEV_CLK_GATE
> DEV_RET
> DEV_PG
>
> So, as (I think) Lina was trying to say, including CPU idle states
> inside domain idles states doesn't really scale well because it would
> also imply domain states would also include device idle states.
>
> IMO, the device-specific states belong in the device nodes, and that
> includes CPUs.
>
OK, IIUC we don't have device idle states binding today, so we are not
breaking anything there. Can you elaborate on the issue you see if we
just have domain idle-states ? Is it because we currently create genpd
domain for each entry ?
If a CPU/Device can be enter idle-state(s) it means that it is in a
power domain on its own, so I don't see any issue in such representation.
> It's up to the domain (genpd) governor to look at *all* devices in the
> domain, check their state and make a domain-wide decision.
>
Lets not mix the current genpd implementation in the kernel into this
discussion for simplicity. How is the implementation in the kernel today
and what can be done is a separate topic.
What this discussion should aim at is to present the idle states in the
system in the device tree so that it address the issues we have
currently and extensible in near future with any compatibility issues.
> The tricky part remains, IMO, the mapping between device/CPU states and
> allowable domain states.
>
> As was suggested earlier, a good potential starting point would be that
> all devices/CPUs would need to be in their deepest state before the
> domain would make any decisions. While that leaves soem power savings
> on the table, it maps well to how genpd works today with only on/off
> states and could be extended with more complicated governors down the
> road.
>
Agreed.
Some example below for discussion, feel free to add more cases.
--
Regards,
Sudeep
--->8
1. Dual cluster with 2 CPUs in each cluster with powerdown at both CPU and
cluster level
idle-states {
CPU_SLEEP_0: cpu-sleep-0 {
...
entry-latency-us = <300>;
...
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
...
entry-latency-us = <300>;
...
};
};
cpu@0 {
...
/*
* implentation may ignore cpu-idle-states if power-domains
* has idle-states, DT's may have both for backward compatibility
*/
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_0_1_PD>;
...
};
cpu@1 {
...
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_0_1_PD>;
...
};
cpu@100 {
...
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_1_0_PD>;
...
};
cpu@101 {
...
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_1_1_PD>;
...
};
power-domains {
CLUSTER_0_PD: cluster-0-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0>;
};
CPU_0_0_PD: cpu-0-0-pd@0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_0_PD>;
};
CPU_0_1_PD: cpu-0-1-pd@1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_0_PD>;
};
CLUSTER_1_PD: cluster-1-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0>;
};
CPU_1_0_PD: cpu-1-0-pd@0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_1_PD>;
};
CPU_1_1_PD: cpu-1-1-pd@1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_1_PD>;
};
};
2. Dual cluster with 2 CPUs in each cluster with retention and powerdown
at both
CPU and cluster level
idle-states {
CPU_SLEEP_0: cpu-sleep-0 { /* Retention */
...
entry-latency-us = <100>;
...
};
CPU_SLEEP_1: cpu-sleep-1 { /* Power-down */
...
entry-latency-us = <500>;
...
};
CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
cpu@0 {
...
power-domains = <&CPU_0_1_PD>;
...
};
cpu@1 {
...
power-domains = <&CPU_0_1_PD>;
...
};
cpu@100 {
...
power-domains = <&CPU_1_0_PD>;
...
};
cpu@101 {
...
power-domains = <&CPU_1_1_PD>;
...
};
power-domains {
/*
* Each cluster/core PD may point to different idle states,
* it's all same here in the example to keep it short and
* simple
*/
CLUSTER_0_PD: cluster-0-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
CPU_0_0_PD: cpu-0-0-pd@0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_0_PD>;
};
CPU_0_1_PD: cpu-0-1-pd@1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_0_PD>;
};
CLUSTER_1_PD: cluster-1-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
CPU_1_0_PD: cpu-1-0-pd@0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_1_PD>;
};
CPU_1_1_PD: cpu-1-1-pd@1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_1_PD>;
};
};
3. Dual cluster with 2 CPUs in each cluster with retention and powerdown at
just cluster level
idle-states {
CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
cpu@0 {
...
power-domains = <&CLUSTER_0_PD>;
...
};
cpu@1 {
...
power-domains = <&CLUSTER_0_PD>;
...
};
cpu@100 {
...
power-domains = <&CLUSTER_1_PD>;
...
};
cpu@101 {
...
power-domains = <&CLUSTER_1_PD>;
...
};
power-domains {
CLUSTER_0_PD: cluster-0-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
CLUSTER_1_PD: cluster-1-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
};
4. 4 devices sharing the power domain.
idle-states {
/*
* Device idle states may differ from CPU idle states in terms
* of the list of properties
*/
DEVPD_SLEEP_0: devpd-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
DEVPD_SLEEP_1: devpd-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
dev@0 {
...
power-domains = <&DEV_PD_0>;
...
};
dev@1 {
...
power-domains = <&DEV_PD_0>;
...
};
dev@2 {
...
power-domains = <&DEV_PD_0>;
...
};
dev@3 {
...
power-domains = <&DEV_PD_0>;
...
};
power-domains {
DEV_PD_0: device-pd-0 {
#power-domain-cells = <0>;
domain-idle-states = <&DEVPD_SLEEP_0 &DEVPD_SLEEP_1>;
};
};
5. 4 devices sharing the power domain + another device sharing the power
domain but has it's own sub-domain
idle-states {
DEVPD_0_SLEEP_0: devpd-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
DEVPD_0_SLEEP_1: devpd-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
DEVPD_1_SLEEP_0: devpd-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
DEVPD_1_SLEEP_1: devpd-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
dev@0 {
...
power-domains = <&DEV_PD_0>;
...
};
dev@1 {
...
power-domains = <&DEV_PD_0>;
...
};
dev@2 {
...
power-domains = <&DEV_PD_0>;
...
};
dev@3 {
...
power-domains = <&DEV_PD_0>;
...
};
dev@4 {
...
power-domains = <&DEV_PD_1>;
...
};
power-domains {
DEV_PD_0: device-pd-0 {
#power-domain-cells = <0>;
domain-idle-states = <&DEVPD_0_SLEEP_0 &DEVPD_0_SLEEP_1>;
};
DEV_PD_1: device-pd-1 {
#power-domain-cells = <0>;
power-domains = <&DEV_PD_0>;
domain-idle-states = <&DEVPD_1_SLEEP_0 &DEVPD_1_SLEEP_1>;
};
};
^ permalink raw reply [flat|nested] 83+ messages in thread
* [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states
@ 2016-08-24 14:07 ` Sudeep Holla
0 siblings, 0 replies; 83+ messages in thread
From: Sudeep Holla @ 2016-08-24 14:07 UTC (permalink / raw)
To: linux-arm-kernel
On 19/08/16 19:10, Kevin Hilman wrote:
> Sudeep Holla <sudeep.holla@arm.com> writes:
>
> [...]
>
>> In general whatever binding we come up must not just address OS
>> coordinated mode. Also I was thinking to have better coverage in the
>> description by having a bit more complex system like:
>>
>> cluster0
>> CLUSTER_RET(Retention)
>> CLUSTER_PG(Power Gate)
>> core0
>> CORE_RET
>> CORE_PG
>> core1
>> CORE_RET
>> CORE_PG
>
> Also, remember that a power domain may contain more than just CPUs, so
> this will also need to handle things like:
>
> device0..N
> DEV_CLK_GATE
> DEV_RET
> DEV_PG
>
> So, as (I think) Lina was trying to say, including CPU idle states
> inside domain idles states doesn't really scale well because it would
> also imply domain states would also include device idle states.
>
> IMO, the device-specific states belong in the device nodes, and that
> includes CPUs.
>
OK, IIUC we don't have device idle states binding today, so we are not
breaking anything there. Can you elaborate on the issue you see if we
just have domain idle-states ? Is it because we currently create genpd
domain for each entry ?
If a CPU/Device can be enter idle-state(s) it means that it is in a
power domain on its own, so I don't see any issue in such representation.
> It's up to the domain (genpd) governor to look at *all* devices in the
> domain, check their state and make a domain-wide decision.
>
Lets not mix the current genpd implementation in the kernel into this
discussion for simplicity. How is the implementation in the kernel today
and what can be done is a separate topic.
What this discussion should aim at is to present the idle states in the
system in the device tree so that it address the issues we have
currently and extensible in near future with any compatibility issues.
> The tricky part remains, IMO, the mapping between device/CPU states and
> allowable domain states.
>
> As was suggested earlier, a good potential starting point would be that
> all devices/CPUs would need to be in their deepest state before the
> domain would make any decisions. While that leaves soem power savings
> on the table, it maps well to how genpd works today with only on/off
> states and could be extended with more complicated governors down the
> road.
>
Agreed.
Some example below for discussion, feel free to add more cases.
--
Regards,
Sudeep
--->8
1. Dual cluster with 2 CPUs in each cluster with powerdown at both CPU and
cluster level
idle-states {
CPU_SLEEP_0: cpu-sleep-0 {
...
entry-latency-us = <300>;
...
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
...
entry-latency-us = <300>;
...
};
};
cpu at 0 {
...
/*
* implentation may ignore cpu-idle-states if power-domains
* has idle-states, DT's may have both for backward compatibility
*/
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_0_1_PD>;
...
};
cpu at 1 {
...
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_0_1_PD>;
...
};
cpu at 100 {
...
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_1_0_PD>;
...
};
cpu at 101 {
...
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
power-domains = <&CPU_1_1_PD>;
...
};
power-domains {
CLUSTER_0_PD: cluster-0-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0>;
};
CPU_0_0_PD: cpu-0-0-pd at 0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_0_PD>;
};
CPU_0_1_PD: cpu-0-1-pd at 1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_0_PD>;
};
CLUSTER_1_PD: cluster-1-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0>;
};
CPU_1_0_PD: cpu-1-0-pd at 0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_1_PD>;
};
CPU_1_1_PD: cpu-1-1-pd at 1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0>;
power-domains = <&CLUSTER_1_PD>;
};
};
2. Dual cluster with 2 CPUs in each cluster with retention and powerdown
at both
CPU and cluster level
idle-states {
CPU_SLEEP_0: cpu-sleep-0 { /* Retention */
...
entry-latency-us = <100>;
...
};
CPU_SLEEP_1: cpu-sleep-1 { /* Power-down */
...
entry-latency-us = <500>;
...
};
CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
cpu at 0 {
...
power-domains = <&CPU_0_1_PD>;
...
};
cpu at 1 {
...
power-domains = <&CPU_0_1_PD>;
...
};
cpu at 100 {
...
power-domains = <&CPU_1_0_PD>;
...
};
cpu at 101 {
...
power-domains = <&CPU_1_1_PD>;
...
};
power-domains {
/*
* Each cluster/core PD may point to different idle states,
* it's all same here in the example to keep it short and
* simple
*/
CLUSTER_0_PD: cluster-0-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
CPU_0_0_PD: cpu-0-0-pd at 0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_0_PD>;
};
CPU_0_1_PD: cpu-0-1-pd at 1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_0_PD>;
};
CLUSTER_1_PD: cluster-1-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
CPU_1_0_PD: cpu-1-0-pd at 0 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_1_PD>;
};
CPU_1_1_PD: cpu-1-1-pd at 1 {
#power-domain-cells = <0>;
domain-idle-states = <&CPU_SLEEP_0 &CPU_SLEEP_1>;
power-domains = <&CLUSTER_1_PD>;
};
};
3. Dual cluster with 2 CPUs in each cluster with retention and powerdown at
just cluster level
idle-states {
CLUSTER_SLEEP_0: cluster-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
CLUSTER_SLEEP_1: cluster-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
cpu at 0 {
...
power-domains = <&CLUSTER_0_PD>;
...
};
cpu at 1 {
...
power-domains = <&CLUSTER_0_PD>;
...
};
cpu at 100 {
...
power-domains = <&CLUSTER_1_PD>;
...
};
cpu at 101 {
...
power-domains = <&CLUSTER_1_PD>;
...
};
power-domains {
CLUSTER_0_PD: cluster-0-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
CLUSTER_1_PD: cluster-1-pd {
#power-domain-cells = <0>;
domain-idle-states = <&CLUSTER_SLEEP_0 &CLUSTER_SLEEP_1>;
};
};
4. 4 devices sharing the power domain.
idle-states {
/*
* Device idle states may differ from CPU idle states in terms
* of the list of properties
*/
DEVPD_SLEEP_0: devpd-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
DEVPD_SLEEP_1: devpd-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
dev at 0 {
...
power-domains = <&DEV_PD_0>;
...
};
dev at 1 {
...
power-domains = <&DEV_PD_0>;
...
};
dev at 2 {
...
power-domains = <&DEV_PD_0>;
...
};
dev at 3 {
...
power-domains = <&DEV_PD_0>;
...
};
power-domains {
DEV_PD_0: device-pd-0 {
#power-domain-cells = <0>;
domain-idle-states = <&DEVPD_SLEEP_0 &DEVPD_SLEEP_1>;
};
};
5. 4 devices sharing the power domain + another device sharing the power
domain but has it's own sub-domain
idle-states {
DEVPD_0_SLEEP_0: devpd-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
DEVPD_0_SLEEP_1: devpd-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
DEVPD_1_SLEEP_0: devpd-sleep-0 { /* Retention */
...
entry-latency-us = <300>;
...
};
DEVPD_1_SLEEP_1: devpd-sleep-1 {/* Power-down */
...
entry-latency-us = <1000>;
...
};
};
dev at 0 {
...
power-domains = <&DEV_PD_0>;
...
};
dev at 1 {
...
power-domains = <&DEV_PD_0>;
...
};
dev at 2 {
...
power-domains = <&DEV_PD_0>;
...
};
dev at 3 {
...
power-domains = <&DEV_PD_0>;
...
};
dev at 4 {
...
power-domains = <&DEV_PD_1>;
...
};
power-domains {
DEV_PD_0: device-pd-0 {
#power-domain-cells = <0>;
domain-idle-states = <&DEVPD_0_SLEEP_0 &DEVPD_0_SLEEP_1>;
};
DEV_PD_1: device-pd-1 {
#power-domain-cells = <0>;
power-domains = <&DEV_PD_0>;
domain-idle-states = <&DEVPD_1_SLEEP_0 &DEVPD_1_SLEEP_1>;
};
};
^ permalink raw reply [flat|nested] 83+ messages in thread
end of thread, other threads:[~2016-08-24 14:07 UTC | newest]
Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-04 23:04 [PATCH v3 00/15] PM: SoC idle support using PM domains Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 01/15] PM / Domains: Allow domain power states to be read from DT Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-09 23:55 ` Rob Herring
2016-08-09 23:55 ` Rob Herring
2016-08-10 15:14 ` Sudeep Holla
2016-08-10 15:14 ` Sudeep Holla
2016-08-10 16:40 ` Lina Iyer
2016-08-10 16:40 ` Lina Iyer
[not found] ` <20160810164034.GA1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-10 18:09 ` Sudeep Holla
2016-08-10 18:09 ` Sudeep Holla
2016-08-10 18:13 ` Sudeep Holla
2016-08-10 18:13 ` Sudeep Holla
[not found] ` <5e59874c-bbb7-270a-199c-da1ff5932554-5wv7dgnIgG8@public.gmane.org>
2016-08-11 21:10 ` Lina Iyer
2016-08-11 21:10 ` Lina Iyer
[not found] ` <20160811211023.GC1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-12 9:47 ` Brendan Jackman
2016-08-12 9:47 ` Brendan Jackman
2016-08-12 10:08 ` Sudeep Holla
2016-08-12 10:08 ` Sudeep Holla
2016-08-15 16:08 ` Lina Iyer
2016-08-15 16:08 ` Lina Iyer
2016-08-15 16:14 ` Sudeep Holla
2016-08-15 16:14 ` Sudeep Holla
2016-08-15 22:40 ` Lina Iyer
2016-08-15 22:40 ` Lina Iyer
[not found] ` <20160815224014.GF1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-16 8:34 ` Brendan Jackman
2016-08-16 8:34 ` Brendan Jackman
2016-08-16 8:41 ` Brendan Jackman
2016-08-16 8:41 ` Brendan Jackman
2016-08-16 9:19 ` Sudeep Holla
2016-08-16 9:19 ` Sudeep Holla
2016-08-12 12:35 ` Brendan Jackman
2016-08-12 12:35 ` Brendan Jackman
2016-08-15 16:06 ` Lina Iyer
2016-08-15 16:06 ` Lina Iyer
2016-08-19 18:10 ` Kevin Hilman
2016-08-19 18:10 ` Kevin Hilman
2016-08-24 14:07 ` Sudeep Holla
2016-08-24 14:07 ` Sudeep Holla
[not found] ` <1470351902-43103-3-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-24 13:48 ` [RFC 0/6] Illustration of using domain-idle-states for CPU " Brendan Jackman
2016-08-24 13:48 ` [RFC 1/6] cpuidle: Rename cpuidle_get_{cpu->dev}_driver Brendan Jackman
2016-08-24 13:48 ` [RFC 2/6] cpuidle: Add public funcion to get driver from CPU index Brendan Jackman
[not found] ` <20160824134822.3591-1-brendan.jackman-5wv7dgnIgG8@public.gmane.org>
2016-08-24 13:48 ` [RFC 3/6] cpuidle: Add device_node pointer in cpuidle_state Brendan Jackman
2016-08-24 13:48 ` [RFC 6/6] arm64: dts: Add domain-idle-states for Juno r0 power domains Brendan Jackman
2016-08-24 13:48 ` [RFC 4/6] cpuidle: dt: Add support for reading states from " Brendan Jackman
2016-08-24 13:48 ` [RFC 5/6] arm64: dts: Add Juno r0 CPU power domain tree Brendan Jackman
2016-08-04 23:04 ` [PATCH v3 03/15] PM / Domains: Abstract genpd locking Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 04/15] PM / Domains: Support IRQ safe PM domains Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 05/15] PM / doc: Update device documentation for devices in " Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 06/15] PM / cpu_domains: Setup PM domains for CPUs/clusters Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 07/15] ARM: cpuidle: Add runtime PM support for CPUs Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 08/15] timer: Export next wake up of a CPU Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 09/15] PM / cpu_domains: Add PM Domain governor for CPUs Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 10/15] doc / cpu_domains: Describe CPU PM domains setup and governor Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 11/15] drivers: firmware: psci: Allow OS Initiated suspend mode Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:04 ` [PATCH v3 12/15] drivers: firmware: psci: Support cluster idle states for OS-Initiated Lina Iyer
2016-08-04 23:04 ` Lina Iyer
2016-08-04 23:05 ` [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings Lina Iyer
2016-08-04 23:05 ` Lina Iyer
2016-08-05 14:44 ` Lina Iyer
2016-08-05 14:44 ` Lina Iyer
2016-08-04 23:05 ` [PATCH v3 14/15] ARM64: dts: Add PSCI cpuidle support for MSM8916 Lina Iyer
2016-08-04 23:05 ` Lina Iyer
[not found] ` <1470351902-43103-1-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-08-04 23:05 ` [PATCH v3 15/15] ARM64: dts: Define CPU power domain " Lina Iyer
2016-08-04 23:05 ` Lina Iyer
2016-08-10 15:27 ` Sudeep Holla
2016-08-10 15:27 ` Sudeep Holla
2016-08-10 17:35 ` Lina Iyer
2016-08-10 17:35 ` Lina Iyer
2016-08-11 9:30 ` Sudeep Holla
2016-08-11 9:30 ` Sudeep Holla
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.