linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] Add support for assigned-performance-states for geni i2c driver
@ 2020-12-24 11:12 Roja Rani Yarubandi
  2020-12-24 11:12 ` [PATCH 1/3] dt-bindings: power: Introduce 'assigned-performance-states' property Roja Rani Yarubandi
                   ` (2 more replies)
  0 siblings, 3 replies; 27+ 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

Roja Rani Yarubandi (3):
  dt-bindings: power: Introduce 'assigned-performance-states' property
  arm64: dts: sc7180: Add assigned-performance-states for i2c
  i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'

 .../bindings/power/power-domain.yaml          | 49 +++++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7180.dtsi          | 24 +++++++++
 drivers/i2c/busses/i2c-qcom-geni.c            | 49 +++++++++++++++++++
 3 files changed, 122 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] 27+ 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)
  2020-12-24 11:12 ` [PATCH 2/3] arm64: dts: sc7180: Add assigned-performance-states for i2c Roja Rani Yarubandi
  2020-12-24 11:12 ` [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states' Roja Rani Yarubandi
  2 siblings, 4 replies; 27+ 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] 27+ messages in thread

* [PATCH 2/3] arm64: dts: sc7180: Add assigned-performance-states for i2c
  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-24 11:12 ` Roja Rani Yarubandi
  2020-12-24 11:12 ` [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states' Roja Rani Yarubandi
  2 siblings, 0 replies; 27+ 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

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: Roja Rani Yarubandi <rojay@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 22b832fc62e3..70d74215ba8b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -782,6 +782,8 @@ i2c0: i2c@880000 {
 						<&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";
 			};
 
@@ -834,6 +836,8 @@ i2c1: i2c@884000 {
 						<&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";
 			};
 
@@ -886,6 +890,8 @@ i2c2: i2c@888000 {
 						<&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";
 			};
 
@@ -920,6 +926,8 @@ i2c3: i2c@88c000 {
 						<&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";
 			};
 
@@ -972,6 +980,8 @@ i2c4: i2c@890000 {
 						<&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";
 			};
 
@@ -1006,6 +1016,8 @@ i2c5: i2c@894000 {
 						<&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";
 			};
 
@@ -1073,6 +1085,8 @@ i2c6: i2c@a80000 {
 						<&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";
 			};
 
@@ -1125,6 +1139,8 @@ i2c7: i2c@a84000 {
 						<&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";
 			};
 
@@ -1159,6 +1175,8 @@ i2c8: i2c@a88000 {
 						<&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";
 			};
 
@@ -1211,6 +1229,8 @@ i2c9: i2c@a8c000 {
 						<&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";
 			};
 
@@ -1245,6 +1265,8 @@ i2c10: i2c@a90000 {
 						<&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";
 			};
 
@@ -1297,6 +1319,8 @@ i2c11: i2c@a94000 {
 						<&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";
 			};
 
-- 
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] 27+ messages in thread

* [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  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-24 11:12 ` [PATCH 2/3] arm64: dts: sc7180: Add assigned-performance-states for i2c Roja Rani Yarubandi
@ 2020-12-24 11:12 ` Roja Rani Yarubandi
  2021-01-15 14:43   ` Bjorn Andersson
  2 siblings, 1 reply; 27+ 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

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

Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org>
---
 drivers/i2c/busses/i2c-qcom-geni.c | 49 ++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index 046d241183c5..250773784631 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -11,6 +11,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
 #include <linux/pm_runtime.h>
 #include <linux/qcom-geni-se.h>
 #include <linux/spinlock.h>
@@ -86,6 +87,7 @@ struct geni_i2c_dev {
 	u32 clk_freq_out;
 	const struct geni_i2c_clk_fld *clk_fld;
 	int suspended;
+	unsigned int assigned_pstate;
 };
 
 struct geni_i2c_err_log {
@@ -497,6 +499,7 @@ static int geni_i2c_probe(struct platform_device *pdev)
 	u32 proto, tx_depth;
 	int ret;
 	struct device *dev = &pdev->dev;
+	unsigned int assigned_pstate;
 
 	gi2c = devm_kzalloc(dev, sizeof(*gi2c), GFP_KERNEL);
 	if (!gi2c)
@@ -520,6 +523,20 @@ static int geni_i2c_probe(struct platform_device *pdev)
 		gi2c->clk_freq_out = KHZ(100);
 	}
 
+	/* Set the assigned performance state */
+	if (!of_property_read_u32(pdev->dev.of_node, "assigned-performance-states",
+					&assigned_pstate)) {
+		if (assigned_pstate) {
+			ret = dev_pm_genpd_set_performance_state(dev,
+								 assigned_pstate);
+			if (ret) {
+				dev_err(dev, "Failed to set performance state\n");
+				return ret;
+			}
+			gi2c->assigned_pstate = assigned_pstate;
+		}
+	}
+
 	if (has_acpi_companion(dev))
 		ACPI_COMPANION_SET(&gi2c->adap.dev, ACPI_COMPANION(dev));
 
@@ -616,10 +633,22 @@ static int geni_i2c_probe(struct platform_device *pdev)
 
 static int geni_i2c_remove(struct platform_device *pdev)
 {
+	int ret;
+	struct device *dev = &pdev->dev;
 	struct geni_i2c_dev *gi2c = platform_get_drvdata(pdev);
 
 	i2c_del_adapter(&gi2c->adap);
 	pm_runtime_disable(gi2c->se.dev);
+
+	/* Drop the assigned performance state */
+	if (gi2c->assigned_pstate) {
+		ret = dev_pm_genpd_set_performance_state(dev, 0);
+		if (ret) {
+			dev_err(dev, "Failed to set performance state\n");
+			return ret;
+		}
+	}
+
 	return 0;
 }
 
@@ -629,6 +658,16 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
 	struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);
 
 	disable_irq(gi2c->irq);
+
+	/* Drop the assigned performance state */
+	if (gi2c->assigned_pstate) {
+		ret = dev_pm_genpd_set_performance_state(dev, 0);
+		if (ret) {
+			dev_err(dev, "Failed to set performance state\n");
+			return ret;
+		}
+	}
+
 	ret = geni_se_resources_off(&gi2c->se);
 	if (ret) {
 		enable_irq(gi2c->irq);
@@ -654,6 +693,16 @@ static int __maybe_unused geni_i2c_runtime_resume(struct device *dev)
 	if (ret)
 		return ret;
 
+	/* Set the assigned performance state */
+	if (gi2c->assigned_pstate) {
+		ret = dev_pm_genpd_set_performance_state(dev,
+							 gi2c->assigned_pstate);
+		if (ret) {
+			dev_err(dev, "Failed to set performance state\n");
+			return ret;
+		}
+	}
+
 	enable_irq(gi2c->irq);
 	gi2c->suspended = 0;
 	return 0;
-- 
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] 27+ 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; 27+ 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] 27+ 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; 27+ 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] 27+ 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; 27+ 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] 27+ 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; 27+ 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] 27+ messages in thread

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2020-12-24 11:12 ` [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states' Roja Rani Yarubandi
@ 2021-01-15 14:43   ` Bjorn Andersson
  2021-01-18  5:36     ` Rajendra Nayak
  0 siblings, 1 reply; 27+ messages in thread
From: Bjorn Andersson @ 2021-01-15 14:43 UTC (permalink / raw)
  To: Roja Rani Yarubandi, ulf.hansson, viresh.kumar
  Cc: 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:

> @@ -629,6 +658,16 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
>  	struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);
>  
>  	disable_irq(gi2c->irq);
> +
> +	/* Drop the assigned performance state */
> +	if (gi2c->assigned_pstate) {
> +		ret = dev_pm_genpd_set_performance_state(dev, 0);
> +		if (ret) {
> +			dev_err(dev, "Failed to set performance state\n");
> +			return ret;
> +		}
> +	}
> +

Ulf, Viresh, I think we discussed this at the time of introducing the
performance states.

The client's state does not affect if its performance_state should
be included in the calculation of the aggregated performance_state, so
each driver that needs to keep some minimum performance state needs to
have these two snippets.

Would it not make sense to on enable/disable re-evaluate the
performance_state and potentially reconfigure the hardware
automatically?

Regards,
Bjorn

>  	ret = geni_se_resources_off(&gi2c->se);
>  	if (ret) {
>  		enable_irq(gi2c->irq);
> @@ -654,6 +693,16 @@ static int __maybe_unused geni_i2c_runtime_resume(struct device *dev)
>  	if (ret)
>  		return ret;
>  
> +	/* Set the assigned performance state */
> +	if (gi2c->assigned_pstate) {
> +		ret = dev_pm_genpd_set_performance_state(dev,
> +							 gi2c->assigned_pstate);
> +		if (ret) {
> +			dev_err(dev, "Failed to set performance state\n");
> +			return ret;
> +		}
> +	}
> +
>  	enable_irq(gi2c->irq);
>  	gi2c->suspended = 0;
>  	return 0;
> -- 
> 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] 27+ 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; 27+ 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] 27+ messages in thread

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-01-15 14:43   ` Bjorn Andersson
@ 2021-01-18  5:36     ` Rajendra Nayak
  2021-01-19 11:02       ` Ulf Hansson
  0 siblings, 1 reply; 27+ messages in thread
From: Rajendra Nayak @ 2021-01-18  5:36 UTC (permalink / raw)
  To: Bjorn Andersson, Roja Rani Yarubandi, ulf.hansson, viresh.kumar
  Cc: 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 8:13 PM, Bjorn Andersson wrote:
> On Thu 24 Dec 05:12 CST 2020, Roja Rani Yarubandi wrote:
> 
>> @@ -629,6 +658,16 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
>>   	struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);
>>   
>>   	disable_irq(gi2c->irq);
>> +
>> +	/* Drop the assigned performance state */
>> +	if (gi2c->assigned_pstate) {
>> +		ret = dev_pm_genpd_set_performance_state(dev, 0);
>> +		if (ret) {
>> +			dev_err(dev, "Failed to set performance state\n");
>> +			return ret;
>> +		}
>> +	}
>> +
> 
> Ulf, Viresh, I think we discussed this at the time of introducing the
> performance states.
> 
> The client's state does not affect if its performance_state should
> be included in the calculation of the aggregated performance_state, so
> each driver that needs to keep some minimum performance state needs to
> have these two snippets.
> 
> Would it not make sense to on enable/disable re-evaluate the
> performance_state and potentially reconfigure the hardware
> automatically?

I agree, this will be repeated across multiple drivers which would
need some minimal vote while they are active, handling this during
genpd enable/disable in genpd core makes sense.

> 
> Regards,
> Bjorn
> 
>>   	ret = geni_se_resources_off(&gi2c->se);
>>   	if (ret) {
>>   		enable_irq(gi2c->irq);
>> @@ -654,6 +693,16 @@ static int __maybe_unused geni_i2c_runtime_resume(struct device *dev)
>>   	if (ret)
>>   		return ret;
>>   
>> +	/* Set the assigned performance state */
>> +	if (gi2c->assigned_pstate) {
>> +		ret = dev_pm_genpd_set_performance_state(dev,
>> +							 gi2c->assigned_pstate);
>> +		if (ret) {
>> +			dev_err(dev, "Failed to set performance state\n");
>> +			return ret;
>> +		}
>> +	}
>> +
>>   	enable_irq(gi2c->irq);
>>   	gi2c->suspended = 0;
>>   	return 0;
>> -- 
>> 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

^ permalink raw reply	[flat|nested] 27+ 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; 27+ 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] 27+ messages in thread

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-01-18  5:36     ` Rajendra Nayak
@ 2021-01-19 11:02       ` Ulf Hansson
  2021-01-19 11:05         ` Viresh Kumar
  2021-04-29  7:50         ` Viresh Kumar
  0 siblings, 2 replies; 27+ messages in thread
From: Ulf Hansson @ 2021-01-19 11:02 UTC (permalink / raw)
  To: Rajendra Nayak, Bjorn Andersson, Viresh Kumar
  Cc: Roja Rani Yarubandi, Rob Herring, Wolfram Sang, Stephen Boyd,
	Doug Anderson, Sai Prakash Ranjan, Matthias Kaehlcke, akashast,
	msavaliy, parashar, Linux PM, DTML, Linux Kernel Mailing List,
	linux-arm-msm, Andy Gross, linux-i2c

On Mon, 18 Jan 2021 at 06:36, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
>
> On 1/15/2021 8:13 PM, Bjorn Andersson wrote:
> > On Thu 24 Dec 05:12 CST 2020, Roja Rani Yarubandi wrote:
> >
> >> @@ -629,6 +658,16 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
> >>      struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);
> >>
> >>      disable_irq(gi2c->irq);
> >> +
> >> +    /* Drop the assigned performance state */
> >> +    if (gi2c->assigned_pstate) {
> >> +            ret = dev_pm_genpd_set_performance_state(dev, 0);
> >> +            if (ret) {
> >> +                    dev_err(dev, "Failed to set performance state\n");
> >> +                    return ret;
> >> +            }
> >> +    }
> >> +
> >
> > Ulf, Viresh, I think we discussed this at the time of introducing the
> > performance states.
> >
> > The client's state does not affect if its performance_state should
> > be included in the calculation of the aggregated performance_state, so
> > each driver that needs to keep some minimum performance state needs to
> > have these two snippets.
> >
> > Would it not make sense to on enable/disable re-evaluate the
> > performance_state and potentially reconfigure the hardware
> > automatically?
>
> I agree, this will be repeated across multiple drivers which would
> need some minimal vote while they are active, handling this during
> genpd enable/disable in genpd core makes sense.

Initially that's what we tried out, but we realized that it was
difficult to deal with this internally in genpd, but more importantly
it also removed some flexibility from consumers and providers. See
commit 68de2fe57a8f ("PM / Domains: Make genpd performance states
orthogonal to the idlestates").

As a matter of fact this was quite recently discussed [1], which also
pointed out some issues when using the "required-opps" in combination,
but perhaps that got resolved? Viresh?

My concern is, if we would make this kind of change to the internals
of genpd, it would lead to the following limitation: A consumer driver
can no longer make its vote for its device to stick around, when the
device becomes runtime suspended - and how do we know that we never
need to support such a case?

>
> >
> > Regards,
> > Bjorn
> >
> >>      ret = geni_se_resources_off(&gi2c->se);
> >>      if (ret) {
> >>              enable_irq(gi2c->irq);
> >> @@ -654,6 +693,16 @@ static int __maybe_unused geni_i2c_runtime_resume(struct device *dev)
> >>      if (ret)
> >>              return ret;
> >>
> >> +    /* Set the assigned performance state */
> >> +    if (gi2c->assigned_pstate) {
> >> +            ret = dev_pm_genpd_set_performance_state(dev,
> >> +                                                     gi2c->assigned_pstate);
> >> +            if (ret) {
> >> +                    dev_err(dev, "Failed to set performance state\n");
> >> +                    return ret;
> >> +            }
> >> +    }
> >> +
> >>      enable_irq(gi2c->irq);
> >>      gi2c->suspended = 0;
> >>      return 0;

Kind regards
Uffe

[1]
https://lkml.org/lkml/2020/9/11/230

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-01-19 11:02       ` Ulf Hansson
@ 2021-01-19 11:05         ` Viresh Kumar
  2021-01-20 13:31           ` Ulf Hansson
  2021-04-29  7:50         ` Viresh Kumar
  1 sibling, 1 reply; 27+ messages in thread
From: Viresh Kumar @ 2021-01-19 11:05 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Rajendra Nayak, Bjorn Andersson, Roja Rani Yarubandi,
	Rob Herring, Wolfram Sang, Stephen Boyd, Doug Anderson,
	Sai Prakash Ranjan, Matthias Kaehlcke, akashast, msavaliy,
	parashar, Linux PM, DTML, Linux Kernel Mailing List,
	linux-arm-msm, Andy Gross, linux-i2c

On 19-01-21, 12:02, Ulf Hansson wrote:
> As a matter of fact this was quite recently discussed [1], which also
> pointed out some issues when using the "required-opps" in combination,
> but perhaps that got resolved? Viresh?

Perhaps we never did anything there ..

-- 
viresh

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-01-19 11:05         ` Viresh Kumar
@ 2021-01-20 13:31           ` Ulf Hansson
  2021-02-12  9:21             ` rojay
  0 siblings, 1 reply; 27+ messages in thread
From: Ulf Hansson @ 2021-01-20 13:31 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Rajendra Nayak, Bjorn Andersson, Roja Rani Yarubandi,
	Rob Herring, Wolfram Sang, Stephen Boyd, Doug Anderson,
	Sai Prakash Ranjan, Matthias Kaehlcke, akashast, msavaliy,
	parashar, Linux PM, DTML, Linux Kernel Mailing List,
	linux-arm-msm, Andy Gross, linux-i2c

On Tue, 19 Jan 2021 at 12:05, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 19-01-21, 12:02, Ulf Hansson wrote:
> > As a matter of fact this was quite recently discussed [1], which also
> > pointed out some issues when using the "required-opps" in combination,
> > but perhaps that got resolved? Viresh?
>
> Perhaps we never did anything there ..

Okay. Looks like we should pick up that discussion again, to conclude
on how to move forward.

>
> --
> viresh

Kind regards
Uffe

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-01-20 13:31           ` Ulf Hansson
@ 2021-02-12  9:21             ` rojay
  2021-04-01  6:39               ` rojay
  0 siblings, 1 reply; 27+ messages in thread
From: rojay @ 2021-02-12  9:21 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Viresh Kumar, Rajendra Nayak, Bjorn Andersson, Rob Herring,
	Wolfram Sang, Stephen Boyd, Doug Anderson, Sai Prakash Ranjan,
	Matthias Kaehlcke, akashast, msavaliy, parashar, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c

On 2021-01-20 19:01, Ulf Hansson wrote:
> On Tue, 19 Jan 2021 at 12:05, Viresh Kumar <viresh.kumar@linaro.org> 
> wrote:
>> 
>> On 19-01-21, 12:02, Ulf Hansson wrote:
>> > As a matter of fact this was quite recently discussed [1], which also
>> > pointed out some issues when using the "required-opps" in combination,
>> > but perhaps that got resolved? Viresh?
>> 
>> Perhaps we never did anything there ..
> 
> Okay. Looks like we should pick up that discussion again, to conclude
> on how to move forward.
> 

Soft Reminder!

>> 
>> --
>> viresh
> 
> Kind regards
> Uffe

- Roja

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-02-12  9:21             ` rojay
@ 2021-04-01  6:39               ` rojay
  2021-04-29  7:02                 ` rojay
  0 siblings, 1 reply; 27+ messages in thread
From: rojay @ 2021-04-01  6:39 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Viresh Kumar, Rajendra Nayak, Bjorn Andersson, Rob Herring,
	Wolfram Sang, Stephen Boyd, Doug Anderson, Sai Prakash Ranjan,
	Matthias Kaehlcke, akashast, msavaliy, parashar, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c

On 2021-02-12 14:51, rojay@codeaurora.org wrote:
> On 2021-01-20 19:01, Ulf Hansson wrote:
>> On Tue, 19 Jan 2021 at 12:05, Viresh Kumar <viresh.kumar@linaro.org> 
>> wrote:
>>> 
>>> On 19-01-21, 12:02, Ulf Hansson wrote:
>>> > As a matter of fact this was quite recently discussed [1], which also
>>> > pointed out some issues when using the "required-opps" in combination,
>>> > but perhaps that got resolved? Viresh?
>>> 
>>> Perhaps we never did anything there ..
>> 
>> Okay. Looks like we should pick up that discussion again, to conclude
>> on how to move forward.
>> 
> 
> Soft Reminder!
> 

Request Viresh, Uffe to discuss on the way forward.

>>> 
>>> --
>>> viresh
>> 
>> Kind regards
>> Uffe
> 
> - Roja

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-04-01  6:39               ` rojay
@ 2021-04-29  7:02                 ` rojay
  0 siblings, 0 replies; 27+ messages in thread
From: rojay @ 2021-04-29  7:02 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Viresh Kumar, Rajendra Nayak, Bjorn Andersson, Rob Herring,
	Wolfram Sang, Stephen Boyd, Doug Anderson, Sai Prakash Ranjan,
	Matthias Kaehlcke, akashast, msavaliy, parashar, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c

On 2021-04-01 12:09, rojay@codeaurora.org wrote:
> On 2021-02-12 14:51, rojay@codeaurora.org wrote:
>> On 2021-01-20 19:01, Ulf Hansson wrote:
>>> On Tue, 19 Jan 2021 at 12:05, Viresh Kumar <viresh.kumar@linaro.org> 
>>> wrote:
>>>> 
>>>> On 19-01-21, 12:02, Ulf Hansson wrote:
>>>> > As a matter of fact this was quite recently discussed [1], which also
>>>> > pointed out some issues when using the "required-opps" in combination,
>>>> > but perhaps that got resolved? Viresh?
>>>> 
>>>> Perhaps we never did anything there ..
>>> 
>>> Okay. Looks like we should pick up that discussion again, to conclude
>>> on how to move forward.
>>> 
>> 
>> Soft Reminder!
>> 
> 
> Request Viresh, Uffe to discuss on the way forward.
> 

Hi Viresh, Uffe, looking forward for your discussion/updates.

Thanks,
Roja

>>>> 
>>>> --
>>>> viresh
>>> 
>>> Kind regards
>>> Uffe
>> 
>> - Roja

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-01-19 11:02       ` Ulf Hansson
  2021-01-19 11:05         ` Viresh Kumar
@ 2021-04-29  7:50         ` Viresh Kumar
  2021-05-04  7:17           ` Rajendra Nayak
  1 sibling, 1 reply; 27+ messages in thread
From: Viresh Kumar @ 2021-04-29  7:50 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Rajendra Nayak, Bjorn Andersson, Roja Rani Yarubandi,
	Rob Herring, Wolfram Sang, Stephen Boyd, Doug Anderson,
	Sai Prakash Ranjan, Matthias Kaehlcke, akashast, msavaliy,
	parashar, Linux PM, DTML, Linux Kernel Mailing List,
	linux-arm-msm, Andy Gross, linux-i2c

Sorry Roja for dragging this too long, unfortunately I didn't have a
lot to add on. Lemme try start this thread again.

On 19-01-21, 12:02, Ulf Hansson wrote:
> On Mon, 18 Jan 2021 at 06:36, Rajendra Nayak <rnayak@codeaurora.org> wrote:
> >
> >
> > On 1/15/2021 8:13 PM, Bjorn Andersson wrote:
> > > On Thu 24 Dec 05:12 CST 2020, Roja Rani Yarubandi wrote:
> > >
> > >> @@ -629,6 +658,16 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
> > >>      struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);
> > >>
> > >>      disable_irq(gi2c->irq);
> > >> +
> > >> +    /* Drop the assigned performance state */
> > >> +    if (gi2c->assigned_pstate) {
> > >> +            ret = dev_pm_genpd_set_performance_state(dev, 0);
> > >> +            if (ret) {
> > >> +                    dev_err(dev, "Failed to set performance state\n");
> > >> +                    return ret;
> > >> +            }
> > >> +    }
> > >> +
> > >
> > > Ulf, Viresh, I think we discussed this at the time of introducing the
> > > performance states.
> > >
> > > The client's state does not affect if its performance_state should
> > > be included in the calculation of the aggregated performance_state, so
> > > each driver that needs to keep some minimum performance state needs to
> > > have these two snippets.
> > >
> > > Would it not make sense to on enable/disable re-evaluate the
> > > performance_state and potentially reconfigure the hardware
> > > automatically?
> >
> > I agree, this will be repeated across multiple drivers which would
> > need some minimal vote while they are active, handling this during
> > genpd enable/disable in genpd core makes sense.
> 
> Initially that's what we tried out, but we realized that it was
> difficult to deal with this internally in genpd, but more importantly
> it also removed some flexibility from consumers and providers. See
> commit 68de2fe57a8f ("PM / Domains: Make genpd performance states
> orthogonal to the idlestates").
> 
> As a matter of fact this was quite recently discussed [1], which also
> pointed out some issues when using the "required-opps" in combination,
> but perhaps that got resolved? Viresh?

So I looked again at that thread in detail today. The basic idea was
to enable/disable the genpd from within the OPP core and there were
doubts on how to do that efficiently as there are cases where domains
may be enabled for an OPP, but not for others.. etc. etc.

I am not sure if I consider that thread as part of the discussion we
are having here, they may be related, but that thread doesn't block
anything to be done in the genpd core.

> My concern is, if we would make this kind of change to the internals
> of genpd, it would lead to the following limitation: A consumer driver
> can no longer make its vote for its device to stick around, when the
> device becomes runtime suspended - and how do we know that we never
> need to support such a case?

What about doing this just for the assigned-performance-state case as
the clients don't want to play with it at all.

-- 
viresh

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-04-29  7:50         ` Viresh Kumar
@ 2021-05-04  7:17           ` Rajendra Nayak
  2021-05-07  9:06             ` Ulf Hansson
  0 siblings, 1 reply; 27+ messages in thread
From: Rajendra Nayak @ 2021-05-04  7:17 UTC (permalink / raw)
  To: Viresh Kumar, Ulf Hansson
  Cc: Bjorn Andersson, Roja Rani Yarubandi, Rob Herring, Wolfram Sang,
	Stephen Boyd, Doug Anderson, Sai Prakash Ranjan,
	Matthias Kaehlcke, akashast, msavaliy, parashar, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c


[]...
>>>>
>>>> Ulf, Viresh, I think we discussed this at the time of introducing the
>>>> performance states.
>>>>
>>>> The client's state does not affect if its performance_state should
>>>> be included in the calculation of the aggregated performance_state, so
>>>> each driver that needs to keep some minimum performance state needs to
>>>> have these two snippets.
>>>>
>>>> Would it not make sense to on enable/disable re-evaluate the
>>>> performance_state and potentially reconfigure the hardware
>>>> automatically?
>>>
>>> I agree, this will be repeated across multiple drivers which would
>>> need some minimal vote while they are active, handling this during
>>> genpd enable/disable in genpd core makes sense.
>>
>> Initially that's what we tried out, but we realized that it was
>> difficult to deal with this internally in genpd, but more importantly
>> it also removed some flexibility from consumers and providers. See
>> commit 68de2fe57a8f ("PM / Domains: Make genpd performance states
>> orthogonal to the idlestates").
>>
>> As a matter of fact this was quite recently discussed [1], which also
>> pointed out some issues when using the "required-opps" in combination,
>> but perhaps that got resolved? Viresh?
> 
> So I looked again at that thread in detail today. The basic idea was
> to enable/disable the genpd from within the OPP core and there were
> doubts on how to do that efficiently as there are cases where domains
> may be enabled for an OPP, but not for others.. etc. etc.
> 
> I am not sure if I consider that thread as part of the discussion we
> are having here, they may be related, but that thread doesn't block
> anything to be done in the genpd core.

That's true, the 2 threads are different in the sense that one talks
about having OPP core managing power on/off along with setting perf state,
while the other talks about genpd core managing a default perf state
along with power on/off, but they are similar in the sense that both
are related to the discussion whether we should treat powering on and off
a domain related to setting its performance state or if it should be
considered completely orthogonal.

I think the clock framework treats setting clock rates and turning
on/off a clock orthogonal because there is an inherent assumption that
once the clock is turned off, what rate it was set to should not matter,
and it can be running at the same rate when we turn the clock back on.

I guess we can have the same assumption here that a perf state of a
power domain should not matter if the power domain is turned off
and hence the perf state need not be dropped explicitly during power off,
atleast that should be true for the qcom power domains supporting perf
state upstream.

Should that be the approach taken here? I guess that would mean the patch
I had proposed earlier [1] to manage this in the genpd core would have to set the default
perf state at attach and remove it only during a detach of the device to
the pm_domain, and not manage it during the runtime_suspend/resume of the device.

>> A consumer driver
>> can no longer make its vote for its device to stick around, when the
>> device becomes runtime suspended - and how do we know that we never
>> need to support such a case?

The above approach should take care of this but the down side of it would be,
unlike in the case of clocks where the devices assigning a default clock rate
might be doing so on a device specific clock (rarely shared with other devices)
in case of power domain, and especially in the qcom implementation of these
power domains which support perf state, these can be large domains with lots of devices,
and any device being active (not necessarily wanting any default perf state) will keep
the domain at the default perf state, requested by a device which isn't really active.

> What about doing this just for the assigned-performance-state case as
> the clients don't want to play with it at all.

well, thats possible too, but you obviously can't reuse the same bindings
in such cases

[1] https://lore.kernel.org/patchwork/patch/1284042/

-- 
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] 27+ messages in thread

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-05-04  7:17           ` Rajendra Nayak
@ 2021-05-07  9:06             ` Ulf Hansson
  2021-05-10  6:37               ` Rajendra Nayak
  0 siblings, 1 reply; 27+ messages in thread
From: Ulf Hansson @ 2021-05-07  9:06 UTC (permalink / raw)
  To: Rajendra Nayak, Viresh Kumar
  Cc: Bjorn Andersson, Roja Rani Yarubandi, Rob Herring, Wolfram Sang,
	Stephen Boyd, Doug Anderson, Sai Prakash Ranjan,
	Matthias Kaehlcke, akashast, msavaliy, parashar, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c

On Tue, 4 May 2021 at 09:18, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
>
> []...
> >>>>
> >>>> Ulf, Viresh, I think we discussed this at the time of introducing the
> >>>> performance states.
> >>>>
> >>>> The client's state does not affect if its performance_state should
> >>>> be included in the calculation of the aggregated performance_state, so
> >>>> each driver that needs to keep some minimum performance state needs to
> >>>> have these two snippets.
> >>>>
> >>>> Would it not make sense to on enable/disable re-evaluate the
> >>>> performance_state and potentially reconfigure the hardware
> >>>> automatically?
> >>>
> >>> I agree, this will be repeated across multiple drivers which would
> >>> need some minimal vote while they are active, handling this during
> >>> genpd enable/disable in genpd core makes sense.
> >>
> >> Initially that's what we tried out, but we realized that it was
> >> difficult to deal with this internally in genpd, but more importantly
> >> it also removed some flexibility from consumers and providers. See
> >> commit 68de2fe57a8f ("PM / Domains: Make genpd performance states
> >> orthogonal to the idlestates").
> >>
> >> As a matter of fact this was quite recently discussed [1], which also
> >> pointed out some issues when using the "required-opps" in combination,
> >> but perhaps that got resolved? Viresh?
> >
> > So I looked again at that thread in detail today. The basic idea was
> > to enable/disable the genpd from within the OPP core and there were
> > doubts on how to do that efficiently as there are cases where domains
> > may be enabled for an OPP, but not for others.. etc. etc.
> >
> > I am not sure if I consider that thread as part of the discussion we
> > are having here, they may be related, but that thread doesn't block
> > anything to be done in the genpd core.
>
> That's true, the 2 threads are different in the sense that one talks
> about having OPP core managing power on/off along with setting perf state,
> while the other talks about genpd core managing a default perf state
> along with power on/off, but they are similar in the sense that both
> are related to the discussion whether we should treat powering on and off
> a domain related to setting its performance state or if it should be
> considered completely orthogonal.
>
> I think the clock framework treats setting clock rates and turning
> on/off a clock orthogonal because there is an inherent assumption that
> once the clock is turned off, what rate it was set to should not matter,
> and it can be running at the same rate when we turn the clock back on.
>
> I guess we can have the same assumption here that a perf state of a
> power domain should not matter if the power domain is turned off
> and hence the perf state need not be dropped explicitly during power off,
> atleast that should be true for the qcom power domains supporting perf
> state upstream.
>
> Should that be the approach taken here? I guess that would mean the patch
> I had proposed earlier [1] to manage this in the genpd core would have to set the default
> perf state at attach and remove it only during a detach of the device to
> the pm_domain, and not manage it during the runtime_suspend/resume of the device.

Right, I think this would be a step in the right direction, but it's
not sufficient to solve the complete problem. As you also point out
below.

>
> >> A consumer driver
> >> can no longer make its vote for its device to stick around, when the
> >> device becomes runtime suspended - and how do we know that we never
> >> need to support such a case?
>
> The above approach should take care of this but the down side of it would be,
> unlike in the case of clocks where the devices assigning a default clock rate
> might be doing so on a device specific clock (rarely shared with other devices)
> in case of power domain, and especially in the qcom implementation of these
> power domains which support perf state, these can be large domains with lots of devices,
> and any device being active (not necessarily wanting any default perf state) will keep
> the domain at the default perf state, requested by a device which isn't really active.

Yep, this certainly sounds suboptimal. To me, this isn't good enough.

>
> > What about doing this just for the assigned-performance-state case as
> > the clients don't want to play with it at all.
>
> well, thats possible too, but you obviously can't reuse the same bindings
> in such cases

Not sure I understand the issue with the DT binding? Let me elaborate
on how I think we could move forward.

It looks like we have two problems to solve:

*) We need a new DT binding.
If that becomes a generic property along the lines of the
"assigned-performance-state" as suggested - or if we decide to add a
SoC specific binding via using an additional cell in "power-domains"
(suggested by Rob), doesn't really matter much to me. The arguments
for the new DT property are very much similar to why we added
"assigned-clock-rates" for clocks.

**) We want to avoid boiler-plate code in drivers to manage
"assigned-performance-state" for their devices.
No matter what DT property we decide on (generic or SoC specific), we
should be able to manage this from the PM domain (genpd) layer. No
changes in the drivers should be needed.
If a generic binding is used, we could consider to let genpd
internally manage the whole thing (DT parsing and updating performance
state votes for assigned-performance-state only).
If we go for an SoC specific binding, the genpd provider needs to be
updated. It can manage DT parsing from the ->attach|detach_dev()
callbacks and update performance votes from the ->start|stop()
callbacks.
We could also consider a hybrid of these two solutions.

>
> [1] https://lore.kernel.org/patchwork/patch/1284042/

Kind regards
Uffe

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

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-05-07  9:06             ` Ulf Hansson
@ 2021-05-10  6:37               ` Rajendra Nayak
  2021-05-12 13:50                 ` Ulf Hansson
  0 siblings, 1 reply; 27+ messages in thread
From: Rajendra Nayak @ 2021-05-10  6:37 UTC (permalink / raw)
  To: Ulf Hansson, Viresh Kumar
  Cc: Bjorn Andersson, Roja Rani Yarubandi, Rob Herring, Wolfram Sang,
	Stephen Boyd, Doug Anderson, Sai Prakash Ranjan,
	Matthias Kaehlcke, akashast, msavaliy, parashar, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c



On 5/7/2021 2:36 PM, Ulf Hansson wrote:
> On Tue, 4 May 2021 at 09:18, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>>
>>
>> []...
>>>>>>
>>>>>> Ulf, Viresh, I think we discussed this at the time of introducing the
>>>>>> performance states.
>>>>>>
>>>>>> The client's state does not affect if its performance_state should
>>>>>> be included in the calculation of the aggregated performance_state, so
>>>>>> each driver that needs to keep some minimum performance state needs to
>>>>>> have these two snippets.
>>>>>>
>>>>>> Would it not make sense to on enable/disable re-evaluate the
>>>>>> performance_state and potentially reconfigure the hardware
>>>>>> automatically?
>>>>>
>>>>> I agree, this will be repeated across multiple drivers which would
>>>>> need some minimal vote while they are active, handling this during
>>>>> genpd enable/disable in genpd core makes sense.
>>>>
>>>> Initially that's what we tried out, but we realized that it was
>>>> difficult to deal with this internally in genpd, but more importantly
>>>> it also removed some flexibility from consumers and providers. See
>>>> commit 68de2fe57a8f ("PM / Domains: Make genpd performance states
>>>> orthogonal to the idlestates").
>>>>
>>>> As a matter of fact this was quite recently discussed [1], which also
>>>> pointed out some issues when using the "required-opps" in combination,
>>>> but perhaps that got resolved? Viresh?
>>>
>>> So I looked again at that thread in detail today. The basic idea was
>>> to enable/disable the genpd from within the OPP core and there were
>>> doubts on how to do that efficiently as there are cases where domains
>>> may be enabled for an OPP, but not for others.. etc. etc.
>>>
>>> I am not sure if I consider that thread as part of the discussion we
>>> are having here, they may be related, but that thread doesn't block
>>> anything to be done in the genpd core.
>>
>> That's true, the 2 threads are different in the sense that one talks
>> about having OPP core managing power on/off along with setting perf state,
>> while the other talks about genpd core managing a default perf state
>> along with power on/off, but they are similar in the sense that both
>> are related to the discussion whether we should treat powering on and off
>> a domain related to setting its performance state or if it should be
>> considered completely orthogonal.
>>
>> I think the clock framework treats setting clock rates and turning
>> on/off a clock orthogonal because there is an inherent assumption that
>> once the clock is turned off, what rate it was set to should not matter,
>> and it can be running at the same rate when we turn the clock back on.
>>
>> I guess we can have the same assumption here that a perf state of a
>> power domain should not matter if the power domain is turned off
>> and hence the perf state need not be dropped explicitly during power off,
>> atleast that should be true for the qcom power domains supporting perf
>> state upstream.
>>
>> Should that be the approach taken here? I guess that would mean the patch
>> I had proposed earlier [1] to manage this in the genpd core would have to set the default
>> perf state at attach and remove it only during a detach of the device to
>> the pm_domain, and not manage it during the runtime_suspend/resume of the device.
> 
> Right, I think this would be a step in the right direction, but it's
> not sufficient to solve the complete problem. As you also point out
> below.
> 
>>
>>>> A consumer driver
>>>> can no longer make its vote for its device to stick around, when the
>>>> device becomes runtime suspended - and how do we know that we never
>>>> need to support such a case?
>>
>> The above approach should take care of this but the down side of it would be,
>> unlike in the case of clocks where the devices assigning a default clock rate
>> might be doing so on a device specific clock (rarely shared with other devices)
>> in case of power domain, and especially in the qcom implementation of these
>> power domains which support perf state, these can be large domains with lots of devices,
>> and any device being active (not necessarily wanting any default perf state) will keep
>> the domain at the default perf state, requested by a device which isn't really active.
> 
> Yep, this certainly sounds suboptimal. To me, this isn't good enough.
> 
>>
>>> What about doing this just for the assigned-performance-state case as
>>> the clients don't want to play with it at all.
>>
>> well, thats possible too, but you obviously can't reuse the same bindings
>> in such cases
> 
> Not sure I understand the issue with the DT binding? Let me elaborate
> on how I think we could move forward.
> 
> It looks like we have two problems to solve:
> 
> *) We need a new DT binding.
> If that becomes a generic property along the lines of the
> "assigned-performance-state" as suggested - or if we decide to add a
> SoC specific binding via using an additional cell in "power-domains"
> (suggested by Rob), doesn't really matter much to me. The arguments
> for the new DT property are very much similar to why we added
> "assigned-clock-rates" for clocks.
> 
> **) We want to avoid boiler-plate code in drivers to manage
> "assigned-performance-state" for their devices.
> No matter what DT property we decide on (generic or SoC specific), we
> should be able to manage this from the PM domain (genpd) layer. No
> changes in the drivers should be needed.
> If a generic binding is used, we could consider to let genpd
> internally manage the whole thing (DT parsing and updating performance
> state votes for assigned-performance-state only).

Sure, so for starters does that mean I should re-spin my series which
adds the generic 'assigned-performance-states' bindings and see if Rob
is OK with that? I am guessing you are OK with the way that binding gets
used within genpd core in that series, or would you want it to be handled
differently?

> If we go for an SoC specific binding, the genpd provider needs to be
> updated. It can manage DT parsing from the ->attach|detach_dev()
> callbacks and update performance votes from the ->start|stop()
> callbacks.
> We could also consider a hybrid of these two solutions.
>>
>> [1] https://lore.kernel.org/patchwork/patch/1284042/
> 
> Kind regards
> Uffe
> 

-- 
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] 27+ messages in thread

* Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
  2021-05-10  6:37               ` Rajendra Nayak
@ 2021-05-12 13:50                 ` Ulf Hansson
  0 siblings, 0 replies; 27+ messages in thread
From: Ulf Hansson @ 2021-05-12 13:50 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: Viresh Kumar, Bjorn Andersson, Roja Rani Yarubandi, Rob Herring,
	Wolfram Sang, Stephen Boyd, Doug Anderson, Sai Prakash Ranjan,
	Matthias Kaehlcke, akashast, msavaliy, parashar, Linux PM, DTML,
	Linux Kernel Mailing List, linux-arm-msm, Andy Gross, linux-i2c

On Mon, 10 May 2021 at 08:37, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
>
>
> On 5/7/2021 2:36 PM, Ulf Hansson wrote:
> > On Tue, 4 May 2021 at 09:18, Rajendra Nayak <rnayak@codeaurora.org> wrote:
> >>
> >>
> >> []...
> >>>>>>
> >>>>>> Ulf, Viresh, I think we discussed this at the time of introducing the
> >>>>>> performance states.
> >>>>>>
> >>>>>> The client's state does not affect if its performance_state should
> >>>>>> be included in the calculation of the aggregated performance_state, so
> >>>>>> each driver that needs to keep some minimum performance state needs to
> >>>>>> have these two snippets.
> >>>>>>
> >>>>>> Would it not make sense to on enable/disable re-evaluate the
> >>>>>> performance_state and potentially reconfigure the hardware
> >>>>>> automatically?
> >>>>>
> >>>>> I agree, this will be repeated across multiple drivers which would
> >>>>> need some minimal vote while they are active, handling this during
> >>>>> genpd enable/disable in genpd core makes sense.
> >>>>
> >>>> Initially that's what we tried out, but we realized that it was
> >>>> difficult to deal with this internally in genpd, but more importantly
> >>>> it also removed some flexibility from consumers and providers. See
> >>>> commit 68de2fe57a8f ("PM / Domains: Make genpd performance states
> >>>> orthogonal to the idlestates").
> >>>>
> >>>> As a matter of fact this was quite recently discussed [1], which also
> >>>> pointed out some issues when using the "required-opps" in combination,
> >>>> but perhaps that got resolved? Viresh?
> >>>
> >>> So I looked again at that thread in detail today. The basic idea was
> >>> to enable/disable the genpd from within the OPP core and there were
> >>> doubts on how to do that efficiently as there are cases where domains
> >>> may be enabled for an OPP, but not for others.. etc. etc.
> >>>
> >>> I am not sure if I consider that thread as part of the discussion we
> >>> are having here, they may be related, but that thread doesn't block
> >>> anything to be done in the genpd core.
> >>
> >> That's true, the 2 threads are different in the sense that one talks
> >> about having OPP core managing power on/off along with setting perf state,
> >> while the other talks about genpd core managing a default perf state
> >> along with power on/off, but they are similar in the sense that both
> >> are related to the discussion whether we should treat powering on and off
> >> a domain related to setting its performance state or if it should be
> >> considered completely orthogonal.
> >>
> >> I think the clock framework treats setting clock rates and turning
> >> on/off a clock orthogonal because there is an inherent assumption that
> >> once the clock is turned off, what rate it was set to should not matter,
> >> and it can be running at the same rate when we turn the clock back on.
> >>
> >> I guess we can have the same assumption here that a perf state of a
> >> power domain should not matter if the power domain is turned off
> >> and hence the perf state need not be dropped explicitly during power off,
> >> atleast that should be true for the qcom power domains supporting perf
> >> state upstream.
> >>
> >> Should that be the approach taken here? I guess that would mean the patch
> >> I had proposed earlier [1] to manage this in the genpd core would have to set the default
> >> perf state at attach and remove it only during a detach of the device to
> >> the pm_domain, and not manage it during the runtime_suspend/resume of the device.
> >
> > Right, I think this would be a step in the right direction, but it's
> > not sufficient to solve the complete problem. As you also point out
> > below.
> >
> >>
> >>>> A consumer driver
> >>>> can no longer make its vote for its device to stick around, when the
> >>>> device becomes runtime suspended - and how do we know that we never
> >>>> need to support such a case?
> >>
> >> The above approach should take care of this but the down side of it would be,
> >> unlike in the case of clocks where the devices assigning a default clock rate
> >> might be doing so on a device specific clock (rarely shared with other devices)
> >> in case of power domain, and especially in the qcom implementation of these
> >> power domains which support perf state, these can be large domains with lots of devices,
> >> and any device being active (not necessarily wanting any default perf state) will keep
> >> the domain at the default perf state, requested by a device which isn't really active.
> >
> > Yep, this certainly sounds suboptimal. To me, this isn't good enough.
> >
> >>
> >>> What about doing this just for the assigned-performance-state case as
> >>> the clients don't want to play with it at all.
> >>
> >> well, thats possible too, but you obviously can't reuse the same bindings
> >> in such cases
> >
> > Not sure I understand the issue with the DT binding? Let me elaborate
> > on how I think we could move forward.
> >
> > It looks like we have two problems to solve:
> >
> > *) We need a new DT binding.
> > If that becomes a generic property along the lines of the
> > "assigned-performance-state" as suggested - or if we decide to add a
> > SoC specific binding via using an additional cell in "power-domains"
> > (suggested by Rob), doesn't really matter much to me. The arguments
> > for the new DT property are very much similar to why we added
> > "assigned-clock-rates" for clocks.
> >
> > **) We want to avoid boiler-plate code in drivers to manage
> > "assigned-performance-state" for their devices.
> > No matter what DT property we decide on (generic or SoC specific), we
> > should be able to manage this from the PM domain (genpd) layer. No
> > changes in the drivers should be needed.
> > If a generic binding is used, we could consider to let genpd
> > internally manage the whole thing (DT parsing and updating performance
> > state votes for assigned-performance-state only).
>
> Sure, so for starters does that mean I should re-spin my series which
> adds the generic 'assigned-performance-states' bindings and see if Rob
> is OK with that? I am guessing you are OK with the way that binding gets
> used within genpd core in that series, or would you want it to be handled
> differently?

A re-spin would definitely move this forward. If we can convince Rob
about the generic DT binding, I will certainly agree to change genpd
to help/manage the DT parsing.

Although, I am not sure yet what is the best. Let genpd to do the
parsing internally in genpd_add_device() or just provide a helper
function that can be called from an ->attach|detach_dev() callback.

In the end it boils done to decide whether we should use the
->start|stop() callbacks or let genpd internally manage the "assigned
performance state". Honestly, I would prefer to look at how the code
would need to  be changed, before answering this.

>
> > If we go for an SoC specific binding, the genpd provider needs to be
> > updated. It can manage DT parsing from the ->attach|detach_dev()
> > callbacks and update performance votes from the ->start|stop()
> > callbacks.
> > We could also consider a hybrid of these two solutions.
> >>
> >> [1] https://lore.kernel.org/patchwork/patch/1284042/

Kind regards
Uffe

^ permalink raw reply	[flat|nested] 27+ 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; 27+ 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] 27+ 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; 27+ 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] 27+ 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; 27+ 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] 27+ 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
  0 siblings, 1 reply; 27+ 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] 27+ messages in thread

end of thread, other threads:[~2021-05-12 13:51 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2020-12-24 11:12 ` [PATCH 2/3] arm64: dts: sc7180: Add assigned-performance-states for i2c Roja Rani Yarubandi
2020-12-24 11:12 ` [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states' Roja Rani Yarubandi
2021-01-15 14:43   ` Bjorn Andersson
2021-01-18  5:36     ` Rajendra Nayak
2021-01-19 11:02       ` Ulf Hansson
2021-01-19 11:05         ` Viresh Kumar
2021-01-20 13:31           ` Ulf Hansson
2021-02-12  9:21             ` rojay
2021-04-01  6:39               ` rojay
2021-04-29  7:02                 ` rojay
2021-04-29  7:50         ` Viresh Kumar
2021-05-04  7:17           ` Rajendra Nayak
2021-05-07  9:06             ` Ulf Hansson
2021-05-10  6:37               ` Rajendra Nayak
2021-05-12 13:50                 ` Ulf Hansson
  -- strict thread matches above, loose matches on Subject: below --
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

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