The 'sustainable_power' attribute provides an estimate of the sustained
power that can be dissipated at the desired control temperature. One
could argue that this value is not necessarily the same for all devices
with the same SoC, which may have different form factors or thermal
designs. However there are reasons to specify a (default) value at SoC
level for SC7180: most importantly, if no value is specified at all the
power_allocator thermal governor (aka 'IPA') estimates a value, using the
minimum power of all cooling devices of the zone, which can result in
overly aggressive thermal throttling. For most devices an approximate
conservative value should be more useful than the minimum guesstimate
of power_allocator. Devices that need a different value can overwrite
it in their <device>.dts. Also the thermal zones for SC7180 have a high
level of granularity (essentially one for each function block), which
makes it more likely that the default value just works for many devices.
The values correspond to 1901 MHz for the big cores, and 1804 MHz for
the small cores. The values were determined by limiting the CPU
frequencies to different max values and launching a bunch of processes
that cause high CPU load ('while true; do true; done &' is simple and
does a good job). A frequency is deemed sustainable if the CPU
temperatures don't rise (consistently) above the second trip point
('control temperature', 95 degC in this case). Once the highest
sustainable frequency is found, the sustainable power can be calculated
by multiplying the energy consumption per core at this frequency (which
can be found in /sys/kernel/debug/energy_model/) with the number of
cores that are specified as cooling devices.
The sustainable frequencies were determined at room temperature
on a device without heat sink or other passive cooling elements.
Signed-off-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx>
---
If maintainers think 'sustainable_power' should be specified at
device level (with which I conceptually agree) I'm fine with
doing that, just seemed it could be useful to have a reasonable
'default' at SoC level in this case.
arch/arm64/boot/dts/qcom/sc7180.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index d46b3833e52f..23f84639d6b9 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -3320,6 +3320,7 @@ cpu0-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 1>;
+ sustainable-power = <768>;
trips {
cpu0_alert0: trip-point0 {
@@ -3368,6 +3369,7 @@ cpu1-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 2>;
+ sustainable-power = <768>;
trips {
cpu1_alert0: trip-point0 {
@@ -3416,6 +3418,7 @@ cpu2-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 3>;
+ sustainable-power = <768>;
trips {
cpu2_alert0: trip-point0 {
@@ -3464,6 +3467,7 @@ cpu3-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 4>;
+ sustainable-power = <768>;
trips {
cpu3_alert0: trip-point0 {
@@ -3512,6 +3516,7 @@ cpu4-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 5>;
+ sustainable-power = <768>;
trips {
cpu4_alert0: trip-point0 {
@@ -3560,6 +3565,7 @@ cpu5-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 6>;
+ sustainable-power = <768>;
trips {
cpu5_alert0: trip-point0 {
@@ -3608,6 +3614,7 @@ cpu6-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 9>;
+ sustainable-power = <1202>;
trips {
cpu6_alert0: trip-point0 {
@@ -3648,6 +3655,7 @@ cpu7-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 10>;
+ sustainable-power = <1202>;
trips {
cpu7_alert0: trip-point0 {
@@ -3688,6 +3696,7 @@ cpu8-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 11>;
+ sustainable-power = <1202>;
trips {
cpu8_alert0: trip-point0 {
@@ -3728,6 +3737,7 @@ cpu9-thermal {
polling-delay = <0>;
thermal-sensors = <&tsens0 12>;
+ sustainable-power = <1202>;
trips {
cpu9_alert0: trip-point0 {
--
2.28.0.220.ged08abb693-goog
