arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite
Subsystems (4)
PATCH 1/2 arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC since the gold cores only support frequencies upto 2.1 GHz.
--- arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi new file +14 -0
@@ -0,0 +1,14 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * SC7180 lite device tree source + * + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ + +&cpu6_opp11 { + opp-peak-kBps = <8532000 22425600>; +}; + +&cpu6_opp12 { + opp-peak-kBps = <8532000 23347200>; +};
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH 2/2 arm64: dts: qcom: sc7180: Add DDR/L3 votes for the pro variant
Add DDR/L3 bandwidth votes for the pro variant of SC7180 SoC, as it support frequencies upto 2.5 GHz.
--- arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm64/boot/dts/qcom/sc7180.dtsi +5 -0
@@ -525,6 +525,11 @@ opp-hz = /bits/ 64 <2400000000>; opp-peak-kBps = <8532000 23347200>; }; + + cpu6_opp16: opp-2553600000 { + opp-hz = /bits/ 64 <2553600000>; + opp-peak-kBps = <8532000 23347200>; + }; }; memory@80000000 {
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Hi,
Quoted 20 lines · Sibi Sankar
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC since the gold cores only support frequencies upto 2.1 GHz.
Signed-off-by Sibi Sankar <[email protected]>--- arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sc7180-lite.dtsiarch/arm64/boot/dts/qcom/sc7180-lite.dtsi new file +4
-0@@ -0,0 +1,14 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * SC7180 lite device tree source + *
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi line 14
Quoted 10 lines
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi new file +10
-0+ * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ + +&cpu6_opp11 { + opp-peak-kBps = <8532000 22425600>; +}; + +&cpu6_opp12 { + opp-peak-kBps = <8532000 23347200>; +};
I guess this is OK, but something about it smells just a little strange... I guess:
a) There's suddenly a big jump from opp10 to opp11. You don't use 7216000 at all anymore.
b) The fact that we need to do this at all feels like a sign that somehow this wasn't designed quite right.
Just brainstorming a bit: If the higher memory rate wasn't useful for OPP11/12 on the non-lite version of the chip, why are they useful for that OPP on the lite version? I guess you're just trying to eek out the last little bits of performance once the cpufreq is maxed out? It almost feels like a better way to do this (though it wouldn't be monotonically increasing anymore so it wouldn't actually work) would be to have a few "OPP" points at the top where the cpufreq stops increasing and all you do is increase the memory frequency.
c) In theory we're supposed to be able to probe whether we're on the normal, lite, or pro version, right? Anyway we could tweak this in code so we don't have to know to include the right dtsi file?
-Doug
Quoted 40 lines · Doug Anderson
Hi,
Quoted 20 lines · Sibi Sankar
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC since the gold cores only support frequencies upto 2.1 GHz.
Signed-off-by Sibi Sankar <[email protected]>--- arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sc7180-lite.dtsiarch/arm64/boot/dts/qcom/sc7180-lite.dtsi new file +4
-0@@ -0,0 +1,14 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * SC7180 lite device tree source + *arch/arm64/boot/dts/qcom/sc7180-lite.dtsi line 14
Quoted 10 lines
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi new file +10
-0+ * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ + +&cpu6_opp11 { + opp-peak-kBps = <8532000 22425600>; +}; + +&cpu6_opp12 { + opp-peak-kBps = <8532000 23347200>; +};I guess this is OK, but something about it smells just a little strange... I guess:
a) There's suddenly a big jump from opp10 to opp11. You don't use 7216000 at all anymore.
Quoted 7 lines
b) The fact that we need to do this at all feels like a sign that somehow this wasn't designed quite right.
Just brainstorming a bit: If the higher memory rate wasn't useful for OPP11/12 on the non-lite version of the chip, why are they useful for that OPP on the lite version? I guess you're just trying to eek out the last little bits of performance once the cpufreq is maxed out? It
Doug,
Really sorry about the delayed response, running power tests and getting some fuse info took longer than expected. Yes the mapping table as expected is a trade off between power/perf and it has been determined that lite version would meet the power numbers even with the high memory votes
at lower freqs.
1900800000 --> opp-peak-kBps = <7216000 22425600>; 1996800000 --> opp-peak-kBps = <7216000 22425600>; 2112000000 --> opp-peak-kBps = <8532000 23347200>;
^^ is the new recommendation from the perf/power QC teams for lite and is expected to have better power numbers with similar perf.
Quoted 8 lines
almost feels like a better way to do this (though it wouldn't be monotonically increasing anymore so it wouldn't actually work) would be to have a few "OPP" points at the top where the cpufreq stops increasing and all you do is increase the memory frequency.
c) In theory we're supposed to be able to probe whether we're on the normal, lite, or pro version, right? Anyway we could tweak this in code so we don't have to know to include the right dtsi file?
Yes we can determine f_max by reading speed_bin efuse values or by OSM table traversal (though latter looks more like a hack) and use that along with opp-supported-hw to identity supported opps.
I would prefer If we can avoid doing ^^ if we can get away with overloading the votes in dt but I don't have any strong opinions on this. So let me know how you want it done and I'll fix it up accordingly in the next re-spin.
Quoted 3 lines
-Doug
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.