On Fri, Jan 11, 2019 at 04:47:15PM +0530, Amit Kucheria wrote: > On Fri, Jan 11, 2019 at 6:00 AM Matthias Kaehlcke <mka@xxxxxxxxxxxx> wrote: > > > > On Thu, Jan 10, 2019 at 05:30:56AM +0530, Amit Kucheria wrote: > > > Since the big and little cpus are in the same frequency domain, use all > > > of them for mitigation in the cooling-map. At the lower trip points we > > > restrict ourselves to throttling only a few OPPs. At higher trip > > > temperatures, allow ourselves to be throttled to any extent. > > > > > > Signed-off-by: Amit Kucheria <amit.kucheria@xxxxxxxxxx> > > > --- > > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 145 +++++++++++++++++++++++++++ > > > 1 file changed, 145 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi > > > index 29e823b0caf4..cd6402a9aa64 100644 > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi > > > @@ -13,6 +13,7 @@ > > > #include <dt-bindings/reset/qcom,sdm845-aoss.h> > > > #include <dt-bindings/soc/qcom,rpmh-rsc.h> > > > #include <dt-bindings/clock/qcom,gcc-sdm845.h> > > > +#include <dt-bindings/thermal/thermal.h> > > > > > > / { > > > interrupt-parent = <&intc>; > > > @@ -99,6 +100,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x0>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_0>; > > > L2_0: l2-cache { > > > compatible = "cache"; > > > @@ -114,6 +116,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x100>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_100>; > > > L2_100: l2-cache { > > > compatible = "cache"; > > > @@ -126,6 +129,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x200>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_200>; > > > L2_200: l2-cache { > > > compatible = "cache"; > > > @@ -138,6 +142,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x300>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_300>; > > > L2_300: l2-cache { > > > compatible = "cache"; > > > @@ -150,6 +155,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x400>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_400>; > > > L2_400: l2-cache { > > > compatible = "cache"; > > > @@ -162,6 +168,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x500>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_500>; > > > L2_500: l2-cache { > > > compatible = "cache"; > > > @@ -174,6 +181,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x600>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_600>; > > > L2_600: l2-cache { > > > compatible = "cache"; > > > @@ -186,6 +194,7 @@ > > > compatible = "qcom,kryo385"; > > > reg = <0x0 0x700>; > > > enable-method = "psci"; > > > + #cooling-cells = <2>; > > > next-level-cache = <&L2_700>; > > > L2_700: l2-cache { > > > compatible = "cache"; > > > @@ -1703,6 +1712,23 @@ > > > type = "critical"; > > > }; > > > }; > > > + > > > + cooling-maps { > > > + map0 { > > > + trip = <&cpu_alert0>; > > > + cooling-device = <&CPU0 THERMAL_NO_LIMIT 4>, > > > + <&CPU1 THERMAL_NO_LIMIT 4>, > > > + <&CPU2 THERMAL_NO_LIMIT 4>, > > > + <&CPU3 THERMAL_NO_LIMIT 4>; > > > + }; > > > + map1 { > > > + trip = <&cpu_crit0>; > > > + cooling-device = <&CPU0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, > > > + <&CPU1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, > > > + <&CPU2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, > > > + <&CPU3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; > > > + }; > > > + }; > > > > Slightly off-topic, buy maybe not so much since we are just starting > > to use the trip points: > > > > Currently we use the naming scheme 'cpu_<type>N' for trip points. I > > anticipate that we're going to add more passive trip points soon, to > > keep the 'power_allocator' thermal governor happy, which expects a > > 'switch_on' and a 'desired_temperature' trip point. With the current > > naming scheme this could become a bit messy. I suggest to change it to > > 'cpuN_<type>[X]', which would allow for something like 'cpuN_alert0' > > and 'cpuN_alert1'. > > > > If you think the change makes sense you can consider to do it within > > this series, I can also send a separate patch once it has landed. > > Sure, I can change them to cpuN_alertX format. Great, thanks! Another concern about adding trip points later could be the node name. We currently have: trips { cpu0_alert0: trip0 { ... }; cpu0_crit: trip1 { ... }; }; If we keep increasing enumeration with the node name this would become: trips { cpu0_alert0: trip0 { ... }; cpu0_alert1: trip1 { ... }; cpu0_crit: trip2 { ... }; }; i.e. the node name of the critical trip-point changes, which might be a concern for dtsi's that override a value, though they should probably use the phandle &cpu0_crit anyway. If this is a concern we could change the node names to 'alert0' and 'crit'. I looked around a bit and actually I kinda like the naming scheme used by hisilicon/hi6220.dtsi, mediatek/mt8173.dtsi and rockchip/rk3328.dtsi (with minor variations): trips { threshold: trip-point@0 { temperature = <68000>; hysteresis = <2000>; type = "passive"; }; target: trip-point@1 { temperature = <85000>; hysteresis = <2000>; type = "passive"; }; cpu_crit: cpu_crit@0 { temperature = <115000>; hysteresis = <2000>; type = "critical"; }; }; If we were to use this we'd have to adapt it slightly since we have multiple thermal zones. In line with the other scheme this could be cpuN_threshold, cpuN_target and cpuN_crit. Up to you, just providing some options ;-) > > You could also consider to add the additional trip point in this > > series if you agree that it will be needed. > > I expect that we'll end up with at least 2 passive trip points but I > don't know what temperature to set the next one at. So let's just go > with 1 passive and 1 critical trip point in this series and you can > send a patch adding more once we've characterised IPA. Sounds good Thanks! Matthias