[RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[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

[RFC PATCH 1/3] PM / Domains: Add helper functions for finding and attaching PM domains

[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

[RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[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

[RFC PATCH 3/3] dt-bindings: Add support for devices with multiple PM domains

[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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Geert Uytterhoeven]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Geert Uytterhoeven]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Geert Uytterhoeven]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rajendra Nayak]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rajendra Nayak]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Ulf Hansson]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Kevin Hilman]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 2/3] PM / Domains: Add support for devices with multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Ulf Hansson]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rajendra Nayak]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rafael J. Wysocki]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Ulf Hansson]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rajendra Nayak]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Stanimir Varbanov]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Ulf Hansson]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Ulf Hansson]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Kevin Hilman]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rafael J. Wysocki]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rajendra Nayak]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rafael J. Wysocki]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Stephen Boyd]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Marek Szyprowski]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Geert Uytterhoeven]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Rajendra Nayak]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Ulf Hansson]

+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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Geert Uytterhoeven]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Geert Uytterhoeven]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Ulf Hansson]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Nayak, Rajendra]

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
>

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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

Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains

[Jon Hunter]

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