Add a node for the a7pll with its frequencies. With this we can use the
apcs-kpss-global driver for the apcs node and use the apcs to scale the
CPU frequency according to the opp-table.
At the same time unfortunately we need to provide the gcc node xo_board
instead of the XO via rpmcc since otherwise we'll have a circular
dependency between apcs, gcc and the rpm.
Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
arch/arm/boot/dts/qcom/qcom-msm8226.dtsi | 103 ++++++++++++++++++++++++++++++-
1 file changed, 100 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
index 270973e85625..6e9fbe2e7223 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8226.dtsi
@@ -44,6 +44,8 @@ CPU0: cpu@0 {
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
+ clocks = <&apcs>;
+ operating-points-v2 = <&cpu_opp_table>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
};
@@ -54,6 +56,8 @@ CPU1: cpu@1 {
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
+ clocks = <&apcs>;
+ operating-points-v2 = <&cpu_opp_table>;
qcom,acc = <&acc1>;
qcom,saw = <&saw1>;
};
@@ -64,6 +68,8 @@ CPU2: cpu@2 {
device_type = "cpu";
reg = <2>;
next-level-cache = <&L2>;
+ clocks = <&apcs>;
+ operating-points-v2 = <&cpu_opp_table>;
qcom,acc = <&acc2>;
qcom,saw = <&saw2>;
};
@@ -74,6 +80,8 @@ CPU3: cpu@3 {
device_type = "cpu";
reg = <3>;
next-level-cache = <&L2>;
+ clocks = <&apcs>;
+ operating-points-v2 = <&cpu_opp_table>;
qcom,acc = <&acc3>;
qcom,saw = <&saw3>;
};
@@ -98,6 +106,29 @@ memory@0 {
reg = <0x0 0x0>;
};
+ cpu_opp_table: opp-table-cpu {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ };
+
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ };
+
+ opp-787200000 {
+ opp-hz = /bits/ 64 <787200000>;
+ };
+
+ /* Higher CPU frequencies need speedbin support */
+ };
+
pmu {
compatible = "arm,cortex-a7-pmu";
interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) |
@@ -231,9 +262,75 @@ intc: interrupt-controller@f9000000 {
#interrupt-cells = <3>;
};
- apcs: syscon@f9011000 {
- compatible = "syscon";
+ apcs: mailbox@f9011000 {
+ compatible = "qcom,msm8226-apcs-kpss-global",
+ "qcom,msm8916-apcs-kpss-global", "syscon";
reg = <0xf9011000 0x1000>;
+ #mbox-cells = <1>;
+ clocks = <&a7pll>, <&gcc GPLL0_VOTE>;
+ clock-names = "pll", "aux";
+ #clock-cells = <0>;
+ };
+
+ a7pll: clock@f9016000 {
+ compatible = "qcom,msm8226-a7pll";
+ reg = <0xf9016000 0x40>;
+ #clock-cells = <0>;
+ clocks = <&xo_board>;
+ clock-names = "xo";
+ operating-points-v2 = <&a7pll_opp_table>;
+
+ a7pll_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-768000000 {
+ opp-hz = /bits/ 64 <768000000>;
+ };
+
+ opp-787200000 {
+ opp-hz = /bits/ 64 <787200000>;
+ };
+
+ opp-998400000 {
+ opp-hz = /bits/ 64 <998400000>;
+ };
+
+ opp-1094400000 {
+ opp-hz = /bits/ 64 <1094400000>;
+ };
+
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ };
+
+ opp-1305600000 {
+ opp-hz = /bits/ 64 <1305600000>;
+ };
+
+ opp-1344000000 {
+ opp-hz = /bits/ 64 <1344000000>;
+ };
+
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ };
+
+ opp-1497600000 {
+ opp-hz = /bits/ 64 <1497600000>;
+ };
+
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ };
+
+ opp-1689600000 {
+ opp-hz = /bits/ 64 <1689600000>;
+ };
+
+ opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ };
+ };
};
saw_l2: power-manager@f9012000 {
@@ -571,7 +668,7 @@ gcc: clock-controller@fc400000 {
#reset-cells = <1>;
#power-domain-cells = <1>;
- clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ clocks = <&xo_board>,
<&sleep_clk>;
clock-names = "xo",
"sleep_clk";
--
2.45.2On 19.06.2024 11:02 PM, Luca Weiss wrote:
> Add a node for the a7pll with its frequencies. With this we can use the
> apcs-kpss-global driver for the apcs node and use the apcs to scale the
> CPU frequency according to the opp-table.
>
> At the same time unfortunately we need to provide the gcc node xo_board
> instead of the XO via rpmcc since otherwise we'll have a circular
> dependency between apcs, gcc and the rpm.
Hm.. thinking of a solution to that, should we maybe split the mux/clk
part of APCS into a subnode and bind the clk device to that?
Dmitry, Bjorn, thoughts?
[...]
> +
> + opp-600000000 {
Can't find this one in the random msm-3.10 I have
> + opp-hz = /bits/ 64 <600000000>;
> + };
> +
> + opp-787200000 {
> + opp-hz = /bits/ 64 <787200000>;
> + };
> +
> + /* Higher CPU frequencies need speedbin support */
1190400 kHz seems to also be a supported-across-the-board one.. unless the
watch edition shuffled things around with a newer tree
> + };
> +
> pmu {
> compatible = "arm,cortex-a7-pmu";
> interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) |
> @@ -231,9 +262,75 @@ intc: interrupt-controller@f9000000 {
> #interrupt-cells = <3>;
> };
>
> - apcs: syscon@f9011000 {
> - compatible = "syscon";
> + apcs: mailbox@f9011000 {
> + compatible = "qcom,msm8226-apcs-kpss-global",
> + "qcom,msm8916-apcs-kpss-global", "syscon";
> reg = <0xf9011000 0x1000>;
> + #mbox-cells = <1>;
> + clocks = <&a7pll>, <&gcc GPLL0_VOTE>;
> + clock-names = "pll", "aux";
> + #clock-cells = <0>;
> + };
> +
> + a7pll: clock@f9016000 {
> + compatible = "qcom,msm8226-a7pll";
> + reg = <0xf9016000 0x40>;
> + #clock-cells = <0>;
> + clocks = <&xo_board>;
> + clock-names = "xo";
> + operating-points-v2 = <&a7pll_opp_table>;
> +
> + a7pll_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-768000000 {
> + opp-hz = /bits/ 64 <768000000>;
> + };
Looks like scaling this PLL should also scale some voltage domains:
CPR (fed by pm8226_s2) and MX
Perhaps hook up MX to this one for now and add CPR to the CPU nodes( & OPP table)
after that is brought up
Konrad
On Wed, Jun 19, 2024 at 11:02:49PM GMT, Luca Weiss wrote: > Add a node for the a7pll with its frequencies. With this we can use the > apcs-kpss-global driver for the apcs node and use the apcs to scale the > CPU frequency according to the opp-table. > > At the same time unfortunately we need to provide the gcc node xo_board > instead of the XO via rpmcc since otherwise we'll have a circular > dependency between apcs, gcc and the rpm. But it should be fine, isn't it? Clock controllers can handle orphaned clocks. The xo_board is really a hack and should eventually be removed. > > Signed-off-by: Luca Weiss <luca@lucaweiss.eu> > --- -- With best wishes Dmitry
On Donnerstag, 20. Juni 2024 22:54:37 MESZ Dmitry Baryshkov wrote: > On Wed, Jun 19, 2024 at 11:02:49PM GMT, Luca Weiss wrote: > > Add a node for the a7pll with its frequencies. With this we can use the > > apcs-kpss-global driver for the apcs node and use the apcs to scale the > > CPU frequency according to the opp-table. > > > > At the same time unfortunately we need to provide the gcc node xo_board > > instead of the XO via rpmcc since otherwise we'll have a circular > > dependency between apcs, gcc and the rpm. > > But it should be fine, isn't it? Clock controllers can handle orphaned > clocks. > > The xo_board is really a hack and should eventually be removed. I can check again what happened but pretty sure there were some issues with this still being rpmcc. But there were also some clock issues with apcs-as-syscon usage (that's the main reason for my influx of patches regarding this topic), so maybe with the apcs one solved that one's also fine. I'll check again! > > > > > Signed-off-by: Luca Weiss <luca@lucaweiss.eu> > > --- > >
© 2016 - 2026 Red Hat, Inc.