kernel/linux.git/Documentation/driver-api/thermal, branch v7.0-rc7

thermal: int340x: processor_thermal: Enable slow workload type hints

2026-01-07T20:42:10+00:00

On processors starting from Panther Lake, additional workload type hints are provided. The hardware analyzes workload residencies over an extended period to determine whether the workload classification tends toward idle/battery life states or sustained/performance states. Based on this long-term analysis, it classifies: Power Classification: If the workload exhibits more idle or battery life residencies, it is classified as "power". This is indicated by setting bit 4 of the current workload type. Performance Classification: If the workload exhibits more sustained or performance residencies, it is classified as "performance". This is indicated by clearing bit 4 of the current workload type. This approach enables applications to ignore short-term workload fluctuations and instead respond to longer-term power vs. performance trends. Hints of this type are called slow workload hints. To get notifications for slow workload hints, bit 22 in the thermal mailbox can be used for configuring workload interrupts. It is possible to exclusively enable slow workload hints or enable them in addition to the current workload hints. To enable slow workload hints, a new sysfs attribute is added to the existing workload hint attributes: workload_slow_hint_enable (RW): Write 1 to enable, 0 to disable. Reading this attribute shows the current state. This attribute is not present on any previous generation of processors. Signed-off-by: Srinivas Pandruvada [ rjw: Dropped redundant local variables, changelog edits ] Link: https://patch.msgid.link/20251218222559.4110027-2-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki

docs: driver-api/thermal/intel_dptf: Add new workload type hint

2025-11-20T20:32:52+00:00

Add documentation for longer term classification of workload type for power or performance. Signed-off-by: Srinivas Pandruvada Reviewed-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://patch.msgid.link/20251118223620.554798-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki

Documentation: Fix driver-api typos

2025-08-18T16:17:49+00:00

Corrected a few spelling mistakes functionalty ==> functionality in Documentation/driver-api/cxl/devices/device-types.rst adjascent ==> adjacent in Documentation/driver-api/cxl/platform/example-configurations/one-dev-per-hb.rst succeessful ==> successful in Documentation/driver-api/thermal/exynos_thermal_emulation.rst Signed-off-by: Ranganath V N Reviewed-by: Randy Dunlap Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20250814184304.20448-1-vnranganath.20@gmail.com

thermal: intel: int340x: Add throttling control interface to PTC

2025-06-16T12:03:09+00:00

Firmware-based thermal temperature control loops may aggressively throttle performance to prevent temperature overshoots relative to the defined target temperature. This can negatively impact performance. User space may prefer to prioritize performance, even if it results in temperature overshoots with in acceptable range. For example, user space might tolerate temperature overshoots when the device is placed on a desk, as opposed to when it's on a lap. To accommodate such scenarios, an optional attribute is provided to specify a tolerance level for temperature overshoots while maintaining acceptable performance. Attribute: thermal_tolerance: This attribute ranges from 0 to 7, where 0 represents the most aggressive control to avoid any temperature overshoots, and 7 represents a more graceful approach, favoring performance even at the expense of temperature overshoots. Note: This level may not scale linearly. For example, a value of 3 does not necessarily imply a 50% improvement in performance compared to a value of 0. Signed-off-by: Srinivas Pandruvada Reviewed-by: Zhang Rui Link: https://patch.msgid.link/20250613214923.2910397-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki

thermal: int340x: processor_thermal: Platform temperature control documentation

2025-05-07T19:34:39+00:00

Update documentation of attributes for platform temperature control. Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20250429000110.236243-4-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki

docs: thermal: sync hardware protection doc with code

2025-03-17T06:24:13+00:00

Originally, the thermal framework's only hardware protection action was to trigger a shutdown. This has been changed a little over a year ago to also support rebooting as alternative hardware protection action. Update the documentation to reflect this. Link: https://lkml.kernel.org/r/20250217-hw_protection-reboot-v3-3-e1c09b090c0c@pengutronix.de Fixes: 62e79e38b257 ("thermal/thermal_of: Allow rebooting after critical temp") Signed-off-by: Ahmad Fatoum Reviewed-by: Tzung-Bi Shih Reviewed-by: Matti Vaittinen Cc: Benson Leung Cc: Daniel Lezcano Cc: Fabio Estevam Cc: Guenter Roeck Cc: Jonathan Corbet Cc: Liam Girdwood Cc: Lukasz Luba Cc: Mark Brown Cc: Matteo Croce Cc: "Rafael J. Wysocki" Cc: Rob Herring (Arm) Cc: Rui Zhang Cc: Sascha Hauer Cc: "Serge E. Hallyn" Signed-off-by: Andrew Morton

thermal: core: Drop unused bind/unbind functions and callbacks

2024-08-23T13:42:58+00:00

There are no more callers of thermal_zone_bind_cooling_device() and thermal_zone_unbind_cooling_device(), so drop them along with all of the corresponding headers, code and documentation. Moreover, because the .bind() and .unbind() thermal zone callbacks would only be used when the above functions, respectively, were called, drop them as well along with all of the code related to them. Signed-off-by: Rafael J. Wysocki Reviewed-by: Zhang Rui Acked-by: Huisong Li Reviewed-by: Daniel Lezcano Link: https://patch.msgid.link/4251116.1IzOArtZ34@rjwysocki.net

thermal: helpers: Drop get_thermal_instance()

2024-08-02T11:57:04+00:00

There are no more users of get_thermal_instance(), so drop it. While at it, replace get_instance() returning a pointer to struct thermal_instance with thermal_instance_present() returning a bool which is more straightforward. No functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/2014591.usQuhbGJ8B@rjwysocki.net [ rjw: Dropped get_thermal_instance() documentation ] Signed-off-by: Rafael J. Wysocki

thermal: core: Update thermal zone registration documentation

2024-08-02T11:22:37+00:00

The thermal sysfs API document is outdated. One of the problems with it is that is still documents thermal_zone_device_register() which does not exit any more and it does not reflect the current thermal zone operations definition. Replace the thermal_zone_device_register() description in it with a thermal_zone_device_register_with_trips() description, including an update of the thermal zone operations list. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/2767845.mvXUDI8C0e@rjwysocki.net

thermal: int340x: processor_thermal: Support power floor notifications

2023-10-12T19:09:48+00:00

When the hardware reduces the power to the minimum possible, the power floor is notified via an interrupt. This can happen when user space requests a power limit via powercap RAPL interface, which forces the system to enter to the lowest power. This power floor indication can be used as a hint to resort to other methods of reducing power than via RAPL power limit. Before power floor status can be read or the firmware can trigger notifications regarding it, it needs to be configured via a mailbox command. The actual power floor status is read via bit 39 of MMIO offset 0x5B18 of the processor thermal PCI device. To show the current power floor status and get notification on a sysfs attribute, add 2 new attributes to /sys/bus/pci/devices/0000\:00\:04.0/power_limits/ power_floor_enable : This attribute is present when power floor notifications are supported. This attribute allows to enable/disable power floor notifications. power_floor_status : This attribute is present when power floor notifications are supported. When enabled via power_floor_enable, this attribute shows the current power floor status. The power floor implementation provides interfaces which are called from the sysfs callbacks to enable/disable and read power floor status. It also provides two additional interfaces to check if the current processor thermal device interrupt is for power floor status and to send notifications to user space. Signed-off-by: Srinivas Pandruvada [ rjw: Changelog and documentation changes edits ] Signed-off-by: Rafael J. Wysocki