linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] Add support for assigned-performance-states
@ 2020-08-04 11:46 Rajendra Nayak
  2020-08-04 11:46 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Rajendra Nayak
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Rajendra Nayak @ 2020-08-04 11:46 UTC (permalink / raw)
  To: ulf.hansson, robh+dt, bjorn.andersson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, Rajendra Nayak

Some devics 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.

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    | 47 ++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7180.dtsi               | 24 +++++++++++
 drivers/base/power/domain.c                        | 27 +++++++++++++
 include/linux/pm_domain.h                          |  1 +
 4 files changed, 99 insertions(+)

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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-08-04 11:46 [PATCH 0/3] Add support for assigned-performance-states Rajendra Nayak
@ 2020-08-04 11:46 ` Rajendra Nayak
  2020-08-05  6:39   ` Stephen Boyd
  2020-08-04 11:46 ` [PATCH 2/3] PM / Domains: Add support for 'assigned-performance-states' Rajendra Nayak
  2020-08-04 11:46 ` [PATCH 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c Rajendra Nayak
  2 siblings, 1 reply; 17+ messages in thread
From: Rajendra Nayak @ 2020-08-04 11:46 UTC (permalink / raw)
  To: ulf.hansson, robh+dt, bjorn.andersson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, 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 of a fixed clock and not support
dyamically 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    | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index ff5936e..48e9319 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -66,6 +66,16 @@ 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 typcially
+       would also run of a fixed clock and not support dyamically 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.
+
 required:
   - "#power-domain-cells"
 
@@ -129,3 +139,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


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 2/3] PM / Domains: Add support for 'assigned-performance-states'
  2020-08-04 11:46 [PATCH 0/3] Add support for assigned-performance-states Rajendra Nayak
  2020-08-04 11:46 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Rajendra Nayak
@ 2020-08-04 11:46 ` Rajendra Nayak
  2020-08-12  9:37   ` Ulf Hansson
  2020-08-04 11:46 ` [PATCH 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c Rajendra Nayak
  2 siblings, 1 reply; 17+ messages in thread
From: Rajendra Nayak @ 2020-08-04 11:46 UTC (permalink / raw)
  To: ulf.hansson, robh+dt, bjorn.andersson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, 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 0a01df60..8704823 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -810,6 +810,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);
@@ -829,6 +833,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;
@@ -857,6 +862,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;
@@ -890,6 +898,8 @@ static int genpd_runtime_resume(struct device *dev)
 err_poweroff:
 	if (!pm_runtime_is_irq_safe(dev) ||
 		(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);
@@ -2405,6 +2415,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)
@@ -2442,6 +2458,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;
@@ -2485,6 +2502,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 9ec78ee..4a415ee 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -180,6 +180,7 @@ struct generic_pm_domain_data {
 	struct notifier_block nb;
 	int cpu;
 	unsigned int performance_state;
+	unsigned int assigned_pstate;
 	void *data;
 };
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c
  2020-08-04 11:46 [PATCH 0/3] Add support for assigned-performance-states Rajendra Nayak
  2020-08-04 11:46 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Rajendra Nayak
  2020-08-04 11:46 ` [PATCH 2/3] PM / Domains: Add support for 'assigned-performance-states' Rajendra Nayak
@ 2020-08-04 11:46 ` Rajendra Nayak
  2020-08-05  6:41   ` Stephen Boyd
  2 siblings, 1 reply; 17+ messages in thread
From: Rajendra Nayak @ 2020-08-04 11:46 UTC (permalink / raw)
  To: ulf.hansson, robh+dt, bjorn.andersson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, 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 d46b383..f96ca21 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -767,6 +767,8 @@
 						<&aggre1_noc MASTER_QUP_0 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -819,6 +821,8 @@
 						<&aggre1_noc MASTER_QUP_0 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -871,6 +875,8 @@
 						<&aggre1_noc MASTER_QUP_0 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -905,6 +911,8 @@
 						<&aggre1_noc MASTER_QUP_0 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -957,6 +965,8 @@
 						<&aggre1_noc MASTER_QUP_0 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -991,6 +1001,8 @@
 						<&aggre1_noc MASTER_QUP_0 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -1058,6 +1070,8 @@
 						<&aggre2_noc MASTER_QUP_1 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -1110,6 +1124,8 @@
 						<&aggre2_noc MASTER_QUP_1 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -1144,6 +1160,8 @@
 						<&aggre2_noc MASTER_QUP_1 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -1196,6 +1214,8 @@
 						<&aggre2_noc MASTER_QUP_1 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -1230,6 +1250,8 @@
 						<&aggre2_noc MASTER_QUP_1 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
@@ -1282,6 +1304,8 @@
 						<&aggre2_noc MASTER_QUP_1 &mc_virt SLAVE_EBI1>;
 				interconnect-names = "qup-core", "qup-config",
 							"qup-memory";
+				power-domains = <&rpmhpd SC7180_CX>;
+				assigned-performance-states = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
 				status = "disabled";
 			};
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-08-04 11:46 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Rajendra Nayak
@ 2020-08-05  6:39   ` Stephen Boyd
  2020-08-05  8:13     ` Rajendra Nayak
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Boyd @ 2020-08-05  6:39 UTC (permalink / raw)
  To: Rajendra Nayak, bjorn.andersson, robh+dt, ulf.hansson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, Rajendra Nayak

Quoting Rajendra Nayak (2020-08-04 04:46:54)
> 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 of a fixed clock and not support

s/of/off/

> dyamically scaling the device's performance, also known as DVFS techniques.

s/dyamically/dynamically/

> 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    | 47 ++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index ff5936e..48e9319 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -66,6 +66,16 @@ 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 typcially
> +       would also run of a fixed clock and not support dyamically scaling the

Same of and dynamically comment.

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

This is different than assigned-clock-rates. I guess that's OK because
we don't need to assign parents with more specifiers. Maybe it should be
worded more strongly to clearly state that each cell corresponds to one
power domain? And that it should match the opp-level inside any OPP
table for the power domain?

> +
>  required:
>    - "#power-domain-cells"
>  
> @@ -129,3 +139,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>;

I guess <0> means don't set anything?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c
  2020-08-04 11:46 ` [PATCH 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c Rajendra Nayak
@ 2020-08-05  6:41   ` Stephen Boyd
  2020-08-05  8:14     ` Rajendra Nayak
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Boyd @ 2020-08-05  6:41 UTC (permalink / raw)
  To: Rajendra Nayak, bjorn.andersson, robh+dt, ulf.hansson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm, Rajendra Nayak

Quoting Rajendra Nayak (2020-08-04 04:46:56)
> qup-i2c devices on sc7180 are clocked with a fixed clock (19.2 Mhz)

s/Mhz/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

Capitalize CX?

> 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(+)

Can you generate this patch with more context? The hunks all look the
same so it's really hard to see where they apply.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-08-05  6:39   ` Stephen Boyd
@ 2020-08-05  8:13     ` Rajendra Nayak
  2020-08-05 23:57       ` Stephen Boyd
  0 siblings, 1 reply; 17+ messages in thread
From: Rajendra Nayak @ 2020-08-05  8:13 UTC (permalink / raw)
  To: Stephen Boyd, bjorn.andersson, robh+dt, ulf.hansson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm


On 8/5/2020 12:09 PM, Stephen Boyd wrote:
> Quoting Rajendra Nayak (2020-08-04 04:46:54)
>> 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 of a fixed clock and not support
> 
> s/of/off/
> 
>> dyamically scaling the device's performance, also known as DVFS techniques.
> 
> s/dyamically/dynamically/
> 
>> 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    | 47 ++++++++++++++++++++++
>>   1 file changed, 47 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
>> index ff5936e..48e9319 100644
>> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
>> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
>> @@ -66,6 +66,16 @@ 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 typcially
>> +       would also run of a fixed clock and not support dyamically scaling the
> 
> Same of and dynamically comment.
> 
>> +       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.
> 
> This is different than assigned-clock-rates. I guess that's OK because
> we don't need to assign parents with more specifiers. Maybe it should be
> worded more strongly to clearly state that each cell corresponds to one
> power domain? And that it should match the opp-level inside any OPP
> table for the power domain?

Sure, I'll reword it to make it clear that we need the same number of cells
as power-domains, and as you pointed out below that 0 corresponds to not setting
anything.

For the matching of opp-level inside the OPP table of the power-domain, I don't
think from the power-domain bindings we limit providers with only OPP tables to
support performance states? It could be just a range that the provider manages
internally?

And thanks for catching all my typos :), I'll have them fixed when I re-spin.

> 
>> +
>>   required:
>>     - "#power-domain-cells"
>>   
>> @@ -129,3 +139,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>;
> 
> I guess <0> means don't set anything?
> 

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c
  2020-08-05  6:41   ` Stephen Boyd
@ 2020-08-05  8:14     ` Rajendra Nayak
  0 siblings, 0 replies; 17+ messages in thread
From: Rajendra Nayak @ 2020-08-05  8:14 UTC (permalink / raw)
  To: Stephen Boyd, bjorn.andersson, robh+dt, ulf.hansson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm


On 8/5/2020 12:11 PM, Stephen Boyd wrote:
> Quoting Rajendra Nayak (2020-08-04 04:46:56)
>> qup-i2c devices on sc7180 are clocked with a fixed clock (19.2 Mhz)
> 
> s/Mhz/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
> 
> Capitalize CX?
> 
>> 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(+)
> 
> Can you generate this patch with more context? The hunks all look the
> same so it's really hard to see where they apply.

Sure, will do and also fix the others mentioned above.

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-08-05  8:13     ` Rajendra Nayak
@ 2020-08-05 23:57       ` Stephen Boyd
  0 siblings, 0 replies; 17+ messages in thread
From: Stephen Boyd @ 2020-08-05 23:57 UTC (permalink / raw)
  To: Rajendra Nayak, bjorn.andersson, robh+dt, ulf.hansson
  Cc: linux-pm, devicetree, linux-kernel, linux-arm-msm

Quoting Rajendra Nayak (2020-08-05 01:13:06)
> 
> On 8/5/2020 12:09 PM, Stephen Boyd wrote:
> > Quoting Rajendra Nayak (2020-08-04 04:46:54)
> > 
> >> +       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.
> > 
> > This is different than assigned-clock-rates. I guess that's OK because
> > we don't need to assign parents with more specifiers. Maybe it should be
> > worded more strongly to clearly state that each cell corresponds to one
> > power domain? And that it should match the opp-level inside any OPP
> > table for the power domain?
> 
> Sure, I'll reword it to make it clear that we need the same number of cells
> as power-domains, and as you pointed out below that 0 corresponds to not setting
> anything.
> 
> For the matching of opp-level inside the OPP table of the power-domain, I don't
> think from the power-domain bindings we limit providers with only OPP tables to
> support performance states? It could be just a range that the provider manages
> internally?

Ok. The example made it match so maybe that can be clarified as well
that it doesn't need to match any OPP table performance state.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] PM / Domains: Add support for 'assigned-performance-states'
  2020-08-04 11:46 ` [PATCH 2/3] PM / Domains: Add support for 'assigned-performance-states' Rajendra Nayak
@ 2020-08-12  9:37   ` Ulf Hansson
  0 siblings, 0 replies; 17+ messages in thread
From: Ulf Hansson @ 2020-08-12  9:37 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: Rob Herring, Bjorn Andersson, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm

On Tue, 4 Aug 2020 at 13:47, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
> 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.

To allow flexibility, I would prefer to keep the performance state
being orthogonal to the power on/off state for a genpd.

Therefore, I am wondering if this is better handled by the consumer
driver instead?

Kind regards
Uffe

>
> 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 0a01df60..8704823 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -810,6 +810,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);
> @@ -829,6 +833,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;
> @@ -857,6 +862,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;
> @@ -890,6 +898,8 @@ static int genpd_runtime_resume(struct device *dev)
>  err_poweroff:
>         if (!pm_runtime_is_irq_safe(dev) ||
>                 (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);
> @@ -2405,6 +2415,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)
> @@ -2442,6 +2458,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;
> @@ -2485,6 +2502,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 9ec78ee..4a415ee 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -180,6 +180,7 @@ struct generic_pm_domain_data {
>         struct notifier_block nb;
>         int cpu;
>         unsigned int performance_state;
> +       unsigned int assigned_pstate;
>         void *data;
>  };
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2021-01-15 16:15   ` Bjorn Andersson
@ 2021-01-18  5:39     ` Rajendra Nayak
  0 siblings, 0 replies; 17+ messages in thread
From: Rajendra Nayak @ 2021-01-18  5:39 UTC (permalink / raw)
  To: Bjorn Andersson, Roja Rani Yarubandi
  Cc: ulf.hansson, robh+dt, wsa, swboyd, dianders, saiprakash.ranjan,
	mka, akashast, msavaliy, parashar, linux-pm, devicetree,
	linux-kernel, linux-arm-msm, agross, linux-i2c


On 1/15/2021 9:45 PM, Bjorn Andersson wrote:
> On Thu 24 Dec 05:12 CST 2020, Roja Rani Yarubandi 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: Roja Rani Yarubandi <rojay@codeaurora.org>
>> ---
>>   .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
>>   1 file changed, 49 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
>> index aed51e9dcb11..a42977a82d06 100644
>> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
>> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
>> @@ -66,6 +66,18 @@ 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 typcially
>> +       would also run off a fixed clock and not support dynamically scaling
>> +       the device's performance, also known as DVFS techniques. Each cell in
>> +       performance state value corresponds to one power domain specified as
>> +       part of the power-domains property. Performance state value can be an
>> +       opp-level inside an OPP table of the power-domain and need not match
>> +       with any OPP table performance state.
>> +
>>   required:
>>     - "#power-domain-cells"
>>   
>> @@ -131,3 +143,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>;
> 
> May I ask how this is different from saying something like:
> 
> 	required-opps = <&??>, <&rpmpd_opp_svs>:

I think its potentially the same. We just don't have any code to handle this
binding in kernel yet (when this property is part of the device/consumer node)

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-12-24 11:12 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Roja Rani Yarubandi
                     ` (2 preceding siblings ...)
  2020-12-31 15:49   ` Rob Herring
@ 2021-01-15 16:15   ` Bjorn Andersson
  2021-01-18  5:39     ` Rajendra Nayak
  3 siblings, 1 reply; 17+ messages in thread
From: Bjorn Andersson @ 2021-01-15 16:15 UTC (permalink / raw)
  To: Roja Rani Yarubandi
  Cc: ulf.hansson, robh+dt, wsa, swboyd, dianders, saiprakash.ranjan,
	mka, akashast, msavaliy, parashar, rnayak, linux-pm, devicetree,
	linux-kernel, linux-arm-msm, agross, linux-i2c

On Thu 24 Dec 05:12 CST 2020, Roja Rani Yarubandi 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: Roja Rani Yarubandi <rojay@codeaurora.org>
> ---
>  .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index aed51e9dcb11..a42977a82d06 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -66,6 +66,18 @@ 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 typcially
> +       would also run off a fixed clock and not support dynamically scaling
> +       the device's performance, also known as DVFS techniques. Each cell in
> +       performance state value corresponds to one power domain specified as
> +       part of the power-domains property. Performance state value can be an
> +       opp-level inside an OPP table of the power-domain and need not match
> +       with any OPP table performance state.
> +
>  required:
>    - "#power-domain-cells"
>  
> @@ -131,3 +143,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>;

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

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

Regards,
Bjorn

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-12-31 15:49   ` Rob Herring
@ 2021-01-08  9:39     ` Ulf Hansson
  0 siblings, 0 replies; 17+ messages in thread
From: Ulf Hansson @ 2021-01-08  9:39 UTC (permalink / raw)
  To: Rob Herring
  Cc: Roja Rani Yarubandi, Bjorn Andersson, Wolfram Sang, Stephen Boyd,
	Doug Anderson, Sai Prakash Ranjan, Matthias Kaehlcke, akashast,
	msavaliy, parashar, Rajendra Nayak, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c

On Thu, 31 Dec 2020 at 16:49, Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Dec 24, 2020 at 04:42:08PM +0530, Roja Rani Yarubandi 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: Roja Rani Yarubandi <rojay@codeaurora.org>
> > ---
> >  .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
> >  1 file changed, 49 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> > index aed51e9dcb11..a42977a82d06 100644
> > --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> > +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> > @@ -66,6 +66,18 @@ 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 typcially
> > +       would also run off a fixed clock and not support dynamically scaling
> > +       the device's performance, also known as DVFS techniques. Each cell in
> > +       performance state value corresponds to one power domain specified as
> > +       part of the power-domains property. Performance state value can be an
> > +       opp-level inside an OPP table of the power-domain and need not match
> > +       with any OPP table performance state.
>
> Couldn't this just be an additional cell in 'power-domains'?

Right. Some SoCs already use the cell to specify per device SoC
specific data [1].

Although, I am wondering if we shouldn't consider
"assigned-performance-states" as a more generic binding. I think it
would be somewhat comparable with the existing "assigned-clock-rates"
binding, don't you think?

[...]

Kind regards
Uffe

[1]
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-12-24 11:12 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Roja Rani Yarubandi
  2020-12-26  0:16   ` Rob Herring
  2020-12-27 16:56   ` Rob Herring
@ 2020-12-31 15:49   ` Rob Herring
  2021-01-08  9:39     ` Ulf Hansson
  2021-01-15 16:15   ` Bjorn Andersson
  3 siblings, 1 reply; 17+ messages in thread
From: Rob Herring @ 2020-12-31 15:49 UTC (permalink / raw)
  To: Roja Rani Yarubandi
  Cc: ulf.hansson, bjorn.andersson, wsa, swboyd, dianders,
	saiprakash.ranjan, mka, akashast, msavaliy, parashar, rnayak,
	linux-pm, devicetree, linux-kernel, linux-arm-msm, agross,
	linux-i2c

On Thu, Dec 24, 2020 at 04:42:08PM +0530, Roja Rani Yarubandi 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: Roja Rani Yarubandi <rojay@codeaurora.org>
> ---
>  .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index aed51e9dcb11..a42977a82d06 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -66,6 +66,18 @@ 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 typcially
> +       would also run off a fixed clock and not support dynamically scaling
> +       the device's performance, also known as DVFS techniques. Each cell in
> +       performance state value corresponds to one power domain specified as
> +       part of the power-domains property. Performance state value can be an
> +       opp-level inside an OPP table of the power-domain and need not match
> +       with any OPP table performance state.

Couldn't this just be an additional cell in 'power-domains'?

> +
>  required:
>    - "#power-domain-cells"
>  
> @@ -131,3 +143,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
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-12-24 11:12 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Roja Rani Yarubandi
  2020-12-26  0:16   ` Rob Herring
@ 2020-12-27 16:56   ` Rob Herring
  2020-12-31 15:49   ` Rob Herring
  2021-01-15 16:15   ` Bjorn Andersson
  3 siblings, 0 replies; 17+ messages in thread
From: Rob Herring @ 2020-12-27 16:56 UTC (permalink / raw)
  To: Roja Rani Yarubandi
  Cc: akashast, robh+dt, bjorn.andersson, wsa, ulf.hansson, parashar,
	dianders, linux-kernel, linux-i2c, agross, linux-pm,
	linux-arm-msm, saiprakash.ranjan, mka, rnayak, swboyd,
	devicetree, msavaliy

On Thu, 24 Dec 2020 16:42:08 +0530, Roja Rani Yarubandi 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: Roja Rani Yarubandi <rojay@codeaurora.org>
> ---
>  .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

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:

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

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.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-12-24 11:12 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Roja Rani Yarubandi
@ 2020-12-26  0:16   ` Rob Herring
  2020-12-27 16:56   ` Rob Herring
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 17+ messages in thread
From: Rob Herring @ 2020-12-26  0:16 UTC (permalink / raw)
  To: Roja Rani Yarubandi
  Cc: akashast, robh+dt, bjorn.andersson, wsa, ulf.hansson, parashar,
	dianders, linux-kernel, linux-i2c, agross, linux-pm,
	linux-arm-msm, saiprakash.ranjan, mka, rnayak, swboyd,
	devicetree, msavaliy

On Thu, 24 Dec 2020 16:42:08 +0530, Roja Rani Yarubandi 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: Roja Rani Yarubandi <rojay@codeaurora.org>
> ---
>  .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

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:

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

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.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property
  2020-12-24 11:12 [PATCH 0/3] Add support for assigned-performance-states for geni i2c driver Roja Rani Yarubandi
@ 2020-12-24 11:12 ` Roja Rani Yarubandi
  2020-12-26  0:16   ` Rob Herring
                     ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Roja Rani Yarubandi @ 2020-12-24 11:12 UTC (permalink / raw)
  To: ulf.hansson, robh+dt, bjorn.andersson, wsa
  Cc: swboyd, dianders, saiprakash.ranjan, mka, akashast, msavaliy,
	parashar, rnayak, linux-pm, devicetree, linux-kernel,
	linux-arm-msm, agross, linux-i2c, Roja Rani Yarubandi

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: Roja Rani Yarubandi <rojay@codeaurora.org>
---
 .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index aed51e9dcb11..a42977a82d06 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -66,6 +66,18 @@ 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 typcially
+       would also run off a fixed clock and not support dynamically scaling
+       the device's performance, also known as DVFS techniques. Each cell in
+       performance state value corresponds to one power domain specified as
+       part of the power-domains property. Performance state value can be an
+       opp-level inside an OPP table of the power-domain and need not match
+       with any OPP table performance state.
+
 required:
   - "#power-domain-cells"
 
@@ -131,3 +143,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


^ permalink raw reply related	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-01-18  5:41 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-04 11:46 [PATCH 0/3] Add support for assigned-performance-states Rajendra Nayak
2020-08-04 11:46 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Rajendra Nayak
2020-08-05  6:39   ` Stephen Boyd
2020-08-05  8:13     ` Rajendra Nayak
2020-08-05 23:57       ` Stephen Boyd
2020-08-04 11:46 ` [PATCH 2/3] PM / Domains: Add support for 'assigned-performance-states' Rajendra Nayak
2020-08-12  9:37   ` Ulf Hansson
2020-08-04 11:46 ` [PATCH 3/3] arm64: dts: sc7180: Add assigned-performance-states for i2c Rajendra Nayak
2020-08-05  6:41   ` Stephen Boyd
2020-08-05  8:14     ` Rajendra Nayak
2020-12-24 11:12 [PATCH 0/3] Add support for assigned-performance-states for geni i2c driver Roja Rani Yarubandi
2020-12-24 11:12 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Roja Rani Yarubandi
2020-12-26  0:16   ` Rob Herring
2020-12-27 16:56   ` Rob Herring
2020-12-31 15:49   ` Rob Herring
2021-01-08  9:39     ` Ulf Hansson
2021-01-15 16:15   ` Bjorn Andersson
2021-01-18  5:39     ` Rajendra Nayak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).