Skip to contentSkip to conversation

cpufreq: qcom-hw: Move clocks to CPU node

RFC PATCH In review Viresh Kumar 4 participants 16 messages Jul 13, 2022 – Sep 26, 2022

Subsystems (5)
Device tree bindings Arm Qualcomm mailing list Arm Qualcomm support CPU frequency scaling framework +1 more subsystems
lore
Share & tools
lore

Viresh Kumar

author maintainer
#0 lore raw

cover cpufreq: qcom-hw: Move clocks to CPU node

Hi,

A recent patch series, targeting enhancements in the OPP core, ended up breaking cpufreq on some of the Qualcomm platforms [1]. Necessary adjustments are made in the OPP core, a bit hacky though, to get it working for now but it would be better to solve the problem at hand in a cleaner way. And this patchset is an attempt towards the same.

cpufreq-hw is a hardware engine, which takes care of frequency management for CPUs. The engine manages the clocks for CPU devices, but it isn't the end consumer of the clocks, which are the CPUs in this case.

For this reason, it looks incorrect to keep the clock related properties in the cpufreq-hw node. They should really be present at the end user, i.e. the CPUs.

The case was simple currently as all the devices, i.e. the CPUs, that the engine manages share the same clock names. What if the clock names are different for different CPUs or clusters ? How will keeping the clock properties in the cpufreq-hw node work in that case ?

This design creates further problems for frameworks like OPP, which expects all such details (clocks) to be present in the end device node itself, instead of another related node.

This patchset moves the clock properties to the node that uses them instead, i.e. the CPU nodes and makes necessary adjustments at other places.

After this is applied, I can drop the unnecessary change from the OPP core, but I wanted to discuss if this is a step in the right direction or not first and so the RFC.

--
Viresh

[1] https://lore.kernel.org/lkml/[email protected]/

Viresh Kumar (4):
dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes
arm64: dts: qcom: Move clocks to CPU nodes
cpufreq: qcom-cpufreq-hw: Clocks are moved to CPU nodes
cpufreq: qcom-cpufreq-hw: Register config_clks helper

 .../bindings/cpufreq/cpufreq-qcom-hw.yaml     | 31 ++++----
 arch/arm64/boot/dts/qcom/sc7180.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sc7280.dtsi          | 18 ++++-
 arch/arm64/boot/dts/qcom/sdm845.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sm6350.dtsi          | 18 ++++-
 arch/arm64/boot/dts/qcom/sm8150.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sm8250.dtsi          | 18 ++++-
 arch/arm64/boot/dts/qcom/sm8350.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sm8450.dtsi          | 18 ++++-
 drivers/cpufreq/qcom-cpufreq-hw.c             | 75 ++++++++++++++-----
 10 files changed, 199 insertions(+), 55 deletions(-)
Signature · 1 line
2.31.1.272.g89b43f80a514
author maintainer
#1 lore raw

RFC PATCH 1/4 dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes

cpufreq-hw is a hardware engine, which takes care of frequency management for CPUs. The engine manages the clocks for CPU devices, but it isn't the end consumer of the clocks, which are the CPUs in this case.

For this reason, it looks incorrect to keep the clock related properties in the cpufreq-hw node. They should really be present at the end user, i.e. the CPUs.

The case was simple currently as all the devices, i.e. the CPUs, that the engine manages share the same clock names. What if the clock names are different for different CPUs or clusters ? How will keeping the clock properties in the cpufreq-hw node work in that case ?

This design creates further problems for frameworks like OPP, which expects all such details (clocks) to be present in the end device node itself, instead of another related node.

Move the clocks properties to the node that uses them instead.

Signed-off-by Viresh Kumar <[email protected]>
---
 .../bindings/cpufreq/cpufreq-qcom-hw.yaml     | 31 ++++++++++---------
 1 file changed, 16 insertions(+), 15 deletions(-)
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +16 -15
index 2f1b8b6852a0..2ef4eeeca9b9 100644
@@ -42,24 +42,12 @@ description: |
       - const: freq-domain1
       - const: freq-domain2
 
-  clocks:
-    items:
-      - description: XO Clock
-      - description: GPLL0 Clock
-
-  clock-names:
-    items:
-      - const: xo
-      - const: alternate
-
   '#freq-domain-cells':
     const: 1
 
 required:
   - compatible
   - reg
-  - clocks
-  - clock-names
   - '#freq-domain-cells'
 
 additionalProperties: false

@@ -81,6 +69,8 @@ additionalProperties: false
         reg = <0x0 0x0>;
         enable-method = "psci";
         next-level-cache = <&L2_0>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 0>;
         L2_0: l2-cache {
           compatible = "cache";

@@ -97,6 +87,8 @@ additionalProperties: false
         reg = <0x0 0x100>;
         enable-method = "psci";
         next-level-cache = <&L2_100>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 0>;
         L2_100: l2-cache {
           compatible = "cache";

@@ -110,6 +102,8 @@ additionalProperties: false
         reg = <0x0 0x200>;
         enable-method = "psci";
         next-level-cache = <&L2_200>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 0>;
         L2_200: l2-cache {
           compatible = "cache";

@@ -123,6 +117,8 @@ additionalProperties: false
         reg = <0x0 0x300>;
         enable-method = "psci";
         next-level-cache = <&L2_300>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 0>;
         L2_300: l2-cache {
           compatible = "cache";

@@ -136,6 +132,8 @@ additionalProperties: false
         reg = <0x0 0x400>;
         enable-method = "psci";
         next-level-cache = <&L2_400>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 1>;
         L2_400: l2-cache {
           compatible = "cache";

@@ -149,6 +147,8 @@ additionalProperties: false
         reg = <0x0 0x500>;
         enable-method = "psci";
         next-level-cache = <&L2_500>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 1>;
         L2_500: l2-cache {
           compatible = "cache";

@@ -162,6 +162,8 @@ additionalProperties: false
         reg = <0x0 0x600>;
         enable-method = "psci";
         next-level-cache = <&L2_600>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 1>;
         L2_600: l2-cache {
           compatible = "cache";

@@ -175,6 +177,8 @@ additionalProperties: false
         reg = <0x0 0x700>;
         enable-method = "psci";
         next-level-cache = <&L2_700>;
+        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+        clock-names = "xo", "alternate";
         qcom,freq-domain = <&cpufreq_hw 1>;
         L2_700: l2-cache {
           compatible = "cache";

@@ -192,9 +196,6 @@ additionalProperties: false
         reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>;
         reg-names = "freq-domain0", "freq-domain1";
 
-        clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
-        clock-names = "xo", "alternate";
-
         #freq-domain-cells = <1>;
       };
     };
Signature · 1 line
2.31.1.272.g89b43f80a514
maintainer
#2 lore raw

Re: [RFC PATCH 1/4] dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes

Quoted 4 lines · Viresh Kumar

cpufreq-hw is a hardware engine, which takes care of frequency management for CPUs. The engine manages the clocks for CPU devices, but it isn't the end consumer of the clocks, which are the CPUs in this case.

The question is really where does the clock mux live?

Quoted 3 lines

For this reason, it looks incorrect to keep the clock related properties in the cpufreq-hw node. They should really be present at the end user, i.e. the CPUs.

The issue is that the CPU itself probably only has 1 clock input (at least for its core frequency). Listing out all possible clock sources in CPU node 'clocks' is wrong too.

Quoted 10 lines

The case was simple currently as all the devices, i.e. the CPUs, that the engine manages share the same clock names. What if the clock names are different for different CPUs or clusters ? How will keeping the clock properties in the cpufreq-hw node work in that case ?

This design creates further problems for frameworks like OPP, which expects all such details (clocks) to be present in the end device node itself, instead of another related node.

Move the clocks properties to the node that uses them instead.

What's the purpose of freq-domain binding now? I thought the idea was to use that instead of clocks directly.

Rob

author maintainer
#3 lore raw

Re: [RFC PATCH 1/4] dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes

Quoted 7 lines · Rob Herring
Quoted 4 lines · Viresh Kumar

cpufreq-hw is a hardware engine, which takes care of frequency management for CPUs. The engine manages the clocks for CPU devices, but it isn't the end consumer of the clocks, which are the CPUs in this case.

The question is really where does the clock mux live?

As Manivannan clarified in another email, these clocks are actually consumed by the cpufreq-hw node, so existing code was fine.

Quoted 6 lines
Quoted 3 lines

For this reason, it looks incorrect to keep the clock related properties in the cpufreq-hw node. They should really be present at the end user, i.e. the CPUs.

The issue is that the CPU itself probably only has 1 clock input (at least for its core frequency).

Right, and they (Qcom) have skipped adding that in DT currently. I have suggested to him to add it there, which will solve the issue as well.

Quoted 1 line

Listing out all possible clock sources in CPU node 'clocks' is wrong too.

Yes, we need to mention only the clocks which are consumed directly by the CPU, maybe just one of them which comes out of cpufreq-hw node.

Quoted 5 lines
Quoted 5 lines

The case was simple currently as all the devices, i.e. the CPUs, that the engine manages share the same clock names. What if the clock names are different for different CPUs or clusters ? How will keeping the clock properties in the cpufreq-hw node work in that case ?

Quoted 8 lines
Quoted 5 lines

This design creates further problems for frameworks like OPP, which expects all such details (clocks) to be present in the end device node itself, instead of another related node.

Move the clocks properties to the node that uses them instead.

What's the purpose of freq-domain binding now? I thought the idea was to use that instead of clocks directly.

Not always I think. It provides register access for programming or voting for the clock, etc. Yes, the code won't do clk_set_rate() but the DT should still mention the clock in the CPU node if it mentions an OPP table with frequencies in it.

Signature · 1 line
viresh
author maintainer
#4 lore raw

RFC PATCH 2/4 arm64: dts: qcom: Move clocks to CPU nodes

In reply to Viresh Kumar

The clock specific properties must be part the consumer nodes, i.e. the CPUs here, instead of the node that manages the frequency engine.

Move the clocks properties to the CPU node instead.

Signed-off-by Viresh Kumar <[email protected]>
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 19 ++++++++++++++++---
 arch/arm64/boot/dts/qcom/sc7280.dtsi | 18 ++++++++++++++++--
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 ++++++++++++++++---
 arch/arm64/boot/dts/qcom/sm6350.dtsi | 18 ++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 19 ++++++++++++++++---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 18 ++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 19 ++++++++++++++++---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 18 ++++++++++++++++--
 8 files changed, 128 insertions(+), 20 deletions(-)
arch/arm64/boot/dts/qcom/sc7180.dtsi +16 -3
index 5dcaac23a138..4c9a5f5e4ab4 100644
@@ -138,6 +138,8 @@ &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			capacity-dmips-mhz = <415>;
 			dynamic-power-coefficient = <137>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -164,6 +166,8 @@ &LITTLE_CPU_SLEEP_1
 			capacity-dmips-mhz = <415>;
 			dynamic-power-coefficient = <137>;
 			next-level-cache = <&L2_100>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -186,6 +190,8 @@ &LITTLE_CPU_SLEEP_1
 			capacity-dmips-mhz = <415>;
 			dynamic-power-coefficient = <137>;
 			next-level-cache = <&L2_200>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -208,6 +214,8 @@ &LITTLE_CPU_SLEEP_1
 			capacity-dmips-mhz = <415>;
 			dynamic-power-coefficient = <137>;
 			next-level-cache = <&L2_300>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -230,6 +238,8 @@ &LITTLE_CPU_SLEEP_1
 			capacity-dmips-mhz = <415>;
 			dynamic-power-coefficient = <137>;
 			next-level-cache = <&L2_400>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -252,6 +262,8 @@ &LITTLE_CPU_SLEEP_1
 			capacity-dmips-mhz = <415>;
 			dynamic-power-coefficient = <137>;
 			next-level-cache = <&L2_500>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -274,6 +286,8 @@ &BIG_CPU_SLEEP_1
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <480>;
 			next-level-cache = <&L2_600>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu6_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -296,6 +310,8 @@ &BIG_CPU_SLEEP_1
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <480>;
 			next-level-cache = <&L2_700>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu6_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&osm_l3 MASTER_OSM_L3_APPS &osm_l3 SLAVE_OSM_L3>;

@@ -3538,9 +3554,6 @@ cpufreq_hw: cpufreq@18323000 {
 			reg = <0 0x18323000 0 0x1400>, <0 0x18325800 0 0x1400>;
 			reg-names = "freq-domain0", "freq-domain1";
 
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
-			clock-names = "xo", "alternate";
-
 			#freq-domain-cells = <1>;
 		};
arch/arm64/boot/dts/qcom/sc7280.dtsi +16 -2
index e66fc67de206..f7600dbdd1e1 100644
@@ -172,6 +172,8 @@ CPU0: cpu@0 {
 					   &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_0>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -195,6 +197,8 @@ CPU1: cpu@100 {
 					   &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_100>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -215,6 +219,8 @@ CPU2: cpu@200 {
 					   &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_200>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -235,6 +241,8 @@ CPU3: cpu@300 {
 					   &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_300>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -255,6 +263,8 @@ CPU4: cpu@400 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_400>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -275,6 +285,8 @@ CPU5: cpu@500 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_500>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -295,6 +307,8 @@ CPU6: cpu@600 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_600>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -315,6 +329,8 @@ CPU7: cpu@700 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			next-level-cache = <&L2_700>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			operating-points-v2 = <&cpu7_opp_table>;
 			interconnects = <&gem_noc MASTER_APPSS_PROC 3 &mc_virt SLAVE_EBI1 3>,
 					<&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>;

@@ -4915,8 +4931,6 @@ cpufreq_hw: cpufreq@18591000 {
 			reg = <0 0x18591000 0 0x1000>,
 			      <0 0x18592000 0 0x1000>,
 			      <0 0x18593000 0 0x1000>;
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
-			clock-names = "xo", "alternate";
 			#freq-domain-cells = <1>;
 		};
 	};
arch/arm64/boot/dts/qcom/sdm845.dtsi +16 -3
index 0692ae0e60a4..3154a8f67f76 100644
@@ -202,6 +202,8 @@ &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			capacity-dmips-mhz = <611>;
 			dynamic-power-coefficient = <290>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -227,6 +229,8 @@ &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			capacity-dmips-mhz = <611>;
 			dynamic-power-coefficient = <290>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -249,6 +253,8 @@ &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			capacity-dmips-mhz = <611>;
 			dynamic-power-coefficient = <290>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -271,6 +277,8 @@ &LITTLE_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			capacity-dmips-mhz = <611>;
 			dynamic-power-coefficient = <290>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -293,6 +301,8 @@ CPU4: cpu@400 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			dynamic-power-coefficient = <442>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -315,6 +325,8 @@ CPU5: cpu@500 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			dynamic-power-coefficient = <442>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -337,6 +349,8 @@ CPU6: cpu@600 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			dynamic-power-coefficient = <442>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -359,6 +373,8 @@ CPU7: cpu@700 {
 					   &BIG_CPU_SLEEP_1
 					   &CLUSTER_SLEEP_0>;
 			dynamic-power-coefficient = <442>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_EBI1 3>,

@@ -5022,9 +5038,6 @@ cpufreq_hw: cpufreq@17d43000 {
 
 			interrupts-extended = <&lmh_cluster0 0>, <&lmh_cluster1 0>;
 
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
-			clock-names = "xo", "alternate";
-
 			#freq-domain-cells = <1>;
 		};
arch/arm64/boot/dts/qcom/sm6350.dtsi +16 -2
index d4f8f33f3f0c..645fb73fdad2 100644
@@ -43,6 +43,8 @@ CPU0: cpu@0 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <100>;
 			next-level-cache = <&L2_0>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_0: l2-cache {

@@ -62,6 +64,8 @@ CPU1: cpu@100 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <100>;
 			next-level-cache = <&L2_100>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_100: l2-cache {

@@ -78,6 +82,8 @@ CPU2: cpu@200 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <100>;
 			next-level-cache = <&L2_200>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_200: l2-cache {

@@ -94,6 +100,8 @@ CPU3: cpu@300 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <100>;
 			next-level-cache = <&L2_300>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_300: l2-cache {

@@ -110,6 +118,8 @@ CPU4: cpu@400 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <100>;
 			next-level-cache = <&L2_400>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_400: l2-cache {

@@ -126,6 +136,8 @@ CPU5: cpu@500 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <100>;
 			next-level-cache = <&L2_500>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_500: l2-cache {

@@ -143,6 +155,8 @@ CPU6: cpu@600 {
 			capacity-dmips-mhz = <1894>;
 			dynamic-power-coefficient = <703>;
 			next-level-cache = <&L2_600>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			L2_600: l2-cache {

@@ -159,6 +173,8 @@ CPU7: cpu@700 {
 			capacity-dmips-mhz = <1894>;
 			dynamic-power-coefficient = <703>;
 			next-level-cache = <&L2_700>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			L2_700: l2-cache {

@@ -1462,8 +1478,6 @@ cpufreq_hw: cpufreq@18323000 {
 			compatible = "qcom,cpufreq-hw";
 			reg = <0 0x18323000 0 0x1000>, <0 0x18325800 0 0x1000>;
 			reg-names = "freq-domain0", "freq-domain1";
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
-			clock-names = "xo", "alternate";
 
 			#freq-domain-cells = <1>;
 		};
arch/arm64/boot/dts/qcom/sm8150.dtsi +16 -3
index 8ea44c4b56b4..bb38e36ae659 100644
@@ -51,6 +51,8 @@ CPU0: cpu@0 {
 			capacity-dmips-mhz = <488>;
 			dynamic-power-coefficient = <232>;
 			next-level-cache = <&L2_0>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -75,6 +77,8 @@ CPU1: cpu@100 {
 			capacity-dmips-mhz = <488>;
 			dynamic-power-coefficient = <232>;
 			next-level-cache = <&L2_100>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -97,6 +101,8 @@ CPU2: cpu@200 {
 			capacity-dmips-mhz = <488>;
 			dynamic-power-coefficient = <232>;
 			next-level-cache = <&L2_200>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -118,6 +124,8 @@ CPU3: cpu@300 {
 			capacity-dmips-mhz = <488>;
 			dynamic-power-coefficient = <232>;
 			next-level-cache = <&L2_300>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -139,6 +147,8 @@ CPU4: cpu@400 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <369>;
 			next-level-cache = <&L2_400>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -160,6 +170,8 @@ CPU5: cpu@500 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <369>;
 			next-level-cache = <&L2_500>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -181,6 +193,8 @@ CPU6: cpu@600 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <369>;
 			next-level-cache = <&L2_600>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -202,6 +216,8 @@ CPU7: cpu@700 {
 			capacity-dmips-mhz = <1024>;
 			dynamic-power-coefficient = <421>;
 			next-level-cache = <&L2_700>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 2>;
 			operating-points-v2 = <&cpu7_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -4102,9 +4118,6 @@ cpufreq_hw: cpufreq@18323000 {
 			reg-names = "freq-domain0", "freq-domain1",
 				    "freq-domain2";
 
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
-			clock-names = "xo", "alternate";
-
 			#freq-domain-cells = <1>;
 		};
arch/arm64/boot/dts/qcom/sm8250.dtsi +16 -2
index cf0c97bd5ad3..29c496e85dda 100644
@@ -101,6 +101,8 @@ CPU0: cpu@0 {
 			next-level-cache = <&L2_0>;
 			power-domains = <&CPU_PD0>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -125,6 +127,8 @@ CPU1: cpu@100 {
 			next-level-cache = <&L2_100>;
 			power-domains = <&CPU_PD1>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -146,6 +150,8 @@ CPU2: cpu@200 {
 			next-level-cache = <&L2_200>;
 			power-domains = <&CPU_PD2>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -167,6 +173,8 @@ CPU3: cpu@300 {
 			next-level-cache = <&L2_300>;
 			power-domains = <&CPU_PD3>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			operating-points-v2 = <&cpu0_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -188,6 +196,8 @@ CPU4: cpu@400 {
 			next-level-cache = <&L2_400>;
 			power-domains = <&CPU_PD4>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -209,6 +219,8 @@ CPU5: cpu@500 {
 			next-level-cache = <&L2_500>;
 			power-domains = <&CPU_PD5>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -231,6 +243,8 @@ CPU6: cpu@600 {
 			next-level-cache = <&L2_600>;
 			power-domains = <&CPU_PD6>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			operating-points-v2 = <&cpu4_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -252,6 +266,8 @@ CPU7: cpu@700 {
 			next-level-cache = <&L2_700>;
 			power-domains = <&CPU_PD7>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 2>;
 			operating-points-v2 = <&cpu7_opp_table>;
 			interconnects = <&gem_noc MASTER_AMPSS_M0 &mc_virt SLAVE_EBI_CH0>,

@@ -5020,8 +5036,6 @@ cpufreq_hw: cpufreq@18591000 {
 			reg-names = "freq-domain0", "freq-domain1",
 				    "freq-domain2";
 
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
-			clock-names = "xo", "alternate";
 			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
arch/arm64/boot/dts/qcom/sm8350.dtsi +16 -3
index 743cba9b683c..c7e9447f0388 100644
@@ -66,6 +66,8 @@ CPU0: cpu@0 {
 			reg = <0x0 0x0>;
 			enable-method = "psci";
 			next-level-cache = <&L2_0>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			power-domains = <&CPU_PD0>;
 			power-domain-names = "psci";

@@ -85,6 +87,8 @@ CPU1: cpu@100 {
 			reg = <0x0 0x100>;
 			enable-method = "psci";
 			next-level-cache = <&L2_100>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			power-domains = <&CPU_PD1>;
 			power-domain-names = "psci";

@@ -101,6 +105,8 @@ CPU2: cpu@200 {
 			reg = <0x0 0x200>;
 			enable-method = "psci";
 			next-level-cache = <&L2_200>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			power-domains = <&CPU_PD2>;
 			power-domain-names = "psci";

@@ -117,6 +123,8 @@ CPU3: cpu@300 {
 			reg = <0x0 0x300>;
 			enable-method = "psci";
 			next-level-cache = <&L2_300>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			power-domains = <&CPU_PD3>;
 			power-domain-names = "psci";

@@ -133,6 +141,8 @@ CPU4: cpu@400 {
 			reg = <0x0 0x400>;
 			enable-method = "psci";
 			next-level-cache = <&L2_400>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			power-domains = <&CPU_PD4>;
 			power-domain-names = "psci";

@@ -149,6 +159,8 @@ CPU5: cpu@500 {
 			reg = <0x0 0x500>;
 			enable-method = "psci";
 			next-level-cache = <&L2_500>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			power-domains = <&CPU_PD5>;
 			power-domain-names = "psci";

@@ -166,6 +178,8 @@ CPU6: cpu@600 {
 			reg = <0x0 0x600>;
 			enable-method = "psci";
 			next-level-cache = <&L2_600>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			power-domains = <&CPU_PD6>;
 			power-domain-names = "psci";

@@ -182,6 +196,8 @@ CPU7: cpu@700 {
 			reg = <0x0 0x700>;
 			enable-method = "psci";
 			next-level-cache = <&L2_700>;
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 2>;
 			power-domains = <&CPU_PD7>;
 			power-domain-names = "psci";

@@ -2074,9 +2090,6 @@ cpufreq_hw: cpufreq@18591000 {
 			      <0 0x18593000 0 0x1000>;
 			reg-names = "freq-domain0", "freq-domain1", "freq-domain2";
 
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
-			clock-names = "xo", "alternate";
-
 			#freq-domain-cells = <1>;
 		};
arch/arm64/boot/dts/qcom/sm8450.dtsi +16 -2
index 7d08fad76371..229cf5eb6447 100644
@@ -48,6 +48,8 @@ CPU0: cpu@0 {
 			next-level-cache = <&L2_0>;
 			power-domains = <&CPU_PD0>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_0: l2-cache {

@@ -67,6 +69,8 @@ CPU1: cpu@100 {
 			next-level-cache = <&L2_100>;
 			power-domains = <&CPU_PD1>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_100: l2-cache {

@@ -83,6 +87,8 @@ CPU2: cpu@200 {
 			next-level-cache = <&L2_200>;
 			power-domains = <&CPU_PD2>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_200: l2-cache {

@@ -99,6 +105,8 @@ CPU3: cpu@300 {
 			next-level-cache = <&L2_300>;
 			power-domains = <&CPU_PD3>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			L2_300: l2-cache {

@@ -115,6 +123,8 @@ CPU4: cpu@400 {
 			next-level-cache = <&L2_400>;
 			power-domains = <&CPU_PD4>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			L2_400: l2-cache {

@@ -131,6 +141,8 @@ CPU5: cpu@500 {
 			next-level-cache = <&L2_500>;
 			power-domains = <&CPU_PD5>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			L2_500: l2-cache {

@@ -148,6 +160,8 @@ CPU6: cpu@600 {
 			next-level-cache = <&L2_600>;
 			power-domains = <&CPU_PD6>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			L2_600: l2-cache {

@@ -164,6 +178,8 @@ CPU7: cpu@700 {
 			next-level-cache = <&L2_700>;
 			power-domains = <&CPU_PD7>;
 			power-domain-names = "psci";
+			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
+			clock-names = "xo", "alternate";
 			qcom,freq-domain = <&cpufreq_hw 2>;
 			#cooling-cells = <2>;
 			L2_700: l2-cache {

@@ -2998,8 +3014,6 @@ cpufreq_hw: cpufreq@17d91000 {
 			      <0 0x17d92000 0 0x1000>,
 			      <0 0x17d93000 0 0x1000>;
 			reg-names = "freq-domain0", "freq-domain1", "freq-domain2";
-			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
-			clock-names = "xo", "alternate";
 			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
Signature · 1 line
2.31.1.272.g89b43f80a514
author maintainer
#5 lore raw

RFC PATCH 3/4 cpufreq: qcom-cpufreq-hw: Clocks are moved to CPU nodes

In reply to Viresh Kumar

The clocks are not in the cpufreq-hw node anymore, and are moved to the respective CPU nodes. Make changes accordingly here.

Signed-off-by Viresh Kumar <[email protected]>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 43 +++++++++++++++++--------------
 1 file changed, 24 insertions(+), 19 deletions(-)
drivers/cpufreq/qcom-cpufreq-hw.c +24 -19
index 0253731d6d25..05fce4a559ca 100644
@@ -57,9 +57,10 @@ struct qcom_cpufreq_data {
 	struct cpufreq_policy *policy;
 
 	bool per_core_dcvs;
+	unsigned long cpu_hw_rate;
+	unsigned long xo_rate;
 };
 
-static unsigned long cpu_hw_rate, xo_rate;
 static bool icc_scaling_enabled;
 
 static int qcom_cpufreq_set_bw(struct cpufreq_policy *policy,

@@ -209,9 +210,9 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 		volt = FIELD_GET(LUT_VOLT, data) * 1000;
 
 		if (src)
-			freq = xo_rate * lval / 1000;
+			freq = drv_data->xo_rate * lval / 1000;
 		else
-			freq = cpu_hw_rate / 1000;
+			freq = drv_data->cpu_hw_rate / 1000;
 
 		if (freq != prev_freq && core_count != LUT_TURBO_IND) {
 			if (!qcom_cpufreq_update_opp(cpu_dev, freq, volt)) {

@@ -293,7 +294,7 @@ static unsigned long qcom_lmh_get_throttle_freq(struct qcom_cpufreq_data *data)
 	else
 		lval = readl_relaxed(data->base + data->soc_data->reg_domain_state) & 0xff;
 
-	return lval * xo_rate;
+	return lval * data->xo_rate;
 }
 
 static void qcom_lmh_dcvs_notify(struct qcom_cpufreq_data *data)

@@ -480,6 +481,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
 	struct device_node *cpu_np;
 	struct device *cpu_dev;
 	struct resource *res;
+	struct clk *clk;
 	void __iomem *base;
 	struct qcom_cpufreq_data *data;
 	int ret, index;

@@ -527,6 +529,24 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
 		goto unmap_base;
 	}
 
+	clk = clk_get(cpu_dev, "xo");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		goto error;
+	}
+
+	data->xo_rate = clk_get_rate(clk);
+	clk_put(clk);
+
+	clk = clk_get(cpu_dev, "alternate");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		goto error;
+	}
+
+	data->cpu_hw_rate = clk_get_rate(clk) / CLK_HW_DIV;
+	clk_put(clk);
+
 	data->soc_data = of_device_get_match_data(&pdev->dev);
 	data->base = base;
 	data->res = res;

@@ -637,23 +657,8 @@ static struct cpufreq_driver cpufreq_qcom_hw_driver = {
 static int qcom_cpufreq_hw_driver_probe(struct platform_device *pdev)
 {
 	struct device *cpu_dev;
-	struct clk *clk;
 	int ret;
 
-	clk = clk_get(&pdev->dev, "xo");
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
-
-	xo_rate = clk_get_rate(clk);
-	clk_put(clk);
-
-	clk = clk_get(&pdev->dev, "alternate");
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
-
-	cpu_hw_rate = clk_get_rate(clk) / CLK_HW_DIV;
-	clk_put(clk);
-
 	cpufreq_qcom_hw_driver.driver_data = pdev;
 
 	/* Check for optional interconnect paths on CPU0 */
Signature · 1 line
2.31.1.272.g89b43f80a514
author maintainer
#6 lore raw

RFC PATCH 4/4 cpufreq: qcom-cpufreq-hw: Register config_clks helper

In reply to Viresh Kumar

There is a corner case with Qcom, where we want to skip clk configuration that happens via dev_pm_opp_set_opp(), but still want the OPP core to read the "opp-hz" property so we can find the right OPP via freq finding helpers.

The OPP core provides support for the platforms to provide config_clks helpers now, lets use that to provide an empty callback to skip clock configuration.

The "table" wasn't getting freed properly on error, fix it as well which we are updating the code.

Signed-off-by Viresh Kumar <[email protected]>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 32 ++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)
drivers/cpufreq/qcom-cpufreq-hw.c +31 -1
index 05fce4a559ca..8d055a5f6575 100644
@@ -59,6 +59,7 @@ struct qcom_cpufreq_data {
 	bool per_core_dcvs;
 	unsigned long cpu_hw_rate;
 	unsigned long xo_rate;
+	int opp_token;
 };
 
 static bool icc_scaling_enabled;

@@ -162,6 +163,15 @@ static unsigned int qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
 	return policy->freq_table[index].frequency;
 }
 
+static int qcom_cpufreq_hw_config_clks_nop(struct device *dev,
+					   struct opp_table *opp_table,
+					   struct dev_pm_opp *opp, void *data,
+					   bool scaling_down)
+{
+	/* We want to skip clk configuration via dev_pm_opp_set_opp() */
+	return 0;
+}
+
 static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 				    struct cpufreq_policy *policy)
 {

@@ -173,11 +183,23 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 	int ret;
 	struct qcom_cpufreq_data *drv_data = policy->driver_data;
 	const struct qcom_cpufreq_soc_data *soc_data = drv_data->soc_data;
+	const char * const clk_names[] = { "xo", NULL };
+	struct dev_pm_opp_config config = {
+		.clk_names = clk_names,
+		.config_clks = qcom_cpufreq_hw_config_clks_nop,
+	};
 
 	table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
 	if (!table)
 		return -ENOMEM;
 
+	ret = dev_pm_opp_set_config(cpu_dev, &config);
+	if (ret < 0) {
+		dev_err(cpu_dev, "Failed to set OPP config: %d\n", ret);
+		goto free_table;
+	}
+	drv_data->opp_token = ret;
+
 	ret = dev_pm_opp_of_add_table(cpu_dev);
 	if (!ret) {
 		/* Disable all opps and cross-validate against LUT later */

@@ -192,7 +214,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 		}
 	} else if (ret != -ENODEV) {
 		dev_err(cpu_dev, "Invalid opp table in device tree\n");
-		return ret;
+		goto clear_config;
 	} else {
 		policy->fast_switch_possible = true;
 		icc_scaling_enabled = false;

@@ -260,6 +282,13 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 	dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
 
 	return 0;
+
+clear_config:
+	dev_pm_opp_clear_config(drv_data->opp_token);
+
+free_table:
+	kfree(table);
+	return ret;
 }
 
 static void qcom_get_related_cpus(int index, struct cpumask *m)

@@ -614,6 +643,7 @@ static int qcom_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
 	dev_pm_opp_remove_all_dynamic(cpu_dev);
 	dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
 	qcom_cpufreq_hw_lmh_exit(data);
+	dev_pm_opp_clear_config(data->opp_token);
 	kfree(policy->freq_table);
 	kfree(data);
 	iounmap(base);
Signature · 1 line
2.31.1.272.g89b43f80a514
#7 lore raw
In reply to Viresh Kumar
Quoted 26 lines · Viresh Kumar

Hi,

A recent patch series, targeting enhancements in the OPP core, ended up breaking cpufreq on some of the Qualcomm platforms [1]. Necessary adjustments are made in the OPP core, a bit hacky though, to get it working for now but it would be better to solve the problem at hand in a cleaner way. And this patchset is an attempt towards the same.

cpufreq-hw is a hardware engine, which takes care of frequency management for CPUs. The engine manages the clocks for CPU devices, but it isn't the end consumer of the clocks, which are the CPUs in this case.

For this reason, it looks incorrect to keep the clock related properties in the cpufreq-hw node. They should really be present at the end user, i.e. the CPUs.

The case was simple currently as all the devices, i.e. the CPUs, that the engine manages share the same clock names. What if the clock names are different for different CPUs or clusters ? How will keeping the clock properties in the cpufreq-hw node work in that case ?

This design creates further problems for frameworks like OPP, which expects all such details (clocks) to be present in the end device node itself, instead of another related node.

Quoted 7 lines

This patchset moves the clock properties to the node that uses them instead, i.e. the CPU nodes and makes necessary adjustments at other places.

After this is applied, I can drop the unnecessary change from the OPP core, but I wanted to discuss if this is a step in the right direction or not first and so the RFC.

The clocks defined in the devicetree currently (CXO, GPLL) are the source clocks of the EPSS block (cpufreq-hw). And EPSS will supply clock and voltage through other blocks to the CPU domains. Even though the end consumer of the source clocks are the CPUs, those clocks are not directly reachign the CPUs but instead through some other blocks in EPSS.

Initially I was temped to add cpufreq-hw as the clock provider and have it source clocks to the individual CPUs. This somehow models the clock topology also, but after having a discussion with Bjorn we concluded that it is best to leave it as it is.

The main issue that Bjorn pointed out was the fact that the clocks coming out of EPSS are not exactly of the same frequency that was requested. EPSS will do its own logic to generate the clocks to the CPUs based on the input frequency vote and limits.

Thanks,
Mani

Quoted 26 lines

--
Viresh

[1] https://lore.kernel.org/lkml/[email protected]/

Viresh Kumar (4):
dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes
arm64: dts: qcom: Move clocks to CPU nodes
cpufreq: qcom-cpufreq-hw: Clocks are moved to CPU nodes
cpufreq: qcom-cpufreq-hw: Register config_clks helper

 .../bindings/cpufreq/cpufreq-qcom-hw.yaml     | 31 ++++----
 arch/arm64/boot/dts/qcom/sc7180.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sc7280.dtsi          | 18 ++++-
 arch/arm64/boot/dts/qcom/sdm845.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sm6350.dtsi          | 18 ++++-
 arch/arm64/boot/dts/qcom/sm8150.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sm8250.dtsi          | 18 ++++-
 arch/arm64/boot/dts/qcom/sm8350.dtsi          | 19 ++++-
 arch/arm64/boot/dts/qcom/sm8450.dtsi          | 18 ++++-
 drivers/cpufreq/qcom-cpufreq-hw.c             | 75 ++++++++++++++-----
 10 files changed, 199 insertions(+), 55 deletions(-)
Signature · 1 line
2.31.1.272.g89b43f80a514
author maintainer
#8 lore raw
Quoted 5 lines · Manivannan Sadhasivam

The clocks defined in the devicetree currently (CXO, GPLL) are the source clocks of the EPSS block (cpufreq-hw). And EPSS will supply clock and voltage through other blocks to the CPU domains. Even though the end consumer of the source clocks are the CPUs, those clocks are not directly reachign the CPUs but instead through some other blocks in EPSS.

Fair enough, o these clocks should be present in the cpufreq-hw node, as there were.

Quoted 3 lines

Initially I was temped to add cpufreq-hw as the clock provider and have it source clocks to the individual CPUs. This somehow models the clock topology also

Right.

Quoted 7 lines

, but after having a discussion with Bjorn we concluded that it is best to leave it as it is.

The main issue that Bjorn pointed out was the fact that the clocks coming out of EPSS are not exactly of the same frequency that was requested. EPSS will do its own logic to generate the clocks to the CPUs based on the input frequency vote and limits.

The OPP tables, which are part of the CPU nodes, mentions clock rates. Are these values for the cxo/gpll clocks or the clock that reaches the CPUs? I believe the latter. The DT is not really complete if the CPU node mentions the frequency, but not the source clock. It works for you because you don't want to do clk_set_rate() in this case, but then it leaves other frameworks, like OPP, confused and rightly so.

Normally, there is always a difference in what the OPP table contains as frequency value and what the hardware programs, mostly it is small though. It shouldn't prevent us from having the hierarchy clearly defined in the DT.

Based on your description, I think it would be better to make cpufreq-hw a clock provider and CPUs the consumer of it. It would then allow the OPP core to not carry the hack to make it all work.

Signature · 1 line
viresh
author maintainer
#9 lore raw
Quoted 7 lines · Viresh Kumar

The OPP tables, which are part of the CPU nodes, mentions clock rates. Are these values for the cxo/gpll clocks or the clock that reaches the CPUs? I believe the latter. The DT is not really complete if the CPU node mentions the frequency, but not the source clock. It works for you because you don't want to do clk_set_rate() in this case, but then it leaves other frameworks, like OPP, confused and rightly so.

Quoted 8 lines

Normally, there is always a difference in what the OPP table contains as frequency value and what the hardware programs, mostly it is small though. It shouldn't prevent us from having the hierarchy clearly defined in the DT.

Based on your description, I think it would be better to make cpufreq-hw a clock provider and CPUs the consumer of it. It would then allow the OPP core to not carry the hack to make it all work.

Bjorn / Mani,

Can we please get this sorted out ? I don't want to carry an unnecessary hack in the OPP core for this.

Signature · 1 line
viresh
#10 lore raw
Quoted 13 lines · Viresh Kumar
Quoted 12 lines · Viresh Kumar

The OPP tables, which are part of the CPU nodes, mentions clock rates. Are these values for the cxo/gpll clocks or the clock that reaches the CPUs? I believe the latter. The DT is not really complete if the CPU node mentions the frequency, but not the source clock. It works for you because you don't want to do clk_set_rate() in this case, but then it leaves other frameworks, like OPP, confused and rightly so.

Normally, there is always a difference in what the OPP table contains as frequency value and what the hardware programs, mostly it is small though. It shouldn't prevent us from having the hierarchy clearly defined in the DT.

Quoted 9 lines
Quoted 3 lines

Based on your description, I think it would be better to make cpufreq-hw a clock provider and CPUs the consumer of it. It would then allow the OPP core to not carry the hack to make it all work.

Bjorn / Mani,

Can we please get this sorted out ? I don't want to carry an unnecessary hack in the OPP core for this.

I'm waiting for inputs from Bjorn.

@Bjorn: What do you think of the proposal to add qcom-cpufreq-hw as the clk provider for CPUs?

Thanks,
Mani

Quoted 2 lines
Signature · 1 line
viresh
Signature · 1 line
மணிவண்ணன் சதாசிவம்
maintainer
#11 lore raw
In reply to Viresh Kumar
Quoted 13 lines · Viresh Kumar
Quoted 12 lines · Viresh Kumar

The OPP tables, which are part of the CPU nodes, mentions clock rates. Are these values for the cxo/gpll clocks or the clock that reaches the CPUs? I believe the latter. The DT is not really complete if the CPU node mentions the frequency, but not the source clock. It works for you because you don't want to do clk_set_rate() in this case, but then it leaves other frameworks, like OPP, confused and rightly so.

Normally, there is always a difference in what the OPP table contains as frequency value and what the hardware programs, mostly it is small though. It shouldn't prevent us from having the hierarchy clearly defined in the DT.

Quoted 9 lines
Quoted 3 lines

Based on your description, I think it would be better to make cpufreq-hw a clock provider and CPUs the consumer of it. It would then allow the OPP core to not carry the hack to make it all work.

Bjorn / Mani,

Can we please get this sorted out ? I don't want to carry an unnecessary hack in the OPP core for this.

Conceptually, it sounds like a good idea to express the clock feeding the CPU clusters, which is controlled by the OSM/EPSS. But do you expect the OPP framework to actually do something with the clock, or just to ensure that the relationship is properly described?

FWIW, the possible discrepancy between the requested frequency and the actual frequency comes from the fact that OSM/EPSS throttles the cluster frequency based on a number of different factors (thermal, voltages ...).
This is reported back to the kernel using the thermal pressure interface. It would be quite interesting to see some investigation in how efficient the kernel is at making use of this feedback.

Regards,
Bjorn

author maintainer
#12 lore raw
Quoted 4 lines · Bjorn Andersson

Conceptually, it sounds like a good idea to express the clock feeding the CPU clusters, which is controlled by the OSM/EPSS. But do you expect the OPP framework to actually do something with the clock, or just to ensure that the relationship is properly described?

No, the OPP core will never try to set the clock rate in your case, though it will do clk_get().

Quoted 7 lines

FWIW, the possible discrepancy between the requested frequency and the actual frequency comes from the fact that OSM/EPSS throttles the cluster frequency based on a number of different factors (thermal, voltages ...).
This is reported back to the kernel using the thermal pressure interface. It would be quite interesting to see some investigation in how efficient the kernel is at making use of this feedback.

Signature · 1 line
viresh
#13 lore raw
Quoted 9 lines · Viresh Kumar
Quoted 4 lines · Bjorn Andersson

Conceptually, it sounds like a good idea to express the clock feeding the CPU clusters, which is controlled by the OSM/EPSS. But do you expect the OPP framework to actually do something with the clock, or just to ensure that the relationship is properly described?

No, the OPP core will never try to set the clock rate in your case, though it will do clk_get().

Okay. Then I think it is a fair argument to make qcom-cpufreq-hw as the clock provider for CPUs.

I will send the RFC soon.

Thanks,
Mani

Quoted 10 lines
Quoted 7 lines

FWIW, the possible discrepancy between the requested frequency and the actual frequency comes from the fact that OSM/EPSS throttles the cluster frequency based on a number of different factors (thermal, voltages ...).
This is reported back to the kernel using the thermal pressure interface. It would be quite interesting to see some investigation in how efficient the kernel is at making use of this feedback.

Signature · 1 line
viresh
author maintainer
#14 lore raw
Quoted 7 lines · Manivannan Sadhasivam
Quoted 6 lines · Viresh Kumar
Quoted 4 lines · Bjorn Andersson

Conceptually, it sounds like a good idea to express the clock feeding the CPU clusters, which is controlled by the OSM/EPSS. But do you expect the OPP framework to actually do something with the clock, or just to ensure that the relationship is properly described?

Quoted 8 lines
Quoted 3 lines

No, the OPP core will never try to set the clock rate in your case, though it will do clk_get().

Okay. Then I think it is a fair argument to make qcom-cpufreq-hw as the clock provider for CPUs.

I will send the RFC soon.

Ping.

Signature · 1 line
viresh
#15 lore raw
Quoted 12 lines · Viresh Kumar
Quoted 11 lines · Manivannan Sadhasivam
Quoted 9 lines · Viresh Kumar
Quoted 4 lines · Bjorn Andersson

Conceptually, it sounds like a good idea to express the clock feeding the CPU clusters, which is controlled by the OSM/EPSS. But do you expect the OPP framework to actually do something with the clock, or just to ensure that the relationship is properly described?

No, the OPP core will never try to set the clock rate in your case, though it will do clk_get().

Quoted 7 lines
Quoted 4 lines

Okay. Then I think it is a fair argument to make qcom-cpufreq-hw as the clock provider for CPUs.

I will send the RFC soon.

Ping.

Didn't get time so far. Will get to this once I'm back from vacation.

Thanks,
Mani

Quoted 2 lines
Signature · 1 line
viresh
Signature · 1 line
மணிவண்ணன் சதாசிவம்