* [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-03-28 14:13 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:13 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
The current generic PM domain framework (GenDP) only allows a single
PM domain to be associated with a given device. There are several
use-cases for various system-on-chip devices where it is necessary for
a PM domain consumer to control more than one PM domain where the PM
domains:
i). Do not conform to a parent-child relationship so are not nested
ii). May not be powered on and off at the same time so need independent
control.
The solution proposed in this RFC is to allow consumers to explictly
control PM domains, by getting a handle to a PM domain and explicitly
making calls to power on and off the PM domain. Note that referencing
counting is used to ensure that a PM domain shared between consumers
is not powered off incorrectly.
The Tegra124/210 XUSB subsystem (that consists of both host and device
controllers) is an example of a consumer that needs to control more than
one PM domain because the logic is partitioned across 3 PM domains which
are:
- XUSBA: Superspeed logic (for USB 3.0)
- XUSBB: Device controller
- XUSBC: Host controller
These power domains are not nested and can be powered-up and down
independently of one another. In practice different scenarios require
different combinations of the power domains, for example:
- Superspeed host: XUSBA and XUSBC
- Superspeed device: XUSBA and XUSBB
Although it could be possible to logically nest both the XUSBB and XUSBC
domains under the XUSBA, superspeed may not always be used/required and
so this would keep it on unnecessarily.
Given that Tegra uses device-tree for describing the hardware, it would
be ideal that the device-tree 'power-domains' property for generic PM
domains could be extended to allow more than one PM domain to be
specified. For example, define the following the Tegra210 xHCI device ...
usb@70090000 {
compatible = "nvidia,tegra210-xusb";
...
power-domains = <&pd_xusbhost>, <&pd_xusbss>;
power-domain-names = "host", "superspeed";
};
This RFC extends the generic PM domain framework to allow a device to
define more than one PM domain in the device-tree 'power-domains'
property. If there is more than one then the assumption is that these
PM domains will be controlled explicitly by the consumer and the device
will not be automatically bound to any PM domain.
This RFC is a follow-up to the following RFC but because it is a
completely different approach has not been titled V2.
https://lkml.org/lkml/2016/9/20/173
Jon Hunter (4):
PM / Domains: Prepare for supporting explicit PM domain control
PM / Domains: Add support for explicit control of PM domains
PM / Domains: Add OF helpers for getting PM domains
dt-bindings: Add support for devices with multiple PM domains
.../devicetree/bindings/power/power_domain.txt | 11 +-
drivers/base/power/domain.c | 203 ++++++++++++++++++++-
include/linux/pm_domain.h | 35 ++++
3 files changed, 246 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 59+ messages in thread
* [RFC PATCH 1/4] PM / Domains: Prepare for supporting explicit PM domain control
2017-03-28 14:13 ` Jon Hunter
@ 2017-03-28 14:14 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
The generic PM domain framework only supports consumers that require a
single PM domain. In order to extend the framework so that consumers can
explicitly control more than one PM domain, detect if the consumers
specifies more than one PM domain and if it does then don't
automatically bind the device with any of the PM domains and (leap of
faith!) assume the consumer knows what to do!
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/base/power/domain.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..0eb75954c087 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2011,6 +2011,16 @@ int genpd_dev_pm_attach(struct device *dev)
if (dev->pm_domain)
return -EEXIST;
+ /*
+ * If there are more than one PM domain defined for a device,
+ * then these need to be manually controlled by the driver
+ * that device, because the genpd core cannot bind a device
+ * with more than one PM domain.
+ */
+ if (of_count_phandle_with_args(dev->of_node, "power-domains",
+ "#power-domain-cells") > 1)
+ return 0;
+
ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
"#power-domain-cells", 0, &pd_args);
if (ret < 0) {
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [RFC PATCH 1/4] PM / Domains: Prepare for supporting explicit PM domain control
@ 2017-03-28 14:14 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
The generic PM domain framework only supports consumers that require a
single PM domain. In order to extend the framework so that consumers can
explicitly control more than one PM domain, detect if the consumers
specifies more than one PM domain and if it does then don't
automatically bind the device with any of the PM domains and (leap of
faith!) assume the consumer knows what to do!
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/base/power/domain.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..0eb75954c087 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2011,6 +2011,16 @@ int genpd_dev_pm_attach(struct device *dev)
if (dev->pm_domain)
return -EEXIST;
+ /*
+ * If there are more than one PM domain defined for a device,
+ * then these need to be manually controlled by the driver
+ * that device, because the genpd core cannot bind a device
+ * with more than one PM domain.
+ */
+ if (of_count_phandle_with_args(dev->of_node, "power-domains",
+ "#power-domain-cells") > 1)
+ return 0;
+
ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
"#power-domain-cells", 0, &pd_args);
if (ret < 0) {
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
2017-03-28 14:13 ` Jon Hunter
@ 2017-03-28 14:14 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
The current generic PM domain framework (GenDP) only allows a single
PM domain to be associated with a given device. There are several
use-cases for various system-on-chip devices where it is necessary for
a PM domain consumer to control more than one PM domain where the PM
domains:
i). Do not conform to a parent-child relationship so are not nested
ii). May not be powered on and off at the same time so need independent
control.
To support the above, add new APIs for GenPD to allow consumers to get,
power-on, power-off and put PM domains so that they can be explicitly
controlled by the consumer.
These new APIs for powering on and off the PM domains, call into the
existing internal functions, genpd_sync_power_on/off(), to power them
on and off. To ensure that PM domains that are both controlled
explicitly (via these new APIs) and implicitly (via runtime-pm
callbacks) do not conflict, the PM domain 'device_count' and
'suspended_count' counters are used to ensure the PM domain is in the
correct state.
For PM domains that are controlled explicitly, the debugfs 'summary'
node for GenPD will display an 'unknown (X)' under the 'device' column
to indicate that 'X' unknown device(s) are controlling the PM domain.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/base/power/domain.c | 123 +++++++++++++++++++++++++++++++++++++++++++-
include/linux/pm_domain.h | 18 +++++++
2 files changed, 139 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0eb75954c087..4980ec157750 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -303,6 +303,9 @@ static int genpd_power_off(struct generic_pm_domain *genpd, bool one_dev_on,
if (atomic_read(&genpd->sd_count) > 0)
return -EBUSY;
+ if (genpd->device_count > genpd->suspended_count)
+ return -EBUSY;
+
list_for_each_entry(pdd, &genpd->dev_list, list_node) {
enum pm_qos_flags_status stat;
@@ -1568,6 +1571,117 @@ int pm_genpd_remove(struct generic_pm_domain *genpd)
}
EXPORT_SYMBOL_GPL(pm_genpd_remove);
+/**
+ * pm_genpd_get - Get a generic I/O PM domain by name
+ * @name: Name of the PM domain.
+ *
+ * Look-ups a PM domain by name. If found, increment the device
+ * count for PM domain to ensure that the PM domain cannot be
+ * removed, increment the suspended count so that it can still
+ * be turned off (when not in-use) and return a pointer to its
+ * generic_pm_domain structure. If not found return ERR_PTR().
+ */
+struct generic_pm_domain *pm_genpd_get(const char *name)
+{
+ struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
+
+ if (!name)
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(&gpd_list_lock);
+ list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
+ if (!strcmp(gpd->name, name)) {
+ genpd_lock(gpd);
+ gpd->device_count++;
+ gpd->suspended_count++;
+ genpd_unlock(gpd);
+ genpd = gpd;
+ break;
+ }
+ }
+ mutex_unlock(&gpd_list_lock);
+
+ return genpd;
+}
+EXPORT_SYMBOL(pm_genpd_get);
+
+/**
+ * pm_genpd_put - Put a generic I/O PM domain
+ * @genpd: Pointer to a PM domain.
+ */
+void pm_genpd_put(struct generic_pm_domain *genpd)
+{
+ if (!genpd)
+ return;
+
+ genpd_lock(genpd);
+
+ if (WARN_ON(!genpd->device_count || !genpd->suspended_count))
+ goto out;
+
+ genpd->suspended_count--;
+ genpd->device_count--;
+
+out:
+ genpd_unlock(genpd);
+}
+EXPORT_SYMBOL(pm_genpd_put);
+
+/**
+ * pm_genpd_poweron - Power on a generic I/O PM domain
+ * @genpd: Pointer to a PM domain.
+ *
+ * Powers on a PM domain, if not already on, and decrements the
+ * 'suspended_count' to prevent the PM domain from being powered off.
+ */
+int pm_genpd_poweron(struct generic_pm_domain *genpd)
+{
+ if (!genpd)
+ return -EINVAL;
+
+ genpd_lock(genpd);
+
+ if (WARN_ON(!genpd->suspended_count))
+ goto out;
+
+ genpd->suspended_count--;
+ genpd_sync_power_on(genpd, true, 0);
+
+out:
+ genpd_unlock(genpd);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_poweron);
+
+/**
+ * pm_genpd_poweroff - Power off a generic I/O PM domain
+ * @genpd: Pointer to a PM domain.
+ *
+ * Increments the 'suspended_count' for a PM domain and if the
+ * 'suspended_count' equals the 'device_count' then will power
+ * off the PM domain.
+ */
+int pm_genpd_poweroff(struct generic_pm_domain *genpd)
+{
+ if (!genpd)
+ return -EINVAL;
+
+ genpd_lock(genpd);
+
+ if (WARN_ON(genpd->suspended_count >= genpd->device_count))
+ goto out;
+
+ genpd->suspended_count++;
+ genpd_sync_power_off(genpd, false, 0);
+
+out:
+ genpd_unlock(genpd);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_poweroff);
+
#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args *args,
@@ -2171,7 +2285,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
return 0;
}
EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
-
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
@@ -2223,7 +2336,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
const char *kobj_path;
struct gpd_link *link;
char state[16];
- int ret;
+ int ret, count;
ret = genpd_lock_interruptible(genpd);
if (ret)
@@ -2250,6 +2363,8 @@ static int pm_genpd_summary_one(struct seq_file *s,
seq_puts(s, ", ");
}
+ count = genpd->device_count;
+
list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
kobj_path = kobject_get_path(&pm_data->dev->kobj,
genpd_is_irq_safe(genpd) ?
@@ -2260,8 +2375,12 @@ static int pm_genpd_summary_one(struct seq_file *s,
seq_printf(s, "\n %-50s ", kobj_path);
rtpm_status_str(s, pm_data->dev);
kfree(kobj_path);
+ count--;
}
+ if (count > 0)
+ seq_printf(s, "\n unknown (%d)", count);
+
seq_puts(s, "\n");
exit:
genpd_unlock(genpd);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 5339ed5bd6f9..b3aa1f237d96 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -143,6 +143,10 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
extern int pm_genpd_init(struct generic_pm_domain *genpd,
struct dev_power_governor *gov, bool is_off);
extern int pm_genpd_remove(struct generic_pm_domain *genpd);
+extern struct generic_pm_domain *pm_genpd_get(const char *name);
+extern void pm_genpd_put(struct generic_pm_domain *genpd);
+extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
+extern int pm_genpd_poweroff(struct generic_pm_domain *genpd);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
@@ -182,6 +186,20 @@ static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
{
return -ENOTSUPP;
}
+static inline struct generic_pm_domain *pm_genpd_get(const char *name)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
+static inline void pm_genpd_put(struct generic_pm_domain *genpd) {}
+static inline int pm_genpd_poweron(struct generic_pm_domain *genpd)
+{
+ return -ENOTSUPP;
+}
+static inline int pm_genpd_poweroff(struct generic_pm_domain *genpd)
+{
+ return -ENOTSUPP;
+}
#define simple_qos_governor (*(struct dev_power_governor *)(NULL))
#define pm_domain_always_on_gov (*(struct dev_power_governor *)(NULL))
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-03-28 14:14 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
The current generic PM domain framework (GenDP) only allows a single
PM domain to be associated with a given device. There are several
use-cases for various system-on-chip devices where it is necessary for
a PM domain consumer to control more than one PM domain where the PM
domains:
i). Do not conform to a parent-child relationship so are not nested
ii). May not be powered on and off at the same time so need independent
control.
To support the above, add new APIs for GenPD to allow consumers to get,
power-on, power-off and put PM domains so that they can be explicitly
controlled by the consumer.
These new APIs for powering on and off the PM domains, call into the
existing internal functions, genpd_sync_power_on/off(), to power them
on and off. To ensure that PM domains that are both controlled
explicitly (via these new APIs) and implicitly (via runtime-pm
callbacks) do not conflict, the PM domain 'device_count' and
'suspended_count' counters are used to ensure the PM domain is in the
correct state.
For PM domains that are controlled explicitly, the debugfs 'summary'
node for GenPD will display an 'unknown (X)' under the 'device' column
to indicate that 'X' unknown device(s) are controlling the PM domain.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/base/power/domain.c | 123 +++++++++++++++++++++++++++++++++++++++++++-
include/linux/pm_domain.h | 18 +++++++
2 files changed, 139 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0eb75954c087..4980ec157750 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -303,6 +303,9 @@ static int genpd_power_off(struct generic_pm_domain *genpd, bool one_dev_on,
if (atomic_read(&genpd->sd_count) > 0)
return -EBUSY;
+ if (genpd->device_count > genpd->suspended_count)
+ return -EBUSY;
+
list_for_each_entry(pdd, &genpd->dev_list, list_node) {
enum pm_qos_flags_status stat;
@@ -1568,6 +1571,117 @@ int pm_genpd_remove(struct generic_pm_domain *genpd)
}
EXPORT_SYMBOL_GPL(pm_genpd_remove);
+/**
+ * pm_genpd_get - Get a generic I/O PM domain by name
+ * @name: Name of the PM domain.
+ *
+ * Look-ups a PM domain by name. If found, increment the device
+ * count for PM domain to ensure that the PM domain cannot be
+ * removed, increment the suspended count so that it can still
+ * be turned off (when not in-use) and return a pointer to its
+ * generic_pm_domain structure. If not found return ERR_PTR().
+ */
+struct generic_pm_domain *pm_genpd_get(const char *name)
+{
+ struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
+
+ if (!name)
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(&gpd_list_lock);
+ list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
+ if (!strcmp(gpd->name, name)) {
+ genpd_lock(gpd);
+ gpd->device_count++;
+ gpd->suspended_count++;
+ genpd_unlock(gpd);
+ genpd = gpd;
+ break;
+ }
+ }
+ mutex_unlock(&gpd_list_lock);
+
+ return genpd;
+}
+EXPORT_SYMBOL(pm_genpd_get);
+
+/**
+ * pm_genpd_put - Put a generic I/O PM domain
+ * @genpd: Pointer to a PM domain.
+ */
+void pm_genpd_put(struct generic_pm_domain *genpd)
+{
+ if (!genpd)
+ return;
+
+ genpd_lock(genpd);
+
+ if (WARN_ON(!genpd->device_count || !genpd->suspended_count))
+ goto out;
+
+ genpd->suspended_count--;
+ genpd->device_count--;
+
+out:
+ genpd_unlock(genpd);
+}
+EXPORT_SYMBOL(pm_genpd_put);
+
+/**
+ * pm_genpd_poweron - Power on a generic I/O PM domain
+ * @genpd: Pointer to a PM domain.
+ *
+ * Powers on a PM domain, if not already on, and decrements the
+ * 'suspended_count' to prevent the PM domain from being powered off.
+ */
+int pm_genpd_poweron(struct generic_pm_domain *genpd)
+{
+ if (!genpd)
+ return -EINVAL;
+
+ genpd_lock(genpd);
+
+ if (WARN_ON(!genpd->suspended_count))
+ goto out;
+
+ genpd->suspended_count--;
+ genpd_sync_power_on(genpd, true, 0);
+
+out:
+ genpd_unlock(genpd);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_poweron);
+
+/**
+ * pm_genpd_poweroff - Power off a generic I/O PM domain
+ * @genpd: Pointer to a PM domain.
+ *
+ * Increments the 'suspended_count' for a PM domain and if the
+ * 'suspended_count' equals the 'device_count' then will power
+ * off the PM domain.
+ */
+int pm_genpd_poweroff(struct generic_pm_domain *genpd)
+{
+ if (!genpd)
+ return -EINVAL;
+
+ genpd_lock(genpd);
+
+ if (WARN_ON(genpd->suspended_count >= genpd->device_count))
+ goto out;
+
+ genpd->suspended_count++;
+ genpd_sync_power_off(genpd, false, 0);
+
+out:
+ genpd_unlock(genpd);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_poweroff);
+
#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args *args,
@@ -2171,7 +2285,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
return 0;
}
EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
-
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
@@ -2223,7 +2336,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
const char *kobj_path;
struct gpd_link *link;
char state[16];
- int ret;
+ int ret, count;
ret = genpd_lock_interruptible(genpd);
if (ret)
@@ -2250,6 +2363,8 @@ static int pm_genpd_summary_one(struct seq_file *s,
seq_puts(s, ", ");
}
+ count = genpd->device_count;
+
list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
kobj_path = kobject_get_path(&pm_data->dev->kobj,
genpd_is_irq_safe(genpd) ?
@@ -2260,8 +2375,12 @@ static int pm_genpd_summary_one(struct seq_file *s,
seq_printf(s, "\n %-50s ", kobj_path);
rtpm_status_str(s, pm_data->dev);
kfree(kobj_path);
+ count--;
}
+ if (count > 0)
+ seq_printf(s, "\n unknown (%d)", count);
+
seq_puts(s, "\n");
exit:
genpd_unlock(genpd);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 5339ed5bd6f9..b3aa1f237d96 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -143,6 +143,10 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
extern int pm_genpd_init(struct generic_pm_domain *genpd,
struct dev_power_governor *gov, bool is_off);
extern int pm_genpd_remove(struct generic_pm_domain *genpd);
+extern struct generic_pm_domain *pm_genpd_get(const char *name);
+extern void pm_genpd_put(struct generic_pm_domain *genpd);
+extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
+extern int pm_genpd_poweroff(struct generic_pm_domain *genpd);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
@@ -182,6 +186,20 @@ static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
{
return -ENOTSUPP;
}
+static inline struct generic_pm_domain *pm_genpd_get(const char *name)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
+static inline void pm_genpd_put(struct generic_pm_domain *genpd) {}
+static inline int pm_genpd_poweron(struct generic_pm_domain *genpd)
+{
+ return -ENOTSUPP;
+}
+static inline int pm_genpd_poweroff(struct generic_pm_domain *genpd)
+{
+ return -ENOTSUPP;
+}
#define simple_qos_governor (*(struct dev_power_governor *)(NULL))
#define pm_domain_always_on_gov (*(struct dev_power_governor *)(NULL))
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
[parent not found: <1490710443-27425-3-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
2017-03-28 14:14 ` Jon Hunter
@ 2017-04-10 4:09 ` Rajendra Nayak
-1 siblings, 0 replies; 59+ messages in thread
From: Rajendra Nayak @ 2017-04-10 4:09 UTC (permalink / raw)
To: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson,
geert-Td1EMuHUCqxL1ZNQvxDV9g
Cc: stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, Marek Szyprowski,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
Hey Jon,
On 03/28/2017 07:44 PM, Jon Hunter wrote:
> The current generic PM domain framework (GenDP) only allows a single
> PM domain to be associated with a given device. There are several
> use-cases for various system-on-chip devices where it is necessary for
> a PM domain consumer to control more than one PM domain where the PM
> domains:
> i). Do not conform to a parent-child relationship so are not nested
> ii). May not be powered on and off at the same time so need independent
> control.
>
> To support the above, add new APIs for GenPD to allow consumers to get,
> power-on, power-off and put PM domains so that they can be explicitly
> controlled by the consumer.
thanks for working on this RFC.
[]..
> +/**
> + * pm_genpd_get - Get a generic I/O PM domain by name
> + * @name: Name of the PM domain.
> + *
> + * Look-ups a PM domain by name. If found, increment the device
> + * count for PM domain to ensure that the PM domain cannot be
> + * removed, increment the suspended count so that it can still
> + * be turned off (when not in-use) and return a pointer to its
> + * generic_pm_domain structure. If not found return ERR_PTR().
> + */
> +struct generic_pm_domain *pm_genpd_get(const char *name)
> +{
> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
> +
> + if (!name)
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(&gpd_list_lock);
> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
> + if (!strcmp(gpd->name, name)) {
> + genpd_lock(gpd);
> + gpd->device_count++;
There apis' should also take a device pointer as a parameter,
so we can track all the devices belonging to a powerdomain.
That would also mean keeping the genpd->dev_list updated instead of
only incrementing the device_count here.
> + gpd->suspended_count++;
> + genpd_unlock(gpd);
> + genpd = gpd;
> + break;
> + }
> + }
> + mutex_unlock(&gpd_list_lock);
> +
> + return genpd;
Instead of returning a pointer to generic_pm_domain to all
consumers (who are then free to poke around it) we should hide
all internal structures handled by the framework and only expose
some kind of a handle to all the consumers.
That would also mean having a clear split of the headers to
distinguish between what's accessible to consumers vs providers.
regards
Rajendra
> +}
> +EXPORT_SYMBOL(pm_genpd_get);
> +
> +/**
> + * pm_genpd_put - Put a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + */
> +void pm_genpd_put(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->device_count || !genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd->device_count--;
> +
> +out:
> + genpd_unlock(genpd);
> +}
> +EXPORT_SYMBOL(pm_genpd_put);
> +
> +/**
> + * pm_genpd_poweron - Power on a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Powers on a PM domain, if not already on, and decrements the
> + * 'suspended_count' to prevent the PM domain from being powered off.
> + */
> +int pm_genpd_poweron(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd_sync_power_on(genpd, true, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweron);
> +
> +/**
> + * pm_genpd_poweroff - Power off a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Increments the 'suspended_count' for a PM domain and if the
> + * 'suspended_count' equals the 'device_count' then will power
> + * off the PM domain.
> + */
> +int pm_genpd_poweroff(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(genpd->suspended_count >= genpd->device_count))
> + goto out;
> +
> + genpd->suspended_count++;
> + genpd_sync_power_off(genpd, false, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweroff);
> +
> #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
>
> typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args *args,
> @@ -2171,7 +2285,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
> -
> #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>
>
> @@ -2223,7 +2336,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
> const char *kobj_path;
> struct gpd_link *link;
> char state[16];
> - int ret;
> + int ret, count;
>
> ret = genpd_lock_interruptible(genpd);
> if (ret)
> @@ -2250,6 +2363,8 @@ static int pm_genpd_summary_one(struct seq_file *s,
> seq_puts(s, ", ");
> }
>
> + count = genpd->device_count;
> +
> list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
> kobj_path = kobject_get_path(&pm_data->dev->kobj,
> genpd_is_irq_safe(genpd) ?
> @@ -2260,8 +2375,12 @@ static int pm_genpd_summary_one(struct seq_file *s,
> seq_printf(s, "\n %-50s ", kobj_path);
> rtpm_status_str(s, pm_data->dev);
> kfree(kobj_path);
> + count--;
> }
>
> + if (count > 0)
> + seq_printf(s, "\n unknown (%d)", count);
> +
> seq_puts(s, "\n");
> exit:
> genpd_unlock(genpd);
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 5339ed5bd6f9..b3aa1f237d96 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -143,6 +143,10 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
> extern int pm_genpd_init(struct generic_pm_domain *genpd,
> struct dev_power_governor *gov, bool is_off);
> extern int pm_genpd_remove(struct generic_pm_domain *genpd);
> +extern struct generic_pm_domain *pm_genpd_get(const char *name);
> +extern void pm_genpd_put(struct generic_pm_domain *genpd);
> +extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
> +extern int pm_genpd_poweroff(struct generic_pm_domain *genpd);
>
> extern struct dev_power_governor simple_qos_governor;
> extern struct dev_power_governor pm_domain_always_on_gov;
> @@ -182,6 +186,20 @@ static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
> {
> return -ENOTSUPP;
> }
> +static inline struct generic_pm_domain *pm_genpd_get(const char *name)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> +
> +static inline void pm_genpd_put(struct generic_pm_domain *genpd) {}
> +static inline int pm_genpd_poweron(struct generic_pm_domain *genpd)
> +{
> + return -ENOTSUPP;
> +}
> +static inline int pm_genpd_poweroff(struct generic_pm_domain *genpd)
> +{
> + return -ENOTSUPP;
> +}
>
> #define simple_qos_governor (*(struct dev_power_governor *)(NULL))
> #define pm_domain_always_on_gov (*(struct dev_power_governor *)(NULL))
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-04-10 4:09 ` Rajendra Nayak
0 siblings, 0 replies; 59+ messages in thread
From: Rajendra Nayak @ 2017-04-10 4:09 UTC (permalink / raw)
To: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
Hey Jon,
On 03/28/2017 07:44 PM, Jon Hunter wrote:
> The current generic PM domain framework (GenDP) only allows a single
> PM domain to be associated with a given device. There are several
> use-cases for various system-on-chip devices where it is necessary for
> a PM domain consumer to control more than one PM domain where the PM
> domains:
> i). Do not conform to a parent-child relationship so are not nested
> ii). May not be powered on and off at the same time so need independent
> control.
>
> To support the above, add new APIs for GenPD to allow consumers to get,
> power-on, power-off and put PM domains so that they can be explicitly
> controlled by the consumer.
thanks for working on this RFC.
[]..
> +/**
> + * pm_genpd_get - Get a generic I/O PM domain by name
> + * @name: Name of the PM domain.
> + *
> + * Look-ups a PM domain by name. If found, increment the device
> + * count for PM domain to ensure that the PM domain cannot be
> + * removed, increment the suspended count so that it can still
> + * be turned off (when not in-use) and return a pointer to its
> + * generic_pm_domain structure. If not found return ERR_PTR().
> + */
> +struct generic_pm_domain *pm_genpd_get(const char *name)
> +{
> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
> +
> + if (!name)
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(&gpd_list_lock);
> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
> + if (!strcmp(gpd->name, name)) {
> + genpd_lock(gpd);
> + gpd->device_count++;
There apis' should also take a device pointer as a parameter,
so we can track all the devices belonging to a powerdomain.
That would also mean keeping the genpd->dev_list updated instead of
only incrementing the device_count here.
> + gpd->suspended_count++;
> + genpd_unlock(gpd);
> + genpd = gpd;
> + break;
> + }
> + }
> + mutex_unlock(&gpd_list_lock);
> +
> + return genpd;
Instead of returning a pointer to generic_pm_domain to all
consumers (who are then free to poke around it) we should hide
all internal structures handled by the framework and only expose
some kind of a handle to all the consumers.
That would also mean having a clear split of the headers to
distinguish between what's accessible to consumers vs providers.
regards
Rajendra
> +}
> +EXPORT_SYMBOL(pm_genpd_get);
> +
> +/**
> + * pm_genpd_put - Put a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + */
> +void pm_genpd_put(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->device_count || !genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd->device_count--;
> +
> +out:
> + genpd_unlock(genpd);
> +}
> +EXPORT_SYMBOL(pm_genpd_put);
> +
> +/**
> + * pm_genpd_poweron - Power on a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Powers on a PM domain, if not already on, and decrements the
> + * 'suspended_count' to prevent the PM domain from being powered off.
> + */
> +int pm_genpd_poweron(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(!genpd->suspended_count))
> + goto out;
> +
> + genpd->suspended_count--;
> + genpd_sync_power_on(genpd, true, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweron);
> +
> +/**
> + * pm_genpd_poweroff - Power off a generic I/O PM domain
> + * @genpd: Pointer to a PM domain.
> + *
> + * Increments the 'suspended_count' for a PM domain and if the
> + * 'suspended_count' equals the 'device_count' then will power
> + * off the PM domain.
> + */
> +int pm_genpd_poweroff(struct generic_pm_domain *genpd)
> +{
> + if (!genpd)
> + return -EINVAL;
> +
> + genpd_lock(genpd);
> +
> + if (WARN_ON(genpd->suspended_count >= genpd->device_count))
> + goto out;
> +
> + genpd->suspended_count++;
> + genpd_sync_power_off(genpd, false, 0);
> +
> +out:
> + genpd_unlock(genpd);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_poweroff);
> +
> #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
>
> typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args *args,
> @@ -2171,7 +2285,6 @@ int of_genpd_parse_idle_states(struct device_node *dn,
> return 0;
> }
> EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
> -
> #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>
>
> @@ -2223,7 +2336,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
> const char *kobj_path;
> struct gpd_link *link;
> char state[16];
> - int ret;
> + int ret, count;
>
> ret = genpd_lock_interruptible(genpd);
> if (ret)
> @@ -2250,6 +2363,8 @@ static int pm_genpd_summary_one(struct seq_file *s,
> seq_puts(s, ", ");
> }
>
> + count = genpd->device_count;
> +
> list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
> kobj_path = kobject_get_path(&pm_data->dev->kobj,
> genpd_is_irq_safe(genpd) ?
> @@ -2260,8 +2375,12 @@ static int pm_genpd_summary_one(struct seq_file *s,
> seq_printf(s, "\n %-50s ", kobj_path);
> rtpm_status_str(s, pm_data->dev);
> kfree(kobj_path);
> + count--;
> }
>
> + if (count > 0)
> + seq_printf(s, "\n unknown (%d)", count);
> +
> seq_puts(s, "\n");
> exit:
> genpd_unlock(genpd);
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 5339ed5bd6f9..b3aa1f237d96 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -143,6 +143,10 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
> extern int pm_genpd_init(struct generic_pm_domain *genpd,
> struct dev_power_governor *gov, bool is_off);
> extern int pm_genpd_remove(struct generic_pm_domain *genpd);
> +extern struct generic_pm_domain *pm_genpd_get(const char *name);
> +extern void pm_genpd_put(struct generic_pm_domain *genpd);
> +extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
> +extern int pm_genpd_poweroff(struct generic_pm_domain *genpd);
>
> extern struct dev_power_governor simple_qos_governor;
> extern struct dev_power_governor pm_domain_always_on_gov;
> @@ -182,6 +186,20 @@ static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
> {
> return -ENOTSUPP;
> }
> +static inline struct generic_pm_domain *pm_genpd_get(const char *name)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> +
> +static inline void pm_genpd_put(struct generic_pm_domain *genpd) {}
> +static inline int pm_genpd_poweron(struct generic_pm_domain *genpd)
> +{
> + return -ENOTSUPP;
> +}
> +static inline int pm_genpd_poweroff(struct generic_pm_domain *genpd)
> +{
> + return -ENOTSUPP;
> +}
>
> #define simple_qos_governor (*(struct dev_power_governor *)(NULL))
> #define pm_domain_always_on_gov (*(struct dev_power_governor *)(NULL))
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
2017-04-10 4:09 ` Rajendra Nayak
@ 2017-04-10 8:24 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-04-10 8:24 UTC (permalink / raw)
To: Rajendra Nayak, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 10/04/17 05:09, Rajendra Nayak wrote:
> Hey Jon,
>
> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>> The current generic PM domain framework (GenDP) only allows a single
>> PM domain to be associated with a given device. There are several
>> use-cases for various system-on-chip devices where it is necessary for
>> a PM domain consumer to control more than one PM domain where the PM
>> domains:
>> i). Do not conform to a parent-child relationship so are not nested
>> ii). May not be powered on and off at the same time so need independent
>> control.
>>
>> To support the above, add new APIs for GenPD to allow consumers to get,
>> power-on, power-off and put PM domains so that they can be explicitly
>> controlled by the consumer.
>
> thanks for working on this RFC.
>
> []..
>
>> +/**
>> + * pm_genpd_get - Get a generic I/O PM domain by name
>> + * @name: Name of the PM domain.
>> + *
>> + * Look-ups a PM domain by name. If found, increment the device
>> + * count for PM domain to ensure that the PM domain cannot be
>> + * removed, increment the suspended count so that it can still
>> + * be turned off (when not in-use) and return a pointer to its
>> + * generic_pm_domain structure. If not found return ERR_PTR().
>> + */
>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>> +{
>> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>> +
>> + if (!name)
>> + return ERR_PTR(-EINVAL);
>> +
>> + mutex_lock(&gpd_list_lock);
>> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>> + if (!strcmp(gpd->name, name)) {
>> + genpd_lock(gpd);
>> + gpd->device_count++;
>
> There apis' should also take a device pointer as a parameter,
> so we can track all the devices belonging to a powerdomain.
> That would also mean keeping the genpd->dev_list updated instead of
> only incrementing the device_count here.
I had contemplated that and I am happy to do that if that is what the
consensus wants. However, my only reservation about doing that was it
only allows devices to call the APIs, but maybe that is ok. I was trying
to keep it similar to the clk and regulator APIs.
>> + gpd->suspended_count++;
>> + genpd_unlock(gpd);
>> + genpd = gpd;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&gpd_list_lock);
>> +
>> + return genpd;
>
> Instead of returning a pointer to generic_pm_domain to all
> consumers (who are then free to poke around it) we should hide
> all internal structures handled by the framework and only expose
> some kind of a handle to all the consumers.
> That would also mean having a clear split of the headers to
> distinguish between what's accessible to consumers vs providers.
OK, I will take a look at that.
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-04-10 8:24 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-04-10 8:24 UTC (permalink / raw)
To: Rajendra Nayak, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 10/04/17 05:09, Rajendra Nayak wrote:
> Hey Jon,
>
> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>> The current generic PM domain framework (GenDP) only allows a single
>> PM domain to be associated with a given device. There are several
>> use-cases for various system-on-chip devices where it is necessary for
>> a PM domain consumer to control more than one PM domain where the PM
>> domains:
>> i). Do not conform to a parent-child relationship so are not nested
>> ii). May not be powered on and off at the same time so need independent
>> control.
>>
>> To support the above, add new APIs for GenPD to allow consumers to get,
>> power-on, power-off and put PM domains so that they can be explicitly
>> controlled by the consumer.
>
> thanks for working on this RFC.
>
> []..
>
>> +/**
>> + * pm_genpd_get - Get a generic I/O PM domain by name
>> + * @name: Name of the PM domain.
>> + *
>> + * Look-ups a PM domain by name. If found, increment the device
>> + * count for PM domain to ensure that the PM domain cannot be
>> + * removed, increment the suspended count so that it can still
>> + * be turned off (when not in-use) and return a pointer to its
>> + * generic_pm_domain structure. If not found return ERR_PTR().
>> + */
>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>> +{
>> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>> +
>> + if (!name)
>> + return ERR_PTR(-EINVAL);
>> +
>> + mutex_lock(&gpd_list_lock);
>> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>> + if (!strcmp(gpd->name, name)) {
>> + genpd_lock(gpd);
>> + gpd->device_count++;
>
> There apis' should also take a device pointer as a parameter,
> so we can track all the devices belonging to a powerdomain.
> That would also mean keeping the genpd->dev_list updated instead of
> only incrementing the device_count here.
I had contemplated that and I am happy to do that if that is what the
consensus wants. However, my only reservation about doing that was it
only allows devices to call the APIs, but maybe that is ok. I was trying
to keep it similar to the clk and regulator APIs.
>> + gpd->suspended_count++;
>> + genpd_unlock(gpd);
>> + genpd = gpd;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&gpd_list_lock);
>> +
>> + return genpd;
>
> Instead of returning a pointer to generic_pm_domain to all
> consumers (who are then free to poke around it) we should hide
> all internal structures handled by the framework and only expose
> some kind of a handle to all the consumers.
> That would also mean having a clear split of the headers to
> distinguish between what's accessible to consumers vs providers.
OK, I will take a look at that.
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
[parent not found: <3135e238-48a3-3693-bb59-63bf2a6d8d0e-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
2017-04-10 8:24 ` Jon Hunter
@ 2017-04-10 10:02 ` Rajendra Nayak
-1 siblings, 0 replies; 59+ messages in thread
From: Rajendra Nayak @ 2017-04-10 10:02 UTC (permalink / raw)
To: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson,
geert-Td1EMuHUCqxL1ZNQvxDV9g
Cc: stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, Marek Szyprowski,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
On 04/10/2017 01:54 PM, Jon Hunter wrote:
>
> On 10/04/17 05:09, Rajendra Nayak wrote:
>> Hey Jon,
>>
>> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>>> The current generic PM domain framework (GenDP) only allows a single
>>> PM domain to be associated with a given device. There are several
>>> use-cases for various system-on-chip devices where it is necessary for
>>> a PM domain consumer to control more than one PM domain where the PM
>>> domains:
>>> i). Do not conform to a parent-child relationship so are not nested
>>> ii). May not be powered on and off at the same time so need independent
>>> control.
>>>
>>> To support the above, add new APIs for GenPD to allow consumers to get,
>>> power-on, power-off and put PM domains so that they can be explicitly
>>> controlled by the consumer.
>>
>> thanks for working on this RFC.
>>
>> []..
>>
>>> +/**
>>> + * pm_genpd_get - Get a generic I/O PM domain by name
>>> + * @name: Name of the PM domain.
>>> + *
>>> + * Look-ups a PM domain by name. If found, increment the device
>>> + * count for PM domain to ensure that the PM domain cannot be
>>> + * removed, increment the suspended count so that it can still
>>> + * be turned off (when not in-use) and return a pointer to its
>>> + * generic_pm_domain structure. If not found return ERR_PTR().
>>> + */
>>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>>> +{
>>> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>>> +
>>> + if (!name)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + mutex_lock(&gpd_list_lock);
>>> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>>> + if (!strcmp(gpd->name, name)) {
Also looking up the powerdomain this way means the consumers need
to know the _exact_ name with which the providers have registered
the powerdomains?
>>> + genpd_lock(gpd);
>>> + gpd->device_count++;
>>
>> There apis' should also take a device pointer as a parameter,
>> so we can track all the devices belonging to a powerdomain.
>> That would also mean keeping the genpd->dev_list updated instead of
>> only incrementing the device_count here.
>
> I had contemplated that and I am happy to do that if that is what the
> consensus wants. However, my only reservation about doing that was it
> only allows devices to call the APIs, but maybe that is ok. I was trying
> to keep it similar to the clk and regulator APIs.
>
>>> + gpd->suspended_count++;
>>> + genpd_unlock(gpd);
>>> + genpd = gpd;
>>> + break;
>>> + }
>>> + }
>>> + mutex_unlock(&gpd_list_lock);
>>> +
>>> + return genpd;
>>
>> Instead of returning a pointer to generic_pm_domain to all
>> consumers (who are then free to poke around it) we should hide
>> all internal structures handled by the framework and only expose
>> some kind of a handle to all the consumers.
>> That would also mean having a clear split of the headers to
>> distinguish between what's accessible to consumers vs providers.
>
> OK, I will take a look at that.
>
> Cheers
> Jon
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-04-10 10:02 ` Rajendra Nayak
0 siblings, 0 replies; 59+ messages in thread
From: Rajendra Nayak @ 2017-04-10 10:02 UTC (permalink / raw)
To: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 04/10/2017 01:54 PM, Jon Hunter wrote:
>
> On 10/04/17 05:09, Rajendra Nayak wrote:
>> Hey Jon,
>>
>> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>>> The current generic PM domain framework (GenDP) only allows a single
>>> PM domain to be associated with a given device. There are several
>>> use-cases for various system-on-chip devices where it is necessary for
>>> a PM domain consumer to control more than one PM domain where the PM
>>> domains:
>>> i). Do not conform to a parent-child relationship so are not nested
>>> ii). May not be powered on and off at the same time so need independent
>>> control.
>>>
>>> To support the above, add new APIs for GenPD to allow consumers to get,
>>> power-on, power-off and put PM domains so that they can be explicitly
>>> controlled by the consumer.
>>
>> thanks for working on this RFC.
>>
>> []..
>>
>>> +/**
>>> + * pm_genpd_get - Get a generic I/O PM domain by name
>>> + * @name: Name of the PM domain.
>>> + *
>>> + * Look-ups a PM domain by name. If found, increment the device
>>> + * count for PM domain to ensure that the PM domain cannot be
>>> + * removed, increment the suspended count so that it can still
>>> + * be turned off (when not in-use) and return a pointer to its
>>> + * generic_pm_domain structure. If not found return ERR_PTR().
>>> + */
>>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>>> +{
>>> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>>> +
>>> + if (!name)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + mutex_lock(&gpd_list_lock);
>>> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>>> + if (!strcmp(gpd->name, name)) {
Also looking up the powerdomain this way means the consumers need
to know the _exact_ name with which the providers have registered
the powerdomains?
>>> + genpd_lock(gpd);
>>> + gpd->device_count++;
>>
>> There apis' should also take a device pointer as a parameter,
>> so we can track all the devices belonging to a powerdomain.
>> That would also mean keeping the genpd->dev_list updated instead of
>> only incrementing the device_count here.
>
> I had contemplated that and I am happy to do that if that is what the
> consensus wants. However, my only reservation about doing that was it
> only allows devices to call the APIs, but maybe that is ok. I was trying
> to keep it similar to the clk and regulator APIs.
>
>>> + gpd->suspended_count++;
>>> + genpd_unlock(gpd);
>>> + genpd = gpd;
>>> + break;
>>> + }
>>> + }
>>> + mutex_unlock(&gpd_list_lock);
>>> +
>>> + return genpd;
>>
>> Instead of returning a pointer to generic_pm_domain to all
>> consumers (who are then free to poke around it) we should hide
>> all internal structures handled by the framework and only expose
>> some kind of a handle to all the consumers.
>> That would also mean having a clear split of the headers to
>> distinguish between what's accessible to consumers vs providers.
>
> OK, I will take a look at that.
>
> Cheers
> Jon
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
2017-04-10 10:02 ` Rajendra Nayak
@ 2017-04-10 19:48 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-04-10 19:48 UTC (permalink / raw)
To: Rajendra Nayak, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 10/04/17 11:02, Rajendra Nayak wrote:
>
>
> On 04/10/2017 01:54 PM, Jon Hunter wrote:
>>
>> On 10/04/17 05:09, Rajendra Nayak wrote:
>>> Hey Jon,
>>>
>>> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>>>> The current generic PM domain framework (GenDP) only allows a single
>>>> PM domain to be associated with a given device. There are several
>>>> use-cases for various system-on-chip devices where it is necessary for
>>>> a PM domain consumer to control more than one PM domain where the PM
>>>> domains:
>>>> i). Do not conform to a parent-child relationship so are not nested
>>>> ii). May not be powered on and off at the same time so need independent
>>>> control.
>>>>
>>>> To support the above, add new APIs for GenPD to allow consumers to get,
>>>> power-on, power-off and put PM domains so that they can be explicitly
>>>> controlled by the consumer.
>>>
>>> thanks for working on this RFC.
>>>
>>> []..
>>>
>>>> +/**
>>>> + * pm_genpd_get - Get a generic I/O PM domain by name
>>>> + * @name: Name of the PM domain.
>>>> + *
>>>> + * Look-ups a PM domain by name. If found, increment the device
>>>> + * count for PM domain to ensure that the PM domain cannot be
>>>> + * removed, increment the suspended count so that it can still
>>>> + * be turned off (when not in-use) and return a pointer to its
>>>> + * generic_pm_domain structure. If not found return ERR_PTR().
>>>> + */
>>>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>>>> +{
>>>> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>>>> +
>>>> + if (!name)
>>>> + return ERR_PTR(-EINVAL);
>>>> +
>>>> + mutex_lock(&gpd_list_lock);
>>>> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>>>> + if (!strcmp(gpd->name, name)) {
>
> Also looking up the powerdomain this way means the consumers need
> to know the _exact_ name with which the providers have registered
> the powerdomains?
Yes, this provides a means for someone not using DT to lookup a PM
domain. How else would you do it?
Patch 3/4 allows you to use DT instead, which I imagine anyone using DT
would use.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 2/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-04-10 19:48 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-04-10 19:48 UTC (permalink / raw)
To: Rajendra Nayak, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 10/04/17 11:02, Rajendra Nayak wrote:
>
>
> On 04/10/2017 01:54 PM, Jon Hunter wrote:
>>
>> On 10/04/17 05:09, Rajendra Nayak wrote:
>>> Hey Jon,
>>>
>>> On 03/28/2017 07:44 PM, Jon Hunter wrote:
>>>> The current generic PM domain framework (GenDP) only allows a single
>>>> PM domain to be associated with a given device. There are several
>>>> use-cases for various system-on-chip devices where it is necessary for
>>>> a PM domain consumer to control more than one PM domain where the PM
>>>> domains:
>>>> i). Do not conform to a parent-child relationship so are not nested
>>>> ii). May not be powered on and off at the same time so need independent
>>>> control.
>>>>
>>>> To support the above, add new APIs for GenPD to allow consumers to get,
>>>> power-on, power-off and put PM domains so that they can be explicitly
>>>> controlled by the consumer.
>>>
>>> thanks for working on this RFC.
>>>
>>> []..
>>>
>>>> +/**
>>>> + * pm_genpd_get - Get a generic I/O PM domain by name
>>>> + * @name: Name of the PM domain.
>>>> + *
>>>> + * Look-ups a PM domain by name. If found, increment the device
>>>> + * count for PM domain to ensure that the PM domain cannot be
>>>> + * removed, increment the suspended count so that it can still
>>>> + * be turned off (when not in-use) and return a pointer to its
>>>> + * generic_pm_domain structure. If not found return ERR_PTR().
>>>> + */
>>>> +struct generic_pm_domain *pm_genpd_get(const char *name)
>>>> +{
>>>> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-EEXIST);
>>>> +
>>>> + if (!name)
>>>> + return ERR_PTR(-EINVAL);
>>>> +
>>>> + mutex_lock(&gpd_list_lock);
>>>> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
>>>> + if (!strcmp(gpd->name, name)) {
>
> Also looking up the powerdomain this way means the consumers need
> to know the _exact_ name with which the providers have registered
> the powerdomains?
Yes, this provides a means for someone not using DT to lookup a PM
domain. How else would you do it?
Patch 3/4 allows you to use DT instead, which I imagine anyone using DT
would use.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
* [RFC PATCH 3/4] PM / Domains: Add OF helpers for getting PM domains
2017-03-28 14:13 ` Jon Hunter
@ 2017-03-28 14:14 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
Add helper functions for getting PM domains via device-tree that are to
be controlled explicitly via the pm_genpd_poweron/off() APIs. PM domains
can be retrieved by either index or name. Retrieving a PM domain by name
requires that the 'power-domain-names' property is present for the
consumer.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/base/power/domain.c | 72 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 17 +++++++++++
2 files changed, 89 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4980ec157750..77516b2b3e58 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2285,6 +2285,78 @@ int of_genpd_parse_idle_states(struct device_node *dn,
return 0;
}
EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
+
+static struct generic_pm_domain *genpd_get(struct device_node *np, int index)
+{
+ struct of_phandle_args genpdspec;
+ struct generic_pm_domain *genpd;
+ int ret;
+
+ if (index < 0)
+ return ERR_PTR(-EINVAL);
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", index,
+ &genpdspec);
+ if (ret)
+ return ERR_PTR(ret);
+
+ mutex_lock(&gpd_list_lock);
+
+ genpd = genpd_get_from_provider(&genpdspec);
+ of_node_put(genpdspec.np);
+
+ if (!IS_ERR(genpd)) {
+ genpd_lock(genpd);
+ genpd->device_count++;
+ genpd->suspended_count++;
+ genpd_unlock(genpd);
+ }
+
+ mutex_unlock(&gpd_list_lock);
+
+ return genpd;
+}
+
+/**
+ * of_genpd_get() - Get a PM domain by index using a device node
+ * @np: pointer to PM domain consumer node
+ * @index: index reference for a PM domain in the consumer node
+ *
+ * This function parses the 'power-domains' property using the index
+ * provided to look up a PM domain from the registered list of PM domain
+ * providers.
+ */
+struct generic_pm_domain *of_genpd_get(struct device_node *np, int index)
+{
+ return genpd_get(np, index);
+}
+EXPORT_SYMBOL(of_genpd_get);
+
+/**
+ * of_genpd_get_by_name() - Get a PM domain by name using a device node
+ * @np: pointer to PM domain consumer node
+ * @name: name reference for a PM domain in the consumer node
+ *
+ * This function parses the 'power-domains' and 'power-domain-names'
+ * properties, and uses them to look up a PM domain from the registered
+ * list of PM domain providers.
+ */
+struct generic_pm_domain *of_genpd_get_by_name(struct device_node *np,
+ const char *name)
+{
+ int index;
+
+ if (!np || !name)
+ return ERR_PTR(-EINVAL);
+
+ index = of_property_match_string(np, "power-domain-names", name);
+ if (index < 0)
+ return ERR_PTR(index);
+
+ return genpd_get(np, index);
+}
+EXPORT_SYMBOL(of_genpd_get_by_name);
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index b3aa1f237d96..d0183d96a1b3 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -240,6 +240,10 @@ extern int of_genpd_add_subdomain(struct of_phandle_args *parent,
extern struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
extern int of_genpd_parse_idle_states(struct device_node *dn,
struct genpd_power_state **states, int *n);
+extern struct generic_pm_domain *of_genpd_get(struct device_node *np,
+ int index);
+extern struct generic_pm_domain *of_genpd_get_by_name(struct device_node *np,
+ const char *name);
int genpd_dev_pm_attach(struct device *dev);
#else /* !CONFIG_PM_GENERIC_DOMAINS_OF */
@@ -285,6 +289,19 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
{
return ERR_PTR(-ENOTSUPP);
}
+
+static inline
+struct generic_pm_domain *of_genpd_get(struct device_node *np, int index)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
+static inline
+struct generic_pm_domain *of_genpd_get_by_name(struct device_node *np,
+ const char *name)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
#ifdef CONFIG_PM
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [RFC PATCH 3/4] PM / Domains: Add OF helpers for getting PM domains
@ 2017-03-28 14:14 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
Add helper functions for getting PM domains via device-tree that are to
be controlled explicitly via the pm_genpd_poweron/off() APIs. PM domains
can be retrieved by either index or name. Retrieving a PM domain by name
requires that the 'power-domain-names' property is present for the
consumer.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/base/power/domain.c | 72 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 17 +++++++++++
2 files changed, 89 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4980ec157750..77516b2b3e58 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2285,6 +2285,78 @@ int of_genpd_parse_idle_states(struct device_node *dn,
return 0;
}
EXPORT_SYMBOL_GPL(of_genpd_parse_idle_states);
+
+static struct generic_pm_domain *genpd_get(struct device_node *np, int index)
+{
+ struct of_phandle_args genpdspec;
+ struct generic_pm_domain *genpd;
+ int ret;
+
+ if (index < 0)
+ return ERR_PTR(-EINVAL);
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", index,
+ &genpdspec);
+ if (ret)
+ return ERR_PTR(ret);
+
+ mutex_lock(&gpd_list_lock);
+
+ genpd = genpd_get_from_provider(&genpdspec);
+ of_node_put(genpdspec.np);
+
+ if (!IS_ERR(genpd)) {
+ genpd_lock(genpd);
+ genpd->device_count++;
+ genpd->suspended_count++;
+ genpd_unlock(genpd);
+ }
+
+ mutex_unlock(&gpd_list_lock);
+
+ return genpd;
+}
+
+/**
+ * of_genpd_get() - Get a PM domain by index using a device node
+ * @np: pointer to PM domain consumer node
+ * @index: index reference for a PM domain in the consumer node
+ *
+ * This function parses the 'power-domains' property using the index
+ * provided to look up a PM domain from the registered list of PM domain
+ * providers.
+ */
+struct generic_pm_domain *of_genpd_get(struct device_node *np, int index)
+{
+ return genpd_get(np, index);
+}
+EXPORT_SYMBOL(of_genpd_get);
+
+/**
+ * of_genpd_get_by_name() - Get a PM domain by name using a device node
+ * @np: pointer to PM domain consumer node
+ * @name: name reference for a PM domain in the consumer node
+ *
+ * This function parses the 'power-domains' and 'power-domain-names'
+ * properties, and uses them to look up a PM domain from the registered
+ * list of PM domain providers.
+ */
+struct generic_pm_domain *of_genpd_get_by_name(struct device_node *np,
+ const char *name)
+{
+ int index;
+
+ if (!np || !name)
+ return ERR_PTR(-EINVAL);
+
+ index = of_property_match_string(np, "power-domain-names", name);
+ if (index < 0)
+ return ERR_PTR(index);
+
+ return genpd_get(np, index);
+}
+EXPORT_SYMBOL(of_genpd_get_by_name);
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index b3aa1f237d96..d0183d96a1b3 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -240,6 +240,10 @@ extern int of_genpd_add_subdomain(struct of_phandle_args *parent,
extern struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
extern int of_genpd_parse_idle_states(struct device_node *dn,
struct genpd_power_state **states, int *n);
+extern struct generic_pm_domain *of_genpd_get(struct device_node *np,
+ int index);
+extern struct generic_pm_domain *of_genpd_get_by_name(struct device_node *np,
+ const char *name);
int genpd_dev_pm_attach(struct device *dev);
#else /* !CONFIG_PM_GENERIC_DOMAINS_OF */
@@ -285,6 +289,19 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
{
return ERR_PTR(-ENOTSUPP);
}
+
+static inline
+struct generic_pm_domain *of_genpd_get(struct device_node *np, int index)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
+static inline
+struct generic_pm_domain *of_genpd_get_by_name(struct device_node *np,
+ const char *name)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
#ifdef CONFIG_PM
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
[parent not found: <1490710443-27425-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple PM domains
2017-03-28 14:13 ` Jon Hunter
@ 2017-03-28 14:14 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson,
geert-Td1EMuHUCqxL1ZNQvxDV9g, rnayak-sgV2jX0FEOL9JmXXK+q4OQ
Cc: stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, Marek Szyprowski,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Jon Hunter
Now that the generic PM domain framework supports consumers that can
control multiple PM domains, update the device-tree binding for generic
PM domains to state that one or more PM domain is permitted for a
device.
Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/power/power_domain.txt | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 723e1ad937da..fb28d37f9e1f 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -20,8 +20,15 @@ Required properties:
as specified by device tree binding documentation of particular provider.
Optional properties:
- - power-domains : A phandle and PM domain specifier as defined by bindings of
- the power controller specified by phandle.
+ - power-domains : An array of one or more PM domain specifiers (defined by the
+ bindings of the PM domain provider) for each PM domain that
+ is required by the device.
+ - power-domain-names: A list of strings of PM domain names. The list must have
+ a name for each PM domain specifier in the
+ 'power-domains' property and these names must be unique
+ within the context of this property. The names must be
+ indexed so that the first name corresponds to the first
+ PM domain specifier and so on.
Some power domains might be powered from another power domain (or have
other hardware specific dependencies). For representing such dependency
a standard PM domain consumer binding is used. When provided, all domains
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
* [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple PM domains
@ 2017-03-28 14:14 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-03-28 14:14 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra, Jon Hunter
Now that the generic PM domain framework supports consumers that can
control multiple PM domains, update the device-tree binding for generic
PM domains to state that one or more PM domain is permitted for a
device.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
Documentation/devicetree/bindings/power/power_domain.txt | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 723e1ad937da..fb28d37f9e1f 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -20,8 +20,15 @@ Required properties:
as specified by device tree binding documentation of particular provider.
Optional properties:
- - power-domains : A phandle and PM domain specifier as defined by bindings of
- the power controller specified by phandle.
+ - power-domains : An array of one or more PM domain specifiers (defined by the
+ bindings of the PM domain provider) for each PM domain that
+ is required by the device.
+ - power-domain-names: A list of strings of PM domain names. The list must have
+ a name for each PM domain specifier in the
+ 'power-domains' property and these names must be unique
+ within the context of this property. The names must be
+ indexed so that the first name corresponds to the first
+ PM domain specifier and so on.
Some power domains might be powered from another power domain (or have
other hardware specific dependencies). For representing such dependency
a standard PM domain consumer binding is used. When provided, all domains
--
2.7.4
^ permalink raw reply related [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 4/4] dt-bindings: Add support for devices with multiple PM domains
2017-03-28 14:14 ` Jon Hunter
(?)
@ 2017-04-10 4:12 ` Rajendra Nayak
[not found] ` <3f96256d-0de5-26a2-e656-7912e06806ea-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
-1 siblings, 1 reply; 59+ messages in thread
From: Rajendra Nayak @ 2017-04-10 4:12 UTC (permalink / raw)
To: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 03/28/2017 07:44 PM, Jon Hunter wrote:
> Now that the generic PM domain framework supports consumers that can
> control multiple PM domains, update the device-tree binding for generic
> PM domains to state that one or more PM domain is permitted for a
> device.
>
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> Documentation/devicetree/bindings/power/power_domain.txt | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 723e1ad937da..fb28d37f9e1f 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -20,8 +20,15 @@ Required properties:
> as specified by device tree binding documentation of particular provider.
>
> Optional properties:
> - - power-domains : A phandle and PM domain specifier as defined by bindings of
> - the power controller specified by phandle.
> + - power-domains : An array of one or more PM domain specifiers (defined by the
> + bindings of the PM domain provider) for each PM domain that
> + is required by the device.
> + - power-domain-names: A list of strings of PM domain names. The list must have
> + a name for each PM domain specifier in the
> + 'power-domains' property and these names must be unique
> + within the context of this property. The names must be
> + indexed so that the first name corresponds to the first
> + PM domain specifier and so on.
These bindings are for power-domain providers. We also need to update the bindings
for the consumers (look further down in the same file)
> Some power domains might be powered from another power domain (or have
> other hardware specific dependencies). For representing such dependency
> a standard PM domain consumer binding is used. When provided, all domains
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-03-28 14:13 ` Jon Hunter
@ 2017-04-25 11:13 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-04-25 11:13 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson,
geert-Td1EMuHUCqxL1ZNQvxDV9g, rnayak-sgV2jX0FEOL9JmXXK+q4OQ
Cc: stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, Marek Szyprowski,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
On 28/03/17 15:13, Jon Hunter wrote:
> The current generic PM domain framework (GenDP) only allows a single
> PM domain to be associated with a given device. There are several
> use-cases for various system-on-chip devices where it is necessary for
> a PM domain consumer to control more than one PM domain where the PM
> domains:
> i). Do not conform to a parent-child relationship so are not nested
> ii). May not be powered on and off at the same time so need independent
> control.
>
> The solution proposed in this RFC is to allow consumers to explictly
> control PM domains, by getting a handle to a PM domain and explicitly
> making calls to power on and off the PM domain. Note that referencing
> counting is used to ensure that a PM domain shared between consumers
> is not powered off incorrectly.
>
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) is an example of a consumer that needs to control more than
> one PM domain because the logic is partitioned across 3 PM domains which
> are:
> - XUSBA: Superspeed logic (for USB 3.0)
> - XUSBB: Device controller
> - XUSBC: Host controller
>
> These power domains are not nested and can be powered-up and down
> independently of one another. In practice different scenarios require
> different combinations of the power domains, for example:
> - Superspeed host: XUSBA and XUSBC
> - Superspeed device: XUSBA and XUSBB
>
> Although it could be possible to logically nest both the XUSBB and XUSBC
> domains under the XUSBA, superspeed may not always be used/required and
> so this would keep it on unnecessarily.
>
> Given that Tegra uses device-tree for describing the hardware, it would
> be ideal that the device-tree 'power-domains' property for generic PM
> domains could be extended to allow more than one PM domain to be
> specified. For example, define the following the Tegra210 xHCI device ...
>
> usb@70090000 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
> power-domain-names = "host", "superspeed";
> };
>
> This RFC extends the generic PM domain framework to allow a device to
> define more than one PM domain in the device-tree 'power-domains'
> property. If there is more than one then the assumption is that these
> PM domains will be controlled explicitly by the consumer and the device
> will not be automatically bound to any PM domain.
Any more comments/inputs on this? I can address Rajendra's feedback, but
before I did I wanted to see if this is along the right lines or not?
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-04-25 11:13 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-04-25 11:13 UTC (permalink / raw)
To: Rafael J . Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak
Cc: stanimir.varbanov, sboyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 28/03/17 15:13, Jon Hunter wrote:
> The current generic PM domain framework (GenDP) only allows a single
> PM domain to be associated with a given device. There are several
> use-cases for various system-on-chip devices where it is necessary for
> a PM domain consumer to control more than one PM domain where the PM
> domains:
> i). Do not conform to a parent-child relationship so are not nested
> ii). May not be powered on and off at the same time so need independent
> control.
>
> The solution proposed in this RFC is to allow consumers to explictly
> control PM domains, by getting a handle to a PM domain and explicitly
> making calls to power on and off the PM domain. Note that referencing
> counting is used to ensure that a PM domain shared between consumers
> is not powered off incorrectly.
>
> The Tegra124/210 XUSB subsystem (that consists of both host and device
> controllers) is an example of a consumer that needs to control more than
> one PM domain because the logic is partitioned across 3 PM domains which
> are:
> - XUSBA: Superspeed logic (for USB 3.0)
> - XUSBB: Device controller
> - XUSBC: Host controller
>
> These power domains are not nested and can be powered-up and down
> independently of one another. In practice different scenarios require
> different combinations of the power domains, for example:
> - Superspeed host: XUSBA and XUSBC
> - Superspeed device: XUSBA and XUSBB
>
> Although it could be possible to logically nest both the XUSBB and XUSBC
> domains under the XUSBA, superspeed may not always be used/required and
> so this would keep it on unnecessarily.
>
> Given that Tegra uses device-tree for describing the hardware, it would
> be ideal that the device-tree 'power-domains' property for generic PM
> domains could be extended to allow more than one PM domain to be
> specified. For example, define the following the Tegra210 xHCI device ...
>
> usb@70090000 {
> compatible = "nvidia,tegra210-xusb";
> ...
> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
> power-domain-names = "host", "superspeed";
> };
>
> This RFC extends the generic PM domain framework to allow a device to
> define more than one PM domain in the device-tree 'power-domains'
> property. If there is more than one then the assumption is that these
> PM domains will be controlled explicitly by the consumer and the device
> will not be automatically bound to any PM domain.
Any more comments/inputs on this? I can address Rajendra's feedback, but
before I did I wanted to see if this is along the right lines or not?
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
[parent not found: <d2e3ceaa-57e2-033d-ecd1-a3b2bd8ffa26-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-04-25 11:13 ` Jon Hunter
@ 2017-04-25 19:34 ` Ulf Hansson
-1 siblings, 0 replies; 59+ messages in thread
From: Ulf Hansson @ 2017-04-25 19:34 UTC (permalink / raw)
To: Jon Hunter, Rafael J . Wysocki
Cc: Kevin Hilman, Geert Uytterhoeven, Rajendra Nayak,
Stanimir Varbanov, Stephen Boyd, Marek Szyprowski,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
On 25 April 2017 at 13:13, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>
> On 28/03/17 15:13, Jon Hunter wrote:
>> The current generic PM domain framework (GenDP) only allows a single
>> PM domain to be associated with a given device. There are several
>> use-cases for various system-on-chip devices where it is necessary for
>> a PM domain consumer to control more than one PM domain where the PM
>> domains:
>> i). Do not conform to a parent-child relationship so are not nested
>> ii). May not be powered on and off at the same time so need independent
>> control.
>>
>> The solution proposed in this RFC is to allow consumers to explictly
>> control PM domains, by getting a handle to a PM domain and explicitly
>> making calls to power on and off the PM domain. Note that referencing
>> counting is used to ensure that a PM domain shared between consumers
>> is not powered off incorrectly.
>>
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) is an example of a consumer that needs to control more than
>> one PM domain because the logic is partitioned across 3 PM domains which
>> are:
>> - XUSBA: Superspeed logic (for USB 3.0)
>> - XUSBB: Device controller
>> - XUSBC: Host controller
>>
>> These power domains are not nested and can be powered-up and down
>> independently of one another. In practice different scenarios require
>> different combinations of the power domains, for example:
>> - Superspeed host: XUSBA and XUSBC
>> - Superspeed device: XUSBA and XUSBB
>>
>> Although it could be possible to logically nest both the XUSBB and XUSBC
>> domains under the XUSBA, superspeed may not always be used/required and
>> so this would keep it on unnecessarily.
>>
>> Given that Tegra uses device-tree for describing the hardware, it would
>> be ideal that the device-tree 'power-domains' property for generic PM
>> domains could be extended to allow more than one PM domain to be
>> specified. For example, define the following the Tegra210 xHCI device ...
>>
>> usb@70090000 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>> power-domain-names = "host", "superspeed";
>> };
>>
>> This RFC extends the generic PM domain framework to allow a device to
>> define more than one PM domain in the device-tree 'power-domains'
>> property. If there is more than one then the assumption is that these
>> PM domains will be controlled explicitly by the consumer and the device
>> will not be automatically bound to any PM domain.
>
> Any more comments/inputs on this? I can address Rajendra's feedback, but
> before I did I wanted to see if this is along the right lines or not?
I discussed this with Rafael at the OSPM summit in Pisa a couple of
weeks ago. Apologize for the delay in providing additional feedback.
First, whether the problem is really rare, perhaps adding a new
API/framework can't be justified - then it may be better to add some
kind of aggregation layer on top of the current PM domain
infrastructure (something along the first attempt you made for genpd).
That was kind of Rafael's thoughts (Rafael, please correct me if I am
wrong).
However, we currently know about at least two different SoCs that need
this. Perhaps we can extend the below list to justify adding a new
framework/APIs. Something along the lines what you propose in $subject
patchset.
1) Nvidia; to solve the USB super-speed host/device problem.
2) QCOM, which has pointed to several cases where the PM topology is
laid out like devices having two PM domains..
3?) I don't fully remember - but I think Geert also pointed to some
examples where a device could reside in a clock domain but also in
power domain for a Renesas SoC!?
4) ?
Moreover, perhaps this could also be useful for SoCs using ACPI? If
so, we shouldn't tie this immediately to genpd, but in the layer above
genpd/ACPI PM domain. Something like dev_pm_domain_get(), which would
be implemented similar as the dev_pm_domain_attach() (which calls both
the ACPI PM domain and genpd to find a match).
Kind regards
Uffe
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-04-25 19:34 ` Ulf Hansson
0 siblings, 0 replies; 59+ messages in thread
From: Ulf Hansson @ 2017-04-25 19:34 UTC (permalink / raw)
To: Jon Hunter, Rafael J . Wysocki
Cc: Kevin Hilman, Geert Uytterhoeven, Rajendra Nayak,
Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
On 25 April 2017 at 13:13, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 28/03/17 15:13, Jon Hunter wrote:
>> The current generic PM domain framework (GenDP) only allows a single
>> PM domain to be associated with a given device. There are several
>> use-cases for various system-on-chip devices where it is necessary for
>> a PM domain consumer to control more than one PM domain where the PM
>> domains:
>> i). Do not conform to a parent-child relationship so are not nested
>> ii). May not be powered on and off at the same time so need independent
>> control.
>>
>> The solution proposed in this RFC is to allow consumers to explictly
>> control PM domains, by getting a handle to a PM domain and explicitly
>> making calls to power on and off the PM domain. Note that referencing
>> counting is used to ensure that a PM domain shared between consumers
>> is not powered off incorrectly.
>>
>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> controllers) is an example of a consumer that needs to control more than
>> one PM domain because the logic is partitioned across 3 PM domains which
>> are:
>> - XUSBA: Superspeed logic (for USB 3.0)
>> - XUSBB: Device controller
>> - XUSBC: Host controller
>>
>> These power domains are not nested and can be powered-up and down
>> independently of one another. In practice different scenarios require
>> different combinations of the power domains, for example:
>> - Superspeed host: XUSBA and XUSBC
>> - Superspeed device: XUSBA and XUSBB
>>
>> Although it could be possible to logically nest both the XUSBB and XUSBC
>> domains under the XUSBA, superspeed may not always be used/required and
>> so this would keep it on unnecessarily.
>>
>> Given that Tegra uses device-tree for describing the hardware, it would
>> be ideal that the device-tree 'power-domains' property for generic PM
>> domains could be extended to allow more than one PM domain to be
>> specified. For example, define the following the Tegra210 xHCI device ...
>>
>> usb@70090000 {
>> compatible = "nvidia,tegra210-xusb";
>> ...
>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>> power-domain-names = "host", "superspeed";
>> };
>>
>> This RFC extends the generic PM domain framework to allow a device to
>> define more than one PM domain in the device-tree 'power-domains'
>> property. If there is more than one then the assumption is that these
>> PM domains will be controlled explicitly by the consumer and the device
>> will not be automatically bound to any PM domain.
>
> Any more comments/inputs on this? I can address Rajendra's feedback, but
> before I did I wanted to see if this is along the right lines or not?
I discussed this with Rafael at the OSPM summit in Pisa a couple of
weeks ago. Apologize for the delay in providing additional feedback.
First, whether the problem is really rare, perhaps adding a new
API/framework can't be justified - then it may be better to add some
kind of aggregation layer on top of the current PM domain
infrastructure (something along the first attempt you made for genpd).
That was kind of Rafael's thoughts (Rafael, please correct me if I am
wrong).
However, we currently know about at least two different SoCs that need
this. Perhaps we can extend the below list to justify adding a new
framework/APIs. Something along the lines what you propose in $subject
patchset.
1) Nvidia; to solve the USB super-speed host/device problem.
2) QCOM, which has pointed to several cases where the PM topology is
laid out like devices having two PM domains..
3?) I don't fully remember - but I think Geert also pointed to some
examples where a device could reside in a clock domain but also in
power domain for a Renesas SoC!?
4) ?
Moreover, perhaps this could also be useful for SoCs using ACPI? If
so, we shouldn't tie this immediately to genpd, but in the layer above
genpd/ACPI PM domain. Something like dev_pm_domain_get(), which would
be implemented similar as the dev_pm_domain_attach() (which calls both
the ACPI PM domain and genpd to find a match).
Kind regards
Uffe
^ permalink raw reply [flat|nested] 59+ messages in thread
[parent not found: <CAPDyKFoJ58pwGz2U90ob8a8cY=hEbE-wLBHZ0BBzqPoLW_wgGA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-04-25 19:34 ` Ulf Hansson
@ 2017-04-25 21:17 ` Rafael J. Wysocki
-1 siblings, 0 replies; 59+ messages in thread
From: Rafael J. Wysocki @ 2017-04-25 21:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 25 April 2017 at 13:13, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> On 28/03/17 15:13, Jon Hunter wrote:
>>> The current generic PM domain framework (GenDP) only allows a single
>>> PM domain to be associated with a given device. There are several
>>> use-cases for various system-on-chip devices where it is necessary for
>>> a PM domain consumer to control more than one PM domain where the PM
>>> domains:
>>> i). Do not conform to a parent-child relationship so are not nested
>>> ii). May not be powered on and off at the same time so need independent
>>> control.
>>>
>>> The solution proposed in this RFC is to allow consumers to explictly
>>> control PM domains, by getting a handle to a PM domain and explicitly
>>> making calls to power on and off the PM domain. Note that referencing
>>> counting is used to ensure that a PM domain shared between consumers
>>> is not powered off incorrectly.
>>>
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) is an example of a consumer that needs to control more than
>>> one PM domain because the logic is partitioned across 3 PM domains which
>>> are:
>>> - XUSBA: Superspeed logic (for USB 3.0)
>>> - XUSBB: Device controller
>>> - XUSBC: Host controller
>>>
>>> These power domains are not nested and can be powered-up and down
>>> independently of one another. In practice different scenarios require
>>> different combinations of the power domains, for example:
>>> - Superspeed host: XUSBA and XUSBC
>>> - Superspeed device: XUSBA and XUSBB
>>>
>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>> domains under the XUSBA, superspeed may not always be used/required and
>>> so this would keep it on unnecessarily.
>>>
>>> Given that Tegra uses device-tree for describing the hardware, it would
>>> be ideal that the device-tree 'power-domains' property for generic PM
>>> domains could be extended to allow more than one PM domain to be
>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>
>>> usb@70090000 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>> power-domain-names = "host", "superspeed";
>>> };
>>>
>>> This RFC extends the generic PM domain framework to allow a device to
>>> define more than one PM domain in the device-tree 'power-domains'
>>> property. If there is more than one then the assumption is that these
>>> PM domains will be controlled explicitly by the consumer and the device
>>> will not be automatically bound to any PM domain.
>>
>> Any more comments/inputs on this? I can address Rajendra's feedback, but
>> before I did I wanted to see if this is along the right lines or not?
>
> I discussed this with Rafael at the OSPM summit in Pisa a couple of
> weeks ago. Apologize for the delay in providing additional feedback.
>
> First, whether the problem is really rare, perhaps adding a new
> API/framework can't be justified - then it may be better to add some
> kind of aggregation layer on top of the current PM domain
> infrastructure (something along the first attempt you made for genpd).
> That was kind of Rafael's thoughts (Rafael, please correct me if I am
> wrong).
We were talking about the original idea behind the pm_domain pointer
concept, which was about adding a set of PM operations above the bus
type/class layer, which could be used for intercepting bus-type PM
operations and providing some common handling above them. This is
still relevant IMO.
The basic observation here is that the PM core takes only one set of
PM operation per device into account and therefore, in every stage of
system suspend, for example, the callback invoked by it has to take
care of all actions that need to be carried out for the given device,
possibly by invoking callbacks from other code layers. That
limitation cannot be removed easily, because it is built into the PM
core design quite fundamentally.
However, this series seems to be about controlling power resources
represented by power domain objects rather than about PM operations.
In ACPI there is a power resource concept which seems to be quite
similar to this, so it is not entirely new. :-)
Of course, question is whether or not to extend genpd this way and I'm
not really sure. I actually probably wouldn't do that, because
poweron/poweroff operations used by genpd can be implemeted in terms
of lower-level power resource control and I don't see the reason for
mixing the two in one framework.
> However, we currently know about at least two different SoCs that need
> this. Perhaps we can extend the below list to justify adding a new
> framework/APIs. Something along the lines what you propose in $subject
> patchset.
>
> 1) Nvidia; to solve the USB super-speed host/device problem.
> 2) QCOM, which has pointed to several cases where the PM topology is
> laid out like devices having two PM domains..
> 3?) I don't fully remember - but I think Geert also pointed to some
> examples where a device could reside in a clock domain but also in
> power domain for a Renesas SoC!?
> 4) ?
>
> Moreover, perhaps this could also be useful for SoCs using ACPI?
No, it couldn't. At least not in general.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-04-25 21:17 ` Rafael J. Wysocki
0 siblings, 0 replies; 59+ messages in thread
From: Rafael J. Wysocki @ 2017-04-25 21:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm, linux-kernel, linux-tegra
On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 25 April 2017 at 13:13, Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> On 28/03/17 15:13, Jon Hunter wrote:
>>> The current generic PM domain framework (GenDP) only allows a single
>>> PM domain to be associated with a given device. There are several
>>> use-cases for various system-on-chip devices where it is necessary for
>>> a PM domain consumer to control more than one PM domain where the PM
>>> domains:
>>> i). Do not conform to a parent-child relationship so are not nested
>>> ii). May not be powered on and off at the same time so need independent
>>> control.
>>>
>>> The solution proposed in this RFC is to allow consumers to explictly
>>> control PM domains, by getting a handle to a PM domain and explicitly
>>> making calls to power on and off the PM domain. Note that referencing
>>> counting is used to ensure that a PM domain shared between consumers
>>> is not powered off incorrectly.
>>>
>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>> controllers) is an example of a consumer that needs to control more than
>>> one PM domain because the logic is partitioned across 3 PM domains which
>>> are:
>>> - XUSBA: Superspeed logic (for USB 3.0)
>>> - XUSBB: Device controller
>>> - XUSBC: Host controller
>>>
>>> These power domains are not nested and can be powered-up and down
>>> independently of one another. In practice different scenarios require
>>> different combinations of the power domains, for example:
>>> - Superspeed host: XUSBA and XUSBC
>>> - Superspeed device: XUSBA and XUSBB
>>>
>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>> domains under the XUSBA, superspeed may not always be used/required and
>>> so this would keep it on unnecessarily.
>>>
>>> Given that Tegra uses device-tree for describing the hardware, it would
>>> be ideal that the device-tree 'power-domains' property for generic PM
>>> domains could be extended to allow more than one PM domain to be
>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>
>>> usb@70090000 {
>>> compatible = "nvidia,tegra210-xusb";
>>> ...
>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>> power-domain-names = "host", "superspeed";
>>> };
>>>
>>> This RFC extends the generic PM domain framework to allow a device to
>>> define more than one PM domain in the device-tree 'power-domains'
>>> property. If there is more than one then the assumption is that these
>>> PM domains will be controlled explicitly by the consumer and the device
>>> will not be automatically bound to any PM domain.
>>
>> Any more comments/inputs on this? I can address Rajendra's feedback, but
>> before I did I wanted to see if this is along the right lines or not?
>
> I discussed this with Rafael at the OSPM summit in Pisa a couple of
> weeks ago. Apologize for the delay in providing additional feedback.
>
> First, whether the problem is really rare, perhaps adding a new
> API/framework can't be justified - then it may be better to add some
> kind of aggregation layer on top of the current PM domain
> infrastructure (something along the first attempt you made for genpd).
> That was kind of Rafael's thoughts (Rafael, please correct me if I am
> wrong).
We were talking about the original idea behind the pm_domain pointer
concept, which was about adding a set of PM operations above the bus
type/class layer, which could be used for intercepting bus-type PM
operations and providing some common handling above them. This is
still relevant IMO.
The basic observation here is that the PM core takes only one set of
PM operation per device into account and therefore, in every stage of
system suspend, for example, the callback invoked by it has to take
care of all actions that need to be carried out for the given device,
possibly by invoking callbacks from other code layers. That
limitation cannot be removed easily, because it is built into the PM
core design quite fundamentally.
However, this series seems to be about controlling power resources
represented by power domain objects rather than about PM operations.
In ACPI there is a power resource concept which seems to be quite
similar to this, so it is not entirely new. :-)
Of course, question is whether or not to extend genpd this way and I'm
not really sure. I actually probably wouldn't do that, because
poweron/poweroff operations used by genpd can be implemeted in terms
of lower-level power resource control and I don't see the reason for
mixing the two in one framework.
> However, we currently know about at least two different SoCs that need
> this. Perhaps we can extend the below list to justify adding a new
> framework/APIs. Something along the lines what you propose in $subject
> patchset.
>
> 1) Nvidia; to solve the USB super-speed host/device problem.
> 2) QCOM, which has pointed to several cases where the PM topology is
> laid out like devices having two PM domains..
> 3?) I don't fully remember - but I think Geert also pointed to some
> examples where a device could reside in a clock domain but also in
> power domain for a Renesas SoC!?
> 4) ?
>
> Moreover, perhaps this could also be useful for SoCs using ACPI?
No, it couldn't. At least not in general.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 59+ messages in thread
[parent not found: <CAJZ5v0gMzN_zfC_2nnRtYFyFon3-_mnioQhNbDP0wsr91RnagA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-04-25 21:17 ` Rafael J. Wysocki
@ 2017-05-02 10:10 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-05-02 10:10 UTC (permalink / raw)
To: Rafael J. Wysocki, Ulf Hansson
Cc: Rafael J . Wysocki, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
On 25/04/17 22:17, Rafael J. Wysocki wrote:
> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On 25 April 2017 at 13:13, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>
>>> On 28/03/17 15:13, Jon Hunter wrote:
>>>> The current generic PM domain framework (GenDP) only allows a single
>>>> PM domain to be associated with a given device. There are several
>>>> use-cases for various system-on-chip devices where it is necessary for
>>>> a PM domain consumer to control more than one PM domain where the PM
>>>> domains:
>>>> i). Do not conform to a parent-child relationship so are not nested
>>>> ii). May not be powered on and off at the same time so need independent
>>>> control.
>>>>
>>>> The solution proposed in this RFC is to allow consumers to explictly
>>>> control PM domains, by getting a handle to a PM domain and explicitly
>>>> making calls to power on and off the PM domain. Note that referencing
>>>> counting is used to ensure that a PM domain shared between consumers
>>>> is not powered off incorrectly.
>>>>
>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>>> controllers) is an example of a consumer that needs to control more than
>>>> one PM domain because the logic is partitioned across 3 PM domains which
>>>> are:
>>>> - XUSBA: Superspeed logic (for USB 3.0)
>>>> - XUSBB: Device controller
>>>> - XUSBC: Host controller
>>>>
>>>> These power domains are not nested and can be powered-up and down
>>>> independently of one another. In practice different scenarios require
>>>> different combinations of the power domains, for example:
>>>> - Superspeed host: XUSBA and XUSBC
>>>> - Superspeed device: XUSBA and XUSBB
>>>>
>>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>>> domains under the XUSBA, superspeed may not always be used/required and
>>>> so this would keep it on unnecessarily.
>>>>
>>>> Given that Tegra uses device-tree for describing the hardware, it would
>>>> be ideal that the device-tree 'power-domains' property for generic PM
>>>> domains could be extended to allow more than one PM domain to be
>>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>>
>>>> usb@70090000 {
>>>> compatible = "nvidia,tegra210-xusb";
>>>> ...
>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>> power-domain-names = "host", "superspeed";
>>>> };
>>>>
>>>> This RFC extends the generic PM domain framework to allow a device to
>>>> define more than one PM domain in the device-tree 'power-domains'
>>>> property. If there is more than one then the assumption is that these
>>>> PM domains will be controlled explicitly by the consumer and the device
>>>> will not be automatically bound to any PM domain.
>>>
>>> Any more comments/inputs on this? I can address Rajendra's feedback, but
>>> before I did I wanted to see if this is along the right lines or not?
>>
>> I discussed this with Rafael at the OSPM summit in Pisa a couple of
>> weeks ago. Apologize for the delay in providing additional feedback.
>>
>> First, whether the problem is really rare, perhaps adding a new
>> API/framework can't be justified - then it may be better to add some
>> kind of aggregation layer on top of the current PM domain
>> infrastructure (something along the first attempt you made for genpd).
>> That was kind of Rafael's thoughts (Rafael, please correct me if I am
>> wrong).
>
> We were talking about the original idea behind the pm_domain pointer
> concept, which was about adding a set of PM operations above the bus
> type/class layer, which could be used for intercepting bus-type PM
> operations and providing some common handling above them. This is
> still relevant IMO.
>
> The basic observation here is that the PM core takes only one set of
> PM operation per device into account and therefore, in every stage of
> system suspend, for example, the callback invoked by it has to take
> care of all actions that need to be carried out for the given device,
> possibly by invoking callbacks from other code layers. That
> limitation cannot be removed easily, because it is built into the PM
> core design quite fundamentally.
>
> However, this series seems to be about controlling power resources
> represented by power domain objects rather than about PM operations.
> In ACPI there is a power resource concept which seems to be quite
> similar to this, so it is not entirely new. :-)
>
> Of course, question is whether or not to extend genpd this way and I'm
> not really sure. I actually probably wouldn't do that, because
> poweron/poweroff operations used by genpd can be implemeted in terms
> of lower-level power resource control and I don't see the reason for
> mixing the two in one framework.
That seems fine to me. However, it seems that genpd itself should also
be a client of this 'low-level power resource control' so that
power-domains are registered once and can be used by either method. So
unless I am misunderstanding you here, it seems that what we need to do
is split the current genpd framework into a couple layers:
1. Low-level power resource control which has:
- Power resource registration (ie. pm_genpd_init/remove())
- Power resource provider registration (ie. of_genpd_add_xxx())
- Power resource control (on/off etc)
- Power resource lookup (what this series is adding)
2. Generic power-domain infrastructure which is a client of the
low-level power resource control that can automatically bind a device to
a singular power resource entity (ie. power-domain).
Is this along the right lines?
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-05-02 10:10 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-05-02 10:10 UTC (permalink / raw)
To: Rafael J. Wysocki, Ulf Hansson
Cc: Rafael J . Wysocki, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm, linux-kernel, linux-tegra
On 25/04/17 22:17, Rafael J. Wysocki wrote:
> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 25 April 2017 at 13:13, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>
>>> On 28/03/17 15:13, Jon Hunter wrote:
>>>> The current generic PM domain framework (GenDP) only allows a single
>>>> PM domain to be associated with a given device. There are several
>>>> use-cases for various system-on-chip devices where it is necessary for
>>>> a PM domain consumer to control more than one PM domain where the PM
>>>> domains:
>>>> i). Do not conform to a parent-child relationship so are not nested
>>>> ii). May not be powered on and off at the same time so need independent
>>>> control.
>>>>
>>>> The solution proposed in this RFC is to allow consumers to explictly
>>>> control PM domains, by getting a handle to a PM domain and explicitly
>>>> making calls to power on and off the PM domain. Note that referencing
>>>> counting is used to ensure that a PM domain shared between consumers
>>>> is not powered off incorrectly.
>>>>
>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>>> controllers) is an example of a consumer that needs to control more than
>>>> one PM domain because the logic is partitioned across 3 PM domains which
>>>> are:
>>>> - XUSBA: Superspeed logic (for USB 3.0)
>>>> - XUSBB: Device controller
>>>> - XUSBC: Host controller
>>>>
>>>> These power domains are not nested and can be powered-up and down
>>>> independently of one another. In practice different scenarios require
>>>> different combinations of the power domains, for example:
>>>> - Superspeed host: XUSBA and XUSBC
>>>> - Superspeed device: XUSBA and XUSBB
>>>>
>>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>>> domains under the XUSBA, superspeed may not always be used/required and
>>>> so this would keep it on unnecessarily.
>>>>
>>>> Given that Tegra uses device-tree for describing the hardware, it would
>>>> be ideal that the device-tree 'power-domains' property for generic PM
>>>> domains could be extended to allow more than one PM domain to be
>>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>>
>>>> usb@70090000 {
>>>> compatible = "nvidia,tegra210-xusb";
>>>> ...
>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>> power-domain-names = "host", "superspeed";
>>>> };
>>>>
>>>> This RFC extends the generic PM domain framework to allow a device to
>>>> define more than one PM domain in the device-tree 'power-domains'
>>>> property. If there is more than one then the assumption is that these
>>>> PM domains will be controlled explicitly by the consumer and the device
>>>> will not be automatically bound to any PM domain.
>>>
>>> Any more comments/inputs on this? I can address Rajendra's feedback, but
>>> before I did I wanted to see if this is along the right lines or not?
>>
>> I discussed this with Rafael at the OSPM summit in Pisa a couple of
>> weeks ago. Apologize for the delay in providing additional feedback.
>>
>> First, whether the problem is really rare, perhaps adding a new
>> API/framework can't be justified - then it may be better to add some
>> kind of aggregation layer on top of the current PM domain
>> infrastructure (something along the first attempt you made for genpd).
>> That was kind of Rafael's thoughts (Rafael, please correct me if I am
>> wrong).
>
> We were talking about the original idea behind the pm_domain pointer
> concept, which was about adding a set of PM operations above the bus
> type/class layer, which could be used for intercepting bus-type PM
> operations and providing some common handling above them. This is
> still relevant IMO.
>
> The basic observation here is that the PM core takes only one set of
> PM operation per device into account and therefore, in every stage of
> system suspend, for example, the callback invoked by it has to take
> care of all actions that need to be carried out for the given device,
> possibly by invoking callbacks from other code layers. That
> limitation cannot be removed easily, because it is built into the PM
> core design quite fundamentally.
>
> However, this series seems to be about controlling power resources
> represented by power domain objects rather than about PM operations.
> In ACPI there is a power resource concept which seems to be quite
> similar to this, so it is not entirely new. :-)
>
> Of course, question is whether or not to extend genpd this way and I'm
> not really sure. I actually probably wouldn't do that, because
> poweron/poweroff operations used by genpd can be implemeted in terms
> of lower-level power resource control and I don't see the reason for
> mixing the two in one framework.
That seems fine to me. However, it seems that genpd itself should also
be a client of this 'low-level power resource control' so that
power-domains are registered once and can be used by either method. So
unless I am misunderstanding you here, it seems that what we need to do
is split the current genpd framework into a couple layers:
1. Low-level power resource control which has:
- Power resource registration (ie. pm_genpd_init/remove())
- Power resource provider registration (ie. of_genpd_add_xxx())
- Power resource control (on/off etc)
- Power resource lookup (what this series is adding)
2. Generic power-domain infrastructure which is a client of the
low-level power resource control that can automatically bind a device to
a singular power resource entity (ie. power-domain).
Is this along the right lines?
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
[parent not found: <ffe13074-9113-0a20-0fa6-76d0209dadfc-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-05-02 10:10 ` Jon Hunter
@ 2017-05-02 21:51 ` Rafael J. Wysocki
-1 siblings, 0 replies; 59+ messages in thread
From: Rafael J. Wysocki @ 2017-05-02 21:51 UTC (permalink / raw)
To: Jon Hunter
Cc: Rafael J. Wysocki, Ulf Hansson, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
On Tuesday, May 02, 2017 11:10:29 AM Jon Hunter wrote:
>
> On 25/04/17 22:17, Rafael J. Wysocki wrote:
> > On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> On 25 April 2017 at 13:13, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> >>>
> >>> On 28/03/17 15:13, Jon Hunter wrote:
> >>>> The current generic PM domain framework (GenDP) only allows a single
> >>>> PM domain to be associated with a given device. There are several
> >>>> use-cases for various system-on-chip devices where it is necessary for
> >>>> a PM domain consumer to control more than one PM domain where the PM
> >>>> domains:
> >>>> i). Do not conform to a parent-child relationship so are not nested
> >>>> ii). May not be powered on and off at the same time so need independent
> >>>> control.
> >>>>
> >>>> The solution proposed in this RFC is to allow consumers to explictly
> >>>> control PM domains, by getting a handle to a PM domain and explicitly
> >>>> making calls to power on and off the PM domain. Note that referencing
> >>>> counting is used to ensure that a PM domain shared between consumers
> >>>> is not powered off incorrectly.
> >>>>
> >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
> >>>> controllers) is an example of a consumer that needs to control more than
> >>>> one PM domain because the logic is partitioned across 3 PM domains which
> >>>> are:
> >>>> - XUSBA: Superspeed logic (for USB 3.0)
> >>>> - XUSBB: Device controller
> >>>> - XUSBC: Host controller
> >>>>
> >>>> These power domains are not nested and can be powered-up and down
> >>>> independently of one another. In practice different scenarios require
> >>>> different combinations of the power domains, for example:
> >>>> - Superspeed host: XUSBA and XUSBC
> >>>> - Superspeed device: XUSBA and XUSBB
> >>>>
> >>>> Although it could be possible to logically nest both the XUSBB and XUSBC
> >>>> domains under the XUSBA, superspeed may not always be used/required and
> >>>> so this would keep it on unnecessarily.
> >>>>
> >>>> Given that Tegra uses device-tree for describing the hardware, it would
> >>>> be ideal that the device-tree 'power-domains' property for generic PM
> >>>> domains could be extended to allow more than one PM domain to be
> >>>> specified. For example, define the following the Tegra210 xHCI device ...
> >>>>
> >>>> usb@70090000 {
> >>>> compatible = "nvidia,tegra210-xusb";
> >>>> ...
> >>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
> >>>> power-domain-names = "host", "superspeed";
> >>>> };
> >>>>
> >>>> This RFC extends the generic PM domain framework to allow a device to
> >>>> define more than one PM domain in the device-tree 'power-domains'
> >>>> property. If there is more than one then the assumption is that these
> >>>> PM domains will be controlled explicitly by the consumer and the device
> >>>> will not be automatically bound to any PM domain.
> >>>
> >>> Any more comments/inputs on this? I can address Rajendra's feedback, but
> >>> before I did I wanted to see if this is along the right lines or not?
> >>
> >> I discussed this with Rafael at the OSPM summit in Pisa a couple of
> >> weeks ago. Apologize for the delay in providing additional feedback.
> >>
> >> First, whether the problem is really rare, perhaps adding a new
> >> API/framework can't be justified - then it may be better to add some
> >> kind of aggregation layer on top of the current PM domain
> >> infrastructure (something along the first attempt you made for genpd).
> >> That was kind of Rafael's thoughts (Rafael, please correct me if I am
> >> wrong).
> >
> > We were talking about the original idea behind the pm_domain pointer
> > concept, which was about adding a set of PM operations above the bus
> > type/class layer, which could be used for intercepting bus-type PM
> > operations and providing some common handling above them. This is
> > still relevant IMO.
> >
> > The basic observation here is that the PM core takes only one set of
> > PM operation per device into account and therefore, in every stage of
> > system suspend, for example, the callback invoked by it has to take
> > care of all actions that need to be carried out for the given device,
> > possibly by invoking callbacks from other code layers. That
> > limitation cannot be removed easily, because it is built into the PM
> > core design quite fundamentally.
> >
> > However, this series seems to be about controlling power resources
> > represented by power domain objects rather than about PM operations.
> > In ACPI there is a power resource concept which seems to be quite
> > similar to this, so it is not entirely new. :-)
> >
> > Of course, question is whether or not to extend genpd this way and I'm
> > not really sure. I actually probably wouldn't do that, because
> > poweron/poweroff operations used by genpd can be implemeted in terms
> > of lower-level power resource control and I don't see the reason for
> > mixing the two in one framework.
>
> That seems fine to me. However, it seems that genpd itself should also
> be a client of this 'low-level power resource control' so that
> power-domains are registered once and can be used by either method.
Right.
> So unless I am misunderstanding you here, it seems that what we need to do
> is split the current genpd framework into a couple layers:
>
> 1. Low-level power resource control which has:
> - Power resource registration (ie. pm_genpd_init/remove())
> - Power resource provider registration (ie. of_genpd_add_xxx())
> - Power resource control (on/off etc)
And reference counting.
> - Power resource lookup (what this series is adding)
>
> 2. Generic power-domain infrastructure which is a client of the
> low-level power resource control that can automatically bind a device to
> a singular power resource entity (ie. power-domain).
Something like that, but I would not require an additional complex framework
to be present below genpd. I would make it *possible* for genpd to use that
framework if available, but if something simpler is sufficient, it should be
fine to use that instead.
That is, I would allow genpd to use either a list of power resources or the on/off
callbacks provided by itself to cover different use cases. That should be
flexible enough.
> Is this along the right lines?
It is, at least for the very narrow definition of "right" as being done along
the lines I would do that. :-)
Thanks,
Rafael
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-05-02 21:51 ` Rafael J. Wysocki
0 siblings, 0 replies; 59+ messages in thread
From: Rafael J. Wysocki @ 2017-05-02 21:51 UTC (permalink / raw)
To: Jon Hunter
Cc: Rafael J. Wysocki, Ulf Hansson, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm, linux-kernel, linux-tegra
On Tuesday, May 02, 2017 11:10:29 AM Jon Hunter wrote:
>
> On 25/04/17 22:17, Rafael J. Wysocki wrote:
> > On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> On 25 April 2017 at 13:13, Jon Hunter <jonathanh@nvidia.com> wrote:
> >>>
> >>> On 28/03/17 15:13, Jon Hunter wrote:
> >>>> The current generic PM domain framework (GenDP) only allows a single
> >>>> PM domain to be associated with a given device. There are several
> >>>> use-cases for various system-on-chip devices where it is necessary for
> >>>> a PM domain consumer to control more than one PM domain where the PM
> >>>> domains:
> >>>> i). Do not conform to a parent-child relationship so are not nested
> >>>> ii). May not be powered on and off at the same time so need independent
> >>>> control.
> >>>>
> >>>> The solution proposed in this RFC is to allow consumers to explictly
> >>>> control PM domains, by getting a handle to a PM domain and explicitly
> >>>> making calls to power on and off the PM domain. Note that referencing
> >>>> counting is used to ensure that a PM domain shared between consumers
> >>>> is not powered off incorrectly.
> >>>>
> >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
> >>>> controllers) is an example of a consumer that needs to control more than
> >>>> one PM domain because the logic is partitioned across 3 PM domains which
> >>>> are:
> >>>> - XUSBA: Superspeed logic (for USB 3.0)
> >>>> - XUSBB: Device controller
> >>>> - XUSBC: Host controller
> >>>>
> >>>> These power domains are not nested and can be powered-up and down
> >>>> independently of one another. In practice different scenarios require
> >>>> different combinations of the power domains, for example:
> >>>> - Superspeed host: XUSBA and XUSBC
> >>>> - Superspeed device: XUSBA and XUSBB
> >>>>
> >>>> Although it could be possible to logically nest both the XUSBB and XUSBC
> >>>> domains under the XUSBA, superspeed may not always be used/required and
> >>>> so this would keep it on unnecessarily.
> >>>>
> >>>> Given that Tegra uses device-tree for describing the hardware, it would
> >>>> be ideal that the device-tree 'power-domains' property for generic PM
> >>>> domains could be extended to allow more than one PM domain to be
> >>>> specified. For example, define the following the Tegra210 xHCI device ...
> >>>>
> >>>> usb@70090000 {
> >>>> compatible = "nvidia,tegra210-xusb";
> >>>> ...
> >>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
> >>>> power-domain-names = "host", "superspeed";
> >>>> };
> >>>>
> >>>> This RFC extends the generic PM domain framework to allow a device to
> >>>> define more than one PM domain in the device-tree 'power-domains'
> >>>> property. If there is more than one then the assumption is that these
> >>>> PM domains will be controlled explicitly by the consumer and the device
> >>>> will not be automatically bound to any PM domain.
> >>>
> >>> Any more comments/inputs on this? I can address Rajendra's feedback, but
> >>> before I did I wanted to see if this is along the right lines or not?
> >>
> >> I discussed this with Rafael at the OSPM summit in Pisa a couple of
> >> weeks ago. Apologize for the delay in providing additional feedback.
> >>
> >> First, whether the problem is really rare, perhaps adding a new
> >> API/framework can't be justified - then it may be better to add some
> >> kind of aggregation layer on top of the current PM domain
> >> infrastructure (something along the first attempt you made for genpd).
> >> That was kind of Rafael's thoughts (Rafael, please correct me if I am
> >> wrong).
> >
> > We were talking about the original idea behind the pm_domain pointer
> > concept, which was about adding a set of PM operations above the bus
> > type/class layer, which could be used for intercepting bus-type PM
> > operations and providing some common handling above them. This is
> > still relevant IMO.
> >
> > The basic observation here is that the PM core takes only one set of
> > PM operation per device into account and therefore, in every stage of
> > system suspend, for example, the callback invoked by it has to take
> > care of all actions that need to be carried out for the given device,
> > possibly by invoking callbacks from other code layers. That
> > limitation cannot be removed easily, because it is built into the PM
> > core design quite fundamentally.
> >
> > However, this series seems to be about controlling power resources
> > represented by power domain objects rather than about PM operations.
> > In ACPI there is a power resource concept which seems to be quite
> > similar to this, so it is not entirely new. :-)
> >
> > Of course, question is whether or not to extend genpd this way and I'm
> > not really sure. I actually probably wouldn't do that, because
> > poweron/poweroff operations used by genpd can be implemeted in terms
> > of lower-level power resource control and I don't see the reason for
> > mixing the two in one framework.
>
> That seems fine to me. However, it seems that genpd itself should also
> be a client of this 'low-level power resource control' so that
> power-domains are registered once and can be used by either method.
Right.
> So unless I am misunderstanding you here, it seems that what we need to do
> is split the current genpd framework into a couple layers:
>
> 1. Low-level power resource control which has:
> - Power resource registration (ie. pm_genpd_init/remove())
> - Power resource provider registration (ie. of_genpd_add_xxx())
> - Power resource control (on/off etc)
And reference counting.
> - Power resource lookup (what this series is adding)
>
> 2. Generic power-domain infrastructure which is a client of the
> low-level power resource control that can automatically bind a device to
> a singular power resource entity (ie. power-domain).
Something like that, but I would not require an additional complex framework
to be present below genpd. I would make it *possible* for genpd to use that
framework if available, but if something simpler is sufficient, it should be
fine to use that instead.
That is, I would allow genpd to use either a list of power resources or the on/off
callbacks provided by itself to cover different use cases. That should be
flexible enough.
> Is this along the right lines?
It is, at least for the very narrow definition of "right" as being done along
the lines I would do that. :-)
Thanks,
Rafael
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-05-02 21:51 ` Rafael J. Wysocki
(?)
@ 2017-05-03 8:12 ` Ulf Hansson
[not found] ` <CAPDyKFokVKZfRAsEAB6ihx1FxW4JjarionyOwCATr3s+QW4aMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
-1 siblings, 1 reply; 59+ messages in thread
From: Ulf Hansson @ 2017-05-03 8:12 UTC (permalink / raw)
To: Rafael J. Wysocki, Jon Hunter
Cc: Rafael J. Wysocki, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm, linux-kernel, linux-tegra
Rafael, Jon,
On 2 May 2017 at 23:51, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, May 02, 2017 11:10:29 AM Jon Hunter wrote:
>>
>> On 25/04/17 22:17, Rafael J. Wysocki wrote:
>> > On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> >> On 25 April 2017 at 13:13, Jon Hunter <jonathanh@nvidia.com> wrote:
>> >>>
>> >>> On 28/03/17 15:13, Jon Hunter wrote:
>> >>>> The current generic PM domain framework (GenDP) only allows a single
>> >>>> PM domain to be associated with a given device. There are several
>> >>>> use-cases for various system-on-chip devices where it is necessary for
>> >>>> a PM domain consumer to control more than one PM domain where the PM
>> >>>> domains:
>> >>>> i). Do not conform to a parent-child relationship so are not nested
>> >>>> ii). May not be powered on and off at the same time so need independent
>> >>>> control.
>> >>>>
>> >>>> The solution proposed in this RFC is to allow consumers to explictly
>> >>>> control PM domains, by getting a handle to a PM domain and explicitly
>> >>>> making calls to power on and off the PM domain. Note that referencing
>> >>>> counting is used to ensure that a PM domain shared between consumers
>> >>>> is not powered off incorrectly.
>> >>>>
>> >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>> >>>> controllers) is an example of a consumer that needs to control more than
>> >>>> one PM domain because the logic is partitioned across 3 PM domains which
>> >>>> are:
>> >>>> - XUSBA: Superspeed logic (for USB 3.0)
>> >>>> - XUSBB: Device controller
>> >>>> - XUSBC: Host controller
>> >>>>
>> >>>> These power domains are not nested and can be powered-up and down
>> >>>> independently of one another. In practice different scenarios require
>> >>>> different combinations of the power domains, for example:
>> >>>> - Superspeed host: XUSBA and XUSBC
>> >>>> - Superspeed device: XUSBA and XUSBB
>> >>>>
>> >>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>> >>>> domains under the XUSBA, superspeed may not always be used/required and
>> >>>> so this would keep it on unnecessarily.
>> >>>>
>> >>>> Given that Tegra uses device-tree for describing the hardware, it would
>> >>>> be ideal that the device-tree 'power-domains' property for generic PM
>> >>>> domains could be extended to allow more than one PM domain to be
>> >>>> specified. For example, define the following the Tegra210 xHCI device ...
>> >>>>
>> >>>> usb@70090000 {
>> >>>> compatible = "nvidia,tegra210-xusb";
>> >>>> ...
>> >>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>> >>>> power-domain-names = "host", "superspeed";
>> >>>> };
>> >>>>
>> >>>> This RFC extends the generic PM domain framework to allow a device to
>> >>>> define more than one PM domain in the device-tree 'power-domains'
>> >>>> property. If there is more than one then the assumption is that these
>> >>>> PM domains will be controlled explicitly by the consumer and the device
>> >>>> will not be automatically bound to any PM domain.
>> >>>
>> >>> Any more comments/inputs on this? I can address Rajendra's feedback, but
>> >>> before I did I wanted to see if this is along the right lines or not?
>> >>
>> >> I discussed this with Rafael at the OSPM summit in Pisa a couple of
>> >> weeks ago. Apologize for the delay in providing additional feedback.
>> >>
>> >> First, whether the problem is really rare, perhaps adding a new
>> >> API/framework can't be justified - then it may be better to add some
>> >> kind of aggregation layer on top of the current PM domain
>> >> infrastructure (something along the first attempt you made for genpd).
>> >> That was kind of Rafael's thoughts (Rafael, please correct me if I am
>> >> wrong).
>> >
>> > We were talking about the original idea behind the pm_domain pointer
>> > concept, which was about adding a set of PM operations above the bus
>> > type/class layer, which could be used for intercepting bus-type PM
>> > operations and providing some common handling above them. This is
>> > still relevant IMO.
>> >
>> > The basic observation here is that the PM core takes only one set of
>> > PM operation per device into account and therefore, in every stage of
>> > system suspend, for example, the callback invoked by it has to take
>> > care of all actions that need to be carried out for the given device,
>> > possibly by invoking callbacks from other code layers. That
>> > limitation cannot be removed easily, because it is built into the PM
>> > core design quite fundamentally.
>> >
>> > However, this series seems to be about controlling power resources
>> > represented by power domain objects rather than about PM operations.
>> > In ACPI there is a power resource concept which seems to be quite
>> > similar to this, so it is not entirely new. :-)
>> >
>> > Of course, question is whether or not to extend genpd this way and I'm
>> > not really sure. I actually probably wouldn't do that, because
>> > poweron/poweroff operations used by genpd can be implemeted in terms
>> > of lower-level power resource control and I don't see the reason for
>> > mixing the two in one framework.
>>
>> That seems fine to me. However, it seems that genpd itself should also
>> be a client of this 'low-level power resource control' so that
>> power-domains are registered once and can be used by either method.
>
> Right.
>
>> So unless I am misunderstanding you here, it seems that what we need to do
>> is split the current genpd framework into a couple layers:
>>
>> 1. Low-level power resource control which has:
>> - Power resource registration (ie. pm_genpd_init/remove())
>> - Power resource provider registration (ie. of_genpd_add_xxx())
>> - Power resource control (on/off etc)
>
> And reference counting.
>
>> - Power resource lookup (what this series is adding)
>>
>> 2. Generic power-domain infrastructure which is a client of the
>> low-level power resource control that can automatically bind a device to
>> a singular power resource entity (ie. power-domain).
>
> Something like that, but I would not require an additional complex framework
> to be present below genpd. I would make it *possible* for genpd to use that
> framework if available, but if something simpler is sufficient, it should be
> fine to use that instead.
>
> That is, I would allow genpd to use either a list of power resources or the on/off
> callbacks provided by itself to cover different use cases. That should be
> flexible enough.
>
>> Is this along the right lines?
>
> It is, at least for the very narrow definition of "right" as being done along
> the lines I would do that. :-)
Let me first give some more background to how it looks like today.
We have the following device callbacks being used by genpd:
struct gpd_dev_ops {
int (*start)(struct device *dev);
int (*stop)(struct device *dev);
bool (*active_wakeup)(struct device *dev);
};
The ->stop|start() callback is invoked from genpd's
->runtime_suspend|resume() callbacks and may be assigned by a genpd
client before it registers a genpd though pm_genpd_init(). Typically
these callbacks can control any "power resources" that the genpd
client finds suitable.
To allow clients to instantiate "power resources" per device, we have
the following callbacks, part of the struct generic_pm_domain.
int (*attach_dev)(struct generic_pm_domain *domain, struct device *dev);
void (*detach_dev)(struct generic_pm_domain *domain, struct device *dev);
These callbacks are invoked when the device gets attached/detached
from its PM domain (genpd).
Moreover, the struct dev_pm_get_subsys_data is being used from within
genpd (via struct pm_domain_data *domain_data), as it allows genpd and
its client, to allocate and associate device specific data, which may
be needed to store information about the "power resources".
Currently Renesas SoCs are a good example of how to deploy this, as it
implements its clock PM domain on top of this. In this regards I
assume that we could consider the pm_clk_*() APIs as in control of the
"power resources".
So my conclusion is; unless I am totally misunderstanding the ideas
here; I think we already have the infrastructure in place and we also
have some good references of how to use it.
What is missing, is how a call to pm_runtime_get_sync() by a driver,
can inform the ->start() callback about what exact power resource(s)
it shall turn on, because it may not always be all of them. Similar
problem exists for pm_runtime_put().
Kind regards
Uffe
^ permalink raw reply [flat|nested] 59+ messages in thread
[parent not found: <1832647.f77WMLkdQb-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org>]
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-05-02 21:51 ` Rafael J. Wysocki
@ 2017-05-03 8:12 ` Jon Hunter
-1 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-05-03 8:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Ulf Hansson, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
On 02/05/17 22:51, Rafael J. Wysocki wrote:
> On Tuesday, May 02, 2017 11:10:29 AM Jon Hunter wrote:
>>
>> On 25/04/17 22:17, Rafael J. Wysocki wrote:
>>> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>> On 25 April 2017 at 13:13, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>>>
>>>>> On 28/03/17 15:13, Jon Hunter wrote:
>>>>>> The current generic PM domain framework (GenDP) only allows a single
>>>>>> PM domain to be associated with a given device. There are several
>>>>>> use-cases for various system-on-chip devices where it is necessary for
>>>>>> a PM domain consumer to control more than one PM domain where the PM
>>>>>> domains:
>>>>>> i). Do not conform to a parent-child relationship so are not nested
>>>>>> ii). May not be powered on and off at the same time so need independent
>>>>>> control.
>>>>>>
>>>>>> The solution proposed in this RFC is to allow consumers to explictly
>>>>>> control PM domains, by getting a handle to a PM domain and explicitly
>>>>>> making calls to power on and off the PM domain. Note that referencing
>>>>>> counting is used to ensure that a PM domain shared between consumers
>>>>>> is not powered off incorrectly.
>>>>>>
>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>>>>> controllers) is an example of a consumer that needs to control more than
>>>>>> one PM domain because the logic is partitioned across 3 PM domains which
>>>>>> are:
>>>>>> - XUSBA: Superspeed logic (for USB 3.0)
>>>>>> - XUSBB: Device controller
>>>>>> - XUSBC: Host controller
>>>>>>
>>>>>> These power domains are not nested and can be powered-up and down
>>>>>> independently of one another. In practice different scenarios require
>>>>>> different combinations of the power domains, for example:
>>>>>> - Superspeed host: XUSBA and XUSBC
>>>>>> - Superspeed device: XUSBA and XUSBB
>>>>>>
>>>>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>>>>> domains under the XUSBA, superspeed may not always be used/required and
>>>>>> so this would keep it on unnecessarily.
>>>>>>
>>>>>> Given that Tegra uses device-tree for describing the hardware, it would
>>>>>> be ideal that the device-tree 'power-domains' property for generic PM
>>>>>> domains could be extended to allow more than one PM domain to be
>>>>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>>>>
>>>>>> usb@70090000 {
>>>>>> compatible = "nvidia,tegra210-xusb";
>>>>>> ...
>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>> power-domain-names = "host", "superspeed";
>>>>>> };
>>>>>>
>>>>>> This RFC extends the generic PM domain framework to allow a device to
>>>>>> define more than one PM domain in the device-tree 'power-domains'
>>>>>> property. If there is more than one then the assumption is that these
>>>>>> PM domains will be controlled explicitly by the consumer and the device
>>>>>> will not be automatically bound to any PM domain.
>>>>>
>>>>> Any more comments/inputs on this? I can address Rajendra's feedback, but
>>>>> before I did I wanted to see if this is along the right lines or not?
>>>>
>>>> I discussed this with Rafael at the OSPM summit in Pisa a couple of
>>>> weeks ago. Apologize for the delay in providing additional feedback.
>>>>
>>>> First, whether the problem is really rare, perhaps adding a new
>>>> API/framework can't be justified - then it may be better to add some
>>>> kind of aggregation layer on top of the current PM domain
>>>> infrastructure (something along the first attempt you made for genpd).
>>>> That was kind of Rafael's thoughts (Rafael, please correct me if I am
>>>> wrong).
>>>
>>> We were talking about the original idea behind the pm_domain pointer
>>> concept, which was about adding a set of PM operations above the bus
>>> type/class layer, which could be used for intercepting bus-type PM
>>> operations and providing some common handling above them. This is
>>> still relevant IMO.
>>>
>>> The basic observation here is that the PM core takes only one set of
>>> PM operation per device into account and therefore, in every stage of
>>> system suspend, for example, the callback invoked by it has to take
>>> care of all actions that need to be carried out for the given device,
>>> possibly by invoking callbacks from other code layers. That
>>> limitation cannot be removed easily, because it is built into the PM
>>> core design quite fundamentally.
>>>
>>> However, this series seems to be about controlling power resources
>>> represented by power domain objects rather than about PM operations.
>>> In ACPI there is a power resource concept which seems to be quite
>>> similar to this, so it is not entirely new. :-)
>>>
>>> Of course, question is whether or not to extend genpd this way and I'm
>>> not really sure. I actually probably wouldn't do that, because
>>> poweron/poweroff operations used by genpd can be implemeted in terms
>>> of lower-level power resource control and I don't see the reason for
>>> mixing the two in one framework.
>>
>> That seems fine to me. However, it seems that genpd itself should also
>> be a client of this 'low-level power resource control' so that
>> power-domains are registered once and can be used by either method.
>
> Right.
>
>> So unless I am misunderstanding you here, it seems that what we need to do
>> is split the current genpd framework into a couple layers:
>>
>> 1. Low-level power resource control which has:
>> - Power resource registration (ie. pm_genpd_init/remove())
>> - Power resource provider registration (ie. of_genpd_add_xxx())
>> - Power resource control (on/off etc)
>
> And reference counting.
Yes, absolutely.
>> - Power resource lookup (what this series is adding)
>>
>> 2. Generic power-domain infrastructure which is a client of the
>> low-level power resource control that can automatically bind a device to
>> a singular power resource entity (ie. power-domain).
>
> Something like that, but I would not require an additional complex framework
> to be present below genpd. I would make it *possible* for genpd to use that
> framework if available, but if something simpler is sufficient, it should be
> fine to use that instead.
>
> That is, I would allow genpd to use either a list of power resources or the on/off
> callbacks provided by itself to cover different use cases. That should be
> flexible enough.
By a 'list', do you mean the pm_domain member of 'struct device' should
become a list instead? That would be a bigger change and I would need to
see how that would work.
>> Is this along the right lines?
>
> It is, at least for the very narrow definition of "right" as being done along
> the lines I would do that. :-)
Thanks
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
@ 2017-05-03 8:12 ` Jon Hunter
0 siblings, 0 replies; 59+ messages in thread
From: Jon Hunter @ 2017-05-03 8:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Ulf Hansson, Kevin Hilman, Geert Uytterhoeven,
Rajendra Nayak, Stanimir Varbanov, Stephen Boyd,
Marek Szyprowski, linux-pm, linux-kernel, linux-tegra
On 02/05/17 22:51, Rafael J. Wysocki wrote:
> On Tuesday, May 02, 2017 11:10:29 AM Jon Hunter wrote:
>>
>> On 25/04/17 22:17, Rafael J. Wysocki wrote:
>>> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>>> On 25 April 2017 at 13:13, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>>
>>>>> On 28/03/17 15:13, Jon Hunter wrote:
>>>>>> The current generic PM domain framework (GenDP) only allows a single
>>>>>> PM domain to be associated with a given device. There are several
>>>>>> use-cases for various system-on-chip devices where it is necessary for
>>>>>> a PM domain consumer to control more than one PM domain where the PM
>>>>>> domains:
>>>>>> i). Do not conform to a parent-child relationship so are not nested
>>>>>> ii). May not be powered on and off at the same time so need independent
>>>>>> control.
>>>>>>
>>>>>> The solution proposed in this RFC is to allow consumers to explictly
>>>>>> control PM domains, by getting a handle to a PM domain and explicitly
>>>>>> making calls to power on and off the PM domain. Note that referencing
>>>>>> counting is used to ensure that a PM domain shared between consumers
>>>>>> is not powered off incorrectly.
>>>>>>
>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device
>>>>>> controllers) is an example of a consumer that needs to control more than
>>>>>> one PM domain because the logic is partitioned across 3 PM domains which
>>>>>> are:
>>>>>> - XUSBA: Superspeed logic (for USB 3.0)
>>>>>> - XUSBB: Device controller
>>>>>> - XUSBC: Host controller
>>>>>>
>>>>>> These power domains are not nested and can be powered-up and down
>>>>>> independently of one another. In practice different scenarios require
>>>>>> different combinations of the power domains, for example:
>>>>>> - Superspeed host: XUSBA and XUSBC
>>>>>> - Superspeed device: XUSBA and XUSBB
>>>>>>
>>>>>> Although it could be possible to logically nest both the XUSBB and XUSBC
>>>>>> domains under the XUSBA, superspeed may not always be used/required and
>>>>>> so this would keep it on unnecessarily.
>>>>>>
>>>>>> Given that Tegra uses device-tree for describing the hardware, it would
>>>>>> be ideal that the device-tree 'power-domains' property for generic PM
>>>>>> domains could be extended to allow more than one PM domain to be
>>>>>> specified. For example, define the following the Tegra210 xHCI device ...
>>>>>>
>>>>>> usb@70090000 {
>>>>>> compatible = "nvidia,tegra210-xusb";
>>>>>> ...
>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>;
>>>>>> power-domain-names = "host", "superspeed";
>>>>>> };
>>>>>>
>>>>>> This RFC extends the generic PM domain framework to allow a device to
>>>>>> define more than one PM domain in the device-tree 'power-domains'
>>>>>> property. If there is more than one then the assumption is that these
>>>>>> PM domains will be controlled explicitly by the consumer and the device
>>>>>> will not be automatically bound to any PM domain.
>>>>>
>>>>> Any more comments/inputs on this? I can address Rajendra's feedback, but
>>>>> before I did I wanted to see if this is along the right lines or not?
>>>>
>>>> I discussed this with Rafael at the OSPM summit in Pisa a couple of
>>>> weeks ago. Apologize for the delay in providing additional feedback.
>>>>
>>>> First, whether the problem is really rare, perhaps adding a new
>>>> API/framework can't be justified - then it may be better to add some
>>>> kind of aggregation layer on top of the current PM domain
>>>> infrastructure (something along the first attempt you made for genpd).
>>>> That was kind of Rafael's thoughts (Rafael, please correct me if I am
>>>> wrong).
>>>
>>> We were talking about the original idea behind the pm_domain pointer
>>> concept, which was about adding a set of PM operations above the bus
>>> type/class layer, which could be used for intercepting bus-type PM
>>> operations and providing some common handling above them. This is
>>> still relevant IMO.
>>>
>>> The basic observation here is that the PM core takes only one set of
>>> PM operation per device into account and therefore, in every stage of
>>> system suspend, for example, the callback invoked by it has to take
>>> care of all actions that need to be carried out for the given device,
>>> possibly by invoking callbacks from other code layers. That
>>> limitation cannot be removed easily, because it is built into the PM
>>> core design quite fundamentally.
>>>
>>> However, this series seems to be about controlling power resources
>>> represented by power domain objects rather than about PM operations.
>>> In ACPI there is a power resource concept which seems to be quite
>>> similar to this, so it is not entirely new. :-)
>>>
>>> Of course, question is whether or not to extend genpd this way and I'm
>>> not really sure. I actually probably wouldn't do that, because
>>> poweron/poweroff operations used by genpd can be implemeted in terms
>>> of lower-level power resource control and I don't see the reason for
>>> mixing the two in one framework.
>>
>> That seems fine to me. However, it seems that genpd itself should also
>> be a client of this 'low-level power resource control' so that
>> power-domains are registered once and can be used by either method.
>
> Right.
>
>> So unless I am misunderstanding you here, it seems that what we need to do
>> is split the current genpd framework into a couple layers:
>>
>> 1. Low-level power resource control which has:
>> - Power resource registration (ie. pm_genpd_init/remove())
>> - Power resource provider registration (ie. of_genpd_add_xxx())
>> - Power resource control (on/off etc)
>
> And reference counting.
Yes, absolutely.
>> - Power resource lookup (what this series is adding)
>>
>> 2. Generic power-domain infrastructure which is a client of the
>> low-level power resource control that can automatically bind a device to
>> a singular power resource entity (ie. power-domain).
>
> Something like that, but I would not require an additional complex framework
> to be present below genpd. I would make it *possible* for genpd to use that
> framework if available, but if something simpler is sufficient, it should be
> fine to use that instead.
>
> That is, I would allow genpd to use either a list of power resources or the on/off
> callbacks provided by itself to cover different use cases. That should be
> flexible enough.
By a 'list', do you mean the pm_domain member of 'struct device' should
become a list instead? That would be a bigger change and I would need to
see how that would work.
>> Is this along the right lines?
>
> It is, at least for the very narrow definition of "right" as being done along
> the lines I would do that. :-)
Thanks
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
2017-04-25 19:34 ` Ulf Hansson
(?)
(?)
@ 2017-04-26 8:06 ` Geert Uytterhoeven
[not found] ` <CAMuHMdWvS6_Zf1nn1=zVLb1qNChyk+B6BDZsK9P9oKRBEpPKMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
-1 siblings, 1 reply; 59+ messages in thread
From: Geert Uytterhoeven @ 2017-04-26 8:06 UTC (permalink / raw)
To: Ulf Hansson
Cc: Jon Hunter, Rafael J . Wysocki, Kevin Hilman, Rajendra Nayak,
Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, linux-pm,
linux-kernel, linux-tegra
Hi Ulf,
On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> However, we currently know about at least two different SoCs that need
> this. Perhaps we can extend the below list to justify adding a new
> framework/APIs. Something along the lines what you propose in $subject
> patchset.
>
> 1) Nvidia; to solve the USB super-speed host/device problem.
> 2) QCOM, which has pointed to several cases where the PM topology is
> laid out like devices having two PM domains..
> 3?) I don't fully remember - but I think Geert also pointed to some
> examples where a device could reside in a clock domain but also in
> power domain for a Renesas SoC!?
> 4) ?
Most Renesas SoCs have module clocks, which we model as a clock domain.
Some Renesas SoCs have power domains for CPUs, others have them for
devices as well.
As we always provide a virtual "always-on" power domain in the power domain
controller, all devices can refer to it using "power-domains" properties,
and the driver for the power domain controller can just forward the clock
domain operations to the clock driver.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 59+ messages in thread