[PATCH/RFC v6 0/7] PM / Domains: DT power-on/off and QoS device latencies

[PATCH/RFC v6 0/7] PM / Domains: DT power-on/off and QoS device latencies

[Geert Uytterhoeven]

	Hi all,

This patch series is an RFC to add (1) PM Domain power-on/off latencies
and (2) QoS device latencies to DT.

To provide a good quality of service, the PM subsystem suspends PM
Domains and devices only if this doesn't break QoS constraints.  While
the PM subsystem performs measurements of the various latencies
involved, and adapts automatically according to these measurements, it's
still beneficial to provide initial values for these latencies.
Currently these initial values, which are properties of the hardware,
can only be specified from C code. This RFC adds DT support for
specifying them.

All of these patches have been sent before (change logs are available in
the individual patches). I'm resending them upon request from Kevin
Hilman, and synced them all to the same version number (v6).

  - Patch 1 adds DT bindings for PM Domain power-on/off latencies,
  - Patches 2 and 3 update the DT bindings and support code for the
    Renesas R-Mobile system controller, providing a sample
    implementation,
  - Patch 4 adds DT bindings for QoS device latencies,
  - Patches 5 and 6 implement retrieving the QoS device latencies in the
    genpd code,
  - Patch 7 updates the DT bindings for the Renesas R-Mobile system
    controller, adding an example.

Compared to previous submissions, I've left out the (preliminary)
patches adding the actual latency values to the .dtsi files, as they
just used a single default value taken from the legacy code[*].

In the mean time, support for PM Domains with multiple states has been
proposed, cfr. "[RFC v5 0/8]  genpd multiple states v5"
(http://marc.info/?l=linux-pm&m=142989694214237&w=2).
If this is accepted, I think we have to rethink how to specify PM Domain
latencies (and be happy we didn't have the DT part cast in stone yet
;-), as they won't be limited to power-on/off latencies anymore.

Perhaps we should switch to a mechanism similar to what's used for idle
states (cfr. Documentation/devicetree/bindings/arm/idle-states.txt)?
I.e. a single "idle-states" node, with subnodes for each state, being
pointed to by phandles in the actual PM domain provider nodes.

What do you think?  Thanks for your comments!

Geert Uytterhoeven (7):
  [RFC] PM / Domains: Add DT bindings for power-on/off latencies
  [RFC] PM / Domains: R-Mobile SYSC: Add PM domain power-on/off
    latencies
  [RFC] ARM: shmobile: R-Mobile: Add support for PM domain power-on/off
    latencies
  [RFC] PM / Domains: Add DT bindings for PM QoS device latencies
  [RFC] PM / Domains: Add helper variable np = dev->of_node
  [RFC] PM / Domains: Retrieve PM QoS device latencies from DT
  [RFC] PM / Domains: R-Mobile SYSC: Add PM QoS device latencies

 .../devicetree/bindings/power/power_domain.txt     | 18 ++++++++++++++++--
 .../bindings/power/renesas,sysc-rmobile.txt        | 13 ++++++++++++-
 arch/arm/mach-shmobile/pm-rmobile.c                |  5 +++++
 drivers/base/power/domain.c                        | 22 +++++++++++++++-------
 4 files changed, 48 insertions(+), 10 deletions(-)

[*] I did perform some real latency measurements a while ago, which was
    complicated by two things:
      1. The ktime_get() based timing were not sufficiently accurate, so
	 I hacked up measurement code using the ARM cycle timer,
      2. The latency values fluctuate a lot, and are impacted by other
	 system activity.
-- 
1.9.1

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

[PATCH/RFC v6 1/7] PM / Domains: Add DT bindings for power-on/off latencies

[Geert Uytterhoeven]

PM domain power-on/off latencies are properties of the hardware.
In legacy code, they're specified from platform code.
On DT platforms, their values should come from DT.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
---
v6:
  - Rebased on top of v4.1-rc1 for new RFC,

v5:
  - No changes,

v4:
  - Add Reviewed-by,
  - Replace single latency value by list of latencies,

v3:
  - No changes,

v2:
  - Add Acked-by.
---
 Documentation/devicetree/bindings/power/power_domain.txt | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7df61c630c..d659e5cb39be6057 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -28,6 +28,12 @@ Optional properties:
    created by the given provider should be subdomains of the domain
    specified by this binding. More details about power domain specifier are
    available in the next section.
+ - power-on-latency: List of power-on latencies (in ns), one for each PM
+   domain. If all power-on latencies are identical, the list may be shortened
+   to a single value.
+ - power-off-latency: List of power-off latencies (in ns), one for each PM
+   domain. If all power-off latencies are identical, the list may be shortened
+   to a single value.
 
 Example:
 
@@ -35,10 +41,12 @@ Example:
 		compatible = "foo,power-controller";
 		reg = <0x12340000 0x1000>;
 		#power-domain-cells = <1>;
+		power-on-latency = <250000 400000 180000>;
+		power-off-latency = <250000 400000 300000>;
 	};
 
-The node above defines a power controller that is a PM domain provider and
-expects one cell as its phandle argument.
+The node above defines a power controller that is a PM domain provider for
+3 PM domains, and expects one cell as its phandle argument.
 
 Example 2:
 
-- 
1.9.1

[PATCH/RFC v6 2/7] PM / Domains: R-Mobile SYSC: Add PM domain power-on/off latencies

[Geert Uytterhoeven]

Add optional generic PM domain power-on/off latencies to the bindings
and example.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v6:
  - Rebased on top of v4.1-rc1 for new RFC.
---
 Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
index beda7d2efc304350..0a6f03a136792e84 100644
--- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
+++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
@@ -45,6 +45,8 @@ Optional properties:
 	 - #address-cells: Must be 1,
 	 - #size-cells: Must be 0.
        If the PM domain is always-on, this property must be omitted.
+- power-on-latency: Power-on latency of the PM domain, in ns,
+- power-off-latency: Power-off latency of the PM domain, in ns.
 
 
 Example:
@@ -68,16 +70,22 @@ which is a subdomain of A4S.
 					#address-cells = <1>;
 					#size-cells = <0>;
 					#power-domain-cells = <0>;
+					power-on-latency = <250000>;
+					power-off-latency = <250000>;
 
 					pd_a3sp: a3sp@11 {
 						reg = <11>;
 						#power-domain-cells = <0>;
+						power-on-latency = <250000>;
+						power-off-latency = <250000>;
 					};
 				};
 
 				pd_a4su: a4su@20 {
 					reg = <20>;
 					#power-domain-cells = <0>;
+					power-on-latency = <250000>;
+					power-off-latency = <250000>;
 				};
 			};
 		};
-- 
1.9.1

[PATCH/RFC v6 3/7] ARM: shmobile: R-Mobile: Add support for PM domain power-on/off latencies

[Geert Uytterhoeven]

Parse the optional PM domain power-on/off latencies, as specified from
DT.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v6:
  - Rebased on top of v4.1-rc1 for new RFC.
---
 arch/arm/mach-shmobile/pm-rmobile.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-shmobile/pm-rmobile.c b/arch/arm/mach-shmobile/pm-rmobile.c
index 95018209ff0b37cc..747d557b7016ec6d 100644
--- a/arch/arm/mach-shmobile/pm-rmobile.c
+++ b/arch/arm/mach-shmobile/pm-rmobile.c
@@ -367,6 +367,7 @@ static int __init rmobile_add_pm_domains(void __iomem *base,
 	for_each_child_of_node(parent, np) {
 		struct rmobile_pm_domain *pd;
 		u32 idx = ~0;
+		u32 latency;
 
 		if (of_property_read_u32(np, "reg", &idx)) {
 			/* always-on domain */
@@ -377,6 +378,10 @@ static int __init rmobile_add_pm_domains(void __iomem *base,
 			return -ENOMEM;
 
 		pd->genpd.name = np->name;
+		if (!of_property_read_u32(np, "power-on-latency", &latency))
+			pd->genpd.power_on_latency_ns = latency;
+		if (!of_property_read_u32(np, "power-off-latency", &latency))
+			pd->genpd.power_off_latency_ns = latency;
 		pd->base = base;
 		pd->bit_shift = idx;
 
-- 
1.9.1

[PATCH/RFC v6 4/7] PM / Domains: Add DT bindings for PM QoS device latencies

[Geert Uytterhoeven]

PM QoS device start/stop are properties of the hardware.
In legacy code, they're specified from platform code.
On DT platforms, their values should come from DT.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v6:
  - Rebased on top of v4.1-rc1 for new RFC,

v4:
  - Drop save/restore state latencies, as they're Linux driver-specific,
  - Change state to RFC, as this is put on hold,

v3:
  - No changes,

v2:
  - New.
---
 Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index d659e5cb39be6057..32d1d3a399fe2a48 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -73,12 +73,18 @@ Required properties:
  - power-domains : A phandle and PM domain specifier as defined by bindings of
                    the power controller specified by phandle.
 
+Optional properties:
+ - stop-latency: Stop latency of the device, in ns,
+ - start-latency: Start latency of the device, in ns,
+
 Example:
 
 	leaky-device@12350000 {
 		compatible = "foo,i-leak-current";
 		reg = <0x12350000 0x1000>;
 		power-domains = <&power 0>;
+		stop-latency = <250000>;
+		start-latency = <250000>;
 	};
 
 The node above defines a typical PM domain consumer device, which is located
-- 
1.9.1

Re: [PATCH/RFC v6 4/7] PM / Domains: Add DT bindings for PM QoS device latencies

[Ulf Hansson]

On 27 April 2015 at 14:43, Geert Uytterhoeven <geert+renesas@glider.be> wrote:
> PM QoS device start/stop are properties of the hardware.
> In legacy code, they're specified from platform code.
> On DT platforms, their values should come from DT.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v6:
>   - Rebased on top of v4.1-rc1 for new RFC,
>
> v4:
>   - Drop save/restore state latencies, as they're Linux driver-specific,
>   - Change state to RFC, as this is put on hold,
>
> v3:
>   - No changes,
>
> v2:
>   - New.
> ---
>  Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index d659e5cb39be6057..32d1d3a399fe2a48 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -73,12 +73,18 @@ Required properties:
>   - power-domains : A phandle and PM domain specifier as defined by bindings of
>                     the power controller specified by phandle.
>
> +Optional properties:
> + - stop-latency: Stop latency of the device, in ns,
> + - start-latency: Start latency of the device, in ns,
> +

What do you think of renaming these to "suspend-latency" and
"resume-latency" instead? I think that better reflects their purpose.
I have no strong opinion though.

>  Example:
>
>         leaky-device@12350000 {
>                 compatible = "foo,i-leak-current";
>                 reg = <0x12350000 0x1000>;
>                 power-domains = <&power 0>;
> +               stop-latency = <250000>;
> +               start-latency = <250000>;
>         };
>
>  The node above defines a typical PM domain consumer device, which is located
> --
> 1.9.1
>

Kind regards
Uffe

[PATCH/RFC v6 5/7] PM / Domains: Add helper variable np = dev->of_node

[Geert Uytterhoeven]

Just a cleanup, no functional changes.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Kevin Hilman <khilman@linaro.org>
---
v6:
  - Rebased on top of v4.1-rc1 for new RFC,

v4:
  - Add more explanations,
  - Add Acked-by,

v3:
  - No changes,

v2:
  - New.
---
 drivers/base/power/domain.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index d1531602ae64528d..d20caa2c92b57edf 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2190,17 +2190,18 @@ static void genpd_dev_pm_sync(struct device *dev)
  */
 int genpd_dev_pm_attach(struct device *dev)
 {
+	struct device_node *np = dev->of_node;
 	struct of_phandle_args pd_args;
 	struct generic_pm_domain *pd;
 	int ret;
 
-	if (!dev->of_node)
+	if (!np)
 		return -ENODEV;
 
 	if (dev->pm_domain)
 		return -EEXIST;
 
-	ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
+	ret = of_parse_phandle_with_args(np, "power-domains",
 					"#power-domain-cells", 0, &pd_args);
 	if (ret < 0) {
 		if (ret != -ENOENT)
@@ -2211,8 +2212,7 @@ int genpd_dev_pm_attach(struct device *dev)
 		 * (for backwards compatibility of DT ABI)
 		 */
 		pd_args.args_count = 0;
-		pd_args.np = of_parse_phandle(dev->of_node,
-						"samsung,power-domain", 0);
+		pd_args.np = of_parse_phandle(np, "samsung,power-domain", 0);
 		if (!pd_args.np)
 			return -ENOENT;
 	}
@@ -2221,7 +2221,7 @@ int genpd_dev_pm_attach(struct device *dev)
 	if (IS_ERR(pd)) {
 		dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
 			__func__, PTR_ERR(pd));
-		of_node_put(dev->of_node);
+		of_node_put(np);
 		return PTR_ERR(pd);
 	}
 
@@ -2237,7 +2237,7 @@ int genpd_dev_pm_attach(struct device *dev)
 	if (ret < 0) {
 		dev_err(dev, "failed to add to PM domain %s: %d",
 			pd->name, ret);
-		of_node_put(dev->of_node);
+		of_node_put(np);
 		return ret;
 	}
 
-- 
1.9.1

Re: [PATCH/RFC v6 5/7] PM / Domains: Add helper variable np = dev->of_node

[Ulf Hansson]

On 27 April 2015 at 14:43, Geert Uytterhoeven <geert+renesas@glider.be> wrote:
> Just a cleanup, no functional changes.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Kevin Hilman <khilman@linaro.org>

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---
> v6:
>   - Rebased on top of v4.1-rc1 for new RFC,
>
> v4:
>   - Add more explanations,
>   - Add Acked-by,
>
> v3:
>   - No changes,
>
> v2:
>   - New.
> ---
>  drivers/base/power/domain.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index d1531602ae64528d..d20caa2c92b57edf 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2190,17 +2190,18 @@ static void genpd_dev_pm_sync(struct device *dev)
>   */
>  int genpd_dev_pm_attach(struct device *dev)
>  {
> +       struct device_node *np = dev->of_node;
>         struct of_phandle_args pd_args;
>         struct generic_pm_domain *pd;
>         int ret;
>
> -       if (!dev->of_node)
> +       if (!np)
>                 return -ENODEV;
>
>         if (dev->pm_domain)
>                 return -EEXIST;
>
> -       ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
> +       ret = of_parse_phandle_with_args(np, "power-domains",
>                                         "#power-domain-cells", 0, &pd_args);
>         if (ret < 0) {
>                 if (ret != -ENOENT)
> @@ -2211,8 +2212,7 @@ int genpd_dev_pm_attach(struct device *dev)
>                  * (for backwards compatibility of DT ABI)
>                  */
>                 pd_args.args_count = 0;
> -               pd_args.np = of_parse_phandle(dev->of_node,
> -                                               "samsung,power-domain", 0);
> +               pd_args.np = of_parse_phandle(np, "samsung,power-domain", 0);
>                 if (!pd_args.np)
>                         return -ENOENT;
>         }
> @@ -2221,7 +2221,7 @@ int genpd_dev_pm_attach(struct device *dev)
>         if (IS_ERR(pd)) {
>                 dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
>                         __func__, PTR_ERR(pd));
> -               of_node_put(dev->of_node);
> +               of_node_put(np);
>                 return PTR_ERR(pd);
>         }
>
> @@ -2237,7 +2237,7 @@ int genpd_dev_pm_attach(struct device *dev)
>         if (ret < 0) {
>                 dev_err(dev, "failed to add to PM domain %s: %d",
>                         pd->name, ret);
> -               of_node_put(dev->of_node);
> +               of_node_put(np);
>                 return ret;
>         }
>
> --
> 1.9.1
>

[PATCH/RFC v6 6/7] PM / Domains: Retrieve PM QoS device latencies from DT

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v6:
  - Rebased on top of v4.1-rc1 for new RFC,

v4:
  - Drop save/restore state latencies, as they're Linux driver-specific,
  - Change state to RFC, as this is put on hold,

v3:
  - No changes,

v2:
  - New.
---
 drivers/base/power/domain.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index d20caa2c92b57edf..da0b9f69919988bb 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2193,6 +2193,8 @@ int genpd_dev_pm_attach(struct device *dev)
 	struct device_node *np = dev->of_node;
 	struct of_phandle_args pd_args;
 	struct generic_pm_domain *pd;
+	struct gpd_timing_data td;
+	u32 latency;
 	int ret;
 
 	if (!np)
@@ -2225,10 +2227,16 @@ int genpd_dev_pm_attach(struct device *dev)
 		return PTR_ERR(pd);
 	}
 
+	memset(&td, 0, sizeof(td));
+	if (!of_property_read_u32(np, "stop-latency", &latency))
+		td.stop_latency_ns = latency;
+	if (!of_property_read_u32(np, "start-latency", &latency))
+		td.start_latency_ns = latency;
+
 	dev_dbg(dev, "adding to PM domain %s\n", pd->name);
 
 	while (1) {
-		ret = pm_genpd_add_device(pd, dev);
+		ret = __pm_genpd_add_device(pd, dev, &td);
 		if (ret != -EAGAIN)
 			break;
 		cond_resched();
-- 
1.9.1

[PATCH/RFC v6 7/7] PM / Domains: R-Mobile SYSC: Add PM QoS device latencies

[Geert Uytterhoeven]

Add optional generic PM QoS device latency properties to the bindings
and example.

Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
v6:
  - Rebased on top of v4.1-rc1 for new RFC,

v4:
  - New.
---
 Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
index 0a6f03a136792e84..e54ee193c9f8e263 100644
--- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
+++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt
@@ -95,7 +95,8 @@ which is a subdomain of A4S.
 == PM Domain Consumers ==
 
 Hardware blocks belonging to a PM domain should contain a "power-domains"
-property that is a phandle pointing to the corresponding PM domain node.
+property that is a phandle pointing to the corresponding PM domain node,
+and optional PM QoS device latencies:
 
 Example:
 
@@ -104,5 +105,7 @@ Example:
 		reg = <0xe6600000 0x100>;
 		clocks = <&mstp3_clks R8A7740_CLK_TPU0>;
 		power-domains = <&pd_a3sp>;
+		stop-latency = <250000>;
+		start-latency = <250000>;
 		#pwm-cells = <3>;
 	};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v6 0/7] PM / Domains: DT power-on/off and QoS device latencies

[Ulf Hansson]

On 27 April 2015 at 14:43, Geert Uytterhoeven <geert+renesas@glider.be> wrote:
>         Hi all,
>
> This patch series is an RFC to add (1) PM Domain power-on/off latencies
> and (2) QoS device latencies to DT.
>
> To provide a good quality of service, the PM subsystem suspends PM
> Domains and devices only if this doesn't break QoS constraints.  While
> the PM subsystem performs measurements of the various latencies
> involved, and adapts automatically according to these measurements, it's
> still beneficial to provide initial values for these latencies.
> Currently these initial values, which are properties of the hardware,
> can only be specified from C code. This RFC adds DT support for
> specifying them.
>
> All of these patches have been sent before (change logs are available in
> the individual patches). I'm resending them upon request from Kevin
> Hilman, and synced them all to the same version number (v6).
>
>   - Patch 1 adds DT bindings for PM Domain power-on/off latencies,
>   - Patches 2 and 3 update the DT bindings and support code for the
>     Renesas R-Mobile system controller, providing a sample
>     implementation,
>   - Patch 4 adds DT bindings for QoS device latencies,
>   - Patches 5 and 6 implement retrieving the QoS device latencies in the
>     genpd code,
>   - Patch 7 updates the DT bindings for the Renesas R-Mobile system
>     controller, adding an example.
>
> Compared to previous submissions, I've left out the (preliminary)
> patches adding the actual latency values to the .dtsi files, as they
> just used a single default value taken from the legacy code[*].
>
> In the mean time, support for PM Domains with multiple states has been
> proposed, cfr. "[RFC v5 0/8]  genpd multiple states v5"
> (http://marc.info/?l=linux-pm&m=142989694214237&w=2).
> If this is accepted, I think we have to rethink how to specify PM Domain
> latencies (and be happy we didn't have the DT part cast in stone yet
> ;-), as they won't be limited to power-on/off latencies anymore.

In regard to the above, how about posting patch 4 and onwards separately?

Then we can come back to patch 1 -> 3, once the above patchset has
been thoroughly discussed.

>
> Perhaps we should switch to a mechanism similar to what's used for idle
> states (cfr. Documentation/devicetree/bindings/arm/idle-states.txt)?
> I.e. a single "idle-states" node, with subnodes for each state, being
> pointed to by phandles in the actual PM domain provider nodes.

Seems reasonable.

Kind regards
Uffe