| Message ID | 20240619-msm8226-cpufreq-v1-5-85143f5291d1@lucaweiss.eu (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add CPU frequency scaling support for MSM8226 | expand |
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> > ---
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> > > --- > >
On 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
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";
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(-)