Support for Thermal Subsystem

[qzed]

The thermal subsystem (TMP) currently lacks a driver for 7th and later generation models. This should be a SSAM client device driver and needs devices to be added to the registry (e.g. IDs ssam:01:03:<TID>:<IID>:<FUN>).

Since we can actually detect which sensor instances are available, there should probably be a thermal hub device managing (i.e. instantiating) individual sensor devices. It seems that there's also the possibility for having different target IDs ('TID') so it might be a good idea to have one hub per target ID. Hubs and sensor devices can be separated by function ID (FUN), e.g. hub has FUN=0 and sensor FUN=1.

There is some functionality to set sensor trip points, implementing this should also considered but might be something for a later time. First priority should be getting the values to sysfs in a format that e.g. thermald can read. Gen7 devices do have a DPTF config which seems to depend on those sensors, so we'll have to figure out what it expects and how to make that compatible, ideally so that thermald can automatically use that config, which should then result in behavior similar to Windows.

On the gen5 devices, these sensors have some ID string embedded in ACPI, which gives an indication what it is used for. Ideally we'd find a mapping for those on the gen7 devices as well. This might be encoded in the Windows driver, so might need some reverse engineering.

A list of currently known commands and events is provided here:

surface-aggregator-module/doc/requests.txt

Lines 139 to 160 in d85d69a

	List of Thermal Subsystem Requests (TC = 0x03)
	--------------------------------------------------------------------------------
	CID IID TID Payload Response Name/Function Source
	------------------------------------------------------------------------
	0x01 #SEN 0x01 no yes ACPI/_TMP dsdt
	0x02 0x00 0x01 no yes Get performance mode log
	0x03 0x00 0x01 yes no Set performance mode log
	0x04 0x00 0x01 no yes Get available sensors dsdt
	0x09 #SEN 0x01 yes yes Set sensor trip point dsdt
	Note: CID 0x09 is an Intel DPTF command.
	List of Thermal Subsystem Events (TC = 0x03)
	--------------------------------------------------------------------------------
	CID IID TID Payload Name/Function Source
	------------------------------------------------------------------------
	0x0b #SEN 0x01 ? Notify sensor trip-point log+dsdt

See https://www.kernel.org/doc/html/latest/driver-api/surface_aggregator/client.html#adding-ssam-devices for documentation on client devices and drivers.

[gamer191]

which should then result in behavior similar to Windows

Wait, is surface-linux currently not behaving (thermal-management-wise) like windows? Is it dangerous/have the potential to cause hardware damage? I'm probably being a bit paranoid, but since I don't really understand that much about Linux's internal etc, I'm a little worried?

[qzed]

Wait, is surface-linux currently not behaving (thermal-management-wise) like windows?

Pretty much no laptop does out of the box. Intel DPTF stuff that describes throttling via ACPI needs at least thermald (and then thermald needs to support the ACPI stuff, which IIRC has also been an issue in the past). On the newer Surfaces we're also missing the thermal sensors so even with thermald at the moment this doesn't work.

Is it dangerous/have the potential to cause hardware damage?

There should be hard safeguards in firmware, like the CPU throttling and being locked to 400MHz (which has been reported on a couple of issues). To avoid these triggering, it's a good idea to have a custom thermald config (like the one provided in the repos) that is a bit more sensible (i.e. have something that throttles gradually before running into those limits, hopefully preventing ever running into those).

Also, as a very late edit to this: CPUs generally have thermal sensors built in and those are not handled via SAM. SAM sensors are mostly skin sensors, and on some devices also peripherals (e.g. battery).

[qzed]

Note: SL3 and SP7 handle temperature sensors via SAN, i.e. still via SAM but indirectly via ACPI and the ACPI bridge, which is already supported. So I've removed those.

[qzed]

I've added some SAM request/interface specifications for the thermal subsystem in linux-surface/surface-aggregator-cmddb@257e4b2. That should provide all the necessary info to implement a Linux driver.

[qzed]

I've added a basic implementation with linux-surface/kernel@5fb7bb8 and linux-surface/kernel@1cdd37f.