* [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-09-20 10:28 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra, Jon Hunter The Tegra124/210 XUSB subsystem (that consists of both host and device controllers) 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>; }; 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. Jon Hunter (3): PM / Domains: Add helper functions for finding and attaching PM domains PM / Domains: Add support for devices with multiple domains dt-bindings: Add support for devices with multiple PM domains .../devicetree/bindings/power/power_domain.txt | 5 +- drivers/base/power/domain.c | 205 +++++++++++++++------ 2 files changed, 155 insertions(+), 55 deletions(-) -- 2.1.4 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-09-20 10:28 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra, Jon Hunter The Tegra124/210 XUSB subsystem (that consists of both host and device controllers) 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>; }; 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. Jon Hunter (3): PM / Domains: Add helper functions for finding and attaching PM domains PM / Domains: Add support for devices with multiple domains dt-bindings: Add support for devices with multiple PM domains .../devicetree/bindings/power/power_domain.txt | 5 +- drivers/base/power/domain.c | 205 +++++++++++++++------ 2 files changed, 155 insertions(+), 55 deletions(-) -- 2.1.4 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [RFC PATCH 1/3] PM / Domains: Add helper functions for finding and attaching PM domains 2016-09-20 10:28 ` Jon Hunter @ 2016-09-20 10:28 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra, Jon Hunter In preparation for supporting devices that require more than one PM domain, move the code for finding and attaching PM domains into local helper functions. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> --- drivers/base/power/domain.c | 121 ++++++++++++++++++++++++++------------------ 1 file changed, 73 insertions(+), 48 deletions(-) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index b0cf46dcae73..382735949591 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -1779,6 +1779,41 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np) } EXPORT_SYMBOL_GPL(of_genpd_remove_last); +static struct generic_pm_domain *genpd_dev_pm_lookup(struct device *dev, + unsigned int index) +{ + struct of_phandle_args pd_args; + struct generic_pm_domain *pd; + int ret; + + ret = of_parse_phandle_with_args(dev->of_node, "power-domains", + "#power-domain-cells", index, &pd_args); + if (ret < 0) { + if (ret != -ENOENT) + return ERR_PTR(ret); + + /* + * Try legacy Samsung-specific bindings + * (for backwards compatibility of DT ABI) + */ + pd_args.args_count = 0; + pd_args.np = of_parse_phandle(dev->of_node, + "samsung,power-domain", 0); + if (!pd_args.np) + return ERR_PTR(-ENOENT); + } + + pd = genpd_get_from_provider(&pd_args); + of_node_put(pd_args.np); + if (IS_ERR(pd)) { + dev_dbg(dev, "%s() failed to find PM domain: %ld\n", + __func__, PTR_ERR(pd)); + return ERR_PTR(-EPROBE_DEFER); + } + + return pd; +} + /** * genpd_dev_pm_detach - Detach a device from its PM domain. * @dev: Device to detach. @@ -1829,6 +1864,40 @@ static void genpd_dev_pm_sync(struct device *dev) genpd_queue_power_off_work(pd); } +static int genpd_dev_pm_attach_device(struct device *dev, + struct generic_pm_domain *pd) +{ + unsigned int i; + int ret; + + dev_dbg(dev, "adding to PM domain %s\n", pd->name); + + for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) { + ret = genpd_add_device(pd, dev, NULL); + if (ret != -EAGAIN) + break; + + mdelay(i); + cond_resched(); + } + + if (ret < 0) { + dev_err(dev, "failed to add to PM domain %s: %d", + pd->name, ret); + goto out; + } + + dev->pm_domain->detach = genpd_dev_pm_detach; + dev->pm_domain->sync = genpd_dev_pm_sync; + + mutex_lock(&pd->lock); + ret = genpd_poweron(pd, 0); + mutex_unlock(&pd->lock); +out: + return ret ? -EPROBE_DEFER : 0; + +} + /** * genpd_dev_pm_attach - Attach a device to its PM domain using DT. * @dev: Device to attach. @@ -1846,9 +1915,7 @@ static void genpd_dev_pm_sync(struct device *dev) */ int genpd_dev_pm_attach(struct device *dev) { - struct of_phandle_args pd_args; struct generic_pm_domain *pd; - unsigned int i; int ret; if (!dev->of_node) @@ -1857,59 +1924,17 @@ int genpd_dev_pm_attach(struct device *dev) if (dev->pm_domain) return -EEXIST; - ret = of_parse_phandle_with_args(dev->of_node, "power-domains", - "#power-domain-cells", 0, &pd_args); - if (ret < 0) { - if (ret != -ENOENT) - return ret; - - /* - * Try legacy Samsung-specific bindings - * (for backwards compatibility of DT ABI) - */ - pd_args.args_count = 0; - pd_args.np = of_parse_phandle(dev->of_node, - "samsung,power-domain", 0); - if (!pd_args.np) - return -ENOENT; - } - mutex_lock(&gpd_list_lock); - pd = genpd_get_from_provider(&pd_args); - of_node_put(pd_args.np); + pd = genpd_dev_pm_lookup(dev, 0); if (IS_ERR(pd)) { mutex_unlock(&gpd_list_lock); - dev_dbg(dev, "%s() failed to find PM domain: %ld\n", - __func__, PTR_ERR(pd)); return -EPROBE_DEFER; } - dev_dbg(dev, "adding to PM domain %s\n", pd->name); - - for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) { - ret = genpd_add_device(pd, dev, NULL); - if (ret != -EAGAIN) - break; - - mdelay(i); - cond_resched(); - } - mutex_unlock(&gpd_list_lock); - - if (ret < 0) { - dev_err(dev, "failed to add to PM domain %s: %d", - pd->name, ret); - goto out; - } - - dev->pm_domain->detach = genpd_dev_pm_detach; - dev->pm_domain->sync = genpd_dev_pm_sync; + ret = genpd_dev_pm_attach_device(dev, pd); + mutex_lock(&gpd_list_lock); - mutex_lock(&pd->lock); - ret = genpd_poweron(pd, 0); - mutex_unlock(&pd->lock); -out: - return ret ? -EPROBE_DEFER : 0; + return ret; } EXPORT_SYMBOL_GPL(genpd_dev_pm_attach); #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */ -- 2.1.4 ^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC PATCH 1/3] PM / Domains: Add helper functions for finding and attaching PM domains @ 2016-09-20 10:28 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra, Jon Hunter In preparation for supporting devices that require more than one PM domain, move the code for finding and attaching PM domains into local helper functions. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> --- drivers/base/power/domain.c | 121 ++++++++++++++++++++++++++------------------ 1 file changed, 73 insertions(+), 48 deletions(-) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index b0cf46dcae73..382735949591 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -1779,6 +1779,41 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np) } EXPORT_SYMBOL_GPL(of_genpd_remove_last); +static struct generic_pm_domain *genpd_dev_pm_lookup(struct device *dev, + unsigned int index) +{ + struct of_phandle_args pd_args; + struct generic_pm_domain *pd; + int ret; + + ret = of_parse_phandle_with_args(dev->of_node, "power-domains", + "#power-domain-cells", index, &pd_args); + if (ret < 0) { + if (ret != -ENOENT) + return ERR_PTR(ret); + + /* + * Try legacy Samsung-specific bindings + * (for backwards compatibility of DT ABI) + */ + pd_args.args_count = 0; + pd_args.np = of_parse_phandle(dev->of_node, + "samsung,power-domain", 0); + if (!pd_args.np) + return ERR_PTR(-ENOENT); + } + + pd = genpd_get_from_provider(&pd_args); + of_node_put(pd_args.np); + if (IS_ERR(pd)) { + dev_dbg(dev, "%s() failed to find PM domain: %ld\n", + __func__, PTR_ERR(pd)); + return ERR_PTR(-EPROBE_DEFER); + } + + return pd; +} + /** * genpd_dev_pm_detach - Detach a device from its PM domain. * @dev: Device to detach. @@ -1829,6 +1864,40 @@ static void genpd_dev_pm_sync(struct device *dev) genpd_queue_power_off_work(pd); } +static int genpd_dev_pm_attach_device(struct device *dev, + struct generic_pm_domain *pd) +{ + unsigned int i; + int ret; + + dev_dbg(dev, "adding to PM domain %s\n", pd->name); + + for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) { + ret = genpd_add_device(pd, dev, NULL); + if (ret != -EAGAIN) + break; + + mdelay(i); + cond_resched(); + } + + if (ret < 0) { + dev_err(dev, "failed to add to PM domain %s: %d", + pd->name, ret); + goto out; + } + + dev->pm_domain->detach = genpd_dev_pm_detach; + dev->pm_domain->sync = genpd_dev_pm_sync; + + mutex_lock(&pd->lock); + ret = genpd_poweron(pd, 0); + mutex_unlock(&pd->lock); +out: + return ret ? -EPROBE_DEFER : 0; + +} + /** * genpd_dev_pm_attach - Attach a device to its PM domain using DT. * @dev: Device to attach. @@ -1846,9 +1915,7 @@ static void genpd_dev_pm_sync(struct device *dev) */ int genpd_dev_pm_attach(struct device *dev) { - struct of_phandle_args pd_args; struct generic_pm_domain *pd; - unsigned int i; int ret; if (!dev->of_node) @@ -1857,59 +1924,17 @@ int genpd_dev_pm_attach(struct device *dev) if (dev->pm_domain) return -EEXIST; - ret = of_parse_phandle_with_args(dev->of_node, "power-domains", - "#power-domain-cells", 0, &pd_args); - if (ret < 0) { - if (ret != -ENOENT) - return ret; - - /* - * Try legacy Samsung-specific bindings - * (for backwards compatibility of DT ABI) - */ - pd_args.args_count = 0; - pd_args.np = of_parse_phandle(dev->of_node, - "samsung,power-domain", 0); - if (!pd_args.np) - return -ENOENT; - } - mutex_lock(&gpd_list_lock); - pd = genpd_get_from_provider(&pd_args); - of_node_put(pd_args.np); + pd = genpd_dev_pm_lookup(dev, 0); if (IS_ERR(pd)) { mutex_unlock(&gpd_list_lock); - dev_dbg(dev, "%s() failed to find PM domain: %ld\n", - __func__, PTR_ERR(pd)); return -EPROBE_DEFER; } - dev_dbg(dev, "adding to PM domain %s\n", pd->name); - - for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) { - ret = genpd_add_device(pd, dev, NULL); - if (ret != -EAGAIN) - break; - - mdelay(i); - cond_resched(); - } - mutex_unlock(&gpd_list_lock); - - if (ret < 0) { - dev_err(dev, "failed to add to PM domain %s: %d", - pd->name, ret); - goto out; - } - - dev->pm_domain->detach = genpd_dev_pm_detach; - dev->pm_domain->sync = genpd_dev_pm_sync; + ret = genpd_dev_pm_attach_device(dev, pd); + mutex_lock(&gpd_list_lock); - mutex_lock(&pd->lock); - ret = genpd_poweron(pd, 0); - mutex_unlock(&pd->lock); -out: - return ret ? -EPROBE_DEFER : 0; + return ret; } EXPORT_SYMBOL_GPL(genpd_dev_pm_attach); #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */ -- 2.1.4 ^ permalink raw reply related [flat|nested] 91+ messages in thread
[parent not found: <1474367287-10402-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-20 10:28 ` Jon Hunter @ 2016-09-20 10:28 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Jon Hunter Some devices may require more than one PM domain to operate and this is not currently by the PM domain framework. Furthermore, the current Linux 'device' structure only allows devices to be associated with a single PM domain and so cannot easily be associated with more than one. To allow devices to be associated with more than one PM domain, if multiple domains are defined for a given device (eg. via device-tree), then: 1. Create a new PM domain for this device. The name of the new PM domain created matches the device name for which it was created for. 2. Register the new PM domain as a sub-domain for all PM domains required by the device. 3. Attach the device to the new PM domain. By default the newly created PM domain is assumed to be in the 'off' state to ensure that any parent PM domains will be turned on if not already on when the new PM domain is turned on. When a device associated with more than one PM domain is detached, wait for any power-off work to complete, then remove the PM domain that was created for the device by calling pm_genpd_remove() (this also removes it as a child to any other PM domains) and free the memory for the PM domain. For devices using device-tree, devices that require multiple PM domains are detected by seeing if the 'power-domains' property has more than one entry defined. Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> --- Here is an example output from pm_genpd_summary following this change for the Tegra210 XHCI device: domain status slaves /device runtime status ---------------------------------------------------------------------- 70090000.usb on /devices/platform/70090000.usb unsupported xusbc on 70090000.usb xusbb off-0 xusba on 70090000.usb I am not sure if this is confusing to have a device and domain with the same name. So let me know if you have any thoughts! drivers/base/power/domain.c | 102 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 88 insertions(+), 14 deletions(-) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index 382735949591..ee39824c03b3 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -1826,7 +1826,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) { struct generic_pm_domain *pd; unsigned int i; - int ret = 0; + int count, ret = 0; pd = genpd_lookup_dev(dev); if (!pd) @@ -1851,6 +1851,19 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) /* Check if PM domain can be powered off after removing this device. */ genpd_queue_power_off_work(pd); + + count = of_count_phandle_with_args(dev->of_node, "power-domains", + "#power-domain-cells"); + if (count > 1) { + cancel_work_sync(&pd->power_off_work); + + ret = pm_genpd_remove(pd); + if (ret < 0) + dev_err(dev, "failed to remove PM domain %s: %d\n", + pd->name, ret); + + kfree(pd); + } } static void genpd_dev_pm_sync(struct device *dev) @@ -1898,6 +1911,73 @@ static int genpd_dev_pm_attach_device(struct device *dev, } +static int genpd_dev_pm_attach_one(struct device *dev) +{ + struct generic_pm_domain *pd; + int ret; + + mutex_lock(&gpd_list_lock); + pd = genpd_dev_pm_lookup(dev, 0); + if (IS_ERR(pd)) { + mutex_unlock(&gpd_list_lock); + return PTR_ERR(pd); + } + + ret = genpd_dev_pm_attach_device(dev, pd); + mutex_unlock(&gpd_list_lock); + + return ret; +} + +static int genpd_dev_pm_attach_many(struct device *dev, unsigned int count) +{ + struct generic_pm_domain *pd, *parent; + unsigned int i; + int ret; + + pd = kzalloc(sizeof(*pd), GFP_KERNEL); + if (!pd) + return -ENOMEM; + + pd->name = dev_name(dev); + + ret = pm_genpd_init(pd, NULL, true); + if (ret < 0) + goto err_free; + + mutex_lock(&gpd_list_lock); + for (i = 0; i < count; i++) { + parent = genpd_dev_pm_lookup(dev, i); + if (IS_ERR(parent)) { + ret = PTR_ERR(parent); + goto err_remove; + } + + ret = genpd_add_subdomain(parent, pd); + if (ret < 0) + goto err_remove; + + } + + ret = genpd_dev_pm_attach_device(dev, pd); + if (ret < 0) + goto err_remove; + + mutex_unlock(&gpd_list_lock); + + return ret; + +err_remove: + WARN_ON(genpd_remove(pd)); + + mutex_unlock(&gpd_list_lock); + +err_free: + kfree(pd); + + return ret; +} + /** * genpd_dev_pm_attach - Attach a device to its PM domain using DT. * @dev: Device to attach. @@ -1915,8 +1995,7 @@ static int genpd_dev_pm_attach_device(struct device *dev, */ int genpd_dev_pm_attach(struct device *dev) { - struct generic_pm_domain *pd; - int ret; + int count; if (!dev->of_node) return -ENODEV; @@ -1924,17 +2003,12 @@ int genpd_dev_pm_attach(struct device *dev) if (dev->pm_domain) return -EEXIST; - mutex_lock(&gpd_list_lock); - pd = genpd_dev_pm_lookup(dev, 0); - if (IS_ERR(pd)) { - mutex_unlock(&gpd_list_lock); - return -EPROBE_DEFER; - } - - ret = genpd_dev_pm_attach_device(dev, pd); - mutex_lock(&gpd_list_lock); - - return ret; + count = of_count_phandle_with_args(dev->of_node, "power-domains", + "#power-domain-cells"); + if (count > 1) + return genpd_dev_pm_attach_many(dev, count); + else + return genpd_dev_pm_attach_one(dev); } EXPORT_SYMBOL_GPL(genpd_dev_pm_attach); #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */ -- 2.1.4 ^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-20 10:28 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra, Jon Hunter Some devices may require more than one PM domain to operate and this is not currently by the PM domain framework. Furthermore, the current Linux 'device' structure only allows devices to be associated with a single PM domain and so cannot easily be associated with more than one. To allow devices to be associated with more than one PM domain, if multiple domains are defined for a given device (eg. via device-tree), then: 1. Create a new PM domain for this device. The name of the new PM domain created matches the device name for which it was created for. 2. Register the new PM domain as a sub-domain for all PM domains required by the device. 3. Attach the device to the new PM domain. By default the newly created PM domain is assumed to be in the 'off' state to ensure that any parent PM domains will be turned on if not already on when the new PM domain is turned on. When a device associated with more than one PM domain is detached, wait for any power-off work to complete, then remove the PM domain that was created for the device by calling pm_genpd_remove() (this also removes it as a child to any other PM domains) and free the memory for the PM domain. For devices using device-tree, devices that require multiple PM domains are detected by seeing if the 'power-domains' property has more than one entry defined. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> --- Here is an example output from pm_genpd_summary following this change for the Tegra210 XHCI device: domain status slaves /device runtime status ---------------------------------------------------------------------- 70090000.usb on /devices/platform/70090000.usb unsupported xusbc on 70090000.usb xusbb off-0 xusba on 70090000.usb I am not sure if this is confusing to have a device and domain with the same name. So let me know if you have any thoughts! drivers/base/power/domain.c | 102 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 88 insertions(+), 14 deletions(-) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index 382735949591..ee39824c03b3 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -1826,7 +1826,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) { struct generic_pm_domain *pd; unsigned int i; - int ret = 0; + int count, ret = 0; pd = genpd_lookup_dev(dev); if (!pd) @@ -1851,6 +1851,19 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) /* Check if PM domain can be powered off after removing this device. */ genpd_queue_power_off_work(pd); + + count = of_count_phandle_with_args(dev->of_node, "power-domains", + "#power-domain-cells"); + if (count > 1) { + cancel_work_sync(&pd->power_off_work); + + ret = pm_genpd_remove(pd); + if (ret < 0) + dev_err(dev, "failed to remove PM domain %s: %d\n", + pd->name, ret); + + kfree(pd); + } } static void genpd_dev_pm_sync(struct device *dev) @@ -1898,6 +1911,73 @@ static int genpd_dev_pm_attach_device(struct device *dev, } +static int genpd_dev_pm_attach_one(struct device *dev) +{ + struct generic_pm_domain *pd; + int ret; + + mutex_lock(&gpd_list_lock); + pd = genpd_dev_pm_lookup(dev, 0); + if (IS_ERR(pd)) { + mutex_unlock(&gpd_list_lock); + return PTR_ERR(pd); + } + + ret = genpd_dev_pm_attach_device(dev, pd); + mutex_unlock(&gpd_list_lock); + + return ret; +} + +static int genpd_dev_pm_attach_many(struct device *dev, unsigned int count) +{ + struct generic_pm_domain *pd, *parent; + unsigned int i; + int ret; + + pd = kzalloc(sizeof(*pd), GFP_KERNEL); + if (!pd) + return -ENOMEM; + + pd->name = dev_name(dev); + + ret = pm_genpd_init(pd, NULL, true); + if (ret < 0) + goto err_free; + + mutex_lock(&gpd_list_lock); + for (i = 0; i < count; i++) { + parent = genpd_dev_pm_lookup(dev, i); + if (IS_ERR(parent)) { + ret = PTR_ERR(parent); + goto err_remove; + } + + ret = genpd_add_subdomain(parent, pd); + if (ret < 0) + goto err_remove; + + } + + ret = genpd_dev_pm_attach_device(dev, pd); + if (ret < 0) + goto err_remove; + + mutex_unlock(&gpd_list_lock); + + return ret; + +err_remove: + WARN_ON(genpd_remove(pd)); + + mutex_unlock(&gpd_list_lock); + +err_free: + kfree(pd); + + return ret; +} + /** * genpd_dev_pm_attach - Attach a device to its PM domain using DT. * @dev: Device to attach. @@ -1915,8 +1995,7 @@ static int genpd_dev_pm_attach_device(struct device *dev, */ int genpd_dev_pm_attach(struct device *dev) { - struct generic_pm_domain *pd; - int ret; + int count; if (!dev->of_node) return -ENODEV; @@ -1924,17 +2003,12 @@ int genpd_dev_pm_attach(struct device *dev) if (dev->pm_domain) return -EEXIST; - mutex_lock(&gpd_list_lock); - pd = genpd_dev_pm_lookup(dev, 0); - if (IS_ERR(pd)) { - mutex_unlock(&gpd_list_lock); - return -EPROBE_DEFER; - } - - ret = genpd_dev_pm_attach_device(dev, pd); - mutex_lock(&gpd_list_lock); - - return ret; + count = of_count_phandle_with_args(dev->of_node, "power-domains", + "#power-domain-cells"); + if (count > 1) + return genpd_dev_pm_attach_many(dev, count); + else + return genpd_dev_pm_attach_one(dev); } EXPORT_SYMBOL_GPL(genpd_dev_pm_attach); #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */ -- 2.1.4 ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-20 10:28 ` Jon Hunter @ 2016-09-20 17:54 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 17:54 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra On 20/09/16 11:28, Jon Hunter wrote: > Some devices may require more than one PM domain to operate and this is > not currently by the PM domain framework. Furthermore, the current Linux > 'device' structure only allows devices to be associated with a single PM > domain and so cannot easily be associated with more than one. To allow > devices to be associated with more than one PM domain, if multiple > domains are defined for a given device (eg. via device-tree), then: > 1. Create a new PM domain for this device. The name of the new PM domain > created matches the device name for which it was created for. > 2. Register the new PM domain as a sub-domain for all PM domains > required by the device. > 3. Attach the device to the new PM domain. > > By default the newly created PM domain is assumed to be in the 'off' > state to ensure that any parent PM domains will be turned on if not > already on when the new PM domain is turned on. > > When a device associated with more than one PM domain is detached, > wait for any power-off work to complete, then remove the PM domain that > was created for the device by calling pm_genpd_remove() (this also > removes it as a child to any other PM domains) and free the memory > for the PM domain. > > For devices using device-tree, devices that require multiple PM domains > are detected by seeing if the 'power-domains' property has more than one > entry defined. > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > --- > > Here is an example output from pm_genpd_summary following this change > for the Tegra210 XHCI device: > > domain status slaves > /device runtime status > ---------------------------------------------------------------------- > 70090000.usb on > /devices/platform/70090000.usb unsupported > xusbc on 70090000.usb > xusbb off-0 > xusba on 70090000.usb > > I am not sure if this is confusing to have a device and domain with the > same name. So let me know if you have any thoughts! > > > drivers/base/power/domain.c | 102 ++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 88 insertions(+), 14 deletions(-) > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index 382735949591..ee39824c03b3 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -1826,7 +1826,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) > { > struct generic_pm_domain *pd; > unsigned int i; > - int ret = 0; > + int count, ret = 0; > > pd = genpd_lookup_dev(dev); > if (!pd) > @@ -1851,6 +1851,19 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) > > /* Check if PM domain can be powered off after removing this device. */ > genpd_queue_power_off_work(pd); > + > + count = of_count_phandle_with_args(dev->of_node, "power-domains", > + "#power-domain-cells"); > + if (count > 1) { > + cancel_work_sync(&pd->power_off_work); > + > + ret = pm_genpd_remove(pd); > + if (ret < 0) > + dev_err(dev, "failed to remove PM domain %s: %d\n", > + pd->name, ret); > + > + kfree(pd); I realise I am missing a return if pm_genpd_remove() returns a failure! Will correct this. Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-20 17:54 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 17:54 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra On 20/09/16 11:28, Jon Hunter wrote: > Some devices may require more than one PM domain to operate and this is > not currently by the PM domain framework. Furthermore, the current Linux > 'device' structure only allows devices to be associated with a single PM > domain and so cannot easily be associated with more than one. To allow > devices to be associated with more than one PM domain, if multiple > domains are defined for a given device (eg. via device-tree), then: > 1. Create a new PM domain for this device. The name of the new PM domain > created matches the device name for which it was created for. > 2. Register the new PM domain as a sub-domain for all PM domains > required by the device. > 3. Attach the device to the new PM domain. > > By default the newly created PM domain is assumed to be in the 'off' > state to ensure that any parent PM domains will be turned on if not > already on when the new PM domain is turned on. > > When a device associated with more than one PM domain is detached, > wait for any power-off work to complete, then remove the PM domain that > was created for the device by calling pm_genpd_remove() (this also > removes it as a child to any other PM domains) and free the memory > for the PM domain. > > For devices using device-tree, devices that require multiple PM domains > are detected by seeing if the 'power-domains' property has more than one > entry defined. > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com> > --- > > Here is an example output from pm_genpd_summary following this change > for the Tegra210 XHCI device: > > domain status slaves > /device runtime status > ---------------------------------------------------------------------- > 70090000.usb on > /devices/platform/70090000.usb unsupported > xusbc on 70090000.usb > xusbb off-0 > xusba on 70090000.usb > > I am not sure if this is confusing to have a device and domain with the > same name. So let me know if you have any thoughts! > > > drivers/base/power/domain.c | 102 ++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 88 insertions(+), 14 deletions(-) > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index 382735949591..ee39824c03b3 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -1826,7 +1826,7 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) > { > struct generic_pm_domain *pd; > unsigned int i; > - int ret = 0; > + int count, ret = 0; > > pd = genpd_lookup_dev(dev); > if (!pd) > @@ -1851,6 +1851,19 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off) > > /* Check if PM domain can be powered off after removing this device. */ > genpd_queue_power_off_work(pd); > + > + count = of_count_phandle_with_args(dev->of_node, "power-domains", > + "#power-domain-cells"); > + if (count > 1) { > + cancel_work_sync(&pd->power_off_work); > + > + ret = pm_genpd_remove(pd); > + if (ret < 0) > + dev_err(dev, "failed to remove PM domain %s: %d\n", > + pd->name, ret); > + > + kfree(pd); I realise I am missing a return if pm_genpd_remove() returns a failure! Will correct this. Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-20 10:28 ` Jon Hunter (?) (?) @ 2016-09-21 8:53 ` Geert Uytterhoeven 2016-09-21 10:01 ` Jon Hunter [not found] ` <CAMuHMdVc+EjkbcpPKyzbCfDjp65gF3xP3bhkjh6SKLt6KDTtXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> -1 siblings, 2 replies; 91+ messages in thread From: Geert Uytterhoeven @ 2016-09-21 8:53 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Jon, On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: > Some devices may require more than one PM domain to operate and this is > not currently by the PM domain framework. Furthermore, the current Linux > 'device' structure only allows devices to be associated with a single PM > domain and so cannot easily be associated with more than one. To allow > devices to be associated with more than one PM domain, if multiple > domains are defined for a given device (eg. via device-tree), then: > 1. Create a new PM domain for this device. The name of the new PM domain > created matches the device name for which it was created for. > 2. Register the new PM domain as a sub-domain for all PM domains > required by the device. > 3. Attach the device to the new PM domain. This looks a suboptimal to me: if you have n devices sharing the same PM domains, you would add n new subdomains? Having a clean way to specify multiple PM domains is very useful, though. E.g. on Renesas ARM SoCs, devices are usually part of two PM domains: 1. A power area (can be "always-on", 2. The clock domain. As power areas and clock domains are fairly orthogonal (the former use the .power_{off,on}() callbacks, the latter set GENPD_FLAG_PM_CLK and use the {at,de}tach_dev() callbacks), we currently setup both in the same driver (SYSC, for controlling power areas), which forwards the clock domain operations to the clock driver (CPG/MSTP or CPG/MSSR). Hence we have only single references in the power-domains properties, but having two would allow to drop the hardcoded links between the two drivers. (Oh no, more DT backwards compatibility issues if this is accepted ;-) 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] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-21 8:53 ` Geert Uytterhoeven @ 2016-09-21 10:01 ` Jon Hunter [not found] ` <CAMuHMdVc+EjkbcpPKyzbCfDjp65gF3xP3bhkjh6SKLt6KDTtXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-21 10:01 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Geert, On 21/09/16 09:53, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure only allows devices to be associated with a single PM >> domain and so cannot easily be associated with more than one. To allow >> devices to be associated with more than one PM domain, if multiple >> domains are defined for a given device (eg. via device-tree), then: >> 1. Create a new PM domain for this device. The name of the new PM domain >> created matches the device name for which it was created for. >> 2. Register the new PM domain as a sub-domain for all PM domains >> required by the device. >> 3. Attach the device to the new PM domain. > > This looks a suboptimal to me: if you have n devices sharing the same PM > domains, you would add n new subdomains? Yes you would and so in that case it would appear to be suboptimal, I agree. One option would be to name the new PM domain after its parents and then see if any PM domains exist that matches the name and verify it has the required parents. We could even add a prefix to the name to indicate that this is a PM domain added by the core. Only problem is we could get some long names! > Having a clean way to specify multiple PM domains is very useful, though. > > E.g. on Renesas ARM SoCs, devices are usually part of two PM domains: > 1. A power area (can be "always-on", > 2. The clock domain. > > As power areas and clock domains are fairly orthogonal (the former use the > .power_{off,on}() callbacks, the latter set GENPD_FLAG_PM_CLK and use the > {at,de}tach_dev() callbacks), we currently setup both in the same driver > (SYSC, for controlling power areas), which forwards the clock domain operations > to the clock driver (CPG/MSTP or CPG/MSSR). > Hence we have only single references in the power-domains properties, but > having two would allow to drop the hardcoded links between the two drivers. Glad to see others could benefit from this ... > (Oh no, more DT backwards compatibility issues if this is accepted ;-) ... despite DT compat issues :-( Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-21 10:01 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-21 10:01 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Geert, On 21/09/16 09:53, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure only allows devices to be associated with a single PM >> domain and so cannot easily be associated with more than one. To allow >> devices to be associated with more than one PM domain, if multiple >> domains are defined for a given device (eg. via device-tree), then: >> 1. Create a new PM domain for this device. The name of the new PM domain >> created matches the device name for which it was created for. >> 2. Register the new PM domain as a sub-domain for all PM domains >> required by the device. >> 3. Attach the device to the new PM domain. > > This looks a suboptimal to me: if you have n devices sharing the same PM > domains, you would add n new subdomains? Yes you would and so in that case it would appear to be suboptimal, I agree. One option would be to name the new PM domain after its parents and then see if any PM domains exist that matches the name and verify it has the required parents. We could even add a prefix to the name to indicate that this is a PM domain added by the core. Only problem is we could get some long names! > Having a clean way to specify multiple PM domains is very useful, though. > > E.g. on Renesas ARM SoCs, devices are usually part of two PM domains: > 1. A power area (can be "always-on", > 2. The clock domain. > > As power areas and clock domains are fairly orthogonal (the former use the > .power_{off,on}() callbacks, the latter set GENPD_FLAG_PM_CLK and use the > {at,de}tach_dev() callbacks), we currently setup both in the same driver > (SYSC, for controlling power areas), which forwards the clock domain operations > to the clock driver (CPG/MSTP or CPG/MSSR). > Hence we have only single references in the power-domains properties, but > having two would allow to drop the hardcoded links between the two drivers. Glad to see others could benefit from this ... > (Oh no, more DT backwards compatibility issues if this is accepted ;-) ... despite DT compat issues :-( Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <CAMuHMdVc+EjkbcpPKyzbCfDjp65gF3xP3bhkjh6SKLt6KDTtXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-21 8:53 ` Geert Uytterhoeven @ 2016-09-21 14:37 ` Jon Hunter [not found] ` <CAMuHMdVc+EjkbcpPKyzbCfDjp65gF3xP3bhkjh6SKLt6KDTtXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-21 14:37 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas Hi Geert, On 21/09/16 09:53, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure only allows devices to be associated with a single PM >> domain and so cannot easily be associated with more than one. To allow >> devices to be associated with more than one PM domain, if multiple >> domains are defined for a given device (eg. via device-tree), then: >> 1. Create a new PM domain for this device. The name of the new PM domain >> created matches the device name for which it was created for. >> 2. Register the new PM domain as a sub-domain for all PM domains >> required by the device. >> 3. Attach the device to the new PM domain. > > This looks a suboptimal to me: if you have n devices sharing the same PM > domains, you would add n new subdomains? BTW, would this be the case today for some renesas devices or are you just pointing this out as something that could be optimised/improved? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-21 14:37 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-21 14:37 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Geert, On 21/09/16 09:53, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure only allows devices to be associated with a single PM >> domain and so cannot easily be associated with more than one. To allow >> devices to be associated with more than one PM domain, if multiple >> domains are defined for a given device (eg. via device-tree), then: >> 1. Create a new PM domain for this device. The name of the new PM domain >> created matches the device name for which it was created for. >> 2. Register the new PM domain as a sub-domain for all PM domains >> required by the device. >> 3. Attach the device to the new PM domain. > > This looks a suboptimal to me: if you have n devices sharing the same PM > domains, you would add n new subdomains? BTW, would this be the case today for some renesas devices or are you just pointing this out as something that could be optimised/improved? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <658004af-e4f4-8b0c-cdc1-43661d331d70-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-21 14:37 ` Jon Hunter @ 2016-09-21 14:57 ` Geert Uytterhoeven -1 siblings, 0 replies; 91+ messages in thread From: Geert Uytterhoeven @ 2016-09-21 14:57 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas Hi Jon, On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > On 21/09/16 09:53, Geert Uytterhoeven wrote: >> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>> Some devices may require more than one PM domain to operate and this is >>> not currently by the PM domain framework. Furthermore, the current Linux >>> 'device' structure only allows devices to be associated with a single PM >>> domain and so cannot easily be associated with more than one. To allow >>> devices to be associated with more than one PM domain, if multiple >>> domains are defined for a given device (eg. via device-tree), then: >>> 1. Create a new PM domain for this device. The name of the new PM domain >>> created matches the device name for which it was created for. >>> 2. Register the new PM domain as a sub-domain for all PM domains >>> required by the device. >>> 3. Attach the device to the new PM domain. >> >> This looks a suboptimal to me: if you have n devices sharing the same PM >> domains, you would add n new subdomains? > > BTW, would this be the case today for some renesas devices or are you > just pointing this out as something that could be optimised/improved? This is the case for all Renesas SoCs that have power areas: devices belong to both the PM domain for the power area, and to the PM domain for the clock domain. See setting of .attach_dev in arch/arm/mach-shmobile/pm-rmobile.c (power areas + clock domain) drivers/clk/renesas/clk-mstp.c (pure clock domain) drivers/clk/renesas/renesas-cpg-mssr.c (pure clock domain) drivers/soc/renesas/rcar-sysc.c (power areas + clock domain) AFAIK there are no devices that belong to multiple power areas (power areas may be nested though, which is handled fine by the current framework, as created by Rafael when he worked on Renesas SoCs). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-21 14:57 ` Geert Uytterhoeven 0 siblings, 0 replies; 91+ messages in thread From: Geert Uytterhoeven @ 2016-09-21 14:57 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Jon, On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh@nvidia.com> wrote: > On 21/09/16 09:53, Geert Uytterhoeven wrote: >> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> Some devices may require more than one PM domain to operate and this is >>> not currently by the PM domain framework. Furthermore, the current Linux >>> 'device' structure only allows devices to be associated with a single PM >>> domain and so cannot easily be associated with more than one. To allow >>> devices to be associated with more than one PM domain, if multiple >>> domains are defined for a given device (eg. via device-tree), then: >>> 1. Create a new PM domain for this device. The name of the new PM domain >>> created matches the device name for which it was created for. >>> 2. Register the new PM domain as a sub-domain for all PM domains >>> required by the device. >>> 3. Attach the device to the new PM domain. >> >> This looks a suboptimal to me: if you have n devices sharing the same PM >> domains, you would add n new subdomains? > > BTW, would this be the case today for some renesas devices or are you > just pointing this out as something that could be optimised/improved? This is the case for all Renesas SoCs that have power areas: devices belong to both the PM domain for the power area, and to the PM domain for the clock domain. See setting of .attach_dev in arch/arm/mach-shmobile/pm-rmobile.c (power areas + clock domain) drivers/clk/renesas/clk-mstp.c (pure clock domain) drivers/clk/renesas/renesas-cpg-mssr.c (pure clock domain) drivers/soc/renesas/rcar-sysc.c (power areas + clock domain) AFAIK there are no devices that belong to multiple power areas (power areas may be nested though, which is handled fine by the current framework, as created by Rafael when he worked on Renesas SoCs). 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] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-21 14:57 ` Geert Uytterhoeven @ 2016-09-23 12:57 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-23 12:57 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Geert, On 21/09/16 15:57, Geert Uytterhoeven wrote: > Hi Jon, > > On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 21/09/16 09:53, Geert Uytterhoeven wrote: >>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> Some devices may require more than one PM domain to operate and this is >>>> not currently by the PM domain framework. Furthermore, the current Linux >>>> 'device' structure only allows devices to be associated with a single PM >>>> domain and so cannot easily be associated with more than one. To allow >>>> devices to be associated with more than one PM domain, if multiple >>>> domains are defined for a given device (eg. via device-tree), then: >>>> 1. Create a new PM domain for this device. The name of the new PM domain >>>> created matches the device name for which it was created for. >>>> 2. Register the new PM domain as a sub-domain for all PM domains >>>> required by the device. >>>> 3. Attach the device to the new PM domain. >>> >>> This looks a suboptimal to me: if you have n devices sharing the same PM >>> domains, you would add n new subdomains? >> >> BTW, would this be the case today for some renesas devices or are you >> just pointing this out as something that could be optimised/improved? > > This is the case for all Renesas SoCs that have power areas: devices belong > to both the PM domain for the power area, and to the PM domain for the clock > domain. To quantify this a bit, for the Renesas case, how many of these duplicated domains would there be if you were to use this approach as-is? I would like to see some agreement about whether we would allow the 'power-domains' property to have more than one power-domain. We could always improve the implementation in the future. I am quite happy to re-work this RFC to avoid duplicated domains for devices like Renesas if people are on board with the overall proposal. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-23 12:57 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-23 12:57 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Geert, On 21/09/16 15:57, Geert Uytterhoeven wrote: > Hi Jon, > > On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 21/09/16 09:53, Geert Uytterhoeven wrote: >>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> Some devices may require more than one PM domain to operate and this is >>>> not currently by the PM domain framework. Furthermore, the current Linux >>>> 'device' structure only allows devices to be associated with a single PM >>>> domain and so cannot easily be associated with more than one. To allow >>>> devices to be associated with more than one PM domain, if multiple >>>> domains are defined for a given device (eg. via device-tree), then: >>>> 1. Create a new PM domain for this device. The name of the new PM domain >>>> created matches the device name for which it was created for. >>>> 2. Register the new PM domain as a sub-domain for all PM domains >>>> required by the device. >>>> 3. Attach the device to the new PM domain. >>> >>> This looks a suboptimal to me: if you have n devices sharing the same PM >>> domains, you would add n new subdomains? >> >> BTW, would this be the case today for some renesas devices or are you >> just pointing this out as something that could be optimised/improved? > > This is the case for all Renesas SoCs that have power areas: devices belong > to both the PM domain for the power area, and to the PM domain for the clock > domain. To quantify this a bit, for the Renesas case, how many of these duplicated domains would there be if you were to use this approach as-is? I would like to see some agreement about whether we would allow the 'power-domains' property to have more than one power-domain. We could always improve the implementation in the future. I am quite happy to re-work this RFC to avoid duplicated domains for devices like Renesas if people are on board with the overall proposal. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <1c217cf4-8682-8e6d-6958-419923e995cd-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-23 12:57 ` Jon Hunter @ 2016-09-23 14:27 ` Geert Uytterhoeven -1 siblings, 0 replies; 91+ messages in thread From: Geert Uytterhoeven @ 2016-09-23 14:27 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas Hi Jon, On Fri, Sep 23, 2016 at 2:57 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > On 21/09/16 15:57, Geert Uytterhoeven wrote: >> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>> On 21/09/16 09:53, Geert Uytterhoeven wrote: >>>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>>>> Some devices may require more than one PM domain to operate and this is >>>>> not currently by the PM domain framework. Furthermore, the current Linux >>>>> 'device' structure only allows devices to be associated with a single PM >>>>> domain and so cannot easily be associated with more than one. To allow >>>>> devices to be associated with more than one PM domain, if multiple >>>>> domains are defined for a given device (eg. via device-tree), then: >>>>> 1. Create a new PM domain for this device. The name of the new PM domain >>>>> created matches the device name for which it was created for. >>>>> 2. Register the new PM domain as a sub-domain for all PM domains >>>>> required by the device. >>>>> 3. Attach the device to the new PM domain. >>>> >>>> This looks a suboptimal to me: if you have n devices sharing the same PM >>>> domains, you would add n new subdomains? >>> >>> BTW, would this be the case today for some renesas devices or are you >>> just pointing this out as something that could be optimised/improved? >> >> This is the case for all Renesas SoCs that have power areas: devices belong >> to both the PM domain for the power area, and to the PM domain for the clock >> domain. > > To quantify this a bit, for the Renesas case, how many of these > duplicated domains would there be if you were to use this approach as-is? for i in $(git grep -l renesas, -- "*dts*") ; do echo --- $i ---; git grep -w power-domains $i | sort | uniq -c | sort -n;done tells you how many (supported) devices are (currently) present in each PM domain. Most of these (all but devices in CPU/SCU power areas) are also part of a clock domain. The synthetic R8A779*_PD_ALWAYS_ON domains could be dropped again, as we could just refer to the CPG/MSSR node for the clock domain instead. For older SH/R-Mobile SoCs with lots of hierarchical domains, that gives us, after removing the above: 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4mp>; 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_d4>; 2 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_c5>; 3 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4r>; 6 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4s>; 15 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a3sp>; R-Car Gen1/Gen2 have all devices in the "always on" PM domain, so they're not affected. R-Car Gen3 again has devices in power areas, mostly for graphics related purposes: 16 arch/arm64/boot/dts/renesas/r8a7795.dtsi: power-domains = <&sysc R8A7795_PD_A3VP>; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-23 14:27 ` Geert Uytterhoeven 0 siblings, 0 replies; 91+ messages in thread From: Geert Uytterhoeven @ 2016-09-23 14:27 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi Jon, On Fri, Sep 23, 2016 at 2:57 PM, Jon Hunter <jonathanh@nvidia.com> wrote: > On 21/09/16 15:57, Geert Uytterhoeven wrote: >> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> On 21/09/16 09:53, Geert Uytterhoeven wrote: >>>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>>> Some devices may require more than one PM domain to operate and this is >>>>> not currently by the PM domain framework. Furthermore, the current Linux >>>>> 'device' structure only allows devices to be associated with a single PM >>>>> domain and so cannot easily be associated with more than one. To allow >>>>> devices to be associated with more than one PM domain, if multiple >>>>> domains are defined for a given device (eg. via device-tree), then: >>>>> 1. Create a new PM domain for this device. The name of the new PM domain >>>>> created matches the device name for which it was created for. >>>>> 2. Register the new PM domain as a sub-domain for all PM domains >>>>> required by the device. >>>>> 3. Attach the device to the new PM domain. >>>> >>>> This looks a suboptimal to me: if you have n devices sharing the same PM >>>> domains, you would add n new subdomains? >>> >>> BTW, would this be the case today for some renesas devices or are you >>> just pointing this out as something that could be optimised/improved? >> >> This is the case for all Renesas SoCs that have power areas: devices belong >> to both the PM domain for the power area, and to the PM domain for the clock >> domain. > > To quantify this a bit, for the Renesas case, how many of these > duplicated domains would there be if you were to use this approach as-is? for i in $(git grep -l renesas, -- "*dts*") ; do echo --- $i ---; git grep -w power-domains $i | sort | uniq -c | sort -n;done tells you how many (supported) devices are (currently) present in each PM domain. Most of these (all but devices in CPU/SCU power areas) are also part of a clock domain. The synthetic R8A779*_PD_ALWAYS_ON domains could be dropped again, as we could just refer to the CPG/MSSR node for the clock domain instead. For older SH/R-Mobile SoCs with lots of hierarchical domains, that gives us, after removing the above: 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4mp>; 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_d4>; 2 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_c5>; 3 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4r>; 6 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4s>; 15 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a3sp>; R-Car Gen1/Gen2 have all devices in the "always on" PM domain, so they're not affected. R-Car Gen3 again has devices in power areas, mostly for graphics related purposes: 16 arch/arm64/boot/dts/renesas/r8a7795.dtsi: power-domains = <&sysc R8A7795_PD_A3VP>; 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] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-23 14:27 ` Geert Uytterhoeven @ 2016-09-30 8:05 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-30 8:05 UTC (permalink / raw) To: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi PM posse! On 23/09/16 15:27, Geert Uytterhoeven wrote: > Hi Jon, > > On Fri, Sep 23, 2016 at 2:57 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 21/09/16 15:57, Geert Uytterhoeven wrote: >>> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> On 21/09/16 09:53, Geert Uytterhoeven wrote: >>>>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>>>> Some devices may require more than one PM domain to operate and this is >>>>>> not currently by the PM domain framework. Furthermore, the current Linux >>>>>> 'device' structure only allows devices to be associated with a single PM >>>>>> domain and so cannot easily be associated with more than one. To allow >>>>>> devices to be associated with more than one PM domain, if multiple >>>>>> domains are defined for a given device (eg. via device-tree), then: >>>>>> 1. Create a new PM domain for this device. The name of the new PM domain >>>>>> created matches the device name for which it was created for. >>>>>> 2. Register the new PM domain as a sub-domain for all PM domains >>>>>> required by the device. >>>>>> 3. Attach the device to the new PM domain. >>>>> >>>>> This looks a suboptimal to me: if you have n devices sharing the same PM >>>>> domains, you would add n new subdomains? >>>> >>>> BTW, would this be the case today for some renesas devices or are you >>>> just pointing this out as something that could be optimised/improved? >>> >>> This is the case for all Renesas SoCs that have power areas: devices belong >>> to both the PM domain for the power area, and to the PM domain for the clock >>> domain. >> >> To quantify this a bit, for the Renesas case, how many of these >> duplicated domains would there be if you were to use this approach as-is? > > for i in $(git grep -l renesas, -- "*dts*") ; do echo --- $i ---; git > grep -w power-domains $i | sort | uniq -c | sort -n;done > > tells you how many (supported) devices are (currently) present in each > PM domain. > Most of these (all but devices in CPU/SCU power areas) are also part of a > clock domain. > The synthetic R8A779*_PD_ALWAYS_ON domains could be dropped again, > as we could just refer to the CPG/MSSR node for the clock domain instead. > > For older SH/R-Mobile SoCs with lots of hierarchical domains, that gives us, > after removing the above: > > 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4mp>; > 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_d4>; > 2 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_c5>; > 3 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4r>; > 6 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4s>; > 15 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a3sp>; > > R-Car Gen1/Gen2 have all devices in the "always on" PM domain, so they're > not affected. > > R-Car Gen3 again has devices in power areas, mostly for graphics related > purposes: > > 16 arch/arm64/boot/dts/renesas/r8a7795.dtsi: > power-domains = <&sysc R8A7795_PD_A3VP>; Does anyone have any more inputs comments on this? Does it look complete bonkers or should I forge ahead with this? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-09-30 8:05 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-30 8:05 UTC (permalink / raw) To: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: Linux PM list, linux-kernel, linux-tegra, Linux-Renesas Hi PM posse! On 23/09/16 15:27, Geert Uytterhoeven wrote: > Hi Jon, > > On Fri, Sep 23, 2016 at 2:57 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 21/09/16 15:57, Geert Uytterhoeven wrote: >>> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> On 21/09/16 09:53, Geert Uytterhoeven wrote: >>>>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>>>> Some devices may require more than one PM domain to operate and this is >>>>>> not currently by the PM domain framework. Furthermore, the current Linux >>>>>> 'device' structure only allows devices to be associated with a single PM >>>>>> domain and so cannot easily be associated with more than one. To allow >>>>>> devices to be associated with more than one PM domain, if multiple >>>>>> domains are defined for a given device (eg. via device-tree), then: >>>>>> 1. Create a new PM domain for this device. The name of the new PM domain >>>>>> created matches the device name for which it was created for. >>>>>> 2. Register the new PM domain as a sub-domain for all PM domains >>>>>> required by the device. >>>>>> 3. Attach the device to the new PM domain. >>>>> >>>>> This looks a suboptimal to me: if you have n devices sharing the same PM >>>>> domains, you would add n new subdomains? >>>> >>>> BTW, would this be the case today for some renesas devices or are you >>>> just pointing this out as something that could be optimised/improved? >>> >>> This is the case for all Renesas SoCs that have power areas: devices belong >>> to both the PM domain for the power area, and to the PM domain for the clock >>> domain. >> >> To quantify this a bit, for the Renesas case, how many of these >> duplicated domains would there be if you were to use this approach as-is? > > for i in $(git grep -l renesas, -- "*dts*") ; do echo --- $i ---; git > grep -w power-domains $i | sort | uniq -c | sort -n;done > > tells you how many (supported) devices are (currently) present in each > PM domain. > Most of these (all but devices in CPU/SCU power areas) are also part of a > clock domain. > The synthetic R8A779*_PD_ALWAYS_ON domains could be dropped again, > as we could just refer to the CPG/MSSR node for the clock domain instead. > > For older SH/R-Mobile SoCs with lots of hierarchical domains, that gives us, > after removing the above: > > 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4mp>; > 1 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_d4>; > 2 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_c5>; > 3 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4r>; > 6 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a4s>; > 15 arch/arm/boot/dts/r8a7740.dtsi: power-domains = <&pd_a3sp>; > > R-Car Gen1/Gen2 have all devices in the "always on" PM domain, so they're > not affected. > > R-Car Gen3 again has devices in power areas, mostly for graphics related > purposes: > > 16 arch/arm64/boot/dts/renesas/r8a7795.dtsi: > power-domains = <&sysc R8A7795_PD_A3VP>; Does anyone have any more inputs comments on this? Does it look complete bonkers or should I forge ahead with this? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-09-20 10:28 ` Jon Hunter @ 2016-10-07 9:14 ` Kevin Hilman -1 siblings, 0 replies; 91+ messages in thread From: Kevin Hilman @ 2016-10-07 9:14 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Ulf Hansson, linux-pm, linux-kernel, linux-tegra Jon Hunter <jonathanh@nvidia.com> writes: > Some devices may require more than one PM domain to operate and this is > not currently by the PM domain framework. Furthermore, the current Linux > 'device' structure only allows devices to be associated with a single PM > domain and so cannot easily be associated with more than one. To allow > devices to be associated with more than one PM domain, if multiple > domains are defined for a given device (eg. via device-tree), then: > 1. Create a new PM domain for this device. The name of the new PM domain > created matches the device name for which it was created for. > 2. Register the new PM domain as a sub-domain for all PM domains > required by the device. > 3. Attach the device to the new PM domain. Did you look at what might be involved to extend struct device to hace a list of pm_domains? Like Ulf, I'm a bit unsettled by this implementation that has to work around the basic limitation in the driver model. Having devices in multitple domains is needed for SoCs I'm familiar with also, so is a needed feature. I think removing the struct device limitation and corresponding assumptions in the driver and PM core is a prerequisite for this feature. Doing that will lead to several questions about how to handle runtime PM operations (e.g. which of the multiple PM domains should the one to call the drivers runtime PM hooks when a device changes runtime PM state?) Anyways, even with the potential complexities, I think attempting this is the right way forward. Kevin ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-10-07 9:14 ` Kevin Hilman 0 siblings, 0 replies; 91+ messages in thread From: Kevin Hilman @ 2016-10-07 9:14 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Ulf Hansson, linux-pm, linux-kernel, linux-tegra Jon Hunter <jonathanh@nvidia.com> writes: > Some devices may require more than one PM domain to operate and this is > not currently by the PM domain framework. Furthermore, the current Linux > 'device' structure only allows devices to be associated with a single PM > domain and so cannot easily be associated with more than one. To allow > devices to be associated with more than one PM domain, if multiple > domains are defined for a given device (eg. via device-tree), then: > 1. Create a new PM domain for this device. The name of the new PM domain > created matches the device name for which it was created for. > 2. Register the new PM domain as a sub-domain for all PM domains > required by the device. > 3. Attach the device to the new PM domain. Did you look at what might be involved to extend struct device to hace a list of pm_domains? Like Ulf, I'm a bit unsettled by this implementation that has to work around the basic limitation in the driver model. Having devices in multitple domains is needed for SoCs I'm familiar with also, so is a needed feature. I think removing the struct device limitation and corresponding assumptions in the driver and PM core is a prerequisite for this feature. Doing that will lead to several questions about how to handle runtime PM operations (e.g. which of the multiple PM domains should the one to call the drivers runtime PM hooks when a device changes runtime PM state?) Anyways, even with the potential complexities, I think attempting this is the right way forward. Kevin ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <7hlgy0frlb.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>]
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains 2016-10-07 9:14 ` Kevin Hilman @ 2016-10-10 11:24 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-10-10 11:24 UTC (permalink / raw) To: Kevin Hilman Cc: Rafael J. Wysocki, Ulf Hansson, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA On 07/10/16 10:14, Kevin Hilman wrote: > Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> writes: > >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure only allows devices to be associated with a single PM >> domain and so cannot easily be associated with more than one. To allow >> devices to be associated with more than one PM domain, if multiple >> domains are defined for a given device (eg. via device-tree), then: >> 1. Create a new PM domain for this device. The name of the new PM domain >> created matches the device name for which it was created for. >> 2. Register the new PM domain as a sub-domain for all PM domains >> required by the device. >> 3. Attach the device to the new PM domain. > > Did you look at what might be involved to extend struct device to hace a > list of pm_domains? Like Ulf, I'm a bit unsettled by this > implementation that has to work around the basic limitation in the > driver model. I had but it was going to be a much bigger and intrusive change. So I went with this as a initial idea to see if others also had a need for it. I am happy to start looking at extended the device struct if this is the preferred path and I would agree that would make most sense. > Having devices in multitple domains is needed for SoCs I'm familiar with > also, so is a needed feature. Ok great. > I think removing the struct device limitation and corresponding > assumptions in the driver and PM core is a prerequisite for this > feature. > > Doing that will lead to several questions about how to handle runtime PM > operations (e.g. which of the multiple PM domains should the one to call > the drivers runtime PM hooks when a device changes runtime PM state?) Right. My initial thought would be that at least for device-tree based configuration, that the order in which the pm-domains are defined in DT would determine the order in which the pm-domains are power-on/off. > Anyways, even with the potential complexities, I think attempting this > is the right way forward. Ok. I will start having a think about this but will probably not get back to this for a few weeks. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains @ 2016-10-10 11:24 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-10-10 11:24 UTC (permalink / raw) To: Kevin Hilman Cc: Rafael J. Wysocki, Ulf Hansson, linux-pm, linux-kernel, linux-tegra On 07/10/16 10:14, Kevin Hilman wrote: > Jon Hunter <jonathanh@nvidia.com> writes: > >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure only allows devices to be associated with a single PM >> domain and so cannot easily be associated with more than one. To allow >> devices to be associated with more than one PM domain, if multiple >> domains are defined for a given device (eg. via device-tree), then: >> 1. Create a new PM domain for this device. The name of the new PM domain >> created matches the device name for which it was created for. >> 2. Register the new PM domain as a sub-domain for all PM domains >> required by the device. >> 3. Attach the device to the new PM domain. > > Did you look at what might be involved to extend struct device to hace a > list of pm_domains? Like Ulf, I'm a bit unsettled by this > implementation that has to work around the basic limitation in the > driver model. I had but it was going to be a much bigger and intrusive change. So I went with this as a initial idea to see if others also had a need for it. I am happy to start looking at extended the device struct if this is the preferred path and I would agree that would make most sense. > Having devices in multitple domains is needed for SoCs I'm familiar with > also, so is a needed feature. Ok great. > I think removing the struct device limitation and corresponding > assumptions in the driver and PM core is a prerequisite for this > feature. > > Doing that will lead to several questions about how to handle runtime PM > operations (e.g. which of the multiple PM domains should the one to call > the drivers runtime PM hooks when a device changes runtime PM state?) Right. My initial thought would be that at least for device-tree based configuration, that the order in which the pm-domains are defined in DT would determine the order in which the pm-domains are power-on/off. > Anyways, even with the potential complexities, I think attempting this > is the right way forward. Ok. I will start having a think about this but will probably not get back to this for a few weeks. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* [RFC PATCH 3/3] dt-bindings: Add support for devices with multiple PM domains 2016-09-20 10:28 ` Jon Hunter @ 2016-09-20 10:28 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra, Jon Hunter Now that the generic PM domain framework supports devices that require 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 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt index 025b5e7df61c..12131159b605 100644 --- a/Documentation/devicetree/bindings/power/power_domain.txt +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -20,8 +20,9 @@ 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. 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.1.4 ^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC PATCH 3/3] dt-bindings: Add support for devices with multiple PM domains @ 2016-09-20 10:28 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-09-20 10:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra, Jon Hunter Now that the generic PM domain framework supports devices that require 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 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt index 025b5e7df61c..12131159b605 100644 --- a/Documentation/devicetree/bindings/power/power_domain.txt +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -20,8 +20,9 @@ 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. 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.1.4 ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-09-20 10:28 ` Jon Hunter ` (3 preceding siblings ...) (?) @ 2016-10-06 6:04 ` Rajendra Nayak 2016-10-06 8:25 ` Jon Hunter -1 siblings, 1 reply; 91+ messages in thread From: Rajendra Nayak @ 2016-10-06 6:04 UTC (permalink / raw) To: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra On 09/20/2016 03:58 PM, Jon Hunter wrote: > The Tegra124/210 XUSB subsystem (that consists of both host and device > controllers) 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. Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains for a device (which then will *all* be powered on/off together) or does it also provide for more granular control of these powerdomains? The above statement seems to suggest you would need more granular control of these powerdomains (like keeping XUSBA off in case superspeed it not needed) but I can't seem to figure out how you achieve it with this series. - Rajendra -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-06 6:04 ` [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Rajendra Nayak @ 2016-10-06 8:25 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-10-06 8:25 UTC (permalink / raw) To: Rajendra Nayak, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra Hi Rajendra, On 06/10/16 07:04, Rajendra Nayak wrote: > > On 09/20/2016 03:58 PM, Jon Hunter wrote: >> The Tegra124/210 XUSB subsystem (that consists of both host and device >> controllers) 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. > > Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains > for a device (which then will *all* be powered on/off together) or does > it also provide for more granular control of these powerdomains? Only to specify multiple power-domains for a device and not the later. > The above statement seems to suggest you would need more granular control > of these powerdomains (like keeping XUSBA off in case superspeed it not > needed) but I can't seem to figure out how you achieve it with this series. It is an interesting point but today we have always kept the superspeed partition on if the device is configured for superspeed regardless of what is actually connected. I will check to see if the h/w would allow us to turn it off if a non-superspeed device is in use but I did not think so. Do you have any interesting use-cases that would make use of this or require other such enhancements? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-10-06 8:25 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-10-06 8:25 UTC (permalink / raw) To: Rajendra Nayak, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra Hi Rajendra, On 06/10/16 07:04, Rajendra Nayak wrote: > > On 09/20/2016 03:58 PM, Jon Hunter wrote: >> The Tegra124/210 XUSB subsystem (that consists of both host and device >> controllers) 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. > > Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains > for a device (which then will *all* be powered on/off together) or does > it also provide for more granular control of these powerdomains? Only to specify multiple power-domains for a device and not the later. > The above statement seems to suggest you would need more granular control > of these powerdomains (like keeping XUSBA off in case superspeed it not > needed) but I can't seem to figure out how you achieve it with this series. It is an interesting point but today we have always kept the superspeed partition on if the device is configured for superspeed regardless of what is actually connected. I will check to see if the h/w would allow us to turn it off if a non-superspeed device is in use but I did not think so. Do you have any interesting use-cases that would make use of this or require other such enhancements? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-06 8:25 ` Jon Hunter (?) @ 2016-10-06 8:43 ` Rajendra Nayak 2016-10-31 10:44 ` Jon Hunter -1 siblings, 1 reply; 91+ messages in thread From: Rajendra Nayak @ 2016-10-06 8:43 UTC (permalink / raw) To: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra On 10/06/2016 01:55 PM, Jon Hunter wrote: > Hi Rajendra, > > On 06/10/16 07:04, Rajendra Nayak wrote: >> >> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>> controllers) 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. >> >> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >> for a device (which then will *all* be powered on/off together) or does >> it also provide for more granular control of these powerdomains? > > Only to specify multiple power-domains for a device and not the later. > >> The above statement seems to suggest you would need more granular control >> of these powerdomains (like keeping XUSBA off in case superspeed it not >> needed) but I can't seem to figure out how you achieve it with this series. > > It is an interesting point but today we have always kept the superspeed > partition on if the device is configured for superspeed regardless of > what is actually connected. I will check to see if the h/w would allow > us to turn it off if a non-superspeed device is in use but I did not > think so. > > Do you have any interesting use-cases that would make use of this or > require other such enhancements? We do have atleast a few devices which need to control multiple power domains, I will need to look more to see if any of them can be controlled individually. The downstream code we have models these (powerdomains) as regulators and the drivers hence have individual control on each (specifying multiple -supply's in DT) Regardless, the idea of being able to specify more than one powerdomain associated to a device seems quite useful, though providing a way for the driver to control them individually seems tricky. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-06 8:43 ` Rajendra Nayak @ 2016-10-31 10:44 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-10-31 10:44 UTC (permalink / raw) To: Rajendra Nayak, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra Hi Rajendra, On 06/10/16 09:43, Rajendra Nayak wrote: > > On 10/06/2016 01:55 PM, Jon Hunter wrote: >> Hi Rajendra, >> >> On 06/10/16 07:04, Rajendra Nayak wrote: >>> >>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>> controllers) 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. >>> >>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>> for a device (which then will *all* be powered on/off together) or does >>> it also provide for more granular control of these powerdomains? >> >> Only to specify multiple power-domains for a device and not the later. >> >>> The above statement seems to suggest you would need more granular control >>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>> needed) but I can't seem to figure out how you achieve it with this series. >> >> It is an interesting point but today we have always kept the superspeed >> partition on if the device is configured for superspeed regardless of >> what is actually connected. I will check to see if the h/w would allow >> us to turn it off if a non-superspeed device is in use but I did not >> think so. >> >> Do you have any interesting use-cases that would make use of this or >> require other such enhancements? > > We do have atleast a few devices which need to control multiple power domains, > I will need to look more to see if any of them can be controlled individually. > The downstream code we have models these (powerdomains) as regulators and > the drivers hence have individual control on each (specifying multiple -supply's > in DT) Were you able to check to see if you need to have individual control for the power-domains? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-10-31 10:44 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-10-31 10:44 UTC (permalink / raw) To: Rajendra Nayak, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra Hi Rajendra, On 06/10/16 09:43, Rajendra Nayak wrote: > > On 10/06/2016 01:55 PM, Jon Hunter wrote: >> Hi Rajendra, >> >> On 06/10/16 07:04, Rajendra Nayak wrote: >>> >>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>> controllers) 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. >>> >>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>> for a device (which then will *all* be powered on/off together) or does >>> it also provide for more granular control of these powerdomains? >> >> Only to specify multiple power-domains for a device and not the later. >> >>> The above statement seems to suggest you would need more granular control >>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>> needed) but I can't seem to figure out how you achieve it with this series. >> >> It is an interesting point but today we have always kept the superspeed >> partition on if the device is configured for superspeed regardless of >> what is actually connected. I will check to see if the h/w would allow >> us to turn it off if a non-superspeed device is in use but I did not >> think so. >> >> Do you have any interesting use-cases that would make use of this or >> require other such enhancements? > > We do have atleast a few devices which need to control multiple power domains, > I will need to look more to see if any of them can be controlled individually. > The downstream code we have models these (powerdomains) as regulators and > the drivers hence have individual control on each (specifying multiple -supply's > in DT) Were you able to check to see if you need to have individual control for the power-domains? Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-31 10:44 ` Jon Hunter (?) @ 2016-11-02 8:56 ` Rajendra Nayak [not found] ` <5819AA42.5060603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> -1 siblings, 1 reply; 91+ messages in thread From: Rajendra Nayak @ 2016-11-02 8:56 UTC (permalink / raw) To: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: linux-pm, linux-kernel, linux-tegra Hi Jon, On 10/31/2016 04:14 PM, Jon Hunter wrote: > Hi Rajendra, > > On 06/10/16 09:43, Rajendra Nayak wrote: >> >> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>> Hi Rajendra, >>> >>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>> >>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>> controllers) 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. >>>> >>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>> for a device (which then will *all* be powered on/off together) or does >>>> it also provide for more granular control of these powerdomains? >>> >>> Only to specify multiple power-domains for a device and not the later. >>> >>>> The above statement seems to suggest you would need more granular control >>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>> needed) but I can't seem to figure out how you achieve it with this series. >>> >>> It is an interesting point but today we have always kept the superspeed >>> partition on if the device is configured for superspeed regardless of >>> what is actually connected. I will check to see if the h/w would allow >>> us to turn it off if a non-superspeed device is in use but I did not >>> think so. >>> >>> Do you have any interesting use-cases that would make use of this or >>> require other such enhancements? >> >> We do have atleast a few devices which need to control multiple power domains, >> I will need to look more to see if any of them can be controlled individually. >> The downstream code we have models these (powerdomains) as regulators and >> the drivers hence have individual control on each (specifying multiple -supply's >> in DT) > > Were you able to check to see if you need to have individual control for the power-domains? I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, so for things like firmware image loading you ideally need only venus PD to be ON, but during an encode/decode operation you would need all 3 to be ON. The downstream driver turns *all* of them together, and does not control them individually. For upstream, the way we have it working (the driver is not merged) is by having venus be the parent of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as the powerdomain for the video decode block in DT. So in summary, there is still no need to control them individually, but given there is no way to specify more than one powerdomain for a given device, we are ending up hooking up some parent/child relations in the powerdomain code. regards, Rajendra -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <5819AA42.5060603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-02 8:56 ` Rajendra Nayak @ 2016-11-16 13:11 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-11-16 13:11 UTC (permalink / raw) To: Rajendra Nayak Cc: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA On 2 November 2016 at 09:56, Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote: > Hi Jon, > > On 10/31/2016 04:14 PM, Jon Hunter wrote: >> Hi Rajendra, >> >> On 06/10/16 09:43, Rajendra Nayak wrote: >>> >>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>> Hi Rajendra, >>>> >>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>> >>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>> controllers) 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. >>>>> >>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>> for a device (which then will *all* be powered on/off together) or does >>>>> it also provide for more granular control of these powerdomains? >>>> >>>> Only to specify multiple power-domains for a device and not the later. >>>> >>>>> The above statement seems to suggest you would need more granular control >>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>> >>>> It is an interesting point but today we have always kept the superspeed >>>> partition on if the device is configured for superspeed regardless of >>>> what is actually connected. I will check to see if the h/w would allow >>>> us to turn it off if a non-superspeed device is in use but I did not >>>> think so. >>>> >>>> Do you have any interesting use-cases that would make use of this or >>>> require other such enhancements? >>> >>> We do have atleast a few devices which need to control multiple power domains, >>> I will need to look more to see if any of them can be controlled individually. >>> The downstream code we have models these (powerdomains) as regulators and >>> the drivers hence have individual control on each (specifying multiple -supply's >>> in DT) >> >> Were you able to check to see if you need to have individual control for the power-domains? > > I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different > powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core > which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, > so for things like firmware image loading you ideally need only venus PD to be ON, but during > an encode/decode operation you would need all 3 to be ON. Isn't there a scenario when encoding *or* decoding happens, not always both? If so, doesn't that mean you may have venus + venus_core0 powered and in some other case venus + venus_core1 powered? > The downstream driver turns *all* of them together, and does not control them individually. > For upstream, the way we have it working (the driver is not merged) is by having venus be the parent > of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as > the powerdomain for the video decode block in DT. > > So in summary, there is still no need to control them individually, but given there is no way to > specify more than one powerdomain for a given device, we are ending up hooking up some > parent/child relations in the powerdomain code. > I think a better solution would be to model the video decode block as three struct devices. 1) The main ARM device, attached to the venus PM domain. 2) The encoder device, having the main device assigned as its parent and being attached to the venus_core0 PM domain. 3) The decoder device, having the main device assigned as its parent and being attached to the venus_core1 PM domain. Then there is no need to specific a PM domain hierarchy (which seems to be the issue here), but instead only the parent/child relationships between the struct devices. Moreover, as you deploy runtime PM for these devices, you can more easily distinguish which device you need to operate on (pm_runtime_get|put*()) depending on what particular operations you want to do (encode, decode etc). Would that work? Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-16 13:11 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-11-16 13:11 UTC (permalink / raw) To: Rajendra Nayak Cc: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra On 2 November 2016 at 09:56, Rajendra Nayak <rnayak@codeaurora.org> wrote: > Hi Jon, > > On 10/31/2016 04:14 PM, Jon Hunter wrote: >> Hi Rajendra, >> >> On 06/10/16 09:43, Rajendra Nayak wrote: >>> >>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>> Hi Rajendra, >>>> >>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>> >>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>> controllers) 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. >>>>> >>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>> for a device (which then will *all* be powered on/off together) or does >>>>> it also provide for more granular control of these powerdomains? >>>> >>>> Only to specify multiple power-domains for a device and not the later. >>>> >>>>> The above statement seems to suggest you would need more granular control >>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>> >>>> It is an interesting point but today we have always kept the superspeed >>>> partition on if the device is configured for superspeed regardless of >>>> what is actually connected. I will check to see if the h/w would allow >>>> us to turn it off if a non-superspeed device is in use but I did not >>>> think so. >>>> >>>> Do you have any interesting use-cases that would make use of this or >>>> require other such enhancements? >>> >>> We do have atleast a few devices which need to control multiple power domains, >>> I will need to look more to see if any of them can be controlled individually. >>> The downstream code we have models these (powerdomains) as regulators and >>> the drivers hence have individual control on each (specifying multiple -supply's >>> in DT) >> >> Were you able to check to see if you need to have individual control for the power-domains? > > I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different > powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core > which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, > so for things like firmware image loading you ideally need only venus PD to be ON, but during > an encode/decode operation you would need all 3 to be ON. Isn't there a scenario when encoding *or* decoding happens, not always both? If so, doesn't that mean you may have venus + venus_core0 powered and in some other case venus + venus_core1 powered? > The downstream driver turns *all* of them together, and does not control them individually. > For upstream, the way we have it working (the driver is not merged) is by having venus be the parent > of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as > the powerdomain for the video decode block in DT. > > So in summary, there is still no need to control them individually, but given there is no way to > specify more than one powerdomain for a given device, we are ending up hooking up some > parent/child relations in the powerdomain code. > I think a better solution would be to model the video decode block as three struct devices. 1) The main ARM device, attached to the venus PM domain. 2) The encoder device, having the main device assigned as its parent and being attached to the venus_core0 PM domain. 3) The decoder device, having the main device assigned as its parent and being attached to the venus_core1 PM domain. Then there is no need to specific a PM domain hierarchy (which seems to be the issue here), but instead only the parent/child relationships between the struct devices. Moreover, as you deploy runtime PM for these devices, you can more easily distinguish which device you need to operate on (pm_runtime_get|put*()) depending on what particular operations you want to do (encode, decode etc). Would that work? Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <CAPDyKFpdRzDotofr+0F6gfuWg4hHikEfmxS2aM2D+hmq_JpHRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-16 13:11 ` Ulf Hansson @ 2016-11-17 2:31 ` Rajendra Nayak -1 siblings, 0 replies; 91+ messages in thread From: Rajendra Nayak @ 2016-11-17 2:31 UTC (permalink / raw) To: Ulf Hansson Cc: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Sricharan, stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A On 11/16/2016 06:41 PM, Ulf Hansson wrote: > On 2 November 2016 at 09:56, Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote: >> Hi Jon, >> >> On 10/31/2016 04:14 PM, Jon Hunter wrote: >>> Hi Rajendra, >>> >>> On 06/10/16 09:43, Rajendra Nayak wrote: >>>> >>>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>>> Hi Rajendra, >>>>> >>>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>>> >>>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>>> controllers) 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. >>>>>> >>>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>>> for a device (which then will *all* be powered on/off together) or does >>>>>> it also provide for more granular control of these powerdomains? >>>>> >>>>> Only to specify multiple power-domains for a device and not the later. >>>>> >>>>>> The above statement seems to suggest you would need more granular control >>>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>>> >>>>> It is an interesting point but today we have always kept the superspeed >>>>> partition on if the device is configured for superspeed regardless of >>>>> what is actually connected. I will check to see if the h/w would allow >>>>> us to turn it off if a non-superspeed device is in use but I did not >>>>> think so. >>>>> >>>>> Do you have any interesting use-cases that would make use of this or >>>>> require other such enhancements? >>>> >>>> We do have atleast a few devices which need to control multiple power domains, >>>> I will need to look more to see if any of them can be controlled individually. >>>> The downstream code we have models these (powerdomains) as regulators and >>>> the drivers hence have individual control on each (specifying multiple -supply's >>>> in DT) >>> >>> Were you able to check to see if you need to have individual control for the power-domains? >> >> I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different >> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core >> which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, >> so for things like firmware image loading you ideally need only venus PD to be ON, but during >> an encode/decode operation you would need all 3 to be ON. > > Isn't there a scenario when encoding *or* decoding happens, not always both? > > If so, doesn't that mean you may have venus + venus_core0 powered and > in some other case venus + venus_core1 powered? > >> The downstream driver turns *all* of them together, and does not control them individually. >> For upstream, the way we have it working (the driver is not merged) is by having venus be the parent >> of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as >> the powerdomain for the video decode block in DT. >> >> So in summary, there is still no need to control them individually, but given there is no way to >> specify more than one powerdomain for a given device, we are ending up hooking up some >> parent/child relations in the powerdomain code. >> > > I think a better solution would be to model the video decode block as > three struct devices. > > 1) The main ARM device, attached to the venus PM domain. > 2) The encoder device, having the main device assigned as its parent > and being attached to the venus_core0 PM domain. > 3) The decoder device, having the main device assigned as its parent > and being attached to the venus_core1 PM domain. > > Then there is no need to specific a PM domain hierarchy (which seems > to be the issue here), but instead only the parent/child relationships > between the struct devices. > > Moreover, as you deploy runtime PM for these devices, you can more > easily distinguish which device you need to operate on > (pm_runtime_get|put*()) depending on what particular operations you > want to do (encode, decode etc). Stan, is this something you think is possible to do, given the way the vidc driver is designed? This is mainly for 8996 which has 3 different powerdomains associated with the video decode block. regards, Rajendra > > Would that work? > > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-17 2:31 ` Rajendra Nayak 0 siblings, 0 replies; 91+ messages in thread From: Rajendra Nayak @ 2016-11-17 2:31 UTC (permalink / raw) To: Ulf Hansson Cc: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra, Sricharan, stanimir.varbanov On 11/16/2016 06:41 PM, Ulf Hansson wrote: > On 2 November 2016 at 09:56, Rajendra Nayak <rnayak@codeaurora.org> wrote: >> Hi Jon, >> >> On 10/31/2016 04:14 PM, Jon Hunter wrote: >>> Hi Rajendra, >>> >>> On 06/10/16 09:43, Rajendra Nayak wrote: >>>> >>>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>>> Hi Rajendra, >>>>> >>>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>>> >>>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>>> controllers) 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. >>>>>> >>>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>>> for a device (which then will *all* be powered on/off together) or does >>>>>> it also provide for more granular control of these powerdomains? >>>>> >>>>> Only to specify multiple power-domains for a device and not the later. >>>>> >>>>>> The above statement seems to suggest you would need more granular control >>>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>>> >>>>> It is an interesting point but today we have always kept the superspeed >>>>> partition on if the device is configured for superspeed regardless of >>>>> what is actually connected. I will check to see if the h/w would allow >>>>> us to turn it off if a non-superspeed device is in use but I did not >>>>> think so. >>>>> >>>>> Do you have any interesting use-cases that would make use of this or >>>>> require other such enhancements? >>>> >>>> We do have atleast a few devices which need to control multiple power domains, >>>> I will need to look more to see if any of them can be controlled individually. >>>> The downstream code we have models these (powerdomains) as regulators and >>>> the drivers hence have individual control on each (specifying multiple -supply's >>>> in DT) >>> >>> Were you able to check to see if you need to have individual control for the power-domains? >> >> I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different >> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core >> which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, >> so for things like firmware image loading you ideally need only venus PD to be ON, but during >> an encode/decode operation you would need all 3 to be ON. > > Isn't there a scenario when encoding *or* decoding happens, not always both? > > If so, doesn't that mean you may have venus + venus_core0 powered and > in some other case venus + venus_core1 powered? > >> The downstream driver turns *all* of them together, and does not control them individually. >> For upstream, the way we have it working (the driver is not merged) is by having venus be the parent >> of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as >> the powerdomain for the video decode block in DT. >> >> So in summary, there is still no need to control them individually, but given there is no way to >> specify more than one powerdomain for a given device, we are ending up hooking up some >> parent/child relations in the powerdomain code. >> > > I think a better solution would be to model the video decode block as > three struct devices. > > 1) The main ARM device, attached to the venus PM domain. > 2) The encoder device, having the main device assigned as its parent > and being attached to the venus_core0 PM domain. > 3) The decoder device, having the main device assigned as its parent > and being attached to the venus_core1 PM domain. > > Then there is no need to specific a PM domain hierarchy (which seems > to be the issue here), but instead only the parent/child relationships > between the struct devices. > > Moreover, as you deploy runtime PM for these devices, you can more > easily distinguish which device you need to operate on > (pm_runtime_get|put*()) depending on what particular operations you > want to do (encode, decode etc). Stan, is this something you think is possible to do, given the way the vidc driver is designed? This is mainly for 8996 which has 3 different powerdomains associated with the video decode block. regards, Rajendra > > Would that work? > > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-17 2:31 ` Rajendra Nayak (?) @ 2016-11-17 15:39 ` Stanimir Varbanov [not found] ` <4bafcd71-edc9-9ddd-d8c4-093e4d9c58db-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> -1 siblings, 1 reply; 91+ messages in thread From: Stanimir Varbanov @ 2016-11-17 15:39 UTC (permalink / raw) To: Rajendra Nayak, Ulf Hansson Cc: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra, Sricharan Hi, On 11/17/2016 04:31 AM, Rajendra Nayak wrote: > > > On 11/16/2016 06:41 PM, Ulf Hansson wrote: >> On 2 November 2016 at 09:56, Rajendra Nayak <rnayak@codeaurora.org> wrote: >>> Hi Jon, >>> >>> On 10/31/2016 04:14 PM, Jon Hunter wrote: >>>> Hi Rajendra, >>>> >>>> On 06/10/16 09:43, Rajendra Nayak wrote: >>>>> >>>>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>>>> Hi Rajendra, >>>>>> >>>>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>>>> >>>>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>>>> controllers) 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. >>>>>>> >>>>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>>>> for a device (which then will *all* be powered on/off together) or does >>>>>>> it also provide for more granular control of these powerdomains? >>>>>> >>>>>> Only to specify multiple power-domains for a device and not the later. >>>>>> >>>>>>> The above statement seems to suggest you would need more granular control >>>>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>>>> >>>>>> It is an interesting point but today we have always kept the superspeed >>>>>> partition on if the device is configured for superspeed regardless of >>>>>> what is actually connected. I will check to see if the h/w would allow >>>>>> us to turn it off if a non-superspeed device is in use but I did not >>>>>> think so. >>>>>> >>>>>> Do you have any interesting use-cases that would make use of this or >>>>>> require other such enhancements? >>>>> >>>>> We do have atleast a few devices which need to control multiple power domains, >>>>> I will need to look more to see if any of them can be controlled individually. >>>>> The downstream code we have models these (powerdomains) as regulators and >>>>> the drivers hence have individual control on each (specifying multiple -supply's >>>>> in DT) >>>> >>>> Were you able to check to see if you need to have individual control for the power-domains? >>> >>> I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different >>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core >>> which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, >>> so for things like firmware image loading you ideally need only venus PD to be ON, but during >>> an encode/decode operation you would need all 3 to be ON. >> >> Isn't there a scenario when encoding *or* decoding happens, not always both? >> >> If so, doesn't that mean you may have venus + venus_core0 powered and >> in some other case venus + venus_core1 powered? >> >>> The downstream driver turns *all* of them together, and does not control them individually. >>> For upstream, the way we have it working (the driver is not merged) is by having venus be the parent >>> of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as >>> the powerdomain for the video decode block in DT. >>> >>> So in summary, there is still no need to control them individually, but given there is no way to >>> specify more than one powerdomain for a given device, we are ending up hooking up some >>> parent/child relations in the powerdomain code. >>> >> >> I think a better solution would be to model the video decode block as >> three struct devices. >> >> 1) The main ARM device, attached to the venus PM domain. >> 2) The encoder device, having the main device assigned as its parent >> and being attached to the venus_core0 PM domain. >> 3) The decoder device, having the main device assigned as its parent >> and being attached to the venus_core1 PM domain. >> >> Then there is no need to specific a PM domain hierarchy (which seems >> to be the issue here), but instead only the parent/child relationships >> between the struct devices. >> >> Moreover, as you deploy runtime PM for these devices, you can more >> easily distinguish which device you need to operate on >> (pm_runtime_get|put*()) depending on what particular operations you >> want to do (encode, decode etc). > > Stan, is this something you think is possible to do, given the way the > vidc driver is designed? This is mainly for 8996 which has 3 different > powerdomains associated with the video decode block. Even if it is possible it will be difficult for many reasons. On the other side, current design (firmware) doesn't expect kernel driver to have control over venus_core0 and venus_core1 pm domains. The firmware manages those two pm domains internally and the only thing which we need to do is to prepare those domains (and follow the power up sequence) to be in hardware control mode. So I think the best we could do is to model those two power domains as genpd subdomains of the parent venus pm domain. -- regards, Stan ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <4bafcd71-edc9-9ddd-d8c4-093e4d9c58db-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-17 15:39 ` Stanimir Varbanov @ 2016-11-22 13:05 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-11-22 13:05 UTC (permalink / raw) To: Stanimir Varbanov Cc: Rajendra Nayak, Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Sricharan On 17 November 2016 at 16:39, Stanimir Varbanov <stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > Hi, > > On 11/17/2016 04:31 AM, Rajendra Nayak wrote: >> >> >> On 11/16/2016 06:41 PM, Ulf Hansson wrote: >>> On 2 November 2016 at 09:56, Rajendra Nayak <rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote: >>>> Hi Jon, >>>> >>>> On 10/31/2016 04:14 PM, Jon Hunter wrote: >>>>> Hi Rajendra, >>>>> >>>>> On 06/10/16 09:43, Rajendra Nayak wrote: >>>>>> >>>>>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>>>>> Hi Rajendra, >>>>>>> >>>>>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>>>>> >>>>>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>>>>> controllers) 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. >>>>>>>> >>>>>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>>>>> for a device (which then will *all* be powered on/off together) or does >>>>>>>> it also provide for more granular control of these powerdomains? >>>>>>> >>>>>>> Only to specify multiple power-domains for a device and not the later. >>>>>>> >>>>>>>> The above statement seems to suggest you would need more granular control >>>>>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>>>>> >>>>>>> It is an interesting point but today we have always kept the superspeed >>>>>>> partition on if the device is configured for superspeed regardless of >>>>>>> what is actually connected. I will check to see if the h/w would allow >>>>>>> us to turn it off if a non-superspeed device is in use but I did not >>>>>>> think so. >>>>>>> >>>>>>> Do you have any interesting use-cases that would make use of this or >>>>>>> require other such enhancements? >>>>>> >>>>>> We do have atleast a few devices which need to control multiple power domains, >>>>>> I will need to look more to see if any of them can be controlled individually. >>>>>> The downstream code we have models these (powerdomains) as regulators and >>>>>> the drivers hence have individual control on each (specifying multiple -supply's >>>>>> in DT) >>>>> >>>>> Were you able to check to see if you need to have individual control for the power-domains? >>>> >>>> I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different >>>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core >>>> which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, >>>> so for things like firmware image loading you ideally need only venus PD to be ON, but during >>>> an encode/decode operation you would need all 3 to be ON. >>> >>> Isn't there a scenario when encoding *or* decoding happens, not always both? >>> >>> If so, doesn't that mean you may have venus + venus_core0 powered and >>> in some other case venus + venus_core1 powered? >>> >>>> The downstream driver turns *all* of them together, and does not control them individually. >>>> For upstream, the way we have it working (the driver is not merged) is by having venus be the parent >>>> of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as >>>> the powerdomain for the video decode block in DT. >>>> >>>> So in summary, there is still no need to control them individually, but given there is no way to >>>> specify more than one powerdomain for a given device, we are ending up hooking up some >>>> parent/child relations in the powerdomain code. >>>> >>> >>> I think a better solution would be to model the video decode block as >>> three struct devices. >>> >>> 1) The main ARM device, attached to the venus PM domain. >>> 2) The encoder device, having the main device assigned as its parent >>> and being attached to the venus_core0 PM domain. >>> 3) The decoder device, having the main device assigned as its parent >>> and being attached to the venus_core1 PM domain. >>> >>> Then there is no need to specific a PM domain hierarchy (which seems >>> to be the issue here), but instead only the parent/child relationships >>> between the struct devices. >>> >>> Moreover, as you deploy runtime PM for these devices, you can more >>> easily distinguish which device you need to operate on >>> (pm_runtime_get|put*()) depending on what particular operations you >>> want to do (encode, decode etc). >> >> Stan, is this something you think is possible to do, given the way the >> vidc driver is designed? This is mainly for 8996 which has 3 different >> powerdomains associated with the video decode block. > > Even if it is possible it will be difficult for many reasons. > > On the other side, current design (firmware) doesn't expect kernel > driver to have control over venus_core0 and venus_core1 pm domains. The > firmware manages those two pm domains internally and the only thing > which we need to do is to prepare those domains (and follow the power up > sequence) to be in hardware control mode. So I think the best we could > do is to model those two power domains as genpd subdomains of the parent > venus pm domain. Okay, so that was easy then. Why all the fuzz? :-) Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-22 13:05 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-11-22 13:05 UTC (permalink / raw) To: Stanimir Varbanov Cc: Rajendra Nayak, Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra, Sricharan On 17 November 2016 at 16:39, Stanimir Varbanov <stanimir.varbanov@linaro.org> wrote: > Hi, > > On 11/17/2016 04:31 AM, Rajendra Nayak wrote: >> >> >> On 11/16/2016 06:41 PM, Ulf Hansson wrote: >>> On 2 November 2016 at 09:56, Rajendra Nayak <rnayak@codeaurora.org> wrote: >>>> Hi Jon, >>>> >>>> On 10/31/2016 04:14 PM, Jon Hunter wrote: >>>>> Hi Rajendra, >>>>> >>>>> On 06/10/16 09:43, Rajendra Nayak wrote: >>>>>> >>>>>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>>>>> Hi Rajendra, >>>>>>> >>>>>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>>>>> >>>>>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>>>>> controllers) 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. >>>>>>>> >>>>>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>>>>> for a device (which then will *all* be powered on/off together) or does >>>>>>>> it also provide for more granular control of these powerdomains? >>>>>>> >>>>>>> Only to specify multiple power-domains for a device and not the later. >>>>>>> >>>>>>>> The above statement seems to suggest you would need more granular control >>>>>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>>>>> >>>>>>> It is an interesting point but today we have always kept the superspeed >>>>>>> partition on if the device is configured for superspeed regardless of >>>>>>> what is actually connected. I will check to see if the h/w would allow >>>>>>> us to turn it off if a non-superspeed device is in use but I did not >>>>>>> think so. >>>>>>> >>>>>>> Do you have any interesting use-cases that would make use of this or >>>>>>> require other such enhancements? >>>>>> >>>>>> We do have atleast a few devices which need to control multiple power domains, >>>>>> I will need to look more to see if any of them can be controlled individually. >>>>>> The downstream code we have models these (powerdomains) as regulators and >>>>>> the drivers hence have individual control on each (specifying multiple -supply's >>>>>> in DT) >>>>> >>>>> Were you able to check to see if you need to have individual control for the power-domains? >>>> >>>> I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different >>>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core >>>> which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, >>>> so for things like firmware image loading you ideally need only venus PD to be ON, but during >>>> an encode/decode operation you would need all 3 to be ON. >>> >>> Isn't there a scenario when encoding *or* decoding happens, not always both? >>> >>> If so, doesn't that mean you may have venus + venus_core0 powered and >>> in some other case venus + venus_core1 powered? >>> >>>> The downstream driver turns *all* of them together, and does not control them individually. >>>> For upstream, the way we have it working (the driver is not merged) is by having venus be the parent >>>> of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as >>>> the powerdomain for the video decode block in DT. >>>> >>>> So in summary, there is still no need to control them individually, but given there is no way to >>>> specify more than one powerdomain for a given device, we are ending up hooking up some >>>> parent/child relations in the powerdomain code. >>>> >>> >>> I think a better solution would be to model the video decode block as >>> three struct devices. >>> >>> 1) The main ARM device, attached to the venus PM domain. >>> 2) The encoder device, having the main device assigned as its parent >>> and being attached to the venus_core0 PM domain. >>> 3) The decoder device, having the main device assigned as its parent >>> and being attached to the venus_core1 PM domain. >>> >>> Then there is no need to specific a PM domain hierarchy (which seems >>> to be the issue here), but instead only the parent/child relationships >>> between the struct devices. >>> >>> Moreover, as you deploy runtime PM for these devices, you can more >>> easily distinguish which device you need to operate on >>> (pm_runtime_get|put*()) depending on what particular operations you >>> want to do (encode, decode etc). >> >> Stan, is this something you think is possible to do, given the way the >> vidc driver is designed? This is mainly for 8996 which has 3 different >> powerdomains associated with the video decode block. > > Even if it is possible it will be difficult for many reasons. > > On the other side, current design (firmware) doesn't expect kernel > driver to have control over venus_core0 and venus_core1 pm domains. The > firmware manages those two pm domains internally and the only thing > which we need to do is to prepare those domains (and follow the power up > sequence) to be in hardware control mode. So I think the best we could > do is to model those two power domains as genpd subdomains of the parent > venus pm domain. Okay, so that was easy then. Why all the fuzz? :-) Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 13:05 ` Ulf Hansson (?) @ 2016-11-23 3:48 ` Rajendra Nayak -1 siblings, 0 replies; 91+ messages in thread From: Rajendra Nayak @ 2016-11-23 3:48 UTC (permalink / raw) To: Ulf Hansson, Stanimir Varbanov Cc: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra, Sricharan On 11/22/2016 06:35 PM, Ulf Hansson wrote: > On 17 November 2016 at 16:39, Stanimir Varbanov > <stanimir.varbanov@linaro.org> wrote: >> Hi, >> >> On 11/17/2016 04:31 AM, Rajendra Nayak wrote: >>> >>> >>> On 11/16/2016 06:41 PM, Ulf Hansson wrote: >>>> On 2 November 2016 at 09:56, Rajendra Nayak <rnayak@codeaurora.org> wrote: >>>>> Hi Jon, >>>>> >>>>> On 10/31/2016 04:14 PM, Jon Hunter wrote: >>>>>> Hi Rajendra, >>>>>> >>>>>> On 06/10/16 09:43, Rajendra Nayak wrote: >>>>>>> >>>>>>> On 10/06/2016 01:55 PM, Jon Hunter wrote: >>>>>>>> Hi Rajendra, >>>>>>>> >>>>>>>> On 06/10/16 07:04, Rajendra Nayak wrote: >>>>>>>>> >>>>>>>>> On 09/20/2016 03:58 PM, Jon Hunter wrote: >>>>>>>>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>>>>>>>> controllers) 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. >>>>>>>>> >>>>>>>>> Hey Jon, so does this RFC provide a way to just specify multiple Powerdomains >>>>>>>>> for a device (which then will *all* be powered on/off together) or does >>>>>>>>> it also provide for more granular control of these powerdomains? >>>>>>>> >>>>>>>> Only to specify multiple power-domains for a device and not the later. >>>>>>>> >>>>>>>>> The above statement seems to suggest you would need more granular control >>>>>>>>> of these powerdomains (like keeping XUSBA off in case superspeed it not >>>>>>>>> needed) but I can't seem to figure out how you achieve it with this series. >>>>>>>> >>>>>>>> It is an interesting point but today we have always kept the superspeed >>>>>>>> partition on if the device is configured for superspeed regardless of >>>>>>>> what is actually connected. I will check to see if the h/w would allow >>>>>>>> us to turn it off if a non-superspeed device is in use but I did not >>>>>>>> think so. >>>>>>>> >>>>>>>> Do you have any interesting use-cases that would make use of this or >>>>>>>> require other such enhancements? >>>>>>> >>>>>>> We do have atleast a few devices which need to control multiple power domains, >>>>>>> I will need to look more to see if any of them can be controlled individually. >>>>>>> The downstream code we have models these (powerdomains) as regulators and >>>>>>> the drivers hence have individual control on each (specifying multiple -supply's >>>>>>> in DT) >>>>>> >>>>>> Were you able to check to see if you need to have individual control for the power-domains? >>>>> >>>>> I had a look at the Video decode block (for msm8996), which seems to be powered using 3 different >>>>> powerdomains, mainly venus, venus_core0 and venus_core1. The venus PD powers the ARM core >>>>> which runs the firmware, while the venus_core0 and venus_core1 power the encode/decode logic, >>>>> so for things like firmware image loading you ideally need only venus PD to be ON, but during >>>>> an encode/decode operation you would need all 3 to be ON. >>>> >>>> Isn't there a scenario when encoding *or* decoding happens, not always both? >>>> >>>> If so, doesn't that mean you may have venus + venus_core0 powered and >>>> in some other case venus + venus_core1 powered? >>>> >>>>> The downstream driver turns *all* of them together, and does not control them individually. >>>>> For upstream, the way we have it working (the driver is not merged) is by having venus be the parent >>>>> of venus_core0 and venus_core0 as the parent of venus_core1, and having venus_core1 mentioned as >>>>> the powerdomain for the video decode block in DT. >>>>> >>>>> So in summary, there is still no need to control them individually, but given there is no way to >>>>> specify more than one powerdomain for a given device, we are ending up hooking up some >>>>> parent/child relations in the powerdomain code. >>>>> >>>> >>>> I think a better solution would be to model the video decode block as >>>> three struct devices. >>>> >>>> 1) The main ARM device, attached to the venus PM domain. >>>> 2) The encoder device, having the main device assigned as its parent >>>> and being attached to the venus_core0 PM domain. >>>> 3) The decoder device, having the main device assigned as its parent >>>> and being attached to the venus_core1 PM domain. >>>> >>>> Then there is no need to specific a PM domain hierarchy (which seems >>>> to be the issue here), but instead only the parent/child relationships >>>> between the struct devices. >>>> >>>> Moreover, as you deploy runtime PM for these devices, you can more >>>> easily distinguish which device you need to operate on >>>> (pm_runtime_get|put*()) depending on what particular operations you >>>> want to do (encode, decode etc). >>> >>> Stan, is this something you think is possible to do, given the way the >>> vidc driver is designed? This is mainly for 8996 which has 3 different >>> powerdomains associated with the video decode block. >> >> Even if it is possible it will be difficult for many reasons. >> >> On the other side, current design (firmware) doesn't expect kernel >> driver to have control over venus_core0 and venus_core1 pm domains. The >> firmware manages those two pm domains internally and the only thing >> which we need to do is to prepare those domains (and follow the power up >> sequence) to be in hardware control mode. So I think the best we could >> do is to model those two power domains as genpd subdomains of the parent >> venus pm domain. > > Okay, so that was easy then. Why all the fuzz? :-) Not as easy as it sounds :-), so Venus has 3 powerdomains, core, subcore0 and subcore1. So the ideal way of representing the parent/child relation in this case would be Core / \ / \ / \ subcore0 subcore1 So what powerdomain would you associate with the venus device in such case so a runtime call from the venus driver would turn all 3 of them? So, instead we end up with something like.. Core | | subcore0 | | subcore1 ..and associate subcore1 as the powerdomain for Venus. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-09-20 10:28 ` Jon Hunter ` (4 preceding siblings ...) (?) @ 2016-10-06 12:22 ` Ulf Hansson 2016-10-10 11:18 ` Jon Hunter -1 siblings, 1 reply; 91+ messages in thread From: Ulf Hansson @ 2016-10-06 12:22 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra On 20 September 2016 at 12:28, Jon Hunter <jonathanh@nvidia.com> wrote: > The Tegra124/210 XUSB subsystem (that consists of both host and device > controllers) 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>; > }; > > 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. First, I don't really like extending the internal logic of genpd to deal with multiple PM domains per device. *If* this really is needed, I think we should try to extend the struct device to cover this, then make genpd to use it somehow. Second, another way of seeing this is: Depending on the current runtime selected configuration you need to re-configure the PM domain topology - but the device would still remain in the same PM domain. In other words, you would need to remove/add subdomain(s) depending on the selected configuration. Would that better reflect the HW? [...] Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-06 12:22 ` Ulf Hansson @ 2016-10-10 11:18 ` Jon Hunter [not found] ` <90faea7d-65b6-590a-83f1-24fcdffa0569-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 91+ messages in thread From: Jon Hunter @ 2016-10-10 11:18 UTC (permalink / raw) To: Ulf Hansson Cc: Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra On 06/10/16 13:22, Ulf Hansson wrote: > On 20 September 2016 at 12:28, Jon Hunter <jonathanh@nvidia.com> wrote: >> The Tegra124/210 XUSB subsystem (that consists of both host and device >> controllers) 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>; >> }; >> >> 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. > > First, I don't really like extending the internal logic of genpd to > deal with multiple PM domains per device. *If* this really is needed, > I think we should try to extend the struct device to cover this, then > make genpd to use it somehow. I had looked at that initially but it was looking quite complex because of the various structures (dev_pm_domain in the device structure, pm_domain_data in pm_subsys_data, etc). This implementation is quite simple and less intrusive. However, if there is a lot of interest in this and it does appear to be, I would agree that having the device structure handle this would be best. > Second, another way of seeing this is: Depending on the current > runtime selected configuration you need to re-configure the PM domain > topology - but the device would still remain in the same PM domain. > > In other words, you would need to remove/add subdomain(s) depending on > the selected configuration. Would that better reflect the HW? I am not 100% sure I follow what you are saying, but ultimately, I would like to get to ... usb@70090000 { compatible = "nvidia,tegra210-xusb"; ... power-domains = <&pd_xusbhost>, <&pd_xusbss>; }; Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <90faea7d-65b6-590a-83f1-24fcdffa0569-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-10 11:18 ` Jon Hunter @ 2016-10-10 14:04 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-10-10 14:04 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA On 10 October 2016 at 13:18, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > > On 06/10/16 13:22, Ulf Hansson wrote: >> On 20 September 2016 at 12:28, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>> controllers) 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>; >>> }; >>> >>> 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. >> >> First, I don't really like extending the internal logic of genpd to >> deal with multiple PM domains per device. *If* this really is needed, >> I think we should try to extend the struct device to cover this, then >> make genpd to use it somehow. > > I had looked at that initially but it was looking quite complex because > of the various structures (dev_pm_domain in the device structure, > pm_domain_data in pm_subsys_data, etc). This implementation is quite I didn't care much about the complexity, more trying to understand how the HW actually works. :-) > simple and less intrusive. However, if there is a lot of interest in > this and it does appear to be, I would agree that having the device > structure handle this would be best. > >> Second, another way of seeing this is: Depending on the current >> runtime selected configuration you need to re-configure the PM domain >> topology - but the device would still remain in the same PM domain. >> >> In other words, you would need to remove/add subdomain(s) depending on >> the selected configuration. Would that better reflect the HW? > > I am not 100% sure I follow what you are saying, but ultimately, I would > like to get to ... > > usb@70090000 { > compatible = "nvidia,tegra210-xusb"; > ... > power-domains = <&pd_xusbhost>, <&pd_xusbss>; > }; So, is this really is a proper description of the HW? Isn't it so, that the usb device always resides in one and the same PM domain? Now, depending on the selected speed mode (superspeed) additional logic may needs to be powered on and configured for the usb device to work? Perhaps, one could consider those additional logics as a master/parent PM domain for the usb device's PM domain? Or this is not how the HW works? :-) Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-10-10 14:04 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-10-10 14:04 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra On 10 October 2016 at 13:18, Jon Hunter <jonathanh@nvidia.com> wrote: > > On 06/10/16 13:22, Ulf Hansson wrote: >> On 20 September 2016 at 12:28, Jon Hunter <jonathanh@nvidia.com> wrote: >>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>> controllers) 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>; >>> }; >>> >>> 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. >> >> First, I don't really like extending the internal logic of genpd to >> deal with multiple PM domains per device. *If* this really is needed, >> I think we should try to extend the struct device to cover this, then >> make genpd to use it somehow. > > I had looked at that initially but it was looking quite complex because > of the various structures (dev_pm_domain in the device structure, > pm_domain_data in pm_subsys_data, etc). This implementation is quite I didn't care much about the complexity, more trying to understand how the HW actually works. :-) > simple and less intrusive. However, if there is a lot of interest in > this and it does appear to be, I would agree that having the device > structure handle this would be best. > >> Second, another way of seeing this is: Depending on the current >> runtime selected configuration you need to re-configure the PM domain >> topology - but the device would still remain in the same PM domain. >> >> In other words, you would need to remove/add subdomain(s) depending on >> the selected configuration. Would that better reflect the HW? > > I am not 100% sure I follow what you are saying, but ultimately, I would > like to get to ... > > usb@70090000 { > compatible = "nvidia,tegra210-xusb"; > ... > power-domains = <&pd_xusbhost>, <&pd_xusbss>; > }; So, is this really is a proper description of the HW? Isn't it so, that the usb device always resides in one and the same PM domain? Now, depending on the selected speed mode (superspeed) additional logic may needs to be powered on and configured for the usb device to work? Perhaps, one could consider those additional logics as a master/parent PM domain for the usb device's PM domain? Or this is not how the HW works? :-) Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-10 14:04 ` Ulf Hansson (?) @ 2016-10-11 9:15 ` Jon Hunter [not found] ` <fd7c8f40-2a9f-b71c-bd11-43ee657441ae-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> -1 siblings, 1 reply; 91+ messages in thread From: Jon Hunter @ 2016-10-11 9:15 UTC (permalink / raw) To: Ulf Hansson Cc: Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 10/10/16 15:04, Ulf Hansson wrote: > On 10 October 2016 at 13:18, Jon Hunter <jonathanh@nvidia.com> wrote: >> >> On 06/10/16 13:22, Ulf Hansson wrote: >>> On 20 September 2016 at 12:28, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>> controllers) 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>; >>>> }; >>>> >>>> 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. >>> >>> First, I don't really like extending the internal logic of genpd to >>> deal with multiple PM domains per device. *If* this really is needed, >>> I think we should try to extend the struct device to cover this, then >>> make genpd to use it somehow. >> >> I had looked at that initially but it was looking quite complex because >> of the various structures (dev_pm_domain in the device structure, >> pm_domain_data in pm_subsys_data, etc). This implementation is quite > > I didn't care much about the complexity, more trying to understand how > the HW actually works. :-) OK. >> simple and less intrusive. However, if there is a lot of interest in >> this and it does appear to be, I would agree that having the device >> structure handle this would be best. >> >>> Second, another way of seeing this is: Depending on the current >>> runtime selected configuration you need to re-configure the PM domain >>> topology - but the device would still remain in the same PM domain. >>> >>> In other words, you would need to remove/add subdomain(s) depending on >>> the selected configuration. Would that better reflect the HW? >> >> I am not 100% sure I follow what you are saying, but ultimately, I would >> like to get to ... >> >> usb@70090000 { >> compatible = "nvidia,tegra210-xusb"; >> ... >> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >> }; > > So, is this really is a proper description of the HW? Isn't it so, > that the usb device always resides in one and the same PM domain? I guess technically, the usbhost controller resides in one partition and the super-speed logic in another. So could the usbhost domain be the primary? Possibly, but the device cannot be probed without both enabled. > Now, depending on the selected speed mode (superspeed) additional > logic may needs to be powered on and configured for the usb device to > work? > Perhaps, one could consider those additional logics as a master/parent > PM domain for the usb device's PM domain? > > Or this is not how the HW works? :-) It might be possible for this case, but to be honest, the more I think about this, I do wonder if we need to be able to make the framework a lot more flexible for devices that need multiple power-domains. In other words, for devices that use multiple domains allow them to control them similarly to what we do for regulators or clocks. So if there is more than one defined, then the genpd core will not bind the device to the pm-domain and let the driver handle it. This way if you do need more granular control of the pm-domains in the driver you can do whatever you need to. I know that Rajendra (CC'ed) was looking into whether he had a need to control multiple power-domains individually from within the context of a single device driver. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <fd7c8f40-2a9f-b71c-bd11-43ee657441ae-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-10-11 9:15 ` Jon Hunter @ 2016-11-03 14:20 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-11-03 14:20 UTC (permalink / raw) To: Ulf Hansson Cc: Rafael J. Wysocki, Kevin Hilman, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rajendra Nayak On 11/10/16 10:15, Jon Hunter wrote: ... >>>> Second, another way of seeing this is: Depending on the current >>>> runtime selected configuration you need to re-configure the PM domain >>>> topology - but the device would still remain in the same PM domain. >>>> >>>> In other words, you would need to remove/add subdomain(s) depending on >>>> the selected configuration. Would that better reflect the HW? >>> >>> I am not 100% sure I follow what you are saying, but ultimately, I would >>> like to get to ... >>> >>> usb@70090000 { >>> compatible = "nvidia,tegra210-xusb"; >>> ... >>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>> }; >> >> So, is this really is a proper description of the HW? Isn't it so, >> that the usb device always resides in one and the same PM domain? > > I guess technically, the usbhost controller resides in one partition and > the super-speed logic in another. So could the usbhost domain be the > primary? Possibly, but the device cannot be probed without both enabled. > >> Now, depending on the selected speed mode (superspeed) additional >> logic may needs to be powered on and configured for the usb device to >> work? >> Perhaps, one could consider those additional logics as a master/parent >> PM domain for the usb device's PM domain? >> >> Or this is not how the HW works? :-) > > It might be possible for this case, but to be honest, the more I think > about this, I do wonder if we need to be able to make the framework a > lot more flexible for devices that need multiple power-domains. In other > words, for devices that use multiple domains allow them to control them > similarly to what we do for regulators or clocks. So if there is more > than one defined, then the genpd core will not bind the device to the > pm-domain and let the driver handle it. This way if you do need more > granular control of the pm-domains in the driver you can do whatever you > need to. > > I know that Rajendra (CC'ed) was looking into whether he had a need to > control multiple power-domains individually from within the context of a > single device driver. So Rajendra commented to say that he does not see a need for individual control of power-domains for now, but a need for specifying multiple. One simple option would be to allow users to specify multiple and have the genpd core effectively ignore such devices and leave it to the driver to configure manually. I have been able to do this for XUSB by dynamically adding power-domains to the device. Let me know if you have any more thoughts on how we can do this. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-03 14:20 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-11-03 14:20 UTC (permalink / raw) To: Ulf Hansson Cc: Rafael J. Wysocki, Kevin Hilman, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 11/10/16 10:15, Jon Hunter wrote: ... >>>> Second, another way of seeing this is: Depending on the current >>>> runtime selected configuration you need to re-configure the PM domain >>>> topology - but the device would still remain in the same PM domain. >>>> >>>> In other words, you would need to remove/add subdomain(s) depending on >>>> the selected configuration. Would that better reflect the HW? >>> >>> I am not 100% sure I follow what you are saying, but ultimately, I would >>> like to get to ... >>> >>> usb@70090000 { >>> compatible = "nvidia,tegra210-xusb"; >>> ... >>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>> }; >> >> So, is this really is a proper description of the HW? Isn't it so, >> that the usb device always resides in one and the same PM domain? > > I guess technically, the usbhost controller resides in one partition and > the super-speed logic in another. So could the usbhost domain be the > primary? Possibly, but the device cannot be probed without both enabled. > >> Now, depending on the selected speed mode (superspeed) additional >> logic may needs to be powered on and configured for the usb device to >> work? >> Perhaps, one could consider those additional logics as a master/parent >> PM domain for the usb device's PM domain? >> >> Or this is not how the HW works? :-) > > It might be possible for this case, but to be honest, the more I think > about this, I do wonder if we need to be able to make the framework a > lot more flexible for devices that need multiple power-domains. In other > words, for devices that use multiple domains allow them to control them > similarly to what we do for regulators or clocks. So if there is more > than one defined, then the genpd core will not bind the device to the > pm-domain and let the driver handle it. This way if you do need more > granular control of the pm-domains in the driver you can do whatever you > need to. > > I know that Rajendra (CC'ed) was looking into whether he had a need to > control multiple power-domains individually from within the context of a > single device driver. So Rajendra commented to say that he does not see a need for individual control of power-domains for now, but a need for specifying multiple. One simple option would be to allow users to specify multiple and have the genpd core effectively ignore such devices and leave it to the driver to configure manually. I have been able to do this for XUSB by dynamically adding power-domains to the device. Let me know if you have any more thoughts on how we can do this. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-03 14:20 ` Jon Hunter (?) @ 2016-11-16 10:48 ` Jon Hunter [not found] ` <d961715d-820a-dd63-e3a9-c908ce465582-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> -1 siblings, 1 reply; 91+ messages in thread From: Jon Hunter @ 2016-11-16 10:48 UTC (permalink / raw) To: Ulf Hansson, Kevin Hilman Cc: Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak Hi Kevin, Ulf, On 03/11/16 14:20, Jon Hunter wrote: > > On 11/10/16 10:15, Jon Hunter wrote: > > ... > >>>>> Second, another way of seeing this is: Depending on the current >>>>> runtime selected configuration you need to re-configure the PM domain >>>>> topology - but the device would still remain in the same PM domain. >>>>> >>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>> the selected configuration. Would that better reflect the HW? >>>> >>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>> like to get to ... >>>> >>>> usb@70090000 { >>>> compatible = "nvidia,tegra210-xusb"; >>>> ... >>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>> }; >>> >>> So, is this really is a proper description of the HW? Isn't it so, >>> that the usb device always resides in one and the same PM domain? >> >> I guess technically, the usbhost controller resides in one partition and >> the super-speed logic in another. So could the usbhost domain be the >> primary? Possibly, but the device cannot be probed without both enabled. >> >>> Now, depending on the selected speed mode (superspeed) additional >>> logic may needs to be powered on and configured for the usb device to >>> work? >>> Perhaps, one could consider those additional logics as a master/parent >>> PM domain for the usb device's PM domain? >>> >>> Or this is not how the HW works? :-) >> >> It might be possible for this case, but to be honest, the more I think >> about this, I do wonder if we need to be able to make the framework a >> lot more flexible for devices that need multiple power-domains. In other >> words, for devices that use multiple domains allow them to control them >> similarly to what we do for regulators or clocks. So if there is more >> than one defined, then the genpd core will not bind the device to the >> pm-domain and let the driver handle it. This way if you do need more >> granular control of the pm-domains in the driver you can do whatever you >> need to. >> >> I know that Rajendra (CC'ed) was looking into whether he had a need to >> control multiple power-domains individually from within the context of a >> single device driver. > > So Rajendra commented to say that he does not see a need for individual > control of power-domains for now, but a need for specifying multiple. > > One simple option would be to allow users to specify multiple and have > the genpd core effectively ignore such devices and leave it to the > driver to configure manually. I have been able to do this for XUSB by > dynamically adding power-domains to the device. > > Let me know if you have any more thoughts on how we can do this. Any more thoughts on this? Seems that there are a few others that would be interested in supporting multiple domains for a device. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <d961715d-820a-dd63-e3a9-c908ce465582-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-16 10:48 ` Jon Hunter @ 2016-11-16 12:53 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2016-11-16 12:53 UTC (permalink / raw) To: Jon Hunter Cc: Ulf Hansson, Kevin Hilman, Rafael J. Wysocki, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rajendra Nayak On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > Hi Kevin, Ulf, > > On 03/11/16 14:20, Jon Hunter wrote: >> >> On 11/10/16 10:15, Jon Hunter wrote: >> >> ... >> >>>>>> Second, another way of seeing this is: Depending on the current >>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>> topology - but the device would still remain in the same PM domain. >>>>>> >>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>> the selected configuration. Would that better reflect the HW? >>>>> >>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>> like to get to ... >>>>> >>>>> usb@70090000 { >>>>> compatible = "nvidia,tegra210-xusb"; >>>>> ... >>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>> }; >>>> >>>> So, is this really is a proper description of the HW? Isn't it so, >>>> that the usb device always resides in one and the same PM domain? >>> >>> I guess technically, the usbhost controller resides in one partition and >>> the super-speed logic in another. So could the usbhost domain be the >>> primary? Possibly, but the device cannot be probed without both enabled. >>> >>>> Now, depending on the selected speed mode (superspeed) additional >>>> logic may needs to be powered on and configured for the usb device to >>>> work? >>>> Perhaps, one could consider those additional logics as a master/parent >>>> PM domain for the usb device's PM domain? >>>> >>>> Or this is not how the HW works? :-) >>> >>> It might be possible for this case, but to be honest, the more I think >>> about this, I do wonder if we need to be able to make the framework a >>> lot more flexible for devices that need multiple power-domains. In other >>> words, for devices that use multiple domains allow them to control them >>> similarly to what we do for regulators or clocks. So if there is more >>> than one defined, then the genpd core will not bind the device to the >>> pm-domain and let the driver handle it. This way if you do need more >>> granular control of the pm-domains in the driver you can do whatever you >>> need to. >>> >>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>> control multiple power-domains individually from within the context of a >>> single device driver. >> >> So Rajendra commented to say that he does not see a need for individual >> control of power-domains for now, but a need for specifying multiple. >> >> One simple option would be to allow users to specify multiple and have >> the genpd core effectively ignore such devices and leave it to the >> driver to configure manually. I have been able to do this for XUSB by >> dynamically adding power-domains to the device. >> >> Let me know if you have any more thoughts on how we can do this. > > Any more thoughts on this? Seems that there are a few others that would > be interested in supporting multiple domains for a device. There is a design limitation to that, however. The PM domain concept really is about intercepting the flow of PM callbacks for a device in order to carry out additional operations, not covered by the bus type or driver. That's why there is only one set of PM domain callbacks per device and I don't quite see how and why it would be useful to add more of them in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-16 12:53 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2016-11-16 12:53 UTC (permalink / raw) To: Jon Hunter Cc: Ulf Hansson, Kevin Hilman, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: > Hi Kevin, Ulf, > > On 03/11/16 14:20, Jon Hunter wrote: >> >> On 11/10/16 10:15, Jon Hunter wrote: >> >> ... >> >>>>>> Second, another way of seeing this is: Depending on the current >>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>> topology - but the device would still remain in the same PM domain. >>>>>> >>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>> the selected configuration. Would that better reflect the HW? >>>>> >>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>> like to get to ... >>>>> >>>>> usb@70090000 { >>>>> compatible = "nvidia,tegra210-xusb"; >>>>> ... >>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>> }; >>>> >>>> So, is this really is a proper description of the HW? Isn't it so, >>>> that the usb device always resides in one and the same PM domain? >>> >>> I guess technically, the usbhost controller resides in one partition and >>> the super-speed logic in another. So could the usbhost domain be the >>> primary? Possibly, but the device cannot be probed without both enabled. >>> >>>> Now, depending on the selected speed mode (superspeed) additional >>>> logic may needs to be powered on and configured for the usb device to >>>> work? >>>> Perhaps, one could consider those additional logics as a master/parent >>>> PM domain for the usb device's PM domain? >>>> >>>> Or this is not how the HW works? :-) >>> >>> It might be possible for this case, but to be honest, the more I think >>> about this, I do wonder if we need to be able to make the framework a >>> lot more flexible for devices that need multiple power-domains. In other >>> words, for devices that use multiple domains allow them to control them >>> similarly to what we do for regulators or clocks. So if there is more >>> than one defined, then the genpd core will not bind the device to the >>> pm-domain and let the driver handle it. This way if you do need more >>> granular control of the pm-domains in the driver you can do whatever you >>> need to. >>> >>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>> control multiple power-domains individually from within the context of a >>> single device driver. >> >> So Rajendra commented to say that he does not see a need for individual >> control of power-domains for now, but a need for specifying multiple. >> >> One simple option would be to allow users to specify multiple and have >> the genpd core effectively ignore such devices and leave it to the >> driver to configure manually. I have been able to do this for XUSB by >> dynamically adding power-domains to the device. >> >> Let me know if you have any more thoughts on how we can do this. > > Any more thoughts on this? Seems that there are a few others that would > be interested in supporting multiple domains for a device. There is a design limitation to that, however. The PM domain concept really is about intercepting the flow of PM callbacks for a device in order to carry out additional operations, not covered by the bus type or driver. That's why there is only one set of PM domain callbacks per device and I don't quite see how and why it would be useful to add more of them in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-16 12:53 ` Rafael J. Wysocki (?) @ 2016-11-22 11:12 ` Jon Hunter [not found] ` <d9a4c1cd-6682-663d-e30d-cc85f665cf64-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-11-22 18:26 ` Kevin Hilman -1 siblings, 2 replies; 91+ messages in thread From: Jon Hunter @ 2016-11-22 11:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ulf Hansson, Kevin Hilman, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 16/11/16 12:53, Rafael J. Wysocki wrote: > On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >> Hi Kevin, Ulf, >> >> On 03/11/16 14:20, Jon Hunter wrote: >>> >>> On 11/10/16 10:15, Jon Hunter wrote: >>> >>> ... >>> >>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>> >>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>> the selected configuration. Would that better reflect the HW? >>>>>> >>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>> like to get to ... >>>>>> >>>>>> usb@70090000 { >>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>> ... >>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>> }; >>>>> >>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>> that the usb device always resides in one and the same PM domain? >>>> >>>> I guess technically, the usbhost controller resides in one partition and >>>> the super-speed logic in another. So could the usbhost domain be the >>>> primary? Possibly, but the device cannot be probed without both enabled. >>>> >>>>> Now, depending on the selected speed mode (superspeed) additional >>>>> logic may needs to be powered on and configured for the usb device to >>>>> work? >>>>> Perhaps, one could consider those additional logics as a master/parent >>>>> PM domain for the usb device's PM domain? >>>>> >>>>> Or this is not how the HW works? :-) >>>> >>>> It might be possible for this case, but to be honest, the more I think >>>> about this, I do wonder if we need to be able to make the framework a >>>> lot more flexible for devices that need multiple power-domains. In other >>>> words, for devices that use multiple domains allow them to control them >>>> similarly to what we do for regulators or clocks. So if there is more >>>> than one defined, then the genpd core will not bind the device to the >>>> pm-domain and let the driver handle it. This way if you do need more >>>> granular control of the pm-domains in the driver you can do whatever you >>>> need to. >>>> >>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>> control multiple power-domains individually from within the context of a >>>> single device driver. >>> >>> So Rajendra commented to say that he does not see a need for individual >>> control of power-domains for now, but a need for specifying multiple. >>> >>> One simple option would be to allow users to specify multiple and have >>> the genpd core effectively ignore such devices and leave it to the >>> driver to configure manually. I have been able to do this for XUSB by >>> dynamically adding power-domains to the device. >>> >>> Let me know if you have any more thoughts on how we can do this. >> >> Any more thoughts on this? Seems that there are a few others that would >> be interested in supporting multiple domains for a device. > > There is a design limitation to that, however. > > The PM domain concept really is about intercepting the flow of PM > callbacks for a device in order to carry out additional operations, > not covered by the bus type or driver. That's why there is only one > set of PM domain callbacks per device and I don't quite see how and > why it would be useful to add more of them in there. Sorry for the delay. We do, however, support the nesting of power-domains to allow more than one power-domain to be controlled for a device. For the current implementations that use nested power-domains, I am not sure if the power-domains are truly nested or just describing a relationship between power-domains. Nesting power-domains could also work for the Tegra XHCI device. However, I don't wish to statically nest the power-domains in device-tree where they are defined so they are always nested, because this may not be always necessary. However, I would rather the client of the power-domains specify which power-domains they require and dynamically nested the power-domains at runtime. This is slightly different to what I proposed in this RFC, but it is not really beyond the bounds of what we support today IMO. What is missing is a means to do this dynamically and not statically. By the way, I am not sure if you are suggesting that for devices that may need multiple power-domains we should architect the driver differently and split it up in some way such that we have a power-domain per device. But for the case of the Tegra XHCI it is quite complex because the driver loads firmware which runs on a micro-controller and we need to manage the various power-domains that are used. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <d9a4c1cd-6682-663d-e30d-cc85f665cf64-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 11:12 ` Jon Hunter @ 2016-11-22 13:31 ` Ulf Hansson 2016-11-22 18:26 ` Kevin Hilman 1 sibling, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-11-22 13:31 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Rafael J. Wysocki, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rajendra Nayak On 22 November 2016 at 12:12, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > > On 16/11/16 12:53, Rafael J. Wysocki wrote: >> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>> Hi Kevin, Ulf, >>> >>> On 03/11/16 14:20, Jon Hunter wrote: >>>> >>>> On 11/10/16 10:15, Jon Hunter wrote: >>>> >>>> ... >>>> >>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>> >>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>> >>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>> like to get to ... >>>>>>> >>>>>>> usb@70090000 { >>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>> ... >>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>> }; >>>>>> >>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>> that the usb device always resides in one and the same PM domain? >>>>> >>>>> I guess technically, the usbhost controller resides in one partition and >>>>> the super-speed logic in another. So could the usbhost domain be the >>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>> >>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>> logic may needs to be powered on and configured for the usb device to >>>>>> work? >>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>> PM domain for the usb device's PM domain? >>>>>> >>>>>> Or this is not how the HW works? :-) >>>>> >>>>> It might be possible for this case, but to be honest, the more I think >>>>> about this, I do wonder if we need to be able to make the framework a >>>>> lot more flexible for devices that need multiple power-domains. In other >>>>> words, for devices that use multiple domains allow them to control them >>>>> similarly to what we do for regulators or clocks. So if there is more >>>>> than one defined, then the genpd core will not bind the device to the >>>>> pm-domain and let the driver handle it. This way if you do need more >>>>> granular control of the pm-domains in the driver you can do whatever you >>>>> need to. >>>>> >>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>> control multiple power-domains individually from within the context of a >>>>> single device driver. >>>> >>>> So Rajendra commented to say that he does not see a need for individual >>>> control of power-domains for now, but a need for specifying multiple. >>>> >>>> One simple option would be to allow users to specify multiple and have >>>> the genpd core effectively ignore such devices and leave it to the >>>> driver to configure manually. I have been able to do this for XUSB by >>>> dynamically adding power-domains to the device. >>>> >>>> Let me know if you have any more thoughts on how we can do this. >>> >>> Any more thoughts on this? Seems that there are a few others that would >>> be interested in supporting multiple domains for a device. >> >> There is a design limitation to that, however. >> >> The PM domain concept really is about intercepting the flow of PM >> callbacks for a device in order to carry out additional operations, >> not covered by the bus type or driver. That's why there is only one >> set of PM domain callbacks per device and I don't quite see how and >> why it would be useful to add more of them in there. > > Sorry for the delay. > > We do, however, support the nesting of power-domains to allow more than > one power-domain to be controlled for a device. For the current > implementations that use nested power-domains, I am not sure if the > power-domains are truly nested or just describing a relationship between > power-domains. > > Nesting power-domains could also work for the Tegra XHCI device. > However, I don't wish to statically nest the power-domains in > device-tree where they are defined so they are always nested, because > this may not be always necessary. However, I would rather the client of > the power-domains specify which power-domains they require and > dynamically nested the power-domains at runtime. This is slightly > different to what I proposed in this RFC, but it is not really beyond > the bounds of what we support today IMO. What is missing is a means to > do this dynamically and not statically. Hmm, going back to the original post for this thread. This more or less sounds very similar as the case for when Rajendra described the problem for the video decode block in msm8996, except that in this case you already have couple of different struct devices available that for you could deploy runtime PM. Then, wouldn't it be possible to assign a parent/child relationship for these devices, each device has its own corresponding PM domain - instead of having to dynamically nest PM domains. Runtime PM will help to make sure parent devices are always active when child devices also are active. > > By the way, I am not sure if you are suggesting that for devices that > may need multiple power-domains we should architect the driver > differently and split it up in some way such that we have a power-domain > per device. But for the case of the Tegra XHCI it is quite complex > because the driver loads firmware which runs on a micro-controller and > we need to manage the various power-domains that are used. Again, if it's possible to model the topology by using parent/child devices, and deploy runtime PM for them, then we shouldn't need more than one PM domain per device. I am not sure that works here though, but just and idea. Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-22 13:31 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2016-11-22 13:31 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 22 November 2016 at 12:12, Jon Hunter <jonathanh@nvidia.com> wrote: > > On 16/11/16 12:53, Rafael J. Wysocki wrote: >> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> Hi Kevin, Ulf, >>> >>> On 03/11/16 14:20, Jon Hunter wrote: >>>> >>>> On 11/10/16 10:15, Jon Hunter wrote: >>>> >>>> ... >>>> >>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>> >>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>> >>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>> like to get to ... >>>>>>> >>>>>>> usb@70090000 { >>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>> ... >>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>> }; >>>>>> >>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>> that the usb device always resides in one and the same PM domain? >>>>> >>>>> I guess technically, the usbhost controller resides in one partition and >>>>> the super-speed logic in another. So could the usbhost domain be the >>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>> >>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>> logic may needs to be powered on and configured for the usb device to >>>>>> work? >>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>> PM domain for the usb device's PM domain? >>>>>> >>>>>> Or this is not how the HW works? :-) >>>>> >>>>> It might be possible for this case, but to be honest, the more I think >>>>> about this, I do wonder if we need to be able to make the framework a >>>>> lot more flexible for devices that need multiple power-domains. In other >>>>> words, for devices that use multiple domains allow them to control them >>>>> similarly to what we do for regulators or clocks. So if there is more >>>>> than one defined, then the genpd core will not bind the device to the >>>>> pm-domain and let the driver handle it. This way if you do need more >>>>> granular control of the pm-domains in the driver you can do whatever you >>>>> need to. >>>>> >>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>> control multiple power-domains individually from within the context of a >>>>> single device driver. >>>> >>>> So Rajendra commented to say that he does not see a need for individual >>>> control of power-domains for now, but a need for specifying multiple. >>>> >>>> One simple option would be to allow users to specify multiple and have >>>> the genpd core effectively ignore such devices and leave it to the >>>> driver to configure manually. I have been able to do this for XUSB by >>>> dynamically adding power-domains to the device. >>>> >>>> Let me know if you have any more thoughts on how we can do this. >>> >>> Any more thoughts on this? Seems that there are a few others that would >>> be interested in supporting multiple domains for a device. >> >> There is a design limitation to that, however. >> >> The PM domain concept really is about intercepting the flow of PM >> callbacks for a device in order to carry out additional operations, >> not covered by the bus type or driver. That's why there is only one >> set of PM domain callbacks per device and I don't quite see how and >> why it would be useful to add more of them in there. > > Sorry for the delay. > > We do, however, support the nesting of power-domains to allow more than > one power-domain to be controlled for a device. For the current > implementations that use nested power-domains, I am not sure if the > power-domains are truly nested or just describing a relationship between > power-domains. > > Nesting power-domains could also work for the Tegra XHCI device. > However, I don't wish to statically nest the power-domains in > device-tree where they are defined so they are always nested, because > this may not be always necessary. However, I would rather the client of > the power-domains specify which power-domains they require and > dynamically nested the power-domains at runtime. This is slightly > different to what I proposed in this RFC, but it is not really beyond > the bounds of what we support today IMO. What is missing is a means to > do this dynamically and not statically. Hmm, going back to the original post for this thread. This more or less sounds very similar as the case for when Rajendra described the problem for the video decode block in msm8996, except that in this case you already have couple of different struct devices available that for you could deploy runtime PM. Then, wouldn't it be possible to assign a parent/child relationship for these devices, each device has its own corresponding PM domain - instead of having to dynamically nest PM domains. Runtime PM will help to make sure parent devices are always active when child devices also are active. > > By the way, I am not sure if you are suggesting that for devices that > may need multiple power-domains we should architect the driver > differently and split it up in some way such that we have a power-domain > per device. But for the case of the Tegra XHCI it is quite complex > because the driver loads firmware which runs on a micro-controller and > we need to manage the various power-domains that are used. Again, if it's possible to model the topology by using parent/child devices, and deploy runtime PM for them, then we shouldn't need more than one PM domain per device. I am not sure that works here though, but just and idea. Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 13:31 ` Ulf Hansson (?) @ 2016-11-22 14:28 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-11-22 14:28 UTC (permalink / raw) To: Ulf Hansson Cc: Rafael J. Wysocki, Kevin Hilman, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 22/11/16 13:31, Ulf Hansson wrote: > On 22 November 2016 at 12:12, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 16/11/16 12:53, Rafael J. Wysocki wrote: ... >>> There is a design limitation to that, however. >>> >>> The PM domain concept really is about intercepting the flow of PM >>> callbacks for a device in order to carry out additional operations, >>> not covered by the bus type or driver. That's why there is only one >>> set of PM domain callbacks per device and I don't quite see how and >>> why it would be useful to add more of them in there. >> >> Sorry for the delay. >> >> We do, however, support the nesting of power-domains to allow more than >> one power-domain to be controlled for a device. For the current >> implementations that use nested power-domains, I am not sure if the >> power-domains are truly nested or just describing a relationship between >> power-domains. >> >> Nesting power-domains could also work for the Tegra XHCI device. >> However, I don't wish to statically nest the power-domains in >> device-tree where they are defined so they are always nested, because >> this may not be always necessary. However, I would rather the client of >> the power-domains specify which power-domains they require and >> dynamically nested the power-domains at runtime. This is slightly >> different to what I proposed in this RFC, but it is not really beyond >> the bounds of what we support today IMO. What is missing is a means to >> do this dynamically and not statically. > > Hmm, going back to the original post for this thread. > > This more or less sounds very similar as the case for when Rajendra > described the problem for the video decode block in msm8996, except > that in this case you already have couple of different struct devices > available that for you could deploy runtime PM. In this case there is only one device, so ... > Then, wouldn't it be possible to assign a parent/child relationship > for these devices, each device has its own corresponding PM domain - > instead of having to dynamically nest PM domains. ... no that will not work in this case unless we create some sort of dummy parent device but I was hoping to avoid that. > Runtime PM will help to make sure parent devices are always active > when child devices also are active. > >> >> By the way, I am not sure if you are suggesting that for devices that >> may need multiple power-domains we should architect the driver >> differently and split it up in some way such that we have a power-domain >> per device. But for the case of the Tegra XHCI it is quite complex >> because the driver loads firmware which runs on a micro-controller and >> we need to manage the various power-domains that are used. > > Again, if it's possible to model the topology by using parent/child > devices, and deploy runtime PM for them, then we shouldn't need more > than one PM domain per device. I am not sure that works here though, > but just and idea. It is really not too different from how we nest power-domains today. In fact I can manually nest them and add them to the device in the driver with the existing genpd APIs. However, I don't have a meaningful way to describe the power-domains that are used by the device in DT because there is more than one. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 11:12 ` Jon Hunter @ 2016-11-22 18:26 ` Kevin Hilman 2016-11-22 18:26 ` Kevin Hilman 1 sibling, 0 replies; 91+ messages in thread From: Kevin Hilman @ 2016-11-22 18:26 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak Jon Hunter <jonathanh@nvidia.com> writes: > On 16/11/16 12:53, Rafael J. Wysocki wrote: >> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> Hi Kevin, Ulf, >>> >>> On 03/11/16 14:20, Jon Hunter wrote: >>>> >>>> On 11/10/16 10:15, Jon Hunter wrote: >>>> >>>> ... >>>> >>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>> >>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>> >>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>> like to get to ... >>>>>>> >>>>>>> usb@70090000 { >>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>> ... >>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>> }; >>>>>> >>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>> that the usb device always resides in one and the same PM domain? >>>>> >>>>> I guess technically, the usbhost controller resides in one partition and >>>>> the super-speed logic in another. So could the usbhost domain be the >>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>> >>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>> logic may needs to be powered on and configured for the usb device to >>>>>> work? >>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>> PM domain for the usb device's PM domain? >>>>>> >>>>>> Or this is not how the HW works? :-) >>>>> >>>>> It might be possible for this case, but to be honest, the more I think >>>>> about this, I do wonder if we need to be able to make the framework a >>>>> lot more flexible for devices that need multiple power-domains. In other >>>>> words, for devices that use multiple domains allow them to control them >>>>> similarly to what we do for regulators or clocks. So if there is more >>>>> than one defined, then the genpd core will not bind the device to the >>>>> pm-domain and let the driver handle it. This way if you do need more >>>>> granular control of the pm-domains in the driver you can do whatever you >>>>> need to. >>>>> >>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>> control multiple power-domains individually from within the context of a >>>>> single device driver. >>>> >>>> So Rajendra commented to say that he does not see a need for individual >>>> control of power-domains for now, but a need for specifying multiple. >>>> >>>> One simple option would be to allow users to specify multiple and have >>>> the genpd core effectively ignore such devices and leave it to the >>>> driver to configure manually. I have been able to do this for XUSB by >>>> dynamically adding power-domains to the device. >>>> >>>> Let me know if you have any more thoughts on how we can do this. >>> >>> Any more thoughts on this? Seems that there are a few others that would >>> be interested in supporting multiple domains for a device. >> >> There is a design limitation to that, however. >> >> The PM domain concept really is about intercepting the flow of PM >> callbacks for a device in order to carry out additional operations, >> not covered by the bus type or driver. That's why there is only one >> set of PM domain callbacks per device and I don't quite see how and >> why it would be useful to add more of them in there. @Rafael: Re: why it would be useful... Many ARM SoCs have devices that have independent power rails for the memory and the logic of an IP block. For example, while powering off the logic you could keep the memory at a retention voltage, so you'd want to treat those power domains separately. Today, in order to model this, you'd have to create another (dummy) device, just for the memory and put it in its own domain so the two could be controlled separately. > Sorry for the delay. > > We do, however, support the nesting of power-domains to allow more than > one power-domain to be controlled for a device. For the current > implementations that use nested power-domains, I am not sure if the > power-domains are truly nested or just describing a relationship between > power-domains. @Jon: Do you think the nesting could work to handle the above case too? > Nesting power-domains could also work for the Tegra XHCI device. > However, I don't wish to statically nest the power-domains in > device-tree where they are defined so they are always nested, because > this may not be always necessary. And, that's not describing the hardware very accurately either, IIUC > However, I would rather the client of > the power-domains specify which power-domains they require and > dynamically nested the power-domains at runtime. This is slightly > different to what I proposed in this RFC, but it is not really beyond > the bounds of what we support today IMO. What is missing is a means to > do this dynamically and not statically. > > By the way, I am not sure if you are suggesting that for devices that > may need multiple power-domains we should architect the driver > differently and split it up in some way such that we have a power-domain > per device. But for the case of the Tegra XHCI it is quite complex > because the driver loads firmware which runs on a micro-controller and > we need to manage the various power-domains that are used. IMO, constructing a network of new struct devices just to workaround limitations in the framework doesn't sound quite right either. Kevin ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-22 18:26 ` Kevin Hilman 0 siblings, 0 replies; 91+ messages in thread From: Kevin Hilman @ 2016-11-22 18:26 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak Jon Hunter <jonathanh@nvidia.com> writes: > On 16/11/16 12:53, Rafael J. Wysocki wrote: >> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> Hi Kevin, Ulf, >>> >>> On 03/11/16 14:20, Jon Hunter wrote: >>>> >>>> On 11/10/16 10:15, Jon Hunter wrote: >>>> >>>> ... >>>> >>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>> >>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>> >>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>> like to get to ... >>>>>>> >>>>>>> usb@70090000 { >>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>> ... >>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>> }; >>>>>> >>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>> that the usb device always resides in one and the same PM domain? >>>>> >>>>> I guess technically, the usbhost controller resides in one partition and >>>>> the super-speed logic in another. So could the usbhost domain be the >>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>> >>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>> logic may needs to be powered on and configured for the usb device to >>>>>> work? >>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>> PM domain for the usb device's PM domain? >>>>>> >>>>>> Or this is not how the HW works? :-) >>>>> >>>>> It might be possible for this case, but to be honest, the more I think >>>>> about this, I do wonder if we need to be able to make the framework a >>>>> lot more flexible for devices that need multiple power-domains. In other >>>>> words, for devices that use multiple domains allow them to control them >>>>> similarly to what we do for regulators or clocks. So if there is more >>>>> than one defined, then the genpd core will not bind the device to the >>>>> pm-domain and let the driver handle it. This way if you do need more >>>>> granular control of the pm-domains in the driver you can do whatever you >>>>> need to. >>>>> >>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>> control multiple power-domains individually from within the context of a >>>>> single device driver. >>>> >>>> So Rajendra commented to say that he does not see a need for individual >>>> control of power-domains for now, but a need for specifying multiple. >>>> >>>> One simple option would be to allow users to specify multiple and have >>>> the genpd core effectively ignore such devices and leave it to the >>>> driver to configure manually. I have been able to do this for XUSB by >>>> dynamically adding power-domains to the device. >>>> >>>> Let me know if you have any more thoughts on how we can do this. >>> >>> Any more thoughts on this? Seems that there are a few others that would >>> be interested in supporting multiple domains for a device. >> >> There is a design limitation to that, however. >> >> The PM domain concept really is about intercepting the flow of PM >> callbacks for a device in order to carry out additional operations, >> not covered by the bus type or driver. That's why there is only one >> set of PM domain callbacks per device and I don't quite see how and >> why it would be useful to add more of them in there. @Rafael: Re: why it would be useful... Many ARM SoCs have devices that have independent power rails for the memory and the logic of an IP block. For example, while powering off the logic you could keep the memory at a retention voltage, so you'd want to treat those power domains separately. Today, in order to model this, you'd have to create another (dummy) device, just for the memory and put it in its own domain so the two could be controlled separately. > Sorry for the delay. > > We do, however, support the nesting of power-domains to allow more than > one power-domain to be controlled for a device. For the current > implementations that use nested power-domains, I am not sure if the > power-domains are truly nested or just describing a relationship between > power-domains. @Jon: Do you think the nesting could work to handle the above case too? > Nesting power-domains could also work for the Tegra XHCI device. > However, I don't wish to statically nest the power-domains in > device-tree where they are defined so they are always nested, because > this may not be always necessary. And, that's not describing the hardware very accurately either, IIUC > However, I would rather the client of > the power-domains specify which power-domains they require and > dynamically nested the power-domains at runtime. This is slightly > different to what I proposed in this RFC, but it is not really beyond > the bounds of what we support today IMO. What is missing is a means to > do this dynamically and not statically. > > By the way, I am not sure if you are suggesting that for devices that > may need multiple power-domains we should architect the driver > differently and split it up in some way such that we have a power-domain > per device. But for the case of the Tegra XHCI it is quite complex > because the driver loads firmware which runs on a micro-controller and > we need to manage the various power-domains that are used. IMO, constructing a network of new struct devices just to workaround limitations in the framework doesn't sound quite right either. Kevin ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 18:26 ` Kevin Hilman (?) @ 2016-11-22 18:41 ` Jon Hunter 2016-11-24 2:30 ` Stephen Boyd -1 siblings, 1 reply; 91+ messages in thread From: Jon Hunter @ 2016-11-22 18:41 UTC (permalink / raw) To: Kevin Hilman Cc: Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 22/11/16 18:26, Kevin Hilman wrote: > Jon Hunter <jonathanh@nvidia.com> writes: > >> On 16/11/16 12:53, Rafael J. Wysocki wrote: >>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> Hi Kevin, Ulf, >>>> >>>> On 03/11/16 14:20, Jon Hunter wrote: >>>>> >>>>> On 11/10/16 10:15, Jon Hunter wrote: >>>>> >>>>> ... >>>>> >>>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>>> >>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>>> >>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>>> like to get to ... >>>>>>>> >>>>>>>> usb@70090000 { >>>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>>> ... >>>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>>> }; >>>>>>> >>>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>>> that the usb device always resides in one and the same PM domain? >>>>>> >>>>>> I guess technically, the usbhost controller resides in one partition and >>>>>> the super-speed logic in another. So could the usbhost domain be the >>>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>>> >>>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>>> logic may needs to be powered on and configured for the usb device to >>>>>>> work? >>>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>>> PM domain for the usb device's PM domain? >>>>>>> >>>>>>> Or this is not how the HW works? :-) >>>>>> >>>>>> It might be possible for this case, but to be honest, the more I think >>>>>> about this, I do wonder if we need to be able to make the framework a >>>>>> lot more flexible for devices that need multiple power-domains. In other >>>>>> words, for devices that use multiple domains allow them to control them >>>>>> similarly to what we do for regulators or clocks. So if there is more >>>>>> than one defined, then the genpd core will not bind the device to the >>>>>> pm-domain and let the driver handle it. This way if you do need more >>>>>> granular control of the pm-domains in the driver you can do whatever you >>>>>> need to. >>>>>> >>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>>> control multiple power-domains individually from within the context of a >>>>>> single device driver. >>>>> >>>>> So Rajendra commented to say that he does not see a need for individual >>>>> control of power-domains for now, but a need for specifying multiple. >>>>> >>>>> One simple option would be to allow users to specify multiple and have >>>>> the genpd core effectively ignore such devices and leave it to the >>>>> driver to configure manually. I have been able to do this for XUSB by >>>>> dynamically adding power-domains to the device. >>>>> >>>>> Let me know if you have any more thoughts on how we can do this. >>>> >>>> Any more thoughts on this? Seems that there are a few others that would >>>> be interested in supporting multiple domains for a device. >>> >>> There is a design limitation to that, however. >>> >>> The PM domain concept really is about intercepting the flow of PM >>> callbacks for a device in order to carry out additional operations, >>> not covered by the bus type or driver. That's why there is only one >>> set of PM domain callbacks per device and I don't quite see how and >>> why it would be useful to add more of them in there. > > @Rafael: Re: why it would be useful... > > Many ARM SoCs have devices that have independent power rails for the > memory and the logic of an IP block. For example, while powering off > the logic you could keep the memory at a retention voltage, so you'd > want to treat those power domains separately. > > Today, in order to model this, you'd have to create another (dummy) > device, just for the memory and put it in its own domain so the two > could be controlled separately. > >> Sorry for the delay. >> >> We do, however, support the nesting of power-domains to allow more than >> one power-domain to be controlled for a device. For the current >> implementations that use nested power-domains, I am not sure if the >> power-domains are truly nested or just describing a relationship between >> power-domains. > > @Jon: Do you think the nesting could work to handle the above case too? Difficult to say without all the details, for example do we need to worry about the order in which they are power-up/down? >> Nesting power-domains could also work for the Tegra XHCI device. >> However, I don't wish to statically nest the power-domains in >> device-tree where they are defined so they are always nested, because >> this may not be always necessary. > > And, that's not describing the hardware very accurately either, IIUC Right, but in DT may be I would have something like ... dev-xyz { compatible ="blah blah"; ... power-domains = <&domain-a>, <&domain-b>; }; ... which should describe the h/w, but it could just be implemented so that to make this work b would be nested under a. We would have to turn them on in sequence any way and so nesting here would be ok. The only problem would be then if you have another device ... dev-abc { compatible ="blah blah"; ... power-domains = <&domain-b>, <&domain-c>; }; ... which would mean c is nested under a and b. So may be for the generic case this is no good either. >> However, I would rather the client of >> the power-domains specify which power-domains they require and >> dynamically nested the power-domains at runtime. This is slightly >> different to what I proposed in this RFC, but it is not really beyond >> the bounds of what we support today IMO. What is missing is a means to >> do this dynamically and not statically. >> >> By the way, I am not sure if you are suggesting that for devices that >> may need multiple power-domains we should architect the driver >> differently and split it up in some way such that we have a power-domain >> per device. But for the case of the Tegra XHCI it is quite complex >> because the driver loads firmware which runs on a micro-controller and >> we need to manage the various power-domains that are used. > > IMO, constructing a network of new struct devices just to workaround > limitations in the framework doesn't sound quite right either. I agree. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 18:41 ` Jon Hunter @ 2016-11-24 2:30 ` Stephen Boyd [not found] ` <20161124023014.GK6095-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 0 siblings, 1 reply; 91+ messages in thread From: Stephen Boyd @ 2016-11-24 2:30 UTC (permalink / raw) To: Jon Hunter Cc: Kevin Hilman, Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak, Marek Szyprowski On 11/22, Jon Hunter wrote: > > On 22/11/16 18:26, Kevin Hilman wrote: > > Jon Hunter <jonathanh@nvidia.com> writes: > > > >> However, I would rather the client of > >> the power-domains specify which power-domains they require and > >> dynamically nested the power-domains at runtime. This is slightly > >> different to what I proposed in this RFC, but it is not really beyond > >> the bounds of what we support today IMO. What is missing is a means to > >> do this dynamically and not statically. > >> > >> By the way, I am not sure if you are suggesting that for devices that > >> may need multiple power-domains we should architect the driver > >> differently and split it up in some way such that we have a power-domain > >> per device. But for the case of the Tegra XHCI it is quite complex > >> because the driver loads firmware which runs on a micro-controller and > >> we need to manage the various power-domains that are used. > > > > IMO, constructing a network of new struct devices just to workaround > > limitations in the framework doesn't sound quite right either. > > I agree. > Marek is attempting to do this for the samsung clock controller[1] (patch #5 is informative). From what I can tell they have one DT node for their clock controller because it's one register address space to control clocks. But, certain clocks exposed by that driver only work when certain power domains are enabled. For example, they have a clock controller that exposes clock signals for multimedia hardware blocks like video accelerators, gpus, and cameras. The clocks seem to have been placed inside different power domains for the multimedia hardware they're associated with, so there may be 10 or so power domains that need to be enabled at different times for different clocks to work. If the GPU power domain isn't enabled when the GPU clocks are touched by the driver, things break, etc. In the proposed patchset, we have the top-level clock controller node with subnodes for each power domain that needs to be associated with clocks inside these different multimedia blocks. So we end up with one parent device and attached driver for the clock driver, and then that driver populates child nodes as devices and matches up clocks with child nodes while registering clks with clk_register(). Because we pass a dev pointer to clk_register, we associate different devices with different clocks all from the same top-level clock controller device driver. Then clk framework calls runtime_pm APIs with devices used during clk registration. Some of those devices don't have any driver bound to them, which feels odd. This seems like a case where we really want a better way to explicitly control power domains without making up subnodes and registering struct devices just to work around the one device to one genpd construct we have today. Maybe power domains just don't map to genpd though and that's the disconnect. [1] http://lkml.kernel.org/r/1477311130-6534-1-git-send-email-m.szyprowski@samsung.com -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <20161124023014.GK6095-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-24 2:30 ` Stephen Boyd @ 2016-11-29 11:33 ` Marek Szyprowski 0 siblings, 0 replies; 91+ messages in thread From: Marek Szyprowski @ 2016-11-29 11:33 UTC (permalink / raw) To: Stephen Boyd, Jon Hunter Cc: Kevin Hilman, Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rajendra Nayak Hi Stephen, Thanks for pointing to my patches, but I would like to clarify a few things. On 2016-11-24 03:30, Stephen Boyd wrote: > On 11/22, Jon Hunter wrote: >> On 22/11/16 18:26, Kevin Hilman wrote: >>> Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> writes: >>>> However, I would rather the client of >>>> the power-domains specify which power-domains they require and >>>> dynamically nested the power-domains at runtime. This is slightly >>>> different to what I proposed in this RFC, but it is not really beyond >>>> the bounds of what we support today IMO. What is missing is a means to >>>> do this dynamically and not statically. >>>> >>>> By the way, I am not sure if you are suggesting that for devices that >>>> may need multiple power-domains we should architect the driver >>>> differently and split it up in some way such that we have a power-domain >>>> per device. But for the case of the Tegra XHCI it is quite complex >>>> because the driver loads firmware which runs on a micro-controller and >>>> we need to manage the various power-domains that are used. >>> IMO, constructing a network of new struct devices just to workaround >>> limitations in the framework doesn't sound quite right either. >> I agree. >> > Marek is attempting to do this for the samsung clock > controller[1] (patch #5 is informative). You probably meant patch #3 / #4, which is a patch for Exynos 4412 ( https://marc.info/?l=linux-arm-kernel&m=147731142926053&w=2 ). Patch #5 is for Exynos 5433, which already has separate nodes for each clock sub-controller, so there is no problem to add generic power domains there (see multiple CMU nodes): https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261 > From what I can tell > they have one DT node for their clock controller because it's one > register address space to control clocks. But, certain clocks > exposed by that driver only work when certain power domains are > enabled. For example, they have a clock controller that exposes > clock signals for multimedia hardware blocks like video > accelerators, gpus, and cameras. The clocks seem to have been > placed inside different power domains for the multimedia hardware > they're associated with, so there may be 10 or so power domains > that need to be enabled at different times for different clocks > to work. If the GPU power domain isn't enabled when the GPU > clocks are touched by the driver, things break, etc. > > In the proposed patchset, we have the top-level clock controller > node with subnodes for each power domain that needs to be > associated with clocks inside these different multimedia blocks. This is valid only for the Exynos4412 case (and not-yet-posted Exynos5422), which has a single clock controller node and patch #4 added a sub-node for ISP clocks part (the only one which in fact is in the other power domain). > So we end up with one parent device and attached driver for the > clock driver, and then that driver populates child nodes as > devices and matches up clocks with child nodes while registering > clks with clk_register(). Because we pass a dev pointer to > clk_register, we associate different devices with different > clocks all from the same top-level clock controller device > driver. Then clk framework calls runtime_pm APIs with devices > used during clk registration. Right, this is how I did it for Exynos4412 case. > Some of those devices don't have > any driver bound to them, which feels odd. Well, I don't get this. In the proposed patches each sub-node has a separate driver, none is left without a driver. > This seems like a case where we really want a better way to > explicitly control power domains without making up subnodes and > registering struct devices just to work around the one device to > one genpd construct we have today. Maybe power domains just don't > map to genpd though and that's the disconnect. Having an API for full control over multiple power domain assigned to a single device node might indeed solve somehow this problem, but as long as runtime pm is tied to struct device, this will again end in creating virtual sub-devices per each power domain to fit runtime pm principles. However we might be able to avoid creating sub-nodes in the device tree. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-29 11:33 ` Marek Szyprowski 0 siblings, 0 replies; 91+ messages in thread From: Marek Szyprowski @ 2016-11-29 11:33 UTC (permalink / raw) To: Stephen Boyd, Jon Hunter Cc: Kevin Hilman, Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak Hi Stephen, Thanks for pointing to my patches, but I would like to clarify a few things. On 2016-11-24 03:30, Stephen Boyd wrote: > On 11/22, Jon Hunter wrote: >> On 22/11/16 18:26, Kevin Hilman wrote: >>> Jon Hunter <jonathanh@nvidia.com> writes: >>>> However, I would rather the client of >>>> the power-domains specify which power-domains they require and >>>> dynamically nested the power-domains at runtime. This is slightly >>>> different to what I proposed in this RFC, but it is not really beyond >>>> the bounds of what we support today IMO. What is missing is a means to >>>> do this dynamically and not statically. >>>> >>>> By the way, I am not sure if you are suggesting that for devices that >>>> may need multiple power-domains we should architect the driver >>>> differently and split it up in some way such that we have a power-domain >>>> per device. But for the case of the Tegra XHCI it is quite complex >>>> because the driver loads firmware which runs on a micro-controller and >>>> we need to manage the various power-domains that are used. >>> IMO, constructing a network of new struct devices just to workaround >>> limitations in the framework doesn't sound quite right either. >> I agree. >> > Marek is attempting to do this for the samsung clock > controller[1] (patch #5 is informative). You probably meant patch #3 / #4, which is a patch for Exynos 4412 ( https://marc.info/?l=linux-arm-kernel&m=147731142926053&w=2 ). Patch #5 is for Exynos 5433, which already has separate nodes for each clock sub-controller, so there is no problem to add generic power domains there (see multiple CMU nodes): https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261 > From what I can tell > they have one DT node for their clock controller because it's one > register address space to control clocks. But, certain clocks > exposed by that driver only work when certain power domains are > enabled. For example, they have a clock controller that exposes > clock signals for multimedia hardware blocks like video > accelerators, gpus, and cameras. The clocks seem to have been > placed inside different power domains for the multimedia hardware > they're associated with, so there may be 10 or so power domains > that need to be enabled at different times for different clocks > to work. If the GPU power domain isn't enabled when the GPU > clocks are touched by the driver, things break, etc. > > In the proposed patchset, we have the top-level clock controller > node with subnodes for each power domain that needs to be > associated with clocks inside these different multimedia blocks. This is valid only for the Exynos4412 case (and not-yet-posted Exynos5422), which has a single clock controller node and patch #4 added a sub-node for ISP clocks part (the only one which in fact is in the other power domain). > So we end up with one parent device and attached driver for the > clock driver, and then that driver populates child nodes as > devices and matches up clocks with child nodes while registering > clks with clk_register(). Because we pass a dev pointer to > clk_register, we associate different devices with different > clocks all from the same top-level clock controller device > driver. Then clk framework calls runtime_pm APIs with devices > used during clk registration. Right, this is how I did it for Exynos4412 case. > Some of those devices don't have > any driver bound to them, which feels odd. Well, I don't get this. In the proposed patches each sub-node has a separate driver, none is left without a driver. > This seems like a case where we really want a better way to > explicitly control power domains without making up subnodes and > registering struct devices just to work around the one device to > one genpd construct we have today. Maybe power domains just don't > map to genpd though and that's the disconnect. Having an API for full control over multiple power domain assigned to a single device node might indeed solve somehow this problem, but as long as runtime pm is tied to struct device, this will again end in creating virtual sub-devices per each power domain to fit runtime pm principles. However we might be able to avoid creating sub-nodes in the device tree. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <52af1977-8ca3-40d1-43bb-920c5b933f94-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-29 11:33 ` Marek Szyprowski @ 2016-12-15 11:38 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-12-15 11:38 UTC (permalink / raw) To: Marek Szyprowski, Stephen Boyd Cc: Kevin Hilman, Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rajendra Nayak On 29/11/16 11:33, Marek Szyprowski wrote: > Hi Stephen, > > Thanks for pointing to my patches, but I would like to clarify a few > things. > > On 2016-11-24 03:30, Stephen Boyd wrote: >> On 11/22, Jon Hunter wrote: >>> On 22/11/16 18:26, Kevin Hilman wrote: >>>> Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> writes: >>>>> However, I would rather the client of >>>>> the power-domains specify which power-domains they require and >>>>> dynamically nested the power-domains at runtime. This is slightly >>>>> different to what I proposed in this RFC, but it is not really beyond >>>>> the bounds of what we support today IMO. What is missing is a means to >>>>> do this dynamically and not statically. >>>>> >>>>> By the way, I am not sure if you are suggesting that for devices that >>>>> may need multiple power-domains we should architect the driver >>>>> differently and split it up in some way such that we have a >>>>> power-domain >>>>> per device. But for the case of the Tegra XHCI it is quite complex >>>>> because the driver loads firmware which runs on a micro-controller and >>>>> we need to manage the various power-domains that are used. >>>> IMO, constructing a network of new struct devices just to workaround >>>> limitations in the framework doesn't sound quite right either. >>> I agree. >>> >> Marek is attempting to do this for the samsung clock >> controller[1] (patch #5 is informative). > > You probably meant patch #3 / #4, which is a patch for Exynos 4412 > ( https://marc.info/?l=linux-arm-kernel&m=147731142926053&w=2 ). Sorry for the delay, I have been meaning to get back to this thread. Yes patch #3 is definitely interesting and highlights power-domain complexities with various SoCs ... https://marc.info/?l=linux-clk&m=147731116925951&w=2 > Patch #5 is for Exynos 5433, which already has separate nodes for > each clock sub-controller, so there is no problem to add generic > power domains there (see multiple CMU nodes): > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261 > > >> From what I can tell >> they have one DT node for their clock controller because it's one >> register address space to control clocks. But, certain clocks >> exposed by that driver only work when certain power domains are >> enabled. For example, they have a clock controller that exposes >> clock signals for multimedia hardware blocks like video >> accelerators, gpus, and cameras. The clocks seem to have been >> placed inside different power domains for the multimedia hardware >> they're associated with, so there may be 10 or so power domains >> that need to be enabled at different times for different clocks >> to work. If the GPU power domain isn't enabled when the GPU >> clocks are touched by the driver, things break, etc. >> >> In the proposed patchset, we have the top-level clock controller >> node with subnodes for each power domain that needs to be >> associated with clocks inside these different multimedia blocks. > > This is valid only for the Exynos4412 case (and not-yet-posted > Exynos5422), which has a single clock controller node and patch #4 > added a sub-node for ISP clocks part (the only one which in fact > is in the other power domain). > >> So we end up with one parent device and attached driver for the >> clock driver, and then that driver populates child nodes as >> devices and matches up clocks with child nodes while registering >> clks with clk_register(). Because we pass a dev pointer to >> clk_register, we associate different devices with different >> clocks all from the same top-level clock controller device >> driver. Then clk framework calls runtime_pm APIs with devices >> used during clk registration. > > Right, this is how I did it for Exynos4412 case. > >> Some of those devices don't have >> any driver bound to them, which feels odd. > > Well, I don't get this. In the proposed patches each sub-node has > a separate driver, none is left without a driver. So it seems in this solution you are creating a pseudo device in order to control the pm-domain. >> This seems like a case where we really want a better way to >> explicitly control power domains without making up subnodes and >> registering struct devices just to work around the one device to >> one genpd construct we have today. Maybe power domains just don't >> map to genpd though and that's the disconnect. > > Having an API for full control over multiple power domain assigned to > a single device node might indeed solve somehow this problem, but as > long as runtime pm is tied to struct device, this will again end in > creating virtual sub-devices per each power domain to fit runtime pm > principles. However we might be able to avoid creating sub-nodes in > the device tree. Right, but what if the device is not bound to the pm-domain? What if due to pm-domain complexities we need to have finer granularity over the control of pm-domains? It seems to me that because we don't always have foresight into the creativeness of the SoC h/w designers, may be the pm-domain framework needs to expose APIs to allow direct control of the pm-domains without binding the pm-domain to the device, so that these APIs can be called in the context on the runtime-pm callbacks as we do for clocks, etc. Do you see any benefit to being able to directly control the pm-domains? That said, I did recently add a patch to prevent the expose of the pm-domain struct to clients in order to be able to remove them [0]. However, ref-counting can obviously be used to allow client to request handles to pm-domains. Cheers Jon [0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/base/power/domain.c?id=f58d4e5ab0ca3453f091eab514474e9fdbfc539f -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-12-15 11:38 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-12-15 11:38 UTC (permalink / raw) To: Marek Szyprowski, Stephen Boyd Cc: Kevin Hilman, Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 29/11/16 11:33, Marek Szyprowski wrote: > Hi Stephen, > > Thanks for pointing to my patches, but I would like to clarify a few > things. > > On 2016-11-24 03:30, Stephen Boyd wrote: >> On 11/22, Jon Hunter wrote: >>> On 22/11/16 18:26, Kevin Hilman wrote: >>>> Jon Hunter <jonathanh@nvidia.com> writes: >>>>> However, I would rather the client of >>>>> the power-domains specify which power-domains they require and >>>>> dynamically nested the power-domains at runtime. This is slightly >>>>> different to what I proposed in this RFC, but it is not really beyond >>>>> the bounds of what we support today IMO. What is missing is a means to >>>>> do this dynamically and not statically. >>>>> >>>>> By the way, I am not sure if you are suggesting that for devices that >>>>> may need multiple power-domains we should architect the driver >>>>> differently and split it up in some way such that we have a >>>>> power-domain >>>>> per device. But for the case of the Tegra XHCI it is quite complex >>>>> because the driver loads firmware which runs on a micro-controller and >>>>> we need to manage the various power-domains that are used. >>>> IMO, constructing a network of new struct devices just to workaround >>>> limitations in the framework doesn't sound quite right either. >>> I agree. >>> >> Marek is attempting to do this for the samsung clock >> controller[1] (patch #5 is informative). > > You probably meant patch #3 / #4, which is a patch for Exynos 4412 > ( https://marc.info/?l=linux-arm-kernel&m=147731142926053&w=2 ). Sorry for the delay, I have been meaning to get back to this thread. Yes patch #3 is definitely interesting and highlights power-domain complexities with various SoCs ... https://marc.info/?l=linux-clk&m=147731116925951&w=2 > Patch #5 is for Exynos 5433, which already has separate nodes for > each clock sub-controller, so there is no problem to add generic > power domains there (see multiple CMU nodes): > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261 > > >> From what I can tell >> they have one DT node for their clock controller because it's one >> register address space to control clocks. But, certain clocks >> exposed by that driver only work when certain power domains are >> enabled. For example, they have a clock controller that exposes >> clock signals for multimedia hardware blocks like video >> accelerators, gpus, and cameras. The clocks seem to have been >> placed inside different power domains for the multimedia hardware >> they're associated with, so there may be 10 or so power domains >> that need to be enabled at different times for different clocks >> to work. If the GPU power domain isn't enabled when the GPU >> clocks are touched by the driver, things break, etc. >> >> In the proposed patchset, we have the top-level clock controller >> node with subnodes for each power domain that needs to be >> associated with clocks inside these different multimedia blocks. > > This is valid only for the Exynos4412 case (and not-yet-posted > Exynos5422), which has a single clock controller node and patch #4 > added a sub-node for ISP clocks part (the only one which in fact > is in the other power domain). > >> So we end up with one parent device and attached driver for the >> clock driver, and then that driver populates child nodes as >> devices and matches up clocks with child nodes while registering >> clks with clk_register(). Because we pass a dev pointer to >> clk_register, we associate different devices with different >> clocks all from the same top-level clock controller device >> driver. Then clk framework calls runtime_pm APIs with devices >> used during clk registration. > > Right, this is how I did it for Exynos4412 case. > >> Some of those devices don't have >> any driver bound to them, which feels odd. > > Well, I don't get this. In the proposed patches each sub-node has > a separate driver, none is left without a driver. So it seems in this solution you are creating a pseudo device in order to control the pm-domain. >> This seems like a case where we really want a better way to >> explicitly control power domains without making up subnodes and >> registering struct devices just to work around the one device to >> one genpd construct we have today. Maybe power domains just don't >> map to genpd though and that's the disconnect. > > Having an API for full control over multiple power domain assigned to > a single device node might indeed solve somehow this problem, but as > long as runtime pm is tied to struct device, this will again end in > creating virtual sub-devices per each power domain to fit runtime pm > principles. However we might be able to avoid creating sub-nodes in > the device tree. Right, but what if the device is not bound to the pm-domain? What if due to pm-domain complexities we need to have finer granularity over the control of pm-domains? It seems to me that because we don't always have foresight into the creativeness of the SoC h/w designers, may be the pm-domain framework needs to expose APIs to allow direct control of the pm-domains without binding the pm-domain to the device, so that these APIs can be called in the context on the runtime-pm callbacks as we do for clocks, etc. Do you see any benefit to being able to directly control the pm-domains? That said, I did recently add a patch to prevent the expose of the pm-domain struct to clients in order to be able to remove them [0]. However, ref-counting can obviously be used to allow client to request handles to pm-domains. Cheers Jon [0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/base/power/domain.c?id=f58d4e5ab0ca3453f091eab514474e9fdbfc539f -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 18:26 ` Kevin Hilman (?) (?) @ 2016-11-22 21:55 ` Rafael J. Wysocki [not found] ` <CAJZ5v0gUO8TqxbyLh37mfvoTLY1y1Uj91i9T6zcx5A9SmmcReA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> -1 siblings, 1 reply; 91+ messages in thread From: Rafael J. Wysocki @ 2016-11-22 21:55 UTC (permalink / raw) To: Kevin Hilman Cc: Jon Hunter, Rafael J. Wysocki, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman@baylibre.com> wrote: > Jon Hunter <jonathanh@nvidia.com> writes: > >> On 16/11/16 12:53, Rafael J. Wysocki wrote: >>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> Hi Kevin, Ulf, >>>> >>>> On 03/11/16 14:20, Jon Hunter wrote: >>>>> >>>>> On 11/10/16 10:15, Jon Hunter wrote: >>>>> >>>>> ... >>>>> >>>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>>> >>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>>> >>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>>> like to get to ... >>>>>>>> >>>>>>>> usb@70090000 { >>>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>>> ... >>>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>>> }; >>>>>>> >>>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>>> that the usb device always resides in one and the same PM domain? >>>>>> >>>>>> I guess technically, the usbhost controller resides in one partition and >>>>>> the super-speed logic in another. So could the usbhost domain be the >>>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>>> >>>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>>> logic may needs to be powered on and configured for the usb device to >>>>>>> work? >>>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>>> PM domain for the usb device's PM domain? >>>>>>> >>>>>>> Or this is not how the HW works? :-) >>>>>> >>>>>> It might be possible for this case, but to be honest, the more I think >>>>>> about this, I do wonder if we need to be able to make the framework a >>>>>> lot more flexible for devices that need multiple power-domains. In other >>>>>> words, for devices that use multiple domains allow them to control them >>>>>> similarly to what we do for regulators or clocks. So if there is more >>>>>> than one defined, then the genpd core will not bind the device to the >>>>>> pm-domain and let the driver handle it. This way if you do need more >>>>>> granular control of the pm-domains in the driver you can do whatever you >>>>>> need to. >>>>>> >>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>>> control multiple power-domains individually from within the context of a >>>>>> single device driver. >>>>> >>>>> So Rajendra commented to say that he does not see a need for individual >>>>> control of power-domains for now, but a need for specifying multiple. >>>>> >>>>> One simple option would be to allow users to specify multiple and have >>>>> the genpd core effectively ignore such devices and leave it to the >>>>> driver to configure manually. I have been able to do this for XUSB by >>>>> dynamically adding power-domains to the device. >>>>> >>>>> Let me know if you have any more thoughts on how we can do this. >>>> >>>> Any more thoughts on this? Seems that there are a few others that would >>>> be interested in supporting multiple domains for a device. >>> >>> There is a design limitation to that, however. >>> >>> The PM domain concept really is about intercepting the flow of PM >>> callbacks for a device in order to carry out additional operations, >>> not covered by the bus type or driver. That's why there is only one >>> set of PM domain callbacks per device and I don't quite see how and >>> why it would be useful to add more of them in there. > > @Rafael: Re: why it would be useful... > > Many ARM SoCs have devices that have independent power rails for the > memory and the logic of an IP block. For example, while powering off > the logic you could keep the memory at a retention voltage, so you'd > want to treat those power domains separately. > > Today, in order to model this, you'd have to create another (dummy) > device, just for the memory and put it in its own domain so the two > could be controlled separately. Perhaps if you want to use genpd for that. :-) Let me rephrase, though. I don't see why and how it would be useful to intercept the flow of PM callbacks for a given device more than once. Thanks, Rafael ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <CAJZ5v0gUO8TqxbyLh37mfvoTLY1y1Uj91i9T6zcx5A9SmmcReA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-22 21:55 ` Rafael J. Wysocki @ 2016-11-23 9:29 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-11-23 9:29 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman Cc: Ulf Hansson, Rafael J. Wysocki, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rajendra Nayak On 22/11/16 21:55, Rafael J. Wysocki wrote: > On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote: >> Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> writes: >> >>> On 16/11/16 12:53, Rafael J. Wysocki wrote: >>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>>>> Hi Kevin, Ulf, >>>>> >>>>> On 03/11/16 14:20, Jon Hunter wrote: >>>>>> >>>>>> On 11/10/16 10:15, Jon Hunter wrote: >>>>>> >>>>>> ... >>>>>> >>>>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>>>> >>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>>>> >>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>>>> like to get to ... >>>>>>>>> >>>>>>>>> usb@70090000 { >>>>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>>>> ... >>>>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>>>> }; >>>>>>>> >>>>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>>>> that the usb device always resides in one and the same PM domain? >>>>>>> >>>>>>> I guess technically, the usbhost controller resides in one partition and >>>>>>> the super-speed logic in another. So could the usbhost domain be the >>>>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>>>> >>>>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>>>> logic may needs to be powered on and configured for the usb device to >>>>>>>> work? >>>>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>>>> PM domain for the usb device's PM domain? >>>>>>>> >>>>>>>> Or this is not how the HW works? :-) >>>>>>> >>>>>>> It might be possible for this case, but to be honest, the more I think >>>>>>> about this, I do wonder if we need to be able to make the framework a >>>>>>> lot more flexible for devices that need multiple power-domains. In other >>>>>>> words, for devices that use multiple domains allow them to control them >>>>>>> similarly to what we do for regulators or clocks. So if there is more >>>>>>> than one defined, then the genpd core will not bind the device to the >>>>>>> pm-domain and let the driver handle it. This way if you do need more >>>>>>> granular control of the pm-domains in the driver you can do whatever you >>>>>>> need to. >>>>>>> >>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>>>> control multiple power-domains individually from within the context of a >>>>>>> single device driver. >>>>>> >>>>>> So Rajendra commented to say that he does not see a need for individual >>>>>> control of power-domains for now, but a need for specifying multiple. >>>>>> >>>>>> One simple option would be to allow users to specify multiple and have >>>>>> the genpd core effectively ignore such devices and leave it to the >>>>>> driver to configure manually. I have been able to do this for XUSB by >>>>>> dynamically adding power-domains to the device. >>>>>> >>>>>> Let me know if you have any more thoughts on how we can do this. >>>>> >>>>> Any more thoughts on this? Seems that there are a few others that would >>>>> be interested in supporting multiple domains for a device. >>>> >>>> There is a design limitation to that, however. >>>> >>>> The PM domain concept really is about intercepting the flow of PM >>>> callbacks for a device in order to carry out additional operations, >>>> not covered by the bus type or driver. That's why there is only one >>>> set of PM domain callbacks per device and I don't quite see how and >>>> why it would be useful to add more of them in there. >> >> @Rafael: Re: why it would be useful... >> >> Many ARM SoCs have devices that have independent power rails for the >> memory and the logic of an IP block. For example, while powering off >> the logic you could keep the memory at a retention voltage, so you'd >> want to treat those power domains separately. >> >> Today, in order to model this, you'd have to create another (dummy) >> device, just for the memory and put it in its own domain so the two >> could be controlled separately. > > Perhaps if you want to use genpd for that. :-) > > Let me rephrase, though. I don't see why and how it would be useful > to intercept the flow of PM callbacks for a given device more than > once. In this RFC, all I was proposing is that we create a dummy pm-domain that is a child of the actual pm-domains it uses and this new dummy pm-domain is associated with the device. Hence, you are still only intercepting the flow of PM callback once even with this approach. I am just using the parent-child relationship to ensure that all require pm-domains are turned on thats all. Sorry if I am still missing your point! Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-23 9:29 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2016-11-23 9:29 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman Cc: Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On 22/11/16 21:55, Rafael J. Wysocki wrote: > On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman@baylibre.com> wrote: >> Jon Hunter <jonathanh@nvidia.com> writes: >> >>> On 16/11/16 12:53, Rafael J. Wysocki wrote: >>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>>> Hi Kevin, Ulf, >>>>> >>>>> On 03/11/16 14:20, Jon Hunter wrote: >>>>>> >>>>>> On 11/10/16 10:15, Jon Hunter wrote: >>>>>> >>>>>> ... >>>>>> >>>>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>>>> >>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>>>> >>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>>>> like to get to ... >>>>>>>>> >>>>>>>>> usb@70090000 { >>>>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>>>> ... >>>>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>>>> }; >>>>>>>> >>>>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>>>> that the usb device always resides in one and the same PM domain? >>>>>>> >>>>>>> I guess technically, the usbhost controller resides in one partition and >>>>>>> the super-speed logic in another. So could the usbhost domain be the >>>>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>>>> >>>>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>>>> logic may needs to be powered on and configured for the usb device to >>>>>>>> work? >>>>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>>>> PM domain for the usb device's PM domain? >>>>>>>> >>>>>>>> Or this is not how the HW works? :-) >>>>>>> >>>>>>> It might be possible for this case, but to be honest, the more I think >>>>>>> about this, I do wonder if we need to be able to make the framework a >>>>>>> lot more flexible for devices that need multiple power-domains. In other >>>>>>> words, for devices that use multiple domains allow them to control them >>>>>>> similarly to what we do for regulators or clocks. So if there is more >>>>>>> than one defined, then the genpd core will not bind the device to the >>>>>>> pm-domain and let the driver handle it. This way if you do need more >>>>>>> granular control of the pm-domains in the driver you can do whatever you >>>>>>> need to. >>>>>>> >>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>>>> control multiple power-domains individually from within the context of a >>>>>>> single device driver. >>>>>> >>>>>> So Rajendra commented to say that he does not see a need for individual >>>>>> control of power-domains for now, but a need for specifying multiple. >>>>>> >>>>>> One simple option would be to allow users to specify multiple and have >>>>>> the genpd core effectively ignore such devices and leave it to the >>>>>> driver to configure manually. I have been able to do this for XUSB by >>>>>> dynamically adding power-domains to the device. >>>>>> >>>>>> Let me know if you have any more thoughts on how we can do this. >>>>> >>>>> Any more thoughts on this? Seems that there are a few others that would >>>>> be interested in supporting multiple domains for a device. >>>> >>>> There is a design limitation to that, however. >>>> >>>> The PM domain concept really is about intercepting the flow of PM >>>> callbacks for a device in order to carry out additional operations, >>>> not covered by the bus type or driver. That's why there is only one >>>> set of PM domain callbacks per device and I don't quite see how and >>>> why it would be useful to add more of them in there. >> >> @Rafael: Re: why it would be useful... >> >> Many ARM SoCs have devices that have independent power rails for the >> memory and the logic of an IP block. For example, while powering off >> the logic you could keep the memory at a retention voltage, so you'd >> want to treat those power domains separately. >> >> Today, in order to model this, you'd have to create another (dummy) >> device, just for the memory and put it in its own domain so the two >> could be controlled separately. > > Perhaps if you want to use genpd for that. :-) > > Let me rephrase, though. I don't see why and how it would be useful > to intercept the flow of PM callbacks for a given device more than > once. In this RFC, all I was proposing is that we create a dummy pm-domain that is a child of the actual pm-domains it uses and this new dummy pm-domain is associated with the device. Hence, you are still only intercepting the flow of PM callback once even with this approach. I am just using the parent-child relationship to ensure that all require pm-domains are turned on thats all. Sorry if I am still missing your point! Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <82802459-8292-efb7-ac23-733de8687d51-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-11-23 9:29 ` Jon Hunter @ 2016-11-23 13:15 ` Rafael J. Wysocki -1 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2016-11-23 13:15 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Rafael J. Wysocki, linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Rajendra Nayak On Wed, Nov 23, 2016 at 10:29 AM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > > On 22/11/16 21:55, Rafael J. Wysocki wrote: >> On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote: >>> Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> writes: >>> >>>> On 16/11/16 12:53, Rafael J. Wysocki wrote: >>>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>>>>> Hi Kevin, Ulf, >>>>>> >>>>>> On 03/11/16 14:20, Jon Hunter wrote: >>>>>>> >>>>>>> On 11/10/16 10:15, Jon Hunter wrote: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>>>>> >>>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>>>>> >>>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>>>>> like to get to ... >>>>>>>>>> >>>>>>>>>> usb@70090000 { >>>>>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>>>>> ... >>>>>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>>>>> }; >>>>>>>>> >>>>>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>>>>> that the usb device always resides in one and the same PM domain? >>>>>>>> >>>>>>>> I guess technically, the usbhost controller resides in one partition and >>>>>>>> the super-speed logic in another. So could the usbhost domain be the >>>>>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>>>>> >>>>>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>>>>> logic may needs to be powered on and configured for the usb device to >>>>>>>>> work? >>>>>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>>>>> PM domain for the usb device's PM domain? >>>>>>>>> >>>>>>>>> Or this is not how the HW works? :-) >>>>>>>> >>>>>>>> It might be possible for this case, but to be honest, the more I think >>>>>>>> about this, I do wonder if we need to be able to make the framework a >>>>>>>> lot more flexible for devices that need multiple power-domains. In other >>>>>>>> words, for devices that use multiple domains allow them to control them >>>>>>>> similarly to what we do for regulators or clocks. So if there is more >>>>>>>> than one defined, then the genpd core will not bind the device to the >>>>>>>> pm-domain and let the driver handle it. This way if you do need more >>>>>>>> granular control of the pm-domains in the driver you can do whatever you >>>>>>>> need to. >>>>>>>> >>>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>>>>> control multiple power-domains individually from within the context of a >>>>>>>> single device driver. >>>>>>> >>>>>>> So Rajendra commented to say that he does not see a need for individual >>>>>>> control of power-domains for now, but a need for specifying multiple. >>>>>>> >>>>>>> One simple option would be to allow users to specify multiple and have >>>>>>> the genpd core effectively ignore such devices and leave it to the >>>>>>> driver to configure manually. I have been able to do this for XUSB by >>>>>>> dynamically adding power-domains to the device. >>>>>>> >>>>>>> Let me know if you have any more thoughts on how we can do this. >>>>>> >>>>>> Any more thoughts on this? Seems that there are a few others that would >>>>>> be interested in supporting multiple domains for a device. >>>>> >>>>> There is a design limitation to that, however. >>>>> >>>>> The PM domain concept really is about intercepting the flow of PM >>>>> callbacks for a device in order to carry out additional operations, >>>>> not covered by the bus type or driver. That's why there is only one >>>>> set of PM domain callbacks per device and I don't quite see how and >>>>> why it would be useful to add more of them in there. >>> >>> @Rafael: Re: why it would be useful... >>> >>> Many ARM SoCs have devices that have independent power rails for the >>> memory and the logic of an IP block. For example, while powering off >>> the logic you could keep the memory at a retention voltage, so you'd >>> want to treat those power domains separately. >>> >>> Today, in order to model this, you'd have to create another (dummy) >>> device, just for the memory and put it in its own domain so the two >>> could be controlled separately. >> >> Perhaps if you want to use genpd for that. :-) >> >> Let me rephrase, though. I don't see why and how it would be useful >> to intercept the flow of PM callbacks for a given device more than >> once. > > In this RFC, all I was proposing is that we create a dummy pm-domain > that is a child of the actual pm-domains it uses and this new dummy > pm-domain is associated with the device. Hence, you are still only > intercepting the flow of PM callback once even with this approach. I am > just using the parent-child relationship to ensure that all require > pm-domains are turned on thats all. Sorry if I am still missing your point! No, you aren't, thanks for explaining that! Thanks, Rafael ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2016-11-23 13:15 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2016-11-23 13:15 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Rafael J. Wysocki, linux-pm, linux-kernel, linux-tegra, Rajendra Nayak On Wed, Nov 23, 2016 at 10:29 AM, Jon Hunter <jonathanh@nvidia.com> wrote: > > On 22/11/16 21:55, Rafael J. Wysocki wrote: >> On Tue, Nov 22, 2016 at 7:26 PM, Kevin Hilman <khilman@baylibre.com> wrote: >>> Jon Hunter <jonathanh@nvidia.com> writes: >>> >>>> On 16/11/16 12:53, Rafael J. Wysocki wrote: >>>>> On Wed, Nov 16, 2016 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>>>> Hi Kevin, Ulf, >>>>>> >>>>>> On 03/11/16 14:20, Jon Hunter wrote: >>>>>>> >>>>>>> On 11/10/16 10:15, Jon Hunter wrote: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>>>>> Second, another way of seeing this is: Depending on the current >>>>>>>>>>> runtime selected configuration you need to re-configure the PM domain >>>>>>>>>>> topology - but the device would still remain in the same PM domain. >>>>>>>>>>> >>>>>>>>>>> In other words, you would need to remove/add subdomain(s) depending on >>>>>>>>>>> the selected configuration. Would that better reflect the HW? >>>>>>>>>> >>>>>>>>>> I am not 100% sure I follow what you are saying, but ultimately, I would >>>>>>>>>> like to get to ... >>>>>>>>>> >>>>>>>>>> usb@70090000 { >>>>>>>>>> compatible = "nvidia,tegra210-xusb"; >>>>>>>>>> ... >>>>>>>>>> power-domains = <&pd_xusbhost>, <&pd_xusbss>; >>>>>>>>>> }; >>>>>>>>> >>>>>>>>> So, is this really is a proper description of the HW? Isn't it so, >>>>>>>>> that the usb device always resides in one and the same PM domain? >>>>>>>> >>>>>>>> I guess technically, the usbhost controller resides in one partition and >>>>>>>> the super-speed logic in another. So could the usbhost domain be the >>>>>>>> primary? Possibly, but the device cannot be probed without both enabled. >>>>>>>> >>>>>>>>> Now, depending on the selected speed mode (superspeed) additional >>>>>>>>> logic may needs to be powered on and configured for the usb device to >>>>>>>>> work? >>>>>>>>> Perhaps, one could consider those additional logics as a master/parent >>>>>>>>> PM domain for the usb device's PM domain? >>>>>>>>> >>>>>>>>> Or this is not how the HW works? :-) >>>>>>>> >>>>>>>> It might be possible for this case, but to be honest, the more I think >>>>>>>> about this, I do wonder if we need to be able to make the framework a >>>>>>>> lot more flexible for devices that need multiple power-domains. In other >>>>>>>> words, for devices that use multiple domains allow them to control them >>>>>>>> similarly to what we do for regulators or clocks. So if there is more >>>>>>>> than one defined, then the genpd core will not bind the device to the >>>>>>>> pm-domain and let the driver handle it. This way if you do need more >>>>>>>> granular control of the pm-domains in the driver you can do whatever you >>>>>>>> need to. >>>>>>>> >>>>>>>> I know that Rajendra (CC'ed) was looking into whether he had a need to >>>>>>>> control multiple power-domains individually from within the context of a >>>>>>>> single device driver. >>>>>>> >>>>>>> So Rajendra commented to say that he does not see a need for individual >>>>>>> control of power-domains for now, but a need for specifying multiple. >>>>>>> >>>>>>> One simple option would be to allow users to specify multiple and have >>>>>>> the genpd core effectively ignore such devices and leave it to the >>>>>>> driver to configure manually. I have been able to do this for XUSB by >>>>>>> dynamically adding power-domains to the device. >>>>>>> >>>>>>> Let me know if you have any more thoughts on how we can do this. >>>>>> >>>>>> Any more thoughts on this? Seems that there are a few others that would >>>>>> be interested in supporting multiple domains for a device. >>>>> >>>>> There is a design limitation to that, however. >>>>> >>>>> The PM domain concept really is about intercepting the flow of PM >>>>> callbacks for a device in order to carry out additional operations, >>>>> not covered by the bus type or driver. That's why there is only one >>>>> set of PM domain callbacks per device and I don't quite see how and >>>>> why it would be useful to add more of them in there. >>> >>> @Rafael: Re: why it would be useful... >>> >>> Many ARM SoCs have devices that have independent power rails for the >>> memory and the logic of an IP block. For example, while powering off >>> the logic you could keep the memory at a retention voltage, so you'd >>> want to treat those power domains separately. >>> >>> Today, in order to model this, you'd have to create another (dummy) >>> device, just for the memory and put it in its own domain so the two >>> could be controlled separately. >> >> Perhaps if you want to use genpd for that. :-) >> >> Let me rephrase, though. I don't see why and how it would be useful >> to intercept the flow of PM callbacks for a given device more than >> once. > > In this RFC, all I was proposing is that we create a dummy pm-domain > that is a child of the actual pm-domains it uses and this new dummy > pm-domain is associated with the device. Hence, you are still only > intercepting the flow of PM callback once even with this approach. I am > just using the parent-child relationship to ensure that all require > pm-domains are turned on thats all. Sorry if I am still missing your point! No, you aren't, thanks for explaining that! Thanks, Rafael ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2016-09-20 10:28 ` Jon Hunter @ 2017-02-28 15:18 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-02-28 15:18 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak, stanimir.varbanov, sboyd, Marek Szyprowski Cc: linux-pm, linux-kernel, linux-tegra Hi all, On 20/09/16 11:28, Jon Hunter wrote: > The Tegra124/210 XUSB subsystem (that consists of both host and device > controllers) 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>; > }; > > 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. I wanted to kick this thread again now in the new year and see if there is still some interest in pursuing this? There is still very much a need from a Tegra perspective. I have put all those who responded on TO. I know that a lot of time has passed since we discuss this and so if you are scratching your head wondering what I am harping on about, essentially with this RFC I was looking for a way to support devices that require multiple power domains where the domains do not have a parent-child relationship and so not are nested in anyway. If you need me to elaborate on the need for this, I am happy to do this. My take away from when we discussed this last year, was that there was a need for this. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-02-28 15:18 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-02-28 15:18 UTC (permalink / raw) To: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, geert, rnayak, stanimir.varbanov, sboyd, Marek Szyprowski Cc: linux-pm, linux-kernel, linux-tegra Hi all, On 20/09/16 11:28, Jon Hunter wrote: > The Tegra124/210 XUSB subsystem (that consists of both host and device > controllers) 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>; > }; > > 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. I wanted to kick this thread again now in the new year and see if there is still some interest in pursuing this? There is still very much a need from a Tegra perspective. I have put all those who responded on TO. I know that a lot of time has passed since we discuss this and so if you are scratching your head wondering what I am harping on about, essentially with this RFC I was looking for a way to support devices that require multiple power domains where the domains do not have a parent-child relationship and so not are nested in anyway. If you need me to elaborate on the need for this, I am happy to do this. My take away from when we discussed this last year, was that there was a need for this. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-02-28 15:18 ` Jon Hunter (?) @ 2017-02-28 15:29 ` Geert Uytterhoeven [not found] ` <CAMuHMdUAN+PHr_GSvyMzA8N6LgzPEXhQyG_rSwFUOvc9_v7JiA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> -1 siblings, 1 reply; 91+ messages in thread From: Geert Uytterhoeven @ 2017-02-28 15:29 UTC (permalink / raw) To: Jon Hunter Cc: Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, Rajendra Nayak, stanimir.varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra Hi Jon, On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter <jonathanh@nvidia.com> wrote: > On 20/09/16 11:28, Jon Hunter wrote: >> The Tegra124/210 XUSB subsystem (that consists of both host and device >> controllers) 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>; >> }; >> >> 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. > > I wanted to kick this thread again now in the new year and see if there > is still some interest in pursuing this? > > There is still very much a need from a Tegra perspective. I have put all > those who responded on TO. > > I know that a lot of time has passed since we discuss this and so if you > are scratching your head wondering what I am harping on about, > essentially with this RFC I was looking for a way to support devices > that require multiple power domains where the domains do not have a > parent-child relationship and so not are nested in anyway. > > If you need me to elaborate on the need for this, I am happy to do this. > My take away from when we discussed this last year, was that there was a > need for this. It definitely makes sense to me, as the "power-domains" DT binding is not limited to plain "power areas", but may refer to clock domains, too (cfr. the Linux "PM Domain" notion). For my (Renesas) use case, we have devices that are part of both a power area and a clock domain. Currently this is handled by the power area driver calling into the clock driver. Thanks! 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] 91+ messages in thread
[parent not found: <CAMuHMdUAN+PHr_GSvyMzA8N6LgzPEXhQyG_rSwFUOvc9_v7JiA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-02-28 15:29 ` Geert Uytterhoeven @ 2017-03-13 9:37 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-13 9:37 UTC (permalink / raw) To: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: Rajendra Nayak, stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA Hi Rafael, Kevin, Ulf, Looks like there is still some interest/needs in/for this. Any thoughts on how we can move this forward? Cheers Jon On 28/02/17 15:29, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >> On 20/09/16 11:28, Jon Hunter wrote: >>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>> controllers) 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>; >>> }; >>> >>> 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. >> >> I wanted to kick this thread again now in the new year and see if there >> is still some interest in pursuing this? >> >> There is still very much a need from a Tegra perspective. I have put all >> those who responded on TO. >> >> I know that a lot of time has passed since we discuss this and so if you >> are scratching your head wondering what I am harping on about, >> essentially with this RFC I was looking for a way to support devices >> that require multiple power domains where the domains do not have a >> parent-child relationship and so not are nested in anyway. >> >> If you need me to elaborate on the need for this, I am happy to do this. >> My take away from when we discussed this last year, was that there was a >> need for this. > > It definitely makes sense to me, as the "power-domains" DT binding is not > limited to plain "power areas", but may refer to clock domains, too > (cfr. the Linux "PM Domain" notion). > > For my (Renesas) use case, we have devices that are part of both a power > area and a clock domain. Currently this is handled by the power area driver > calling into the clock driver. > > Thanks! > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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 > -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-03-13 9:37 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-13 9:37 UTC (permalink / raw) To: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson Cc: Rajendra Nayak, stanimir.varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra Hi Rafael, Kevin, Ulf, Looks like there is still some interest/needs in/for this. Any thoughts on how we can move this forward? Cheers Jon On 28/02/17 15:29, Geert Uytterhoeven wrote: > Hi Jon, > > On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 20/09/16 11:28, Jon Hunter wrote: >>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>> controllers) 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>; >>> }; >>> >>> 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. >> >> I wanted to kick this thread again now in the new year and see if there >> is still some interest in pursuing this? >> >> There is still very much a need from a Tegra perspective. I have put all >> those who responded on TO. >> >> I know that a lot of time has passed since we discuss this and so if you >> are scratching your head wondering what I am harping on about, >> essentially with this RFC I was looking for a way to support devices >> that require multiple power domains where the domains do not have a >> parent-child relationship and so not are nested in anyway. >> >> If you need me to elaborate on the need for this, I am happy to do this. >> My take away from when we discussed this last year, was that there was a >> need for this. > > It definitely makes sense to me, as the "power-domains" DT binding is not > limited to plain "power areas", but may refer to clock domains, too > (cfr. the Linux "PM Domain" notion). > > For my (Renesas) use case, we have devices that are part of both a power > area and a clock domain. Currently this is handled by the power area driver > calling into the clock driver. > > Thanks! > > 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 > -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <f4b3a93e-e29f-6fc6-6e7f-8c51081cbe15-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 9:37 ` Jon Hunter @ 2017-03-13 11:45 ` Ulf Hansson -1 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2017-03-13 11:45 UTC (permalink / raw) To: Jon Hunter Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Bjorn Andersson +Björn On 13 March 2017 at 10:37, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > Hi Rafael, Kevin, Ulf, > > Looks like there is still some interest/needs in/for this. Any thoughts > on how we can move this forward? At the Linaro Connect last week, I was talking to Björn, Rajendra and Stephen more about these related issues. It definitely seems like we need to progress with this somehow, meaning we need a solution for being able to associate a device with more than one PM domain. In that context, I don't think genpd based on its current design, is a good fit to solve the problem. Instead I think we need something entirely new (perhaps some code can be borrowed from genpd), which is more similar to the clock/regulator framework. In other words, what you also were suggesting in a earlier reply. In this way, the driver/subsystem gains full flexibility of managing its device's PM domains, which seems like the best future-proof solution. Kind regards Uffe > > Cheers > Jon > > On 28/02/17 15:29, Geert Uytterhoeven wrote: >> Hi Jon, >> >> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>> On 20/09/16 11:28, Jon Hunter wrote: >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>> controllers) 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>; >>>> }; >>>> >>>> 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. >>> >>> I wanted to kick this thread again now in the new year and see if there >>> is still some interest in pursuing this? >>> >>> There is still very much a need from a Tegra perspective. I have put all >>> those who responded on TO. >>> >>> I know that a lot of time has passed since we discuss this and so if you >>> are scratching your head wondering what I am harping on about, >>> essentially with this RFC I was looking for a way to support devices >>> that require multiple power domains where the domains do not have a >>> parent-child relationship and so not are nested in anyway. >>> >>> If you need me to elaborate on the need for this, I am happy to do this. >>> My take away from when we discussed this last year, was that there was a >>> need for this. >> >> It definitely makes sense to me, as the "power-domains" DT binding is not >> limited to plain "power areas", but may refer to clock domains, too >> (cfr. the Linux "PM Domain" notion). >> >> For my (Renesas) use case, we have devices that are part of both a power >> area and a clock domain. Currently this is handled by the power area driver >> calling into the clock driver. >> >> Thanks! >> >> 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 >> > > -- > nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-03-13 11:45 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2017-03-13 11:45 UTC (permalink / raw) To: Jon Hunter Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson +Björn On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: > Hi Rafael, Kevin, Ulf, > > Looks like there is still some interest/needs in/for this. Any thoughts > on how we can move this forward? At the Linaro Connect last week, I was talking to Björn, Rajendra and Stephen more about these related issues. It definitely seems like we need to progress with this somehow, meaning we need a solution for being able to associate a device with more than one PM domain. In that context, I don't think genpd based on its current design, is a good fit to solve the problem. Instead I think we need something entirely new (perhaps some code can be borrowed from genpd), which is more similar to the clock/regulator framework. In other words, what you also were suggesting in a earlier reply. In this way, the driver/subsystem gains full flexibility of managing its device's PM domains, which seems like the best future-proof solution. Kind regards Uffe > > Cheers > Jon > > On 28/02/17 15:29, Geert Uytterhoeven wrote: >> Hi Jon, >> >> On Tue, Feb 28, 2017 at 4:18 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> On 20/09/16 11:28, Jon Hunter wrote: >>>> The Tegra124/210 XUSB subsystem (that consists of both host and device >>>> controllers) 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>; >>>> }; >>>> >>>> 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. >>> >>> I wanted to kick this thread again now in the new year and see if there >>> is still some interest in pursuing this? >>> >>> There is still very much a need from a Tegra perspective. I have put all >>> those who responded on TO. >>> >>> I know that a lot of time has passed since we discuss this and so if you >>> are scratching your head wondering what I am harping on about, >>> essentially with this RFC I was looking for a way to support devices >>> that require multiple power domains where the domains do not have a >>> parent-child relationship and so not are nested in anyway. >>> >>> If you need me to elaborate on the need for this, I am happy to do this. >>> My take away from when we discussed this last year, was that there was a >>> need for this. >> >> It definitely makes sense to me, as the "power-domains" DT binding is not >> limited to plain "power areas", but may refer to clock domains, too >> (cfr. the Linux "PM Domain" notion). >> >> For my (Renesas) use case, we have devices that are part of both a power >> area and a clock domain. Currently this is handled by the power area driver >> calling into the clock driver. >> >> Thanks! >> >> 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 >> > > -- > nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <CAPDyKFp20tDickB9mF1ZSRUvYBEsfATysENeMzGV9O8KXH2wig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 11:45 ` Ulf Hansson @ 2017-03-13 14:09 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-13 14:09 UTC (permalink / raw) To: Ulf Hansson Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Bjorn Andersson Hi Ulf, On 13/03/17 11:45, Ulf Hansson wrote: > +Björn > > On 13 March 2017 at 10:37, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >> Hi Rafael, Kevin, Ulf, >> >> Looks like there is still some interest/needs in/for this. Any thoughts >> on how we can move this forward? > > At the Linaro Connect last week, I was talking to Björn, Rajendra and > Stephen more about these related issues. > > It definitely seems like we need to progress with this somehow, > meaning we need a solution for being able to associate a device with > more than one PM domain. In that context, I don't think genpd based on > its current design, is a good fit to solve the problem. > > Instead I think we need something entirely new (perhaps some code can > be borrowed from genpd), which is more similar to the clock/regulator > framework. In other words, what you also were suggesting in a earlier > reply. > In this way, the driver/subsystem gains full flexibility of managing > its device's PM domains, which seems like the best future-proof > solution. I agree, I think that that would give us the most flexibility to handle whatever scenario. However, I was thinking that we could still use the genpd core to register pm-domains with and control. My thought was to allow devices to have a bindings with multiple pm-domains ... dev-xyz { ... power-domains = <&domain-a>, <&domain-b>; }; Then in the genpd core we do having something like ... diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index e697dec9d25b..d1ae6ddf4903 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) "samsung,power-domain", 0); if (!pd_args.np) return -ENOENT; + } else if (ret > 1) { + /* + * If there are more than one PM domain defined for a device, + * then these need to be manually controlled by the device + * driver because the genpd core cannot bind a device with + * more than one PM domain. + */ + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); + return 0; } Then add some new public APIs for getting and controlling the pm-domains ... struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); void pm_genpd_put(struct generic_pm_domain *pd); int pm_genpd_power_on(struct generic_pm_domain *pd); int pm_genpd_power_off(struct generic_pm_domain *pd); - Power on/off APIs would be synchronous types Are there any potential pitfalls of the above? Cheers Jon -- nvpublic ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-03-13 14:09 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-13 14:09 UTC (permalink / raw) To: Ulf Hansson Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson Hi Ulf, On 13/03/17 11:45, Ulf Hansson wrote: > +Björn > > On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: >> Hi Rafael, Kevin, Ulf, >> >> Looks like there is still some interest/needs in/for this. Any thoughts >> on how we can move this forward? > > At the Linaro Connect last week, I was talking to Björn, Rajendra and > Stephen more about these related issues. > > It definitely seems like we need to progress with this somehow, > meaning we need a solution for being able to associate a device with > more than one PM domain. In that context, I don't think genpd based on > its current design, is a good fit to solve the problem. > > Instead I think we need something entirely new (perhaps some code can > be borrowed from genpd), which is more similar to the clock/regulator > framework. In other words, what you also were suggesting in a earlier > reply. > In this way, the driver/subsystem gains full flexibility of managing > its device's PM domains, which seems like the best future-proof > solution. I agree, I think that that would give us the most flexibility to handle whatever scenario. However, I was thinking that we could still use the genpd core to register pm-domains with and control. My thought was to allow devices to have a bindings with multiple pm-domains ... dev-xyz { ... power-domains = <&domain-a>, <&domain-b>; }; Then in the genpd core we do having something like ... diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index e697dec9d25b..d1ae6ddf4903 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) "samsung,power-domain", 0); if (!pd_args.np) return -ENOENT; + } else if (ret > 1) { + /* + * If there are more than one PM domain defined for a device, + * then these need to be manually controlled by the device + * driver because the genpd core cannot bind a device with + * more than one PM domain. + */ + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); + return 0; } Then add some new public APIs for getting and controlling the pm-domains ... struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); void pm_genpd_put(struct generic_pm_domain *pd); int pm_genpd_power_on(struct generic_pm_domain *pd); int pm_genpd_power_off(struct generic_pm_domain *pd); - Power on/off APIs would be synchronous types Are there any potential pitfalls of the above? Cheers Jon -- nvpublic ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 14:09 ` Jon Hunter (?) @ 2017-03-13 14:19 ` Geert Uytterhoeven 2017-03-13 14:27 ` Jon Hunter -1 siblings, 1 reply; 91+ messages in thread From: Geert Uytterhoeven @ 2017-03-13 14:19 UTC (permalink / raw) To: Jon Hunter Cc: Ulf Hansson, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson Hi Jon, On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter <jonathanh@nvidia.com> wrote: > On 13/03/17 11:45, Ulf Hansson wrote: >> +Björn >> >> On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: >>> Looks like there is still some interest/needs in/for this. Any thoughts >>> on how we can move this forward? >> >> At the Linaro Connect last week, I was talking to Björn, Rajendra and >> Stephen more about these related issues. >> >> It definitely seems like we need to progress with this somehow, >> meaning we need a solution for being able to associate a device with >> more than one PM domain. In that context, I don't think genpd based on >> its current design, is a good fit to solve the problem. >> >> Instead I think we need something entirely new (perhaps some code can >> be borrowed from genpd), which is more similar to the clock/regulator >> framework. In other words, what you also were suggesting in a earlier >> reply. >> In this way, the driver/subsystem gains full flexibility of managing >> its device's PM domains, which seems like the best future-proof >> solution. > > I agree, I think that that would give us the most flexibility to handle > whatever scenario. However, I was thinking that we could still use the > genpd core to register pm-domains with and control. My thought was to > allow devices to have a bindings with multiple pm-domains ... > > dev-xyz { > ... > power-domains = <&domain-a>, <&domain-b>; > }; > > Then in the genpd core we do having something like ... > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index e697dec9d25b..d1ae6ddf4903 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) > "samsung,power-domain", 0); > if (!pd_args.np) > return -ENOENT; > + } else if (ret > 1) { > + /* > + * If there are more than one PM domain defined for a device, > + * then these need to be manually controlled by the device > + * driver because the genpd core cannot bind a device with Which device driver? The driver for the device that belongs to multiple PM domains? The PM domain providers? > + * more than one PM domain. > + */ > + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); > + return 0; > } > > Then add some new public APIs for getting and controlling the pm-domains ... > > struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); > - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. > > struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); > void pm_genpd_put(struct generic_pm_domain *pd); > int pm_genpd_power_on(struct generic_pm_domain *pd); > int pm_genpd_power_off(struct generic_pm_domain *pd); > - Power on/off APIs would be synchronous types > > Are there any potential pitfalls of the above? 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] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 14:19 ` Geert Uytterhoeven @ 2017-03-13 14:27 ` Jon Hunter [not found] ` <161ee6b9-7a76-c7b4-3cb4-06259fef4898-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 91+ messages in thread From: Jon Hunter @ 2017-03-13 14:27 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Ulf Hansson, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson Hi Geert, On 13/03/17 14:19, Geert Uytterhoeven wrote: > Hi Jon, > > On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 13/03/17 11:45, Ulf Hansson wrote: >>> +Björn >>> >>> On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>> on how we can move this forward? >>> >>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>> Stephen more about these related issues. >>> >>> It definitely seems like we need to progress with this somehow, >>> meaning we need a solution for being able to associate a device with >>> more than one PM domain. In that context, I don't think genpd based on >>> its current design, is a good fit to solve the problem. >>> >>> Instead I think we need something entirely new (perhaps some code can >>> be borrowed from genpd), which is more similar to the clock/regulator >>> framework. In other words, what you also were suggesting in a earlier >>> reply. >>> In this way, the driver/subsystem gains full flexibility of managing >>> its device's PM domains, which seems like the best future-proof >>> solution. >> >> I agree, I think that that would give us the most flexibility to handle >> whatever scenario. However, I was thinking that we could still use the >> genpd core to register pm-domains with and control. My thought was to >> allow devices to have a bindings with multiple pm-domains ... >> >> dev-xyz { >> ... >> power-domains = <&domain-a>, <&domain-b>; >> }; >> >> Then in the genpd core we do having something like ... >> >> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >> index e697dec9d25b..d1ae6ddf4903 100644 >> --- a/drivers/base/power/domain.c >> +++ b/drivers/base/power/domain.c >> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >> "samsung,power-domain", 0); >> if (!pd_args.np) >> return -ENOENT; >> + } else if (ret > 1) { >> + /* >> + * If there are more than one PM domain defined for a device, >> + * then these need to be manually controlled by the device >> + * driver because the genpd core cannot bind a device with > > Which device driver? > The driver for the device that belongs to multiple PM domains? Yes, exactly. So maybe I would need to say ... "manually controlled by the driver for *this* device ..." Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <161ee6b9-7a76-c7b4-3cb4-06259fef4898-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 14:27 ` Jon Hunter @ 2017-03-13 14:38 ` Geert Uytterhoeven 0 siblings, 0 replies; 91+ messages in thread From: Geert Uytterhoeven @ 2017-03-13 14:38 UTC (permalink / raw) To: Jon Hunter Cc: Ulf Hansson, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Bjorn Andersson Hi Jon, On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > On 13/03/17 14:19, Geert Uytterhoeven wrote: >> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>> On 13/03/17 11:45, Ulf Hansson wrote: >>>> +Björn >>>> >>>> On 13 March 2017 at 10:37, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>>> on how we can move this forward? >>>> >>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>>> Stephen more about these related issues. >>>> >>>> It definitely seems like we need to progress with this somehow, >>>> meaning we need a solution for being able to associate a device with >>>> more than one PM domain. In that context, I don't think genpd based on >>>> its current design, is a good fit to solve the problem. >>>> >>>> Instead I think we need something entirely new (perhaps some code can >>>> be borrowed from genpd), which is more similar to the clock/regulator >>>> framework. In other words, what you also were suggesting in a earlier >>>> reply. >>>> In this way, the driver/subsystem gains full flexibility of managing >>>> its device's PM domains, which seems like the best future-proof >>>> solution. >>> >>> I agree, I think that that would give us the most flexibility to handle >>> whatever scenario. However, I was thinking that we could still use the >>> genpd core to register pm-domains with and control. My thought was to >>> allow devices to have a bindings with multiple pm-domains ... >>> >>> dev-xyz { >>> ... >>> power-domains = <&domain-a>, <&domain-b>; >>> }; >>> >>> Then in the genpd core we do having something like ... >>> >>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >>> index e697dec9d25b..d1ae6ddf4903 100644 >>> --- a/drivers/base/power/domain.c >>> +++ b/drivers/base/power/domain.c >>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >>> "samsung,power-domain", 0); >>> if (!pd_args.np) >>> return -ENOENT; >>> + } else if (ret > 1) { >>> + /* >>> + * If there are more than one PM domain defined for a device, >>> + * then these need to be manually controlled by the device >>> + * driver because the genpd core cannot bind a device with >> >> Which device driver? >> The driver for the device that belongs to multiple PM domains? > > Yes, exactly. So maybe I would need to say ... "manually controlled by > the driver for *this* device ..." That looks a bit cumbersome to me. Power (and clock) domains are platform features. Any IP core may show up in a new SoC, and suddenly have become part of one or more PM Domains. Having to handle that in each individual driver will cause lots of churn. Especially as the multiple PM Domains a device may belong to may be fairly orthogonal to each other. 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] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-03-13 14:38 ` Geert Uytterhoeven 0 siblings, 0 replies; 91+ messages in thread From: Geert Uytterhoeven @ 2017-03-13 14:38 UTC (permalink / raw) To: Jon Hunter Cc: Ulf Hansson, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson Hi Jon, On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter <jonathanh@nvidia.com> wrote: > On 13/03/17 14:19, Geert Uytterhoeven wrote: >> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> On 13/03/17 11:45, Ulf Hansson wrote: >>>> +Björn >>>> >>>> On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: >>>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>>> on how we can move this forward? >>>> >>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>>> Stephen more about these related issues. >>>> >>>> It definitely seems like we need to progress with this somehow, >>>> meaning we need a solution for being able to associate a device with >>>> more than one PM domain. In that context, I don't think genpd based on >>>> its current design, is a good fit to solve the problem. >>>> >>>> Instead I think we need something entirely new (perhaps some code can >>>> be borrowed from genpd), which is more similar to the clock/regulator >>>> framework. In other words, what you also were suggesting in a earlier >>>> reply. >>>> In this way, the driver/subsystem gains full flexibility of managing >>>> its device's PM domains, which seems like the best future-proof >>>> solution. >>> >>> I agree, I think that that would give us the most flexibility to handle >>> whatever scenario. However, I was thinking that we could still use the >>> genpd core to register pm-domains with and control. My thought was to >>> allow devices to have a bindings with multiple pm-domains ... >>> >>> dev-xyz { >>> ... >>> power-domains = <&domain-a>, <&domain-b>; >>> }; >>> >>> Then in the genpd core we do having something like ... >>> >>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >>> index e697dec9d25b..d1ae6ddf4903 100644 >>> --- a/drivers/base/power/domain.c >>> +++ b/drivers/base/power/domain.c >>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >>> "samsung,power-domain", 0); >>> if (!pd_args.np) >>> return -ENOENT; >>> + } else if (ret > 1) { >>> + /* >>> + * If there are more than one PM domain defined for a device, >>> + * then these need to be manually controlled by the device >>> + * driver because the genpd core cannot bind a device with >> >> Which device driver? >> The driver for the device that belongs to multiple PM domains? > > Yes, exactly. So maybe I would need to say ... "manually controlled by > the driver for *this* device ..." That looks a bit cumbersome to me. Power (and clock) domains are platform features. Any IP core may show up in a new SoC, and suddenly have become part of one or more PM Domains. Having to handle that in each individual driver will cause lots of churn. Especially as the multiple PM Domains a device may belong to may be fairly orthogonal to each other. 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] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 14:38 ` Geert Uytterhoeven (?) @ 2017-03-13 14:51 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-13 14:51 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Ulf Hansson, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson Hi Geert, On 13/03/17 14:38, Geert Uytterhoeven wrote: > Hi Jon, > > On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> On 13/03/17 14:19, Geert Uytterhoeven wrote: >>> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> On 13/03/17 11:45, Ulf Hansson wrote: >>>>> +Björn >>>>> >>>>> On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: >>>>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>>>> on how we can move this forward? >>>>> >>>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>>>> Stephen more about these related issues. >>>>> >>>>> It definitely seems like we need to progress with this somehow, >>>>> meaning we need a solution for being able to associate a device with >>>>> more than one PM domain. In that context, I don't think genpd based on >>>>> its current design, is a good fit to solve the problem. >>>>> >>>>> Instead I think we need something entirely new (perhaps some code can >>>>> be borrowed from genpd), which is more similar to the clock/regulator >>>>> framework. In other words, what you also were suggesting in a earlier >>>>> reply. >>>>> In this way, the driver/subsystem gains full flexibility of managing >>>>> its device's PM domains, which seems like the best future-proof >>>>> solution. >>>> >>>> I agree, I think that that would give us the most flexibility to handle >>>> whatever scenario. However, I was thinking that we could still use the >>>> genpd core to register pm-domains with and control. My thought was to >>>> allow devices to have a bindings with multiple pm-domains ... >>>> >>>> dev-xyz { >>>> ... >>>> power-domains = <&domain-a>, <&domain-b>; >>>> }; >>>> >>>> Then in the genpd core we do having something like ... >>>> >>>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >>>> index e697dec9d25b..d1ae6ddf4903 100644 >>>> --- a/drivers/base/power/domain.c >>>> +++ b/drivers/base/power/domain.c >>>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >>>> "samsung,power-domain", 0); >>>> if (!pd_args.np) >>>> return -ENOENT; >>>> + } else if (ret > 1) { >>>> + /* >>>> + * If there are more than one PM domain defined for a device, >>>> + * then these need to be manually controlled by the device >>>> + * driver because the genpd core cannot bind a device with >>> >>> Which device driver? >>> The driver for the device that belongs to multiple PM domains? >> >> Yes, exactly. So maybe I would need to say ... "manually controlled by >> the driver for *this* device ..." > > That looks a bit cumbersome to me. > > Power (and clock) domains are platform features. Any IP core may show up > in a new SoC, and suddenly have become part of one or more PM Domains. > Having to handle that in each individual driver will cause lots of churn. > Especially as the multiple PM Domains a device may belong to may be > fairly orthogonal to each other. Yes that's true. However, in order to make this work for everyone and have a generic solution I am not sure how that can be avoided. If there are cases where devices require multiple PM domains but the usage is quite simple (ie. all on when device in use and all off when device is not in use), I could see the APIs I proposed being extended to include some _bulk() versions like we have for regulators. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <3e88692d-613b-9c25-2554-7d399c45637a-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 14:09 ` Jon Hunter @ 2017-03-13 14:42 ` Ulf Hansson -1 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2017-03-13 14:42 UTC (permalink / raw) To: Jon Hunter Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Bjorn Andersson On 13 March 2017 at 15:09, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > Hi Ulf, > > On 13/03/17 11:45, Ulf Hansson wrote: >> +Björn >> >> On 13 March 2017 at 10:37, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>> Hi Rafael, Kevin, Ulf, >>> >>> Looks like there is still some interest/needs in/for this. Any thoughts >>> on how we can move this forward? >> >> At the Linaro Connect last week, I was talking to Björn, Rajendra and >> Stephen more about these related issues. >> >> It definitely seems like we need to progress with this somehow, >> meaning we need a solution for being able to associate a device with >> more than one PM domain. In that context, I don't think genpd based on >> its current design, is a good fit to solve the problem. >> >> Instead I think we need something entirely new (perhaps some code can >> be borrowed from genpd), which is more similar to the clock/regulator >> framework. In other words, what you also were suggesting in a earlier >> reply. >> In this way, the driver/subsystem gains full flexibility of managing >> its device's PM domains, which seems like the best future-proof >> solution. > > I agree, I think that that would give us the most flexibility to handle > whatever scenario. However, I was thinking that we could still use the > genpd core to register pm-domains with and control. My thought was to > allow devices to have a bindings with multiple pm-domains ... > > dev-xyz { > ... > power-domains = <&domain-a>, <&domain-b>; > }; This could work. However, let's involve DT maintainers to make sure we get their input to this. Perhaps they prefer a different approach. > > Then in the genpd core we do having something like ... > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index e697dec9d25b..d1ae6ddf4903 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) > "samsung,power-domain", 0); > if (!pd_args.np) > return -ENOENT; > + } else if (ret > 1) { > + /* > + * If there are more than one PM domain defined for a device, > + * then these need to be manually controlled by the device > + * driver because the genpd core cannot bind a device with > + * more than one PM domain. > + */ > + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); > + return 0; > } > > Then add some new public APIs for getting and controlling the pm-domains ... > > struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); > - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. > > struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); > void pm_genpd_put(struct generic_pm_domain *pd); > int pm_genpd_power_on(struct generic_pm_domain *pd); > int pm_genpd_power_off(struct generic_pm_domain *pd); > - Power on/off APIs would be synchronous types > > Are there any potential pitfalls of the above? So if I understand correctly, you would like to extend genpd with some new APIs. It's worth a try, however my main worries are these: 1) These new API must not be allowed to be abused. I have seen that before as when people try to handle some corner cases, I don't want to that to happen again. To avoid that, perhaps we should continue the re-structuring and thus move structures/datas that are currently public, to be internal to genpd. To get a clean interface. 2) I wouldn't be surprised if we run into some tricky corner cases, as we get a mixture of devices handled by runtime PM and in some other cases via new APIs. Perhaps that can be sorted out!? Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-03-13 14:42 ` Ulf Hansson 0 siblings, 0 replies; 91+ messages in thread From: Ulf Hansson @ 2017-03-13 14:42 UTC (permalink / raw) To: Jon Hunter Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson On 13 March 2017 at 15:09, Jon Hunter <jonathanh@nvidia.com> wrote: > Hi Ulf, > > On 13/03/17 11:45, Ulf Hansson wrote: >> +Björn >> >> On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: >>> Hi Rafael, Kevin, Ulf, >>> >>> Looks like there is still some interest/needs in/for this. Any thoughts >>> on how we can move this forward? >> >> At the Linaro Connect last week, I was talking to Björn, Rajendra and >> Stephen more about these related issues. >> >> It definitely seems like we need to progress with this somehow, >> meaning we need a solution for being able to associate a device with >> more than one PM domain. In that context, I don't think genpd based on >> its current design, is a good fit to solve the problem. >> >> Instead I think we need something entirely new (perhaps some code can >> be borrowed from genpd), which is more similar to the clock/regulator >> framework. In other words, what you also were suggesting in a earlier >> reply. >> In this way, the driver/subsystem gains full flexibility of managing >> its device's PM domains, which seems like the best future-proof >> solution. > > I agree, I think that that would give us the most flexibility to handle > whatever scenario. However, I was thinking that we could still use the > genpd core to register pm-domains with and control. My thought was to > allow devices to have a bindings with multiple pm-domains ... > > dev-xyz { > ... > power-domains = <&domain-a>, <&domain-b>; > }; This could work. However, let's involve DT maintainers to make sure we get their input to this. Perhaps they prefer a different approach. > > Then in the genpd core we do having something like ... > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index e697dec9d25b..d1ae6ddf4903 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) > "samsung,power-domain", 0); > if (!pd_args.np) > return -ENOENT; > + } else if (ret > 1) { > + /* > + * If there are more than one PM domain defined for a device, > + * then these need to be manually controlled by the device > + * driver because the genpd core cannot bind a device with > + * more than one PM domain. > + */ > + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); > + return 0; > } > > Then add some new public APIs for getting and controlling the pm-domains ... > > struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); > - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. > > struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); > void pm_genpd_put(struct generic_pm_domain *pd); > int pm_genpd_power_on(struct generic_pm_domain *pd); > int pm_genpd_power_off(struct generic_pm_domain *pd); > - Power on/off APIs would be synchronous types > > Are there any potential pitfalls of the above? So if I understand correctly, you would like to extend genpd with some new APIs. It's worth a try, however my main worries are these: 1) These new API must not be allowed to be abused. I have seen that before as when people try to handle some corner cases, I don't want to that to happen again. To avoid that, perhaps we should continue the re-structuring and thus move structures/datas that are currently public, to be internal to genpd. To get a clean interface. 2) I wouldn't be surprised if we run into some tricky corner cases, as we get a mixture of devices handled by runtime PM and in some other cases via new APIs. Perhaps that can be sorted out!? Kind regards Uffe ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <CAPDyKFp6wWZghMuCV5iL=zA=u+m22ibtzB95ktzOPJjfRLi1eg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 14:42 ` Ulf Hansson @ 2017-03-15 8:57 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-15 8:57 UTC (permalink / raw) To: Ulf Hansson Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Bjorn Andersson On 13/03/17 14:42, Ulf Hansson wrote: > On 13 March 2017 at 15:09, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >> Hi Ulf, >> >> On 13/03/17 11:45, Ulf Hansson wrote: >>> +Björn >>> >>> On 13 March 2017 at 10:37, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: >>>> Hi Rafael, Kevin, Ulf, >>>> >>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>> on how we can move this forward? >>> >>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>> Stephen more about these related issues. >>> >>> It definitely seems like we need to progress with this somehow, >>> meaning we need a solution for being able to associate a device with >>> more than one PM domain. In that context, I don't think genpd based on >>> its current design, is a good fit to solve the problem. >>> >>> Instead I think we need something entirely new (perhaps some code can >>> be borrowed from genpd), which is more similar to the clock/regulator >>> framework. In other words, what you also were suggesting in a earlier >>> reply. >>> In this way, the driver/subsystem gains full flexibility of managing >>> its device's PM domains, which seems like the best future-proof >>> solution. >> >> I agree, I think that that would give us the most flexibility to handle >> whatever scenario. However, I was thinking that we could still use the >> genpd core to register pm-domains with and control. My thought was to >> allow devices to have a bindings with multiple pm-domains ... >> >> dev-xyz { >> ... >> power-domains = <&domain-a>, <&domain-b>; >> }; > > This could work. However, let's involve DT maintainers to make sure we > get their input to this. Perhaps they prefer a different approach. No problem. I should point out the above is for the #power-domain-cells = <0> case. >> >> Then in the genpd core we do having something like ... >> >> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >> index e697dec9d25b..d1ae6ddf4903 100644 >> --- a/drivers/base/power/domain.c >> +++ b/drivers/base/power/domain.c >> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >> "samsung,power-domain", 0); >> if (!pd_args.np) >> return -ENOENT; >> + } else if (ret > 1) { >> + /* >> + * If there are more than one PM domain defined for a device, >> + * then these need to be manually controlled by the device >> + * driver because the genpd core cannot bind a device with >> + * more than one PM domain. >> + */ >> + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); >> + return 0; >> } >> >> Then add some new public APIs for getting and controlling the pm-domains ... >> >> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); >> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. >> >> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); >> void pm_genpd_put(struct generic_pm_domain *pd); >> int pm_genpd_power_on(struct generic_pm_domain *pd); >> int pm_genpd_power_off(struct generic_pm_domain *pd); >> - Power on/off APIs would be synchronous types >> >> Are there any potential pitfalls of the above? > > So if I understand correctly, you would like to extend genpd with some > new APIs. It's worth a try, however my main worries are these: > > 1) These new API must not be allowed to be abused. > I have seen that before as when people try to handle some corner > cases, I don't want to that to happen again. To avoid that, perhaps we > should continue the re-structuring and thus move structures/datas that > are currently public, to be internal to genpd. To get a clean > interface. OK, fair enough. Any in particular you are concerned about? > 2) I wouldn't be surprised if we run into some tricky corner cases, as > we get a mixture of devices handled by runtime PM and in some other > cases via new APIs. Perhaps that can be sorted out!? Right that is a concern, however, I think that in the long-term we would be better off with the power-domains being controlled by the same underlying code as opposed to something different. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-03-15 8:57 ` Jon Hunter 0 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-15 8:57 UTC (permalink / raw) To: Ulf Hansson Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Rajendra Nayak, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson On 13/03/17 14:42, Ulf Hansson wrote: > On 13 March 2017 at 15:09, Jon Hunter <jonathanh@nvidia.com> wrote: >> Hi Ulf, >> >> On 13/03/17 11:45, Ulf Hansson wrote: >>> +Björn >>> >>> On 13 March 2017 at 10:37, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> Hi Rafael, Kevin, Ulf, >>>> >>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>> on how we can move this forward? >>> >>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>> Stephen more about these related issues. >>> >>> It definitely seems like we need to progress with this somehow, >>> meaning we need a solution for being able to associate a device with >>> more than one PM domain. In that context, I don't think genpd based on >>> its current design, is a good fit to solve the problem. >>> >>> Instead I think we need something entirely new (perhaps some code can >>> be borrowed from genpd), which is more similar to the clock/regulator >>> framework. In other words, what you also were suggesting in a earlier >>> reply. >>> In this way, the driver/subsystem gains full flexibility of managing >>> its device's PM domains, which seems like the best future-proof >>> solution. >> >> I agree, I think that that would give us the most flexibility to handle >> whatever scenario. However, I was thinking that we could still use the >> genpd core to register pm-domains with and control. My thought was to >> allow devices to have a bindings with multiple pm-domains ... >> >> dev-xyz { >> ... >> power-domains = <&domain-a>, <&domain-b>; >> }; > > This could work. However, let's involve DT maintainers to make sure we > get their input to this. Perhaps they prefer a different approach. No problem. I should point out the above is for the #power-domain-cells = <0> case. >> >> Then in the genpd core we do having something like ... >> >> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >> index e697dec9d25b..d1ae6ddf4903 100644 >> --- a/drivers/base/power/domain.c >> +++ b/drivers/base/power/domain.c >> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >> "samsung,power-domain", 0); >> if (!pd_args.np) >> return -ENOENT; >> + } else if (ret > 1) { >> + /* >> + * If there are more than one PM domain defined for a device, >> + * then these need to be manually controlled by the device >> + * driver because the genpd core cannot bind a device with >> + * more than one PM domain. >> + */ >> + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); >> + return 0; >> } >> >> Then add some new public APIs for getting and controlling the pm-domains ... >> >> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); >> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. >> >> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); >> void pm_genpd_put(struct generic_pm_domain *pd); >> int pm_genpd_power_on(struct generic_pm_domain *pd); >> int pm_genpd_power_off(struct generic_pm_domain *pd); >> - Power on/off APIs would be synchronous types >> >> Are there any potential pitfalls of the above? > > So if I understand correctly, you would like to extend genpd with some > new APIs. It's worth a try, however my main worries are these: > > 1) These new API must not be allowed to be abused. > I have seen that before as when people try to handle some corner > cases, I don't want to that to happen again. To avoid that, perhaps we > should continue the re-structuring and thus move structures/datas that > are currently public, to be internal to genpd. To get a clean > interface. OK, fair enough. Any in particular you are concerned about? > 2) I wouldn't be surprised if we run into some tricky corner cases, as > we get a mixture of devices handled by runtime PM and in some other > cases via new APIs. Perhaps that can be sorted out!? Right that is a concern, however, I think that in the long-term we would be better off with the power-domains being controlled by the same underlying code as opposed to something different. Cheers Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-13 14:09 ` Jon Hunter @ 2017-03-15 3:47 ` Nayak, Rajendra -1 siblings, 0 replies; 91+ messages in thread From: Nayak, Rajendra @ 2017-03-15 3:47 UTC (permalink / raw) To: Jon Hunter, Ulf Hansson Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, Bjorn Andersson Hey Jon, >>> Looks like there is still some interest/needs in/for this. Any thoughts >>> on how we can move this forward? >> >> At the Linaro Connect last week, I was talking to Björn, Rajendra and >> Stephen more about these related issues. >> >> It definitely seems like we need to progress with this somehow, >> meaning we need a solution for being able to associate a device with >> more than one PM domain. In that context, I don't think genpd based on >> its current design, is a good fit to solve the problem. >> >> Instead I think we need something entirely new (perhaps some code can >> be borrowed from genpd), which is more similar to the clock/regulator >> framework. In other words, what you also were suggesting in a earlier >> reply. >> In this way, the driver/subsystem gains full flexibility of managing >> its device's PM domains, which seems like the best future-proof >> solution. > > I agree, I think that that would give us the most flexibility to handle > whatever scenario. However, I was thinking that we could still use the > genpd core to register pm-domains with and control. My thought was to > allow devices to have a bindings with multiple pm-domains ... > > dev-xyz { > ... > power-domains = <&domain-a>, <&domain-b>; > }; > > Then in the genpd core we do having something like ... > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index e697dec9d25b..d1ae6ddf4903 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) > "samsung,power-domain", 0); > if (!pd_args.np) > return -ENOENT; > + } else if (ret > 1) { > + /* > + * If there are more than one PM domain defined for a device, > + * then these need to be manually controlled by the device > + * driver because the genpd core cannot bind a device with > + * more than one PM domain. > + */ > + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); > + return 0; > } > > Then add some new public APIs for getting and controlling the pm-domains ... > > struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); > - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. > > struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); > void pm_genpd_put(struct generic_pm_domain *pd); > int pm_genpd_power_on(struct generic_pm_domain *pd); > int pm_genpd_power_off(struct generic_pm_domain *pd); > - Power on/off APIs would be synchronous types These would also need some kind of usecounting I guess, since genpd otherwise relies on runtime PM to do the usecounting. This overall seems like a reasonable approach to solve the problem we have. While we discussed this approach at connect, we thought it would be a good idea to bring out some RFC on these lines to get the discussion going. Do you think you would be able to work on some quick RFC around these lines, else if you think you would be busy in the near term I can help with hacking up the changes as well. regards, Rajendra > > Are there any potential pitfalls of the above? > > Cheers > Jon > ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains @ 2017-03-15 3:47 ` Nayak, Rajendra 0 siblings, 0 replies; 91+ messages in thread From: Nayak, Rajendra @ 2017-03-15 3:47 UTC (permalink / raw) To: Jon Hunter, Ulf Hansson Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson Hey Jon, >>> Looks like there is still some interest/needs in/for this. Any thoughts >>> on how we can move this forward? >> >> At the Linaro Connect last week, I was talking to Björn, Rajendra and >> Stephen more about these related issues. >> >> It definitely seems like we need to progress with this somehow, >> meaning we need a solution for being able to associate a device with >> more than one PM domain. In that context, I don't think genpd based on >> its current design, is a good fit to solve the problem. >> >> Instead I think we need something entirely new (perhaps some code can >> be borrowed from genpd), which is more similar to the clock/regulator >> framework. In other words, what you also were suggesting in a earlier >> reply. >> In this way, the driver/subsystem gains full flexibility of managing >> its device's PM domains, which seems like the best future-proof >> solution. > > I agree, I think that that would give us the most flexibility to handle > whatever scenario. However, I was thinking that we could still use the > genpd core to register pm-domains with and control. My thought was to > allow devices to have a bindings with multiple pm-domains ... > > dev-xyz { > ... > power-domains = <&domain-a>, <&domain-b>; > }; > > Then in the genpd core we do having something like ... > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index e697dec9d25b..d1ae6ddf4903 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) > "samsung,power-domain", 0); > if (!pd_args.np) > return -ENOENT; > + } else if (ret > 1) { > + /* > + * If there are more than one PM domain defined for a device, > + * then these need to be manually controlled by the device > + * driver because the genpd core cannot bind a device with > + * more than one PM domain. > + */ > + dev_dbg(dev, "cannot add PM domains, %d detected!\n", ret); > + return 0; > } > > Then add some new public APIs for getting and controlling the pm-domains ... > > struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); > - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. > > struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); > void pm_genpd_put(struct generic_pm_domain *pd); > int pm_genpd_power_on(struct generic_pm_domain *pd); > int pm_genpd_power_off(struct generic_pm_domain *pd); > - Power on/off APIs would be synchronous types These would also need some kind of usecounting I guess, since genpd otherwise relies on runtime PM to do the usecounting. This overall seems like a reasonable approach to solve the problem we have. While we discussed this approach at connect, we thought it would be a good idea to bring out some RFC on these lines to get the discussion going. Do you think you would be able to work on some quick RFC around these lines, else if you think you would be busy in the near term I can help with hacking up the changes as well. regards, Rajendra > > Are there any potential pitfalls of the above? > > Cheers > Jon > ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-03-15 3:47 ` Nayak, Rajendra (?) @ 2017-03-15 9:03 ` Jon Hunter -1 siblings, 0 replies; 91+ messages in thread From: Jon Hunter @ 2017-03-15 9:03 UTC (permalink / raw) To: Nayak, Rajendra, Ulf Hansson Cc: Geert Uytterhoeven, Rafael J. Wysocki, Kevin Hilman, Stanimir Varbanov, Stephen Boyd, Marek Szyprowski, Linux PM list, linux-kernel, linux-tegra, Bjorn Andersson Hi Rajendra, On 15/03/17 03:47, Nayak, Rajendra wrote: > Hey Jon, > >>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>> on how we can move this forward? >>> >>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>> Stephen more about these related issues. >>> >>> It definitely seems like we need to progress with this somehow, >>> meaning we need a solution for being able to associate a device with >>> more than one PM domain. In that context, I don't think genpd based on >>> its current design, is a good fit to solve the problem. >>> >>> Instead I think we need something entirely new (perhaps some code can >>> be borrowed from genpd), which is more similar to the clock/regulator >>> framework. In other words, what you also were suggesting in a earlier >>> reply. >>> In this way, the driver/subsystem gains full flexibility of managing >>> its device's PM domains, which seems like the best future-proof >>> solution. >> >> I agree, I think that that would give us the most flexibility to handle >> whatever scenario. However, I was thinking that we could still use the >> genpd core to register pm-domains with and control. My thought was to >> allow devices to have a bindings with multiple pm-domains ... >> >> dev-xyz { >> ... >> power-domains = <&domain-a>, <&domain-b>; >> }; >> >> Then in the genpd core we do having something like ... >> >> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >> index e697dec9d25b..d1ae6ddf4903 100644 >> --- a/drivers/base/power/domain.c >> +++ b/drivers/base/power/domain.c >> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >> >> "samsung,power-domain", 0); >> if (!pd_args.np) >> return -ENOENT; >> + } else if (ret > 1) { >> + /* >> + * If there are more than one PM domain defined for a >> device, >> + * then these need to be manually controlled by the >> device >> + * driver because the genpd core cannot bind a device >> with >> + * more than one PM domain. >> + */ >> + dev_dbg(dev, "cannot add PM domains, %d detected!\n", >> ret); >> + return 0; >> } >> >> Then add some new public APIs for getting and controlling the >> pm-domains ... >> >> struct generic_pm_domain *pm_genpd_get(struct device *dev, char *name); >> - Use 'dev->of_node' to look-up pm-domain if populated, else uses name. >> >> struct generic_pm_domain *of_pm_genpd_get(struct device *dev, int index); >> void pm_genpd_put(struct generic_pm_domain *pd); >> int pm_genpd_power_on(struct generic_pm_domain *pd); >> int pm_genpd_power_off(struct generic_pm_domain *pd); >> - Power on/off APIs would be synchronous types > > These would also need some kind of usecounting I guess, since genpd > otherwise relies on runtime PM to do the usecounting. Yes exactly. > This overall seems like a reasonable approach to solve the problem we > have. While we discussed this approach at connect, we thought it would > be a good idea to bring out some RFC on these lines to get the > discussion going. Do you think you would be able to work on some quick > RFC around these lines, else if you think you would be busy in the near > term I can help with hacking up the changes as well. Yes I plan too. I will let you know if I get side tracked on something else. Cheers! Jon -- nvpublic ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains 2017-02-28 15:18 ` Jon Hunter (?) (?) @ 2017-03-01 6:19 ` Rajendra Nayak -1 siblings, 0 replies; 91+ messages in thread From: Rajendra Nayak @ 2017-03-01 6:19 UTC (permalink / raw) To: Jon Hunter, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson, geert, stanimir.varbanov, sboyd, Marek Szyprowski Cc: linux-pm, linux-kernel, linux-tegra, Viresh Kumar On 02/28/2017 08:48 PM, Jon Hunter wrote: > Hi all, > > On 20/09/16 11:28, Jon Hunter wrote: >> The Tegra124/210 XUSB subsystem (that consists of both host and device >> controllers) 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>; >> }; >> >> 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. > > I wanted to kick this thread again now in the new year and see if there > is still some interest in pursuing this? Thanks Jon for reviving this thread. I ran into the issue of having to support multiple powerdomains for a single device again while working with Viresh's 'domain performance state' patches [1], to add support for corners on qualcomm platforms. We do have devices which have logic and memory powered via separate rails, and the drivers would want to set 'performance states' on both, which an external core then translates into actual uV and programs the PMIC. [1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1340018.html > > There is still very much a need from a Tegra perspective. I have put all > those who responded on TO. > > I know that a lot of time has passed since we discuss this and so if you > are scratching your head wondering what I am harping on about, > essentially with this RFC I was looking for a way to support devices > that require multiple power domains where the domains do not have a > parent-child relationship and so not are nested in anyway. > > If you need me to elaborate on the need for this, I am happy to do this. > My take away from when we discussed this last year, was that there was a > need for this. > > Cheers > Jon > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ^ permalink raw reply [flat|nested] 91+ messages in thread
end of thread, other threads:[~2017-03-15 9:03 UTC | newest] Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-20 10:28 [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Jon Hunter 2016-09-20 10:28 ` Jon Hunter 2016-09-20 10:28 ` [RFC PATCH 1/3] PM / Domains: Add helper functions for finding and attaching PM domains Jon Hunter 2016-09-20 10:28 ` Jon Hunter [not found] ` <1474367287-10402-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-09-20 10:28 ` [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains Jon Hunter 2016-09-20 10:28 ` Jon Hunter 2016-09-20 17:54 ` Jon Hunter 2016-09-20 17:54 ` Jon Hunter 2016-09-21 8:53 ` Geert Uytterhoeven 2016-09-21 10:01 ` Jon Hunter 2016-09-21 10:01 ` Jon Hunter [not found] ` <CAMuHMdVc+EjkbcpPKyzbCfDjp65gF3xP3bhkjh6SKLt6KDTtXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-09-21 14:37 ` Jon Hunter 2016-09-21 14:37 ` Jon Hunter [not found] ` <658004af-e4f4-8b0c-cdc1-43661d331d70-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-09-21 14:57 ` Geert Uytterhoeven 2016-09-21 14:57 ` Geert Uytterhoeven 2016-09-23 12:57 ` Jon Hunter 2016-09-23 12:57 ` Jon Hunter [not found] ` <1c217cf4-8682-8e6d-6958-419923e995cd-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-09-23 14:27 ` Geert Uytterhoeven 2016-09-23 14:27 ` Geert Uytterhoeven 2016-09-30 8:05 ` Jon Hunter 2016-09-30 8:05 ` Jon Hunter 2016-10-07 9:14 ` Kevin Hilman 2016-10-07 9:14 ` Kevin Hilman [not found] ` <7hlgy0frlb.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> 2016-10-10 11:24 ` Jon Hunter 2016-10-10 11:24 ` Jon Hunter 2016-09-20 10:28 ` [RFC PATCH 3/3] dt-bindings: Add support for devices with multiple PM domains Jon Hunter 2016-09-20 10:28 ` Jon Hunter 2016-10-06 6:04 ` [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains Rajendra Nayak 2016-10-06 8:25 ` Jon Hunter 2016-10-06 8:25 ` Jon Hunter 2016-10-06 8:43 ` Rajendra Nayak 2016-10-31 10:44 ` Jon Hunter 2016-10-31 10:44 ` Jon Hunter 2016-11-02 8:56 ` Rajendra Nayak [not found] ` <5819AA42.5060603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2016-11-16 13:11 ` Ulf Hansson 2016-11-16 13:11 ` Ulf Hansson [not found] ` <CAPDyKFpdRzDotofr+0F6gfuWg4hHikEfmxS2aM2D+hmq_JpHRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-11-17 2:31 ` Rajendra Nayak 2016-11-17 2:31 ` Rajendra Nayak 2016-11-17 15:39 ` Stanimir Varbanov [not found] ` <4bafcd71-edc9-9ddd-d8c4-093e4d9c58db-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-11-22 13:05 ` Ulf Hansson 2016-11-22 13:05 ` Ulf Hansson 2016-11-23 3:48 ` Rajendra Nayak 2016-10-06 12:22 ` Ulf Hansson 2016-10-10 11:18 ` Jon Hunter [not found] ` <90faea7d-65b6-590a-83f1-24fcdffa0569-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-10-10 14:04 ` Ulf Hansson 2016-10-10 14:04 ` Ulf Hansson 2016-10-11 9:15 ` Jon Hunter [not found] ` <fd7c8f40-2a9f-b71c-bd11-43ee657441ae-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-11-03 14:20 ` Jon Hunter 2016-11-03 14:20 ` Jon Hunter 2016-11-16 10:48 ` Jon Hunter [not found] ` <d961715d-820a-dd63-e3a9-c908ce465582-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-11-16 12:53 ` Rafael J. Wysocki 2016-11-16 12:53 ` Rafael J. Wysocki 2016-11-22 11:12 ` Jon Hunter [not found] ` <d9a4c1cd-6682-663d-e30d-cc85f665cf64-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-11-22 13:31 ` Ulf Hansson 2016-11-22 13:31 ` Ulf Hansson 2016-11-22 14:28 ` Jon Hunter 2016-11-22 18:26 ` Kevin Hilman 2016-11-22 18:26 ` Kevin Hilman 2016-11-22 18:41 ` Jon Hunter 2016-11-24 2:30 ` Stephen Boyd [not found] ` <20161124023014.GK6095-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2016-11-29 11:33 ` Marek Szyprowski 2016-11-29 11:33 ` Marek Szyprowski [not found] ` <52af1977-8ca3-40d1-43bb-920c5b933f94-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 2016-12-15 11:38 ` Jon Hunter 2016-12-15 11:38 ` Jon Hunter 2016-11-22 21:55 ` Rafael J. Wysocki [not found] ` <CAJZ5v0gUO8TqxbyLh37mfvoTLY1y1Uj91i9T6zcx5A9SmmcReA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-11-23 9:29 ` Jon Hunter 2016-11-23 9:29 ` Jon Hunter [not found] ` <82802459-8292-efb7-ac23-733de8687d51-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2016-11-23 13:15 ` Rafael J. Wysocki 2016-11-23 13:15 ` Rafael J. Wysocki 2017-02-28 15:18 ` Jon Hunter 2017-02-28 15:18 ` Jon Hunter 2017-02-28 15:29 ` Geert Uytterhoeven [not found] ` <CAMuHMdUAN+PHr_GSvyMzA8N6LgzPEXhQyG_rSwFUOvc9_v7JiA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-03-13 9:37 ` Jon Hunter 2017-03-13 9:37 ` Jon Hunter [not found] ` <f4b3a93e-e29f-6fc6-6e7f-8c51081cbe15-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-03-13 11:45 ` Ulf Hansson 2017-03-13 11:45 ` Ulf Hansson [not found] ` <CAPDyKFp20tDickB9mF1ZSRUvYBEsfATysENeMzGV9O8KXH2wig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-03-13 14:09 ` Jon Hunter 2017-03-13 14:09 ` Jon Hunter 2017-03-13 14:19 ` Geert Uytterhoeven 2017-03-13 14:27 ` Jon Hunter [not found] ` <161ee6b9-7a76-c7b4-3cb4-06259fef4898-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-03-13 14:38 ` Geert Uytterhoeven 2017-03-13 14:38 ` Geert Uytterhoeven 2017-03-13 14:51 ` Jon Hunter [not found] ` <3e88692d-613b-9c25-2554-7d399c45637a-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2017-03-13 14:42 ` Ulf Hansson 2017-03-13 14:42 ` Ulf Hansson [not found] ` <CAPDyKFp6wWZghMuCV5iL=zA=u+m22ibtzB95ktzOPJjfRLi1eg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-03-15 8:57 ` Jon Hunter 2017-03-15 8:57 ` Jon Hunter 2017-03-15 3:47 ` Nayak, Rajendra 2017-03-15 3:47 ` Nayak, Rajendra 2017-03-15 9:03 ` Jon Hunter 2017-03-01 6:19 ` Rajendra Nayak
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.