[PATCH v2 0/3] PM / Domains: Add support for assigned-performance-states

[PATCH v2 0/3] PM / Domains: Add support for assigned-performance-states

[Rajendra Nayak]

This is a re-spin of the series that was posted a while back [1]
with no major changes except for some review feedback from Stephen
addressed.

Back when this was posted, we thought its a good idea if client
drivers handle this instead of genpd core handling it [2]
So that lead to another series which handled this in the i2c 
driver [3], but then it looked like it would be duplication
of code across drivers and perhaps it should be done some place
centrally.

The way forward seems like
1. Get the bindings reviewed from DT folks
2. Once the bindings are finalized, figure out how to handle this
centrally without duplication. While this series does it with everything
handled in genpd core, there are perhaps other ways to do it with genpd
core exporting some helpers and genpd providers handling some of it with
callbacks.

----
Some devices within power-domains with performance states do not
support DVFS, but still need to vote on a default/static state
while they are active. Add support for a new device tree property
which the clients can use to specify this and add support in
kernel to parse this value and vote.

[1] https://lore.kernel.org/patchwork/patch/1284040/
[2] https://lore.kernel.org/patchwork/patch/1284042/
[3] https://lore.kernel.org/patchwork/patch/1356618/

Rajendra Nayak (3):
  dt-bindings: power: Introduce 'assigned-performance-states' property
  PM / Domains: Add support for 'assigned-performance-states'
  arm64: dts: sc7180: Add assigned-performance-states for i2c

 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7180.dtsi               | 24 +++++++++++
 drivers/base/power/domain.c                        | 27 ++++++++++++
 include/linux/pm_domain.h                          |  1 +
 4 files changed, 102 insertions(+)

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

[PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[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 <rnayak@codeaurora.org>
---
 .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index aed51e9..88cebf2 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -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

[PATCH v2 2/3] PM / Domains: Add support for 'assigned-performance-states'

[Rajendra Nayak]

For devices which have 'assigned-performance-states' specified in DT,
set the specified performance state during attach and drop it on detach.
Also drop/set as part of runtime suspend/resume callbacks.

Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
 drivers/base/power/domain.c | 27 +++++++++++++++++++++++++++
 include/linux/pm_domain.h   |  1 +
 2 files changed, 28 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index b6a782c..145ce12 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -888,6 +888,10 @@ static int genpd_runtime_suspend(struct device *dev)
 	if (irq_safe_dev_in_no_sleep_domain(dev, genpd))
 		return 0;
 
+	/* Drop the assigned performance state */
+	if (dev_gpd_data(dev)->assigned_pstate)
+		dev_pm_genpd_set_performance_state(dev, 0);
+
 	genpd_lock(genpd);
 	genpd_power_off(genpd, true, 0);
 	genpd_unlock(genpd);
@@ -907,6 +911,7 @@ static int genpd_runtime_resume(struct device *dev)
 {
 	struct generic_pm_domain *genpd;
 	struct gpd_timing_data *td = &dev_gpd_data(dev)->td;
+	unsigned int assigned_pstate = dev_gpd_data(dev)->assigned_pstate;
 	bool runtime_pm = pm_runtime_enabled(dev);
 	ktime_t time_start;
 	s64 elapsed_ns;
@@ -935,6 +940,9 @@ static int genpd_runtime_resume(struct device *dev)
 	if (ret)
 		return ret;
 
+	/* Set the assigned performance state */
+	if (assigned_pstate)
+		dev_pm_genpd_set_performance_state(dev, assigned_pstate);
  out:
 	/* Measure resume latency. */
 	time_start = 0;
@@ -967,6 +975,8 @@ static int genpd_runtime_resume(struct device *dev)
 	genpd_stop_dev(genpd, dev);
 err_poweroff:
 	if (!pm_runtime_is_irq_safe(dev) || genpd_is_irq_safe(genpd)) {
+		if (assigned_pstate)
+			dev_pm_genpd_set_performance_state(dev, 0);
 		genpd_lock(genpd);
 		genpd_power_off(genpd, true, 0);
 		genpd_unlock(genpd);
@@ -2568,6 +2578,12 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
 
 	dev_dbg(dev, "removing from PM domain %s\n", pd->name);
 
+	/* Drop the assigned performance state */
+	if (dev_gpd_data(dev)->assigned_pstate) {
+		dev_pm_genpd_set_performance_state(dev, 0);
+		dev_gpd_data(dev)->assigned_pstate = 0;
+	}
+
 	for (i = 1; i < GENPD_RETRY_MAX_MS; i <<= 1) {
 		ret = genpd_remove_device(pd, dev);
 		if (ret != -EAGAIN)
@@ -2605,6 +2621,7 @@ static void genpd_dev_pm_sync(struct device *dev)
 static int __genpd_dev_pm_attach(struct device *dev, struct device *base_dev,
 				 unsigned int index, bool power_on)
 {
+	unsigned int assigned_pstate;
 	struct of_phandle_args pd_args;
 	struct generic_pm_domain *pd;
 	int ret;
@@ -2648,6 +2665,16 @@ static int __genpd_dev_pm_attach(struct device *dev, struct device *base_dev,
 	if (ret)
 		genpd_remove_device(pd, dev);
 
+	/* Set the assigned performance state */
+	if (!of_property_read_u32_index(base_dev->of_node,
+					"assigned-performance-states",
+					index, &assigned_pstate)) {
+		if (assigned_pstate) {
+			dev_pm_genpd_set_performance_state(dev, assigned_pstate);
+			dev_gpd_data(dev)->assigned_pstate = assigned_pstate;
+		}
+	}
+
 	return ret ? -EPROBE_DEFER : 1;
 }
 
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index dfcfbce..71c1b11 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -198,6 +198,7 @@ struct generic_pm_domain_data {
 	struct notifier_block *power_nb;
 	int cpu;
 	unsigned int performance_state;
+	unsigned int assigned_pstate;
 	ktime_t	next_wakeup;
 	void *data;
 };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v2 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c

[Rajendra Nayak]

qup-i2c devices on sc7180 are clocked with a fixed clock (19.2 MHz)
Though qup-i2c does not support DVFS, it still needs to vote for a
performance state on 'CX' to satisfy the 19.2 Mhz clock frequency
requirement.

Use 'assigned-performance-states' to pass this information from
device tree, and also add the power-domains property to specify
the cx power-domain.

Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6228ba2..7914084 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -786,8 +786,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
 						<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi0: spi@880000 {
@@ -838,8 +840,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
 						<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi1: spi@884000 {
@@ -890,8 +894,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
 						<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			uart2: serial@888000 {
@@ -924,8 +930,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
 						<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi3: spi@88c000 {
@@ -976,8 +984,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
 						<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			uart4: serial@890000 {
@@ -1010,8 +1020,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_0 0>,
 						<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi5: spi@894000 {
@@ -1077,8 +1089,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
 						<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi6: spi@a80000 {
@@ -1129,8 +1143,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
 						<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			uart7: serial@a84000 {
@@ -1163,8 +1179,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
 						<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi8: spi@a88000 {
@@ -1215,8 +1233,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
 						<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			uart9: serial@a8c000 {
@@ -1249,8 +1269,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
 						<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi10: spi@a90000 {
@@ -1301,8 +1323,10 @@
 						<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_1 0>,
 						<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
 			spi11: spi@a94000 {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Viresh Kumar]

On 27-05-21, 11:42, Rajendra Nayak wrote:
> 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 <rnayak@codeaurora.org>
> ---
>  .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index aed51e9..88cebf2 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -66,6 +66,19 @@ properties:
>        by the given provider should be subdomains of the domain specified
>        by this binding.
>  
> +  assigned-performance-states:

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

-- 
viresh

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Rajendra Nayak]

On 5/27/2021 11:46 AM, Viresh Kumar wrote:
> On 27-05-21, 11:42, Rajendra Nayak wrote:
>> 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 <rnayak@codeaurora.org>
>> ---
>>   .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
>> index aed51e9..88cebf2 100644
>> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
>> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
>> @@ -66,6 +66,19 @@ properties:
>>         by the given provider should be subdomains of the domain specified
>>         by this binding.
>>   
>> +  assigned-performance-states:
> 
> Why is this named assigned and not "default"? Just curious :)

I took the cue from assigned-clock-rates/assigned-clock-parents but i am perfectly
fine calling it default-performance-states as well :)

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

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Rob Herring]

On Thu, 27 May 2021 11:42:27 +0530, Rajendra Nayak wrote:
> 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 <rnayak@codeaurora.org>
> ---
>  .../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']

See https://patchwork.ozlabs.org/patch/1484441

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Rob Herring]

On Thu, May 27, 2021 at 9:23 AM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, 27 May 2021 11:42:27 +0530, Rajendra Nayak wrote:
> > 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 <rnayak@codeaurora.org>
> > ---
> >  .../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']

You don't really need to worry about this one as it is already a
warning (but patches welcome if someone wants to convert the OPP
binding).

Rob

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Ulf Hansson]

On Thu, 27 May 2021 at 08:13, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
> 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 <rnayak@codeaurora.org>

I don't have a strong opinion about using "default-performance-state"
or "assigned-performance-state". Although, perhaps people can relate
to the existing "assigned-clock-rates" DT binding?
In any case, please add:

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

Kind regards
Uffe

> ---
>  .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index aed51e9..88cebf2 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -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
>

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Stephan Gerhold]

Hi,

On Thu, May 27, 2021 at 11:42:27AM +0530, Rajendra Nayak wrote:
> 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 <rnayak@codeaurora.org>
> ---
>  .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index aed51e9..88cebf2 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -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.
> +

Is it just me or is this actually in the wrong place here?
Given that #power-domain-cells is required this looks like the bindings
for power domain providers, not consumers. :)

It looks like the consumer bindings are still in
Documentation/devicetree/bindings/power/power_domain.txt

>  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>;
> +    };

Bjorn already asked this in v1 [1]:

> 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".

Stephan

[1]: https://lore.kernel.org/linux-arm-msm/YAG%2FpNXQOS+C2zLr@builder.lan/

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Viresh Kumar]

On 01-06-21, 13:12, Stephan Gerhold wrote:
> > +    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]:
> 
> > 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".

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.

-- 
viresh

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Ulf Hansson]

On Tue, 1 Jun 2021 at 13:44, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 01-06-21, 13:12, Stephan Gerhold wrote:
> > > +    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]:
> >
> > > 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".
>
> 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.

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? Or, is there another better common path?

For fixed regulators, the binding is parsed during the probe and then
the performance state is set/dropped at regulator_enable/disable().

>
> Good point Stephan.
>

Kind regards
Uffe

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Viresh Kumar]

On 02-06-21, 12:45, Ulf Hansson wrote:
> 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?

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.

-- 
viresh

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Ulf Hansson]

On Wed, 2 Jun 2021 at 12:55, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 02-06-21, 12:45, Ulf Hansson wrote:
> > 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?
>
> 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.

Okay, thanks for confirming. That would be along the lines of what
Rajendra did in patch2.

Kind regards
Uffe

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Ulf Hansson]

On Thu, 27 May 2021 at 08:13, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
> 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 <rnayak@codeaurora.org>

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/

> ---
>  .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index aed51e9..88cebf2 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -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
>

Re: [PATCH v2 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property

[Rajendra Nayak]

On 6/15/2021 8:35 PM, Ulf Hansson wrote:
> On Thu, 27 May 2021 at 08:13, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>>
>> 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 <rnayak@codeaurora.org>
> 
> Rajendra, I think this is ready to be re-spinned on top of the latest
> changes for genpd that Rafael recently queued [1].

Thanks Ulf, yes, I plan to re-spin these based on the recent discussions,
re-using the existing required-opps bindings soon.
  
> 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/
> 
>> ---
>>   .../devicetree/bindings/power/power-domain.yaml    | 50 ++++++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
>> index aed51e9..88cebf2 100644
>> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
>> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
>> @@ -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
>>

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