PM / Domains: Fix for domain idle state

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +9 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required

Documentation/devicetree/bindings/power/power_domain.txt +4 -4

index e165036..723e1ad 100644
@@ -31,7 +31,7 @@ Optional properties:
 
 - domain-idle-states : A phandle of an idle-state that shall be soaked into a
                 generic domain power state. The idle state definitions are
-                compatible with arm,idle-state specified in [1].
+                compatible with domain-idle-state specified in [1].
   The domain-idle-state property reflects the idle state of this PM domain and
   not the idle states of the devices or sub-domains in the PM domain. Devices
   and sub-domains have their own idle-states independent of the parent

@@ -85,7 +85,7 @@ Example 3:
        };
 
        DOMAIN_RET: state at 0 {
-               compatible = "arm,idle-state";
+               compatible = "domain-idle-state";
                reg = <0x0>;
                entry-latency-us = <1000>;
                exit-latency-us = <2000>;

@@ -93,7 +93,7 @@ Example 3:
        };
 
        DOMAIN_PWR_DN: state at 1 {
-               compatible = "arm,idle-state";
+               compatible = "domain-idle-state";
                reg = <0x1>;
                entry-latency-us = <5000>;
                exit-latency-us = <8000>;

@@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
 inside a PM domain with index 0 of a power controller represented by a node
 with the label "power".
 
-[1]. Documentation/devicetree/bindings/arm/idle-states.txt
+[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt

drivers/base/power/domain.c +1 -2

index 661737c..f0bc672 100644
@@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 
 static const struct of_device_id idle_state_match[] = {
-       { .compatible = "arm,idle-state", },
+       { .compatible = "domain-idle-state", },
        { }
 };
 
--

2.7.4

Quoted 37 lines · Lina Iyer

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +14 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required

Documentation/devicetree/bindings/power/domain-idle-state.txt line 19

Quoted 5 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +5 -0

+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.

As we anyway are going to change this, why not use an u64 and have the value in ns instead of us?

Quoted 38 lines · Ulf Hansson

Quoted 37 lines · Lina Iyer

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +14 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required

Quoted 8 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt line 19

Quoted 5 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +5 -0

+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.

As we anyway are going to change this, why not use an u64 and have the value in ns instead of us?

I can't imagine that you would need more resolution or range. For times less than 1us, s/w and register access times are going to dominate the time.

Unless there is a real need, I'd keep alignment with the existing binding.

Quoted 38 lines · Ulf Hansson

Quoted 37 lines · Lina Iyer

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +14 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required

Quoted 8 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt line 19

Quoted 5 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +5 -0

+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.

As we anyway are going to change this, why not use an u64 and have the value in ns instead of us?

I can't imagine that you would need more resolution or range. For times less than 1us, s/w and register access times are going to dominate the time.

Unless there is a real need, I'd keep alignment with the existing binding.

Quoted 52 lines · Rob Herring

Quoted 38 lines · Ulf Hansson

Quoted 37 lines · Lina Iyer

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +14 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required

Quoted 8 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt line 19

Quoted 5 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +5 -0

+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.

As we anyway are going to change this, why not use an u64 and have the value in ns instead of us?

I can't imagine that you would need more resolution or range. For times less than 1us, s/w and register access times are going to dominate the time.

Quoted 2 lines

Unless there is a real need, I'd keep alignment with the existing binding.

Rob, are you fine with this? I thought it would be great to get this in for 4.10 rc1.

Quoted 53 lines · Ulf Hansson

Quoted 52 lines · Rob Herring

Quoted 38 lines · Ulf Hansson

Quoted 37 lines · Lina Iyer

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +14 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required

Quoted 8 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt line 19

Quoted 5 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +5 -0

+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.

As we anyway are going to change this, why not use an u64 and have the value in ns instead of us?

I can't imagine that you would need more resolution or range. For times less than 1us, s/w and register access times are going to dominate the time.

Quoted 5 lines

Quoted 2 lines

Unless there is a real need, I'd keep alignment with the existing binding.

Rob, are you fine with this? I thought it would be great to get this in for 4.10 rc1.

Rob, any objections here?

Quoted 57 lines · Rafael J. Wysocki

Quoted 56 lines · Ulf Hansson

Quoted 54 lines · Rob Herring

Quoted 38 lines · Ulf Hansson

Quoted 37 lines · Lina Iyer

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +14 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required

Quoted 8 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt line 19

Quoted 5 lines

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +5 -0

+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.

As we anyway are going to change this, why not use an u64 and have the value in ns instead of us?

I can't imagine that you would need more resolution or range. For times less than 1us, s/w and register access times are going to dominate the time.

Unless there is a real need, I'd keep alignment with the existing binding.

Quoted 4 lines

Quoted 2 lines

Rob, are you fine with this? I thought it would be great to get this in for 4.10 rc1.

Rob, any objections here?

Well, no objections, so applied.

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +33 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+	Usage: Required
+	Value type: <string>
+	Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+	Usage: Required
+	Value type: <prop-encoded-array>
+	Definition: u32 value representing worst case latency in
+		    microseconds required to enter the idle state.
+		    The exit-latency-us duration may be guaranteed
+		    only after entry-latency-us has passed.
+
+- exit-latency-us
+	Usage: Required
+	Value type: <prop-encoded-array>
+	Definition: u32 value representing worst case latency
+		    in microseconds required to exit the idle state.
+
+- min-residency-us
+	Usage: Required
+	Value type: <prop-encoded-array>
+	Definition: u32 value representing minimum residency duration
+		    in microseconds after which the idle state will yield
+		    power benefits after overcoming the overhead in entering
+i		    the idle state.

Documentation/devicetree/bindings/power/power_domain.txt +4 -4

index e165036..723e1ad 100644
@@ -31,7 +31,7 @@ Optional properties:
 
 - domain-idle-states : A phandle of an idle-state that shall be soaked into a
                 generic domain power state. The idle state definitions are
-                compatible with arm,idle-state specified in [1].
+                compatible with domain-idle-state specified in [1].
   The domain-idle-state property reflects the idle state of this PM domain and
   not the idle states of the devices or sub-domains in the PM domain. Devices
   and sub-domains have their own idle-states independent of the parent

@@ -85,7 +85,7 @@ Example 3:
 	};
 
 	DOMAIN_RET: state at 0 {
-		compatible = "arm,idle-state";
+		compatible = "domain-idle-state";
 		reg = <0x0>;
 		entry-latency-us = <1000>;
 		exit-latency-us = <2000>;

@@ -93,7 +93,7 @@ Example 3:
 	};
 
 	DOMAIN_PWR_DN: state at 1 {
-		compatible = "arm,idle-state";
+		compatible = "domain-idle-state";
 		reg = <0x1>;
 		entry-latency-us = <5000>;
 		exit-latency-us = <8000>;

@@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
 inside a PM domain with index 0 of a power controller represented by a node
 with the label "power".
 
-[1]. Documentation/devicetree/bindings/arm/idle-states.txt
+[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt

drivers/base/power/domain.c +1 -1

index 661737c..f0bc672 100644
@@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 
 static const struct of_device_id idle_state_match[] = {
-	{ .compatible = "arm,idle-state", },
+	{ .compatible = "domain-idle-state", },
 	{ }
 };

Hi,

Quoted 6 lines · Lina Iyer

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

This looks good to me, pinging for review from others/queue for merge.

Quoted 93 lines

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +33 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+     Usage: Required
+     Value type: <string>
+     Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+     Usage: Required
+     Value type: <prop-encoded-array>
+     Definition: u32 value representing worst case latency in
+                 microseconds required to enter the idle state.
+                 The exit-latency-us duration may be guaranteed
+                 only after entry-latency-us has passed.
+
+- exit-latency-us
+     Usage: Required
+     Value type: <prop-encoded-array>
+     Definition: u32 value representing worst case latency
+                 in microseconds required to exit the idle state.
+
+- min-residency-us
+     Usage: Required
+     Value type: <prop-encoded-array>
+     Definition: u32 value representing minimum residency duration
+                 in microseconds after which the idle state will yield
+                 power benefits after overcoming the overhead in entering
+i                the idle state.

Documentation/devicetree/bindings/power/power_domain.txt +4 -4

index e165036..723e1ad 100644
@@ -31,7 +31,7 @@ Optional properties:
 
 - domain-idle-states : A phandle of an idle-state that shall be soaked into a
                 generic domain power state. The idle state definitions are
-                compatible with arm,idle-state specified in [1].
+                compatible with domain-idle-state specified in [1].
   The domain-idle-state property reflects the idle state of this PM domain and
   not the idle states of the devices or sub-domains in the PM domain. Devices
   and sub-domains have their own idle-states independent of the parent

@@ -85,7 +85,7 @@ Example 3:
      };
 
      DOMAIN_RET: state at 0 {
-             compatible = "arm,idle-state";
+             compatible = "domain-idle-state";
              reg = <0x0>;
              entry-latency-us = <1000>;
              exit-latency-us = <2000>;

@@ -93,7 +93,7 @@ Example 3:
      };
 
      DOMAIN_PWR_DN: state at 1 {
-             compatible = "arm,idle-state";
+             compatible = "domain-idle-state";
              reg = <0x1>;
              entry-latency-us = <5000>;
              exit-latency-us = <8000>;

@@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
 inside a PM domain with index 0 of a power controller represented by a node
 with the label "power".
 
-[1]. Documentation/devicetree/bindings/arm/idle-states.txt
+[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt

drivers/base/power/domain.c +0 -0

index 661737c..f0bc672 100644
@@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 

drivers/base/power/domain.c int genpd_dev_pm_attach(struct device *dev) · line 2053

Quoted 5 lines

drivers/base/power/domain.c +1 -1

 static const struct of_device_id idle_state_match[] = {
-     { .compatible = "arm,idle-state", },
+     { .compatible = "domain-idle-state", },
      { }
 };

--

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.

Cc <[email protected]>

Cc Rob Herring <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
 .../devicetree/bindings/power/power_domain.txt     |  8 +++---
 drivers/base/power/domain.c                        |  2 +-
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt

Documentation/devicetree/bindings/power/domain-idle-state.txt new file +33 -0

new file mode 100644
index 0000000..eefc7ed
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+       Usage: Required
+       Value type: <string>
+       Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+       Usage: Required
+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency in
+                   microseconds required to enter the idle state.
+                   The exit-latency-us duration may be guaranteed
+                   only after entry-latency-us has passed.
+
+- exit-latency-us
+       Usage: Required
+       Value type: <prop-encoded-array>
+       Definition: u32 value representing worst case latency
+                   in microseconds required to exit the idle state.
+
+- min-residency-us
+       Usage: Required
+       Value type: <prop-encoded-array>
+       Definition: u32 value representing minimum residency duration
+                   in microseconds after which the idle state will yield
+                   power benefits after overcoming the overhead in entering
+i                  the idle state.

Documentation/devicetree/bindings/power/power_domain.txt +4 -4

index e165036..723e1ad 100644
@@ -31,7 +31,7 @@ Optional properties:
 
 - domain-idle-states : A phandle of an idle-state that shall be soaked into a
                 generic domain power state. The idle state definitions are
-                compatible with arm,idle-state specified in [1].
+                compatible with domain-idle-state specified in [1].
   The domain-idle-state property reflects the idle state of this PM domain and
   not the idle states of the devices or sub-domains in the PM domain. Devices
   and sub-domains have their own idle-states independent of the parent

@@ -85,7 +85,7 @@ Example 3:
        };
 
        DOMAIN_RET: state at 0 {
-               compatible = "arm,idle-state";
+               compatible = "domain-idle-state";
                reg = <0x0>;
                entry-latency-us = <1000>;
                exit-latency-us = <2000>;

@@ -93,7 +93,7 @@ Example 3:
        };
 
        DOMAIN_PWR_DN: state at 1 {
-               compatible = "arm,idle-state";
+               compatible = "domain-idle-state";
                reg = <0x1>;
                entry-latency-us = <5000>;
                exit-latency-us = <8000>;

@@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
 inside a PM domain with index 0 of a power controller represented by a node
 with the label "power".
 
-[1]. Documentation/devicetree/bindings/arm/idle-states.txt
+[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt

drivers/base/power/domain.c +1 -2

index 661737c..f0bc672 100644
@@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 
 static const struct of_device_id idle_state_match[] = {
-       { .compatible = "arm,idle-state", },
+       { .compatible = "domain-idle-state", },
        { }
 };
 
--

2.7.4

Re-using idle state definition provided by arm,idle-state for domain idle states creates a lot of confusion and limits further evolution of the domain idle definition. To keep things clear and simple, define a idle states for domain using a new compatible "domain-idle-state".

Fix existing PM domains code to look for the newly defined compatible.