On Tue, 2 Apr 2024 at 13:10, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
On Thu, Mar 28, 2024 at 03:20:44PM +0530, Sibi Sankar wrote:
Enable cpufreq on X1E80100 SoCs through the SCMI perf protocol node.
Signed-off-by: Sibi Sankar <quic_sibis@xxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 27 ++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 4e0ec859ed61..d1d232cd1f25 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -68,6 +68,7 @@ CPU0: cpu@0 {
compatible = "qcom,oryon";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
next-level-cache = <&L2_0>;
power-domains = <&CPU_PD0>;
power-domain-names = "psci";
Any reason why you wouldn't want to use the new genpd based perf controls.
IIRC it was added based on mainly Qcom platform requirements.
- clocks = <&scmi_dvfs 0>;
next-level-cache = <&L2_0>;
- power-domains = <&CPU_PD0>;
- power-domain-names = "psci";
+ power-domains = <&CPU_PD0>, <&scmi_dvfs 0>;
+ power-domain-names = "psci", "perf";
And the associated changes in the scmi dvfs node for cells property.
This change is OK but just wanted to check the reasoning for the choice.
To me, it seems reasonable to move to the new binding with
#power-domain-cells for protocol@13. This becomes more future proof,
as it can then easily be extended to be used beyond CPUs.
That said, I just submitted a patch [1] to update the examples in the
scmi DT doc to use #power-domain-cells in favor of #clock-cells. I
don't know if there is a better way to promote the new bindings?
Perhaps moving Juno to use this too?
Kind regards
Uffe
[1]
https://lore.kernel.org/all/20240403111106.1110940-1-ulf.hansson@xxxxxxxxxx/