From: Shivnandan Kumar <quic_kshivnan@quicinc.com>
Add OPP tables required to scale DDR and L3 per freq-domain
on SA8775P platform.
Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com>
Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
---
arch/arm64/boot/dts/qcom/sa8775p.dtsi | 178 ++++++++++++++++++++++++++++++++++
1 file changed, 178 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
index d8b90bd4b1f05604185f015929a1f296799ad6a4..47eca50b30ffa38a652706014d35ef9e833003ec 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
@@ -48,6 +48,7 @@ CPU0: cpu@0 {
next-level-cache = <&L2_0>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu0_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl0 MASTER_EPSS_L3_APPS
@@ -74,6 +75,7 @@ CPU1: cpu@100 {
next-level-cache = <&L2_1>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu0_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl0 MASTER_EPSS_L3_APPS
@@ -95,6 +97,7 @@ CPU2: cpu@200 {
next-level-cache = <&L2_2>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu0_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl0 MASTER_EPSS_L3_APPS
@@ -116,6 +119,7 @@ CPU3: cpu@300 {
next-level-cache = <&L2_3>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu0_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl0 MASTER_EPSS_L3_APPS
@@ -137,6 +141,7 @@ CPU4: cpu@10000 {
next-level-cache = <&L2_4>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu4_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl1 MASTER_EPSS_L3_APPS
@@ -164,6 +169,7 @@ CPU5: cpu@10100 {
next-level-cache = <&L2_5>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu4_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl1 MASTER_EPSS_L3_APPS
@@ -185,6 +191,7 @@ CPU6: cpu@10200 {
next-level-cache = <&L2_6>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu4_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl1 MASTER_EPSS_L3_APPS
@@ -206,6 +213,7 @@ CPU7: cpu@10300 {
next-level-cache = <&L2_7>;
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
+ operating-points-v2 = <&cpu4_opp_table>;
interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
<&epss_l3_cl1 MASTER_EPSS_L3_APPS
@@ -299,6 +307,176 @@ CLUSTER_SLEEP_APSS_RSC_PC: cluster-sleep-1 {
};
};
+ cpu0_opp_table: opp-table-cpu0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ cpu0_opp_1267mhz: opp-1267200000 {
+ opp-hz = /bits/ 64 <1267200000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu0_opp_1363mhz: opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu0_opp_1459mhz: opp-1459200000 {
+ opp-hz = /bits/ 64 <1459200000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu0_opp_1536mhz: opp-1536000000 {
+ opp-hz = /bits/ 64 <1536000000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu0_opp_1632mhz: opp-1632000000 {
+ opp-hz = /bits/ 64 <1632000000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu0_opp_1708mhz: opp-1708800000 {
+ opp-hz = /bits/ 64 <1708800000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu0_opp_1785mhz: opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu0_opp_1862mhz: opp-1862400000 {
+ opp-hz = /bits/ 64 <1862400000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu0_opp_1939mhz: opp-1939200000 {
+ opp-hz = /bits/ 64 <1939200000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu0_opp_2016mhz: opp-2016000000 {
+ opp-hz = /bits/ 64 <2016000000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu0_opp_2112mhz: opp-2112000000 {
+ opp-hz = /bits/ 64 <2112000000>;
+ opp-peak-kBps = <8371200 49766400>;
+ };
+
+ cpu0_opp_2188mhz: opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-peak-kBps = <8371200 49766400>;
+ };
+
+ cpu0_opp_2265mhz: opp-2265600000 {
+ opp-hz = /bits/ 64 <2265600000>;
+ opp-peak-kBps = <8371200 49766400>;
+ };
+
+ cpu0_opp_2361mhz: opp-2361600000 {
+ opp-hz = /bits/ 64 <2361600000>;
+ opp-peak-kBps = <12787200 51609600>;
+ };
+
+ cpu0_opp_2457mhz: opp-2457600000 {
+ opp-hz = /bits/ 64 <2457600000>;
+ opp-peak-kBps = <12787200 51609600>;
+ };
+
+ cpu0_opp_2553mhz: opp-2553600000 {
+ opp-hz = /bits/ 64 <2553600000>;
+ opp-peak-kBps = <12787200 54681600>;
+ };
+ };
+
+ cpu4_opp_table: opp-table-cpu4 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ cpu4_opp_1267mhz: opp-1267200000 {
+ opp-hz = /bits/ 64 <1267200000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu4_opp_1363mhz: opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu4_opp_1459mhz: opp-1459200000 {
+ opp-hz = /bits/ 64 <1459200000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu4_opp_1536mhz: opp-1536000000 {
+ opp-hz = /bits/ 64 <1536000000>;
+ opp-peak-kBps = <6220800 29491200>;
+ };
+
+ cpu4_opp_1632mhz: opp-1632000000 {
+ opp-hz = /bits/ 64 <1632000000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu4_opp_1708mhz: opp-1708800000 {
+ opp-hz = /bits/ 64 <1708800000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu4_opp_1785mhz: opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu4_opp_1862mhz: opp-1862400000 {
+ opp-hz = /bits/ 64 <1862400000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu4_opp_1939mhz: opp-1939200000 {
+ opp-hz = /bits/ 64 <1939200000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu4_opp_2016mhz: opp-2016000000 {
+ opp-hz = /bits/ 64 <2016000000>;
+ opp-peak-kBps = <6835200 39321600>;
+ };
+
+ cpu4_opp_2112mhz: opp-2112000000 {
+ opp-hz = /bits/ 64 <2112000000>;
+ opp-peak-kBps = <8371200 49766400>;
+ };
+
+ cpu4_opp_2188mhz: opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-peak-kBps = <8371200 49766400>;
+ };
+
+ cpu4_opp_2265mhz: opp-2265600000 {
+ opp-hz = /bits/ 64 <2265600000>;
+ opp-peak-kBps = <8371200 49766400>;
+ };
+
+ cpu4_opp_2361mhz: opp-2361600000 {
+ opp-hz = /bits/ 64 <2361600000>;
+ opp-peak-kBps = <12787200 51609600>;
+ };
+
+ cpu4_opp_2457mhz: opp-2457600000 {
+ opp-hz = /bits/ 64 <2457600000>;
+ opp-peak-kBps = <12787200 51609600>;
+ };
+
+ cpu4_opp_2553mhz: opp-2553600000 {
+ opp-hz = /bits/ 64 <2553600000>;
+ opp-peak-kBps = <12787200 54681600>;
+ };
+ };
+
dummy-sink {
compatible = "arm,coresight-dummy-sink";
--
2.34.1On Thu, Oct 17, 2024 at 02:58:31PM +0530, Jagadeesh Kona wrote:
> + cpu0_opp_table: opp-table-cpu0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + cpu0_opp_1267mhz: opp-1267200000 {
> + opp-hz = /bits/ 64 <1267200000>;
> + opp-peak-kBps = <6220800 29491200>;
> + };
> +
> + cpu0_opp_1363mhz: opp-1363200000 {
> + opp-hz = /bits/ 64 <1363200000>;
> + opp-peak-kBps = <6220800 29491200>;
> + };
[snip]
> + cpu4_opp_table: opp-table-cpu4 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + cpu4_opp_1267mhz: opp-1267200000 {
> + opp-hz = /bits/ 64 <1267200000>;
> + opp-peak-kBps = <6220800 29491200>;
> + };
> +
> + cpu4_opp_1363mhz: opp-1363200000 {
> + opp-hz = /bits/ 64 <1363200000>;
> + opp-peak-kBps = <6220800 29491200>;
> + };
There's no functional differences in the cpu0 and cpu4 opp tables. Can
a single table be used?
This aligns with my recollection that this particular SoC only has the
gold cores.
Brian
On 10/17/2024 9:12 PM, Brian Masney wrote:
> On Thu, Oct 17, 2024 at 02:58:31PM +0530, Jagadeesh Kona wrote:
>> + cpu0_opp_table: opp-table-cpu0 {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + cpu0_opp_1267mhz: opp-1267200000 {
>> + opp-hz = /bits/ 64 <1267200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>> +
>> + cpu0_opp_1363mhz: opp-1363200000 {
>> + opp-hz = /bits/ 64 <1363200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>
> [snip]
>
>> + cpu4_opp_table: opp-table-cpu4 {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + cpu4_opp_1267mhz: opp-1267200000 {
>> + opp-hz = /bits/ 64 <1267200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>> +
>> + cpu4_opp_1363mhz: opp-1363200000 {
>> + opp-hz = /bits/ 64 <1363200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>
> There's no functional differences in the cpu0 and cpu4 opp tables. Can
> a single table be used?
>
> This aligns with my recollection that this particular SoC only has the
> gold cores.
>
> Brian
>
Thanks Brian for your review. Sorry for the delayed response.
We require separate OPP tables for CPU0 and CPU4 to allow independent
scaling of DDR and L3 frequencies for each CPU domain, with the final
DDR and L3 frequencies being an aggregate of both.
If we use a single OPP table for both CPU domains, then _allocate_opp_table() [1]
won't be invoked for CPU4. As a result both CPU devices will end up in sharing
the same ICC path handle, which could lead to one CPU device overwriting the bandwidth
votes of other.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/opp/core.c#n1588
Thanks,
Jagadeesh
On Mon, Nov 11, 2024 at 06:39:48PM +0530, Jagadeesh Kona wrote:
>
>
> On 10/17/2024 9:12 PM, Brian Masney wrote:
> > On Thu, Oct 17, 2024 at 02:58:31PM +0530, Jagadeesh Kona wrote:
> >> + cpu0_opp_table: opp-table-cpu0 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + cpu0_opp_1267mhz: opp-1267200000 {
> >> + opp-hz = /bits/ 64 <1267200000>;
> >> + opp-peak-kBps = <6220800 29491200>;
> >> + };
> >> +
> >> + cpu0_opp_1363mhz: opp-1363200000 {
> >> + opp-hz = /bits/ 64 <1363200000>;
> >> + opp-peak-kBps = <6220800 29491200>;
> >> + };
> >
> > [snip]
> >
> >> + cpu4_opp_table: opp-table-cpu4 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + cpu4_opp_1267mhz: opp-1267200000 {
> >> + opp-hz = /bits/ 64 <1267200000>;
> >> + opp-peak-kBps = <6220800 29491200>;
> >> + };
> >> +
> >> + cpu4_opp_1363mhz: opp-1363200000 {
> >> + opp-hz = /bits/ 64 <1363200000>;
> >> + opp-peak-kBps = <6220800 29491200>;
> >> + };
> >
> > There's no functional differences in the cpu0 and cpu4 opp tables. Can
> > a single table be used?
> >
> > This aligns with my recollection that this particular SoC only has the
> > gold cores.
> >
> > Brian
> >
>
> Thanks Brian for your review. Sorry for the delayed response.
>
> We require separate OPP tables for CPU0 and CPU4 to allow independent
> scaling of DDR and L3 frequencies for each CPU domain, with the final
> DDR and L3 frequencies being an aggregate of both.
>
> If we use a single OPP table for both CPU domains, then _allocate_opp_table() [1]
> won't be invoked for CPU4. As a result both CPU devices will end up in sharing
> the same ICC path handle, which could lead to one CPU device overwriting the bandwidth
> votes of other.
All of this should be a part of the commit message.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/opp/core.c#n1588
>
> Thanks,
> Jagadeesh
>
--
With best wishes
Dmitry
© 2016 - 2024 Red Hat, Inc.