Re: [PATCH 2/3] arm64: dts: qcom: hamoa-crd: Add thermal control

From: Bjorn Andersson

Date: Mon Aug 31 2026 - 16:55:18 EST


On Mon, Aug 31, 2026 at 10:58:56AM +0200, Stephan Gerhold wrote:
> On Sun, Aug 30, 2026 at 09:02:03PM +0000, Bjorn Andersson wrote:
> > The "limits" hardware performs rapid thermal management of the CPU
> > cores, but during prolonged CPU usage the system's overall temperature
> > need to be further managed by software.
> >
> > The reference design provides seven "system thermistors", connected to
> > the PMK8550 VADC. Particularly interesting is the "keyboard hotspot
> > thermistor", which is wired up to sys_therm1.
> >
> > Use this to throttle the CPUs, in the same way that we're throttling
> > previous generation laptops based on "skin-temp". The trips are chosen
> > from those existing examples, but are comparable with the ACPI thermal
> > policy.
> >
>
> In general, following the ACPI thermal policy as close as possible is
> better than following existing examples. Most X1E-based devices use
> hybrid active/passive cooling, with the fan controlled independently by
> the EC. If you start throttling even just 1-2°C before the EC reaches
> its highest fan trip point, it will result in bad performance. Linux
> will try to keep the temperature below the specified temperature, and
> the EC will never fully ramp up the fan.
>

That's certainly true. On X13s it was a bit easier as it's passively
cooled, but these things needs to be taken into consideration.

> This is what I determined from the CRD ACPI tables last year:
> https://github.com/stephan-gh/linux/commit/24f053436ec2eaf70968803adfa8c17905e53cae.patch
>

Why don't you post your patches!? Have I missed it?

> The fact that GPU is only throttled based on back-thermal is a little
> odd, but this is what the ACPI tables specified back then as far as
> I could tell (maybe it was fixed since then).
>
> Your changes seem close enough to not cause the performance problem
> I mentioned above, although I think it would be worth setting a good
> examples for others to follow.
>

Sure, I'll compare with ACPI tables and adjust the numbers accordingly.

> > While not used for cooling/throttling, also add the other thermal zones
> > for temperature reporting purposes.
> >
> > Enable thermal-monitor mode for all 7 channels in the ADC.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxxxx>
> > ---
> > arch/arm64/boot/dts/qcom/x1e80100-crd.dts | 116 ++++++++++++++++++++++++++++++
> > 1 file changed, 116 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
> > index 429deffcf3e9..065af18357d7 100644
> > --- a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts
> > @@ -11,6 +11,92 @@
> > / {
> > model = "Qualcomm Technologies, Inc. X1E80100 CRD";
> > compatible = "qcom,x1e80100-crd", "qcom,x1e80100";
> > +
> > + thermal-zones {
> > + soc-thermal {
> > + thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_GPIO_100K_PU(1)>;
> > + };
> > +
> > + keyboard-thermal {
> > + polling-delay-passive = <250>;
> > +
> > + thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX2_GPIO_100K_PU(1)>;
> > +
> > + trips {
> > + skin_alert0: trip-point0 {
> > + temperature = <55000>;
> > + hysteresis = <1000>;
> > + type = "passive";
> > + };
> > +
> > + skin_alert1: trip-point1 {
> > + temperature = <58000>;
> > + hysteresis = <1000>;
> > + type = "passive";
> > + };
>
> What does this second trip point do differently than the first? It has
> the same cooling devices. Will it try throttling "harder" than before?
>
> I know sc8280xp-lenovo-thinkpad-x13s.dts has the same, but I'm not
> entirely sure what it does there either.
>
> My experience was if you specify 55°C as one passive trip point, then
> Linux will try its best to keep it with the specified cooling devices.
>

I didn't dive into this rabbit hole... I'll review and update
accordingly.

> > +
> > + skin-crit {
> > + temperature = <73000>;

Your patch has 115C here. That may be what the ACPI tables are saying,
but it seems a bit excessive.

> > + hysteresis = <1000>;
> > + type = "critical";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map0 {
> > + trip = <&skin_alert0>;
> > + 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>,
> > + <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu8 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu9 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu10 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu11 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + };
> > +
> > + map1 {
> > + trip = <&skin_alert1>;
> > + 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>,
> > + <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu8 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu9 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu10 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&cpu11 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + };
> > + };
> > + };
> > +
> > + backcover-thermal {
> > + thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
> > + };
>
> Should we add throttling here as well to match Windows?
>

Then there are the reports that indicate that we should throttle things
when the SMB temperatures reaches something like 80C, which doesn't seem
to be something represented in the ACPI tables.

I'll do a respin of this and then we can tweak it from there. The
important thing for me is to get some reference in, so we can propagate
this to the consumer devices (NB: which doesn't have the same sys_therm
mapping).

Thanks,
Bjorn

> Thanks,
> Stephan