PM / Domains: Add support for assigned-performance-states

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

Documentation/devicetree/bindings/power/power-domain.yaml +0 -0

index aed51e9..88cebf2 100644

Quoted 21 lines · Rajendra Nayak

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Signed-off-by Rajendra Nayak <[email protected]>

---
  .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
  1 file changed, 50 insertions(+)

Documentation/devicetree/bindings/power/power-domain.yaml +0 -0

index aed51e9..88cebf2 100644
@@ -66,6 +66,19 @@ properties:
        by the given provider should be subdomains of the domain specified
        by this binding.
 

Documentation/devicetree/bindings/power/power-domain.yaml properties: · line 69

Quoted 1 line

Documentation/devicetree/bindings/power/power-domain.yaml +1 -0

+  assigned-performance-states:

Why is this named assigned and not "default"? Just curious :)

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

Quoted 8 lines · Rajendra Nayak

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Quoted 5 lines

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:
./Documentation/devicetree/bindings/power/power-domain.yaml:72:8: [warning] wrong indentation: expected 6 but found 7 (indentation)

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/power/power-domain.example.dt.yaml:0:0: /example-3/power-controller@43210000/opp-table: failed to match any schema with compatible: ['operating-points-v2']

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

Documentation/devicetree/bindings/power/power-domain.yaml +50 -1

index aed51e9..88cebf2 100644
@@ -66,6 +66,19 @@ properties:
       by the given provider should be subdomains of the domain specified
       by this binding.
 
+  assigned-performance-states:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+       Some devices might need to configure their power domains in a default
+       performance state while the device is active. These devices typically
+       would also run off a fixed clock and not support dynamically scaling the
+       device's performance, also known as DVFS techniques. The list of performance
+       state values should correspond to the list of power domains specified as part
+       of the power-domains property. Each cell corresponds to one power-domain.
+       A value of 0 can be used for power-domains with no performance state
+       requirement. In case the power-domains have OPP tables associated, the values
+       here would typically match with one of the entries in the OPP table.
+
 required:
   - "#power-domain-cells"
 

@@ -131,3 +144,40 @@ examples:
             min-residency-us = <7000>;
         };
     };
+
+  - |
+    parent4: power-controller@12340000 {
+        compatible = "foo,power-controller";
+        reg = <0x12340000 0x1000>;
+        #power-domain-cells = <0>;
+    };
+
+    parent5: power-controller@43210000 {
+        compatible = "foo,power-controller";
+        reg = <0x43210000 0x1000>;
+        #power-domain-cells = <0>;
+        operating-points-v2 = <&power_opp_table>;
+
+        power_opp_table: opp-table {
+            compatible = "operating-points-v2";
+
+            power_opp_low: opp1 {
+                opp-level = <16>;
+            };
+
+            rpmpd_opp_ret: opp2 {
+                opp-level = <64>;
+            };
+
+            rpmpd_opp_svs: opp3 {
+                opp-level = <256>;
+            };
+        };
+    };
+
+    child4: consumer@12341000 {
+        compatible = "foo,consumer";
+        reg = <0x12341000 0x1000>;
+        power-domains = <&parent4>, <&parent5>;
+        assigned-performance-states = <0>, <256>;
+    };
--

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

Documentation/devicetree/bindings/power/power-domain.yaml +3 -0

index aed51e9..88cebf2 100644
@@ -66,6 +66,19 @@ properties:
       by the given provider should be subdomains of the domain specified
       by this binding.
 
+  assigned-performance-states:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:

Documentation/devicetree/bindings/power/power-domain.yaml +27 -0

 required:
   - "#power-domain-cells"
 

@@ -131,3 +144,40 @@ examples:
             min-residency-us = <7000>;
         };
     };
+
+  - |
+    parent4: power-controller@12340000 {
+        compatible = "foo,power-controller";
+        reg = <0x12340000 0x1000>;
+        #power-domain-cells = <0>;
+    };
+
+    parent5: power-controller@43210000 {
+        compatible = "foo,power-controller";
+        reg = <0x43210000 0x1000>;
+        #power-domain-cells = <0>;
+        operating-points-v2 = <&power_opp_table>;
+
+        power_opp_table: opp-table {
+            compatible = "operating-points-v2";
+
+            power_opp_low: opp1 {
+                opp-level = <16>;
+            };
+
+            rpmpd_opp_ret: opp2 {
+                opp-level = <64>;
+            };
+
+            rpmpd_opp_svs: opp3 {
+                opp-level = <256>;

May I ask how this is different from saying something like:

	required-opps = <&??>, <&rpmpd_opp_svs>;

Documentation/devicetree/bindings/power/power-domain.yaml examples: · line 183

Quoted 6 lines

Documentation/devicetree/bindings/power/power-domain.yaml +6 -0

+    child4: consumer@12341000 {
+        compatible = "foo,consumer";
+        reg = <0x12341000 0x1000>;
+        power-domains = <&parent4>, <&parent5>;
+        assigned-performance-states = <0>, <256>;
+    };

Bjorn already asked this in v1 [1]:

Quoted 3 lines

May I ask how this is different from saying something like:

	required-opps = <&??>, <&rpmpd_opp_svs>;

and maybe this was already discussed further elsewhere. But I think at the very least we need some clarification in the commit message + the binding documentation how your new property relates to the existing "required-opps" binding.

Because even if it might not be implemented at the moment, Documentation/devicetree/bindings/power/power_domain.txt actually also specifies "required-opps" for device nodes e.g. with the following example:

	leaky-device0@12350000 {
		compatible = "foo,i-leak-current";
		reg = <0x12350000 0x1000>;
		power-domains = <&power 0>;
		required-opps = <&domain0_opp_0>;
	};

It looks like Viresh added that in commit e856f078bcf1 ("OPP: Introduce "required-opp" property").

And in general I think it's a bit inconsistent that we usually refer to performance states with phandles into the OPP table, but the assigned-performance-states suddenly use "raw numbers".

Quoted 29 lines · Stephan Gerhold

Documentation/devicetree/bindings/power/power-domain.yaml examples: · line 183

Quoted 6 lines

Documentation/devicetree/bindings/power/power-domain.yaml +6 -0

+    child4: consumer@12341000 {
+        compatible = "foo,consumer";
+        reg = <0x12341000 0x1000>;
+        power-domains = <&parent4>, <&parent5>;
+        assigned-performance-states = <0>, <256>;
+    };

Bjorn already asked this in v1 [1]:

Quoted 3 lines

May I ask how this is different from saying something like:

    required-opps = <&??>, <&rpmpd_opp_svs>;

and maybe this was already discussed further elsewhere. But I think at the very least we need some clarification in the commit message + the binding documentation how your new property relates to the existing "required-opps" binding.

Because even if it might not be implemented at the moment, Documentation/devicetree/bindings/power/power_domain.txt actually also specifies "required-opps" for device nodes e.g. with the following example:

      leaky-device0@12350000 {
              compatible = "foo,i-leak-current";
              reg = <0x12350000 0x1000>;
              power-domains = <&power 0>;
              required-opps = <&domain0_opp_0>;
      };

Quoted 6 lines

It looks like Viresh added that in commit e856f078bcf1 ("OPP: Introduce "required-opp" property").

And in general I think it's a bit inconsistent that we usually refer to performance states with phandles into the OPP table, but the assigned-performance-states suddenly use "raw numbers".

I must have missed that discussion, sorry about that.

The required-opps property, when present in device's node directly, is about the (default) OPPs to choose for that device's normal functioning as they may not do DVFS.

Good point Stephan.

Alright, so it looks like we already have the DT binding that we need for this.

That leaves us with the question, at what place should we parse it (call of_get_required_opp_performance_state()) and set the performance state for the device?

Does it still make sense to do it while attaching the device to the genpd, you think?

Quoted 6 lines · Ulf Hansson

Alright, so it looks like we already have the DT binding that we need for this.

That leaves us with the question, at what place should we parse it (call of_get_required_opp_performance_state()) and set the performance state for the device?

Quoted 2 lines

Does it still make sense to do it while attaching the device to the genpd, you think?

For parsing, yes this is the right place. For getting that into effect, whenever the device is supposed to work, i.e. with runtime PM somehow.

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Signed-off-by Rajendra Nayak <[email protected]>

---
 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

Documentation/devicetree/bindings/power/power-domain.yaml +50 -1

index aed51e9..88cebf2 100644
@@ -66,6 +66,19 @@ properties:
       by the given provider should be subdomains of the domain specified
       by this binding.
 
+  assigned-performance-states:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+       Some devices might need to configure their power domains in a default
+       performance state while the device is active. These devices typically
+       would also run off a fixed clock and not support dynamically scaling the
+       device's performance, also known as DVFS techniques. The list of performance
+       state values should correspond to the list of power domains specified as part
+       of the power-domains property. Each cell corresponds to one power-domain.
+       A value of 0 can be used for power-domains with no performance state
+       requirement. In case the power-domains have OPP tables associated, the values
+       here would typically match with one of the entries in the OPP table.
+
 required:
   - "#power-domain-cells"
 

@@ -131,3 +144,40 @@ examples:
             min-residency-us = <7000>;
         };
     };
+
+  - |
+    parent4: power-controller@12340000 {
+        compatible = "foo,power-controller";
+        reg = <0x12340000 0x1000>;
+        #power-domain-cells = <0>;
+    };
+
+    parent5: power-controller@43210000 {
+        compatible = "foo,power-controller";
+        reg = <0x43210000 0x1000>;
+        #power-domain-cells = <0>;
+        operating-points-v2 = <&power_opp_table>;
+
+        power_opp_table: opp-table {
+            compatible = "operating-points-v2";
+
+            power_opp_low: opp1 {
+                opp-level = <16>;
+            };
+
+            rpmpd_opp_ret: opp2 {
+                opp-level = <64>;
+            };
+
+            rpmpd_opp_svs: opp3 {
+                opp-level = <256>;
+            };
+        };
+    };
+
+    child4: consumer@12341000 {
+        compatible = "foo,consumer";
+        reg = <0x12341000 0x1000>;
+        power-domains = <&parent4>, <&parent5>;
+        assigned-performance-states = <0>, <256>;
+    };
--

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 9 lines · Rajendra Nayak

While most devices within power-domains which support performance states, scale the performance state dynamically, some devices might want to set a static/default performance state while the device is active. These devices typically would also run off a fixed clock and not support dynamically scaling the device's performance, also known as DVFS techniques. Add a property 'assigned-performance-states' which client devices can use to set this default performance state on their power-domains.

Quoted 1 line

Signed-off-by Rajendra Nayak <[email protected]>

Rajendra, I think this is ready to be re-spinned on top of the latest changes for genpd that Rafael recently queued [1].

If you would prefer me to do it, then please let me know. Otherwise I will be awaiting a new version from you.

Kind regards
Uffe

[1]
https://lore.kernel.org/linux-pm/CAJZ5v0i0FD-F7tN=AJNEY5HVVTCNuciLT4hCqdoS5bgF5WdmaA@mail.gmail.com/

Quoted 73 lines

---
  .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
  1 file changed, 50 insertions(+)

Documentation/devicetree/bindings/power/power-domain.yaml +50 -1

index aed51e9..88cebf2 100644
@@ -66,6 +66,19 @@ properties:
        by the given provider should be subdomains of the domain specified
        by this binding.
 
+  assigned-performance-states:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+       Some devices might need to configure their power domains in a default
+       performance state while the device is active. These devices typically
+       would also run off a fixed clock and not support dynamically scaling the
+       device's performance, also known as DVFS techniques. The list of performance
+       state values should correspond to the list of power domains specified as part
+       of the power-domains property. Each cell corresponds to one power-domain.
+       A value of 0 can be used for power-domains with no performance state
+       requirement. In case the power-domains have OPP tables associated, the values
+       here would typically match with one of the entries in the OPP table.
+
  required:
    - "#power-domain-cells"
 

@@ -131,3 +144,40 @@ examples:
              min-residency-us = <7000>;
          };
      };
+
+  - |
+    parent4: power-controller@12340000 {
+        compatible = "foo,power-controller";
+        reg = <0x12340000 0x1000>;
+        #power-domain-cells = <0>;
+    };
+
+    parent5: power-controller@43210000 {
+        compatible = "foo,power-controller";
+        reg = <0x43210000 0x1000>;
+        #power-domain-cells = <0>;
+        operating-points-v2 = <&power_opp_table>;
+
+        power_opp_table: opp-table {
+            compatible = "operating-points-v2";
+
+            power_opp_low: opp1 {
+                opp-level = <16>;
+            };
+
+            rpmpd_opp_ret: opp2 {
+                opp-level = <64>;
+            };
+
+            rpmpd_opp_svs: opp3 {
+                opp-level = <256>;
+            };
+        };
+    };
+
+    child4: consumer@12341000 {
+        compatible = "foo,consumer";
+        reg = <0x12341000 0x1000>;
+        power-domains = <&parent4>, <&parent5>;
+        assigned-performance-states = <0>, <256>;
+    };
--

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation