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

[Stephan Gerhold <stephan.gerhold@linaro.org>]

On Mon, Aug 31, 2026 at 01:14:06PM -0500, Bjorn Andersson wrote:
> On Mon, Aug 31, 2026 at 06:11:14PM +0200, Stephan Gerhold wrote:
> > On Mon, Aug 31, 2026 at 09:20:14AM -0500, Bjorn Andersson wrote:
> > > 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:
> [...]
> > I have been working on finishing up my corresponding patch for the T14s
> > (which is something I can still test unlike the CRD). That one is
> > unfortunately currently stuck because the SYS_THERMx mapping really is
> > different from the CRD and even the schematics are not sufficient to
> > understand where each sensor is located. The mapping seems to be
> > different from the CRD, unfortunately.
> > 
> 
> Yes, each design have their own sensor setup, but at least if we land
> this we have a reference for the mechanism.
> 
> Would certainly be nice to get the T14s pieces landed though. And I
> would consider it to be perfectly fine to not fully replicate the
> Windows/ACPI setup - since we don't have the additional layers.
>

Indeed. I tried contacting Mark Pearson a few weeks ago to get some more
details (since he offered his help in [1]), but unfortunately he did not
reply so far.

I'll recheck the info I've already guessed so far and will see if this
is sufficient to add some basic thermal throttling.

[1]: https://lore.kernel.org/linux-arm-msm/ea0b329e-ab3e-4655-8f27-e7a74784302a@app.fastmail.com/

> I did peek at the Dell XPS13 DSDT and I see the same problem there.
> 
> > The ACPI side is also extra tricky because it takes the thermal
> > thresholds for the thermal zones through some lookup table in a random
> > firmware memory region, which is also applied depending on the selected
> > fan profile (for the T14s: "low power", "balanced", "performance").
> 
> I think we need to just treat the current ACPI situation as
> "inspiration", do some measurements and provide something that seems to
> work for DT/Linux.
> 
> And if nothing else, it's going to be way better than what we have now
> (i.e. nothing).
> 

Agreed.

Thanks,
Stephan