lastdragon/linux-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resguardo inicial

Browse Source
This commit is contained in:
lastdragon
2026-09-06 12:53:21 -06:00
parent 662efe3c2a
commit ad2088d178
94853 changed files with 43200404 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
linux-7.2.3/Documentation/driver-api/thermal/cpu-cooling-api.rst
+107
View File
@@ -0,0 +1,107 @@
=======================
CPU cooling APIs How To
=======================
Written by Amit Daniel Kachhap <amit.kachhap@linaro.org>
Updated: 6 Jan 2015
Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
0. Introduction
===============
The generic cpu cooling(freq clipping) provides registration/unregistration APIs
to the caller. The binding of the cooling devices to the trip point is left for
the user. The registration APIs returns the cooling device pointer.
1. cpu cooling APIs
===================
1.1 cpufreq registration/unregistration APIs
--------------------------------------------
::
struct thermal_cooling_device
*cpufreq_cooling_register(struct cpumask *clip_cpus)
This interface function registers the cpufreq cooling device with the name
"thermal-cpufreq-%x". This api can support multiple instances of cpufreq
cooling devices.
clip_cpus:
cpumask of cpus where the frequency constraints will happen.
::
struct thermal_cooling_device
*of_cpufreq_cooling_register(struct cpufreq_policy *policy)
This interface function registers the cpufreq cooling device with
the name "thermal-cpufreq-%x" linking it with a device tree node, in
order to bind it via the thermal DT code. This api can support multiple
instances of cpufreq cooling devices.
policy:
CPUFreq policy.
::
void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
This interface function unregisters the "thermal-cpufreq-%x" cooling device.
cdev: Cooling device pointer which has to be unregistered.
2. Power models
===============
The power API registration functions provide a simple power model for
CPUs. The current power is calculated as dynamic power (static power isn't
supported currently). This power model requires that the operating-points of
the CPUs are registered using the kernel's opp library and the
`cpufreq_frequency_table` is assigned to the `struct device` of the
cpu. If you are using CONFIG_CPUFREQ_DT then the
`cpufreq_frequency_table` should already be assigned to the cpu
device.
The dynamic power consumption of a processor depends on many factors.
For a given processor implementation the primary factors are:
- The time the processor spends running, consuming dynamic power, as
compared to the time in idle states where dynamic consumption is
negligible. Herein we refer to this as 'utilisation'.
- The voltage and frequency levels as a result of DVFS. The DVFS
level is a dominant factor governing power consumption.
- In running time the 'execution' behaviour (instruction types, memory
access patterns and so forth) causes, in most cases, a second order
variation. In pathological cases this variation can be significant,
but typically it is of a much lesser impact than the factors above.
A high level dynamic power consumption model may then be represented as::
Pdyn = f(run) * Voltage^2 * Frequency * Utilisation
f(run) here represents the described execution behaviour and its
result has a units of Watts/Hz/Volt^2 (this often expressed in
mW/MHz/uVolt^2)
The detailed behaviour for f(run) could be modelled on-line. However,
in practice, such an on-line model has dependencies on a number of
implementation specific processor support and characterisation
factors. Therefore, in initial implementation that contribution is
represented as a constant coefficient. This is a simplification
consistent with the relative contribution to overall power variation.
In this simplified representation our model becomes::
Pdyn = Capacitance * Voltage^2 * Frequency * Utilisation
Where `capacitance` is a constant that represents an indicative
running time dynamic power coefficient in fundamental units of
mW/MHz/uVolt^2. Typical values for mobile CPUs might lie in range
from 100 to 500. For reference, the approximate values for the SoC in
ARM's Juno Development Platform are 530 for the Cortex-A57 cluster and
140 for the Cortex-A53 cluster.
linux-7.2.3/Documentation/driver-api/thermal/cpu-idle-cooling.rst
+199
View File
@@ -0,0 +1,199 @@
.. SPDX-License-Identifier: GPL-2.0
================
CPU Idle Cooling
================
Situation:
----------
Under certain circumstances a SoC can reach a critical temperature
limit and is unable to stabilize the temperature around a temperature
control. When the SoC has to stabilize the temperature, the kernel can
act on a cooling device to mitigate the dissipated power. When the
critical temperature is reached, a decision must be taken to reduce
the temperature, that, in turn impacts performance.
Another situation is when the silicon temperature continues to
increase even after the dynamic leakage is reduced to its minimum by
clock gating the component. This runaway phenomenon can continue due
to the static leakage. The only solution is to power down the
component, thus dropping the dynamic and static leakage that will
allow the component to cool down.
Last but not least, the system can ask for a specific power budget but
because of the OPP density, we can only choose an OPP with a power
budget lower than the requested one and under-utilize the CPU, thus
losing performance. In other words, one OPP under-utilizes the CPU
with a power less than the requested power budget and the next OPP
exceeds the power budget. An intermediate OPP could have been used if
it were present.
Solutions:
----------
If we can remove the static and the dynamic leakage for a specific
duration in a controlled period, the SoC temperature will
decrease. Acting on the idle state duration or the idle cycle
injection period, we can mitigate the temperature by modulating the
power budget.
The Operating Performance Point (OPP) density has a great influence on
the control precision of cpufreq, however different vendors have a
plethora of OPP density, and some have large power gap between OPPs,
that will result in loss of performance during thermal control and
loss of power in other scenarios.
At a specific OPP, we can assume that injecting idle cycle on all CPUs
belong to the same cluster, with a duration greater than the cluster
idle state target residency, we lead to dropping the static and the
dynamic leakage for this period (modulo the energy needed to enter
this state). So the sustainable power with idle cycles has a linear
relation with the OPP’s sustainable power and can be computed with a
coefficient similar to::
Power(IdleCycle) = Coef x Power(OPP)
Idle Injection:
---------------
The base concept of the idle injection is to force the CPU to go to an
idle state for a specified time each control cycle, it provides
another way to control CPU power and heat in addition to
cpufreq. Ideally, if all CPUs belonging to the same cluster, inject
their idle cycles synchronously, the cluster can reach its power down
state with a minimum power consumption and reduce the static leakage
to almost zero. However, these idle cycles injection will add extra
latencies as the CPUs will have to wakeup from a deep sleep state.
We use a fixed duration of idle injection that gives an acceptable
performance penalty and a fixed latency. Mitigation can be increased
or decreased by modulating the duty cycle of the idle injection.
::
^
|
|
|------- -------
|_______|_______________________|_______|___________
<------>
idle <---------------------->
running
<----------------------------->
duty cycle 25%
The implementation of the cooling device bases the number of states on
the duty cycle percentage. When no mitigation is happening the cooling
device state is zero, meaning the duty cycle is 0%.
When the mitigation begins, depending on the governor's policy, a
starting state is selected. With a fixed idle duration and the duty
cycle (aka the cooling device state), the running duration can be
computed.
The governor will change the cooling device state thus the duty cycle
and this variation will modulate the cooling effect.
::
^
|
|
|------- -------
|_______|_______________|_______|___________
<------>
idle <-------------->
running
<--------------------->
duty cycle 33%
^
|
|
|------- -------
|_______|_______|_______|___________
<------>
idle <------>
running
<------------->
duty cycle 50%
The idle injection duration value must comply with the constraints:
- It is less than or equal to the latency we tolerate when the
mitigation begins. It is platform dependent and will depend on the
user experience, reactivity vs performance trade off we want. This
value should be specified.
- It is greater than the idle state’s target residency we want to go
for thermal mitigation, otherwise we end up consuming more energy.
Power considerations
--------------------
When we reach the thermal trip point, we have to sustain a specified
power for a specific temperature but at this time we consume::
Power = Capacitance x Voltage^2 x Frequency x Utilisation
... which is more than the sustainable power (or there is something
wrong in the system setup). The ‘Capacitance’ and ‘Utilisation’ are a
fixed value, ‘Voltage’ and the ‘Frequency’ are fixed artificially
because we don’t want to change the OPP. We can group the
‘Capacitance’ and the ‘Utilisation’ into a single term which is the
‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have::
Pdyn = Cdyn x Voltage^2 x Frequency
The power allocator governor will ask us somehow to reduce our power
in order to target the sustainable power defined in the device
tree. So with the idle injection mechanism, we want an average power
(Ptarget) resulting in an amount of time running at full power on a
specific OPP and idle another amount of time. That could be put in a
equation::
P(opp)target = ((Trunning x (P(opp)running) + (Tidle x P(opp)idle)) /
(Trunning + Tidle)
...
Tidle = Trunning x ((P(opp)running / P(opp)target) - 1)
At this point if we know the running period for the CPU, that gives us
the idle injection we need. Alternatively if we have the idle
injection duration, we can compute the running duration with::
Trunning = Tidle / ((P(opp)running / P(opp)target) - 1)
Practically, if the running power is less than the targeted power, we
end up with a negative time value, so obviously the equation usage is
bound to a power reduction, hence a higher OPP is needed to have the
running power greater than the targeted power.
However, in this demonstration we ignore three aspects:
* The static leakage is not defined here, we can introduce it in the
equation but assuming it will be zero most of the time as it is
difficult to get the values from the SoC vendors
* The idle state wake up latency (or entry + exit latency) is not
taken into account, it must be added in the equation in order to
rigorously compute the idle injection
* The injected idle duration must be greater than the idle state
target residency, otherwise we end up consuming more energy and
potentially invert the mitigation effect
So the final equation is::
Trunning = (Tidle - Twakeup ) x
(((P(opp)dyn + P(opp)static ) - P(opp)target) / P(opp)target )
linux-7.2.3/Documentation/driver-api/thermal/exynos_thermal.rst
+90
View File
@@ -0,0 +1,90 @@
========================
Kernel driver exynos_tmu
========================
Supported chips:
* ARM Samsung Exynos4, Exynos5 series of SoC
Datasheet: Not publicly available
Authors: Donggeun Kim <dg77.kim@samsung.com>
Authors: Amit Daniel <amit.daniel@samsung.com>
TMU controller Description:
---------------------------
This driver allows to read temperature inside Samsung Exynos4/5 series of SoC.
The chip only exposes the measured 8-bit temperature code value
through a register.
Temperature can be taken from the temperature code.
There are three equations converting from temperature to temperature code.
The three equations are:
1. Two point trimming::
Tc = (T - 25) * (TI2 - TI1) / (85 - 25) + TI1
2. One point trimming::
Tc = T + TI1 - 25
3. No trimming::
Tc = T + 50
Tc:
Temperature code, T: Temperature,
TI1:
Trimming info for 25 degree Celsius (stored at TRIMINFO register)
Temperature code measured at 25 degree Celsius which is unchanged
TI2:
Trimming info for 85 degree Celsius (stored at TRIMINFO register)
Temperature code measured at 85 degree Celsius which is unchanged
TMU(Thermal Management Unit) in Exynos4/5 generates interrupt
when temperature exceeds pre-defined levels.
The maximum number of configurable threshold is five.
The threshold levels are defined as follows::
Level_0: current temperature > trigger_level_0 + threshold
Level_1: current temperature > trigger_level_1 + threshold
Level_2: current temperature > trigger_level_2 + threshold
Level_3: current temperature > trigger_level_3 + threshold
The threshold and each trigger_level are set
through the corresponding registers.
When an interrupt occurs, this driver notify kernel thermal framework
with the function exynos_report_trigger.
Although an interrupt condition for level_0 can be set,
it can be used to synchronize the cooling action.
TMU driver description:
-----------------------
The exynos thermal driver is structured as::
Kernel Core thermal framework
(thermal_core.c, step_wise.c, cpufreq_cooling.c)
^
|
|
TMU configuration data -----> TMU Driver <----> Exynos Core thermal wrapper
(exynos_tmu_data.c) (exynos_tmu.c) (exynos_thermal_common.c)
(exynos_tmu_data.h) (exynos_tmu.h) (exynos_thermal_common.h)
a) TMU configuration data:
This consist of TMU register offsets/bitfields
described through structure exynos_tmu_registers. Also several
other platform data (struct exynos_tmu_platform_data) members
are used to configure the TMU.
b) TMU driver:
This component initialises the TMU controller and sets different
thresholds. It invokes core thermal implementation with the call
exynos_report_trigger.
c) Exynos Core thermal wrapper:
This provides 3 wrapper function to use the
Kernel core thermal framework. They are exynos_unregister_thermal,
exynos_register_thermal and exynos_report_trigger.
linux-7.2.3/Documentation/driver-api/thermal/exynos_thermal_emulation.rst
+61
View File
@@ -0,0 +1,61 @@
=====================
Exynos Emulation Mode
=====================
Copyright (C) 2012 Samsung Electronics
Written by Jonghwa Lee <jonghwa3.lee@samsung.com>
Description
-----------
Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal
management unit. Thermal emulation mode supports software debug for
TMU's operation. User can set temperature manually with software code
and TMU will read current temperature from user value not from sensor's
value.
Enabling CONFIG_THERMAL_EMULATION option will make this support
available. When it's enabled, sysfs node will be created as
/sys/devices/virtual/thermal/thermal_zone'zone id'/emul_temp.
The sysfs node, 'emul_node', will contain value 0 for the initial state.
When you input any temperature you want to update to sysfs node, it
automatically enable emulation mode and current temperature will be
changed into it.
(Exynos also supports user changeable delay time which would be used to
delay of changing temperature. However, this node only uses same delay
of real sensing time, 938us.)
Exynos emulation mode requires that value changes and enabling are performed
synchronously. This means that when you want to update any value, such as the
delay or the next temperature, you must enable emulation mode at the same
time (or keep the mode enabled). If you do not, the value will fail to update
and the last successful value will continue to be used. For this reason,
this node only allows users to change the temperature. Providing a single
interface makes it simpler to use.
Disabling emulation mode only requires writing value 0 to sysfs node.
::
TEMP 120 |
|
100 |
|
80 |
| +-----------
60 | | |
| +-------------| |
40 | | | |
| | | |
20 | | | +----------
| | | | |
0 |______________|_____________|__________|__________|_________
A A A A TIME
|<----->| |<----->| |<----->| |
| 938us | | | | | |
emulation : 0 50 | 70 | 20 | 0
current temp: sensor 50 70 20 sensor
linux-7.2.3/Documentation/driver-api/thermal/index.rst
+19
View File
@@ -0,0 +1,19 @@
.. SPDX-License-Identifier: GPL-2.0
=======
Thermal
=======
.. toctree::
:maxdepth: 1
cpu-cooling-api
cpu-idle-cooling
sysfs-api
power_allocator
exynos_thermal
exynos_thermal_emulation
nouveau_thermal
x86_pkg_temperature_thermal
intel_dptf
linux-7.2.3/Documentation/driver-api/thermal/intel_dptf.rst
+437
View File
@@ -0,0 +1,437 @@
.. SPDX-License-Identifier: GPL-2.0
===============================================================
Intel(R) Dynamic Platform and Thermal Framework Sysfs Interface
===============================================================
:Copyright: © 2022 Intel Corporation
:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Introduction
------------
Intel(R) Dynamic Platform and Thermal Framework (DPTF) is a platform
level hardware/software solution for power and thermal management.
As a container for multiple power/thermal technologies, DPTF provides
a coordinated approach for different policies to effect the hardware
state of a system.
Since it is a platform level framework, this has several components.
Some parts of the technology is implemented in the firmware and uses
ACPI and PCI devices to expose various features for monitoring and
control. Linux has a set of kernel drivers exposing hardware interface
to user space. This allows user space thermal solutions like
"Linux Thermal Daemon" to read platform specific thermal and power
tables to deliver adequate performance while keeping the system under
thermal limits.
DPTF ACPI Drivers interface
----------------------------
:file:`/sys/bus/platform/devices/<N>/uuids`, where <N>
=INT3400|INTC1040|INTC1041|INTC10A0
``available_uuids`` (RO)
A set of UUIDs strings presenting available policies
which should be notified to the firmware when the
user space can support those policies.
UUID strings:
"42A441D6-AE6A-462b-A84B-4A8CE79027D3" : Passive 1
"3A95C389-E4B8-4629-A526-C52C88626BAE" : Active
"97C68AE7-15FA-499c-B8C9-5DA81D606E0A" : Critical
"63BE270F-1C11-48FD-A6F7-3AF253FF3E2D" : Adaptive performance
"5349962F-71E6-431D-9AE8-0A635B710AEE" : Emergency call
"9E04115A-AE87-4D1C-9500-0F3E340BFE75" : Passive 2
"F5A35014-C209-46A4-993A-EB56DE7530A1" : Power Boss
"6ED722A7-9240-48A5-B479-31EEF723D7CF" : Virtual Sensor
"16CAF1B7-DD38-40ED-B1C1-1B8A1913D531" : Cooling mode
"BE84BABF-C4D4-403D-B495-3128FD44dAC1" : HDC
``current_uuid`` (RW)
User space can write strings from available UUIDs, one at a
time.
:file:`/sys/bus/platform/devices/<N>/`, where <N>
=INT3400|INTC1040|INTC1041|INTC10A0
``imok`` (WO)
User space daemon write 1 to respond to firmware event
for sending keep alive notification. User space receives
THERMAL_EVENT_KEEP_ALIVE kobject uevent notification when
firmware calls for user space to respond with imok ACPI
method.
``odvp*`` (RO)
Firmware thermal status variable values. Thermal tables
calls for different processing based on these variable
values.
``data_vault`` (RO)
Binary thermal table. Refer to
https:/github.com/intel/thermal_daemon for decoding
thermal table.
``production_mode`` (RO)
When different from zero, manufacturer locked thermal configuration
from further changes.
ACPI Thermal Relationship table interface
------------------------------------------
:file:`/dev/acpi_thermal_rel`
This device provides IOCTL interface to read standard ACPI
thermal relationship tables via ACPI methods _TRT and _ART.
These IOCTLs are defined in
drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.h
IOCTLs:
ACPI_THERMAL_GET_TRT_LEN: Get length of TRT table
ACPI_THERMAL_GET_ART_LEN: Get length of ART table
ACPI_THERMAL_GET_TRT_COUNT: Number of records in TRT table
ACPI_THERMAL_GET_ART_COUNT: Number of records in ART table
ACPI_THERMAL_GET_TRT: Read binary TRT table, length to read is
provided via argument to ioctl().
ACPI_THERMAL_GET_ART: Read binary ART table, length to read is
provided via argument to ioctl().
DPTF ACPI Sensor drivers
-------------------------
DPTF Sensor drivers are presented as standard thermal sysfs thermal_zone.
DPTF ACPI Cooling drivers
--------------------------
DPTF cooling drivers are presented as standard thermal sysfs cooling_device.
DPTF Processor thermal PCI Driver interface
--------------------------------------------
:file:`/sys/bus/pci/devices/0000\:00\:04.0/power_limits/`
Refer to Documentation/power/powercap/powercap.rst for powercap
ABI.
``power_limit_0_max_uw`` (RO)
Maximum powercap sysfs constraint_0_power_limit_uw for Intel RAPL
``power_limit_0_step_uw`` (RO)
Power limit increment/decrements for Intel RAPL constraint 0 power limit
``power_limit_0_min_uw`` (RO)
Minimum powercap sysfs constraint_0_power_limit_uw for Intel RAPL
``power_limit_0_tmin_us`` (RO)
Minimum powercap sysfs constraint_0_time_window_us for Intel RAPL
``power_limit_0_tmax_us`` (RO)
Maximum powercap sysfs constraint_0_time_window_us for Intel RAPL
``power_limit_1_max_uw`` (RO)
Maximum powercap sysfs constraint_1_power_limit_uw for Intel RAPL
``power_limit_1_step_uw`` (RO)
Power limit increment/decrements for Intel RAPL constraint 1 power limit
``power_limit_1_min_uw`` (RO)
Minimum powercap sysfs constraint_1_power_limit_uw for Intel RAPL
``power_limit_1_tmin_us`` (RO)
Minimum powercap sysfs constraint_1_time_window_us for Intel RAPL
``power_limit_1_tmax_us`` (RO)
Maximum powercap sysfs constraint_1_time_window_us for Intel RAPL
``power_floor_status`` (RO)
When set to 1, the power floor of the system in the current
configuration has been reached. It needs to be reconfigured to allow
power to be reduced any further.
``power_floor_enable`` (RW)
When set to 1, enable reading and notification of the power floor
status. Notifications are triggered for the power_floor_status
attribute value changes.
:file:`/sys/bus/pci/devices/0000\:00\:04.0/`
``tcc_offset_degree_celsius`` (RW)
TCC offset from the critical temperature where hardware will throttle
CPU.
:file:`/sys/bus/pci/devices/0000\:00\:04.0/workload_request`
``workload_available_types`` (RO)
Available workload types. User space can specify one of the workload type
it is currently executing via workload_type. For example: idle, bursty,
sustained etc.
``workload_type`` (RW)
User space can specify any one of the available workload type using
this interface.
:file:`/sys/bus/pci/devices/0000\:00\:04.0/ptc_0_control`
:file:`/sys/bus/pci/devices/0000\:00\:04.0/ptc_1_control`
:file:`/sys/bus/pci/devices/0000\:00\:04.0/ptc_2_control`
All these controls needs admin privilege to update.
``enable`` (RW)
1 for enable, 0 for disable. Shows the current enable status of
platform temperature control feature. User space can enable/disable
hardware controls.
``temperature_target`` (RW)
Update a new temperature target in milli degree celsius for hardware to
use for the temperature control.
``thermal_tolerance`` (RW)
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.
Given that this is platform temperature control, it is expected that a
single user-level manager owns and manages the controls. If multiple
user-level software applications attempt to write different targets, it
can lead to unexpected behavior.
DPTF Processor thermal RFIM interface
--------------------------------------------
RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator),
DDR (Double Data Rate) and DLVR (Digital Linear Voltage Regulator)
frequencies to avoid RF interference with WiFi and 5G.
Switching voltage regulators (VR) generate radiated EMI or RFI at the
fundamental frequency and its harmonics. Some harmonics may interfere
with very sensitive wireless receivers such as Wi-Fi and cellular that
are integrated into host systems like notebook PCs. One of mitigation
methods is requesting SOC integrated VR (IVR) switching frequency to a
small % and shift away the switching noise harmonic interference from
radio channels. OEM or ODMs can use the driver to control SOC IVR
operation within the range where it does not impact IVR performance.
Some products use DLVR instead of FIVR as switching voltage regulator.
In this case attributes of DLVR must be adjusted instead of FIVR.
While shifting the frequencies additional clock noise can be introduced,
which is compensated by adjusting Spread spectrum percent. This helps
to reduce the clock noise to meet regulatory compliance. This spreading
% increases bandwidth of signal transmission and hence reduces the
effects of interference, noise and signal fading.
DRAM devices of DDR IO interface and their power plane can generate EMI
at the data rates. Similar to IVR control mechanism, Intel offers a
mechanism by which DDR data rates can be changed if several conditions
are met: there is strong RFI interference because of DDR; CPU power
management has no other restriction in changing DDR data rates;
PC ODMs enable this feature (real time DDR RFI Mitigation referred to as
DDR-RFIM) for Wi-Fi from BIOS.
FIVR attributes
:file:`/sys/bus/pci/devices/0000\:00\:04.0/fivr/`
``vco_ref_code_lo`` (RW)
The VCO reference code is an 11-bit field and controls the FIVR
switching frequency. This is the 3-bit LSB field.
``vco_ref_code_hi`` (RW)
The VCO reference code is an 11-bit field and controls the FIVR
switching frequency. This is the 8-bit MSB field.
``spread_spectrum_pct`` (RW)
Set the FIVR spread spectrum clocking percentage
``spread_spectrum_clk_enable`` (RW)
Enable/disable of the FIVR spread spectrum clocking feature
``rfi_vco_ref_code`` (RW)
This field is a read only status register which reflects the
current FIVR switching frequency
``fivr_fffc_rev`` (RW)
This field indicated the revision of the FIVR HW.
DVFS attributes
:file:`/sys/bus/pci/devices/0000\:00\:04.0/dvfs/`
``rfi_restriction_run_busy`` (RW)
Request the restriction of specific DDR data rate and set this
value 1. Self reset to 0 after operation.
``rfi_restriction_err_code`` (RW)
0 :Request is accepted, 1:Feature disabled,
2: the request restricts more points than it is allowed
``rfi_restriction_data_rate_Delta`` (RW)
Restricted DDR data rate for RFI protection: Lower Limit
``rfi_restriction_data_rate_Base`` (RW)
Restricted DDR data rate for RFI protection: Upper Limit
``ddr_data_rate_point_0`` (RO)
DDR data rate selection 1st point
``ddr_data_rate_point_1`` (RO)
DDR data rate selection 2nd point
``ddr_data_rate_point_2`` (RO)
DDR data rate selection 3rd point
``ddr_data_rate_point_3`` (RO)
DDR data rate selection 4th point
``rfi_disable (RW)``
Disable DDR rate change feature
DLVR attributes
:file:`/sys/bus/pci/devices/0000\:00\:04.0/dlvr/`
``dlvr_hardware_rev`` (RO)
DLVR hardware revision.
``dlvr_freq_mhz`` (RO)
Current DLVR PLL frequency in MHz.
``dlvr_freq_select`` (RW)
Sets DLVR PLL clock frequency. Once set, and enabled via
dlvr_rfim_enable, the dlvr_freq_mhz will show the current
DLVR PLL frequency.
``dlvr_pll_busy`` (RO)
PLL can't accept frequency change when set.
``dlvr_rfim_enable`` (RW)
0: Disable RF frequency hopping, 1: Enable RF frequency hopping.
``dlvr_spread_spectrum_pct`` (RW)
Sets DLVR spread spectrum percent value.
``dlvr_control_mode`` (RW)
Specifies how frequencies are spread using spread spectrum.
0: Down spread,
1: Spread in the Center.
``dlvr_control_lock`` (RW)
1: future writes are ignored.
DPTF Power supply and Battery Interface
----------------------------------------
Refer to Documentation/ABI/testing/sysfs-platform-dptf
DPTF Fan Control
----------------------------------------
Refer to Documentation/admin-guide/acpi/fan_performance_states.rst
Workload Type Hints
----------------------------------------
The firmware in Meteor Lake processor generation is capable of identifying
workload type and passing hints regarding it to the OS. A special sysfs
interface is provided to allow user space to obtain workload type hints from
the firmware and control the rate at which they are provided.
User space can poll attribute "workload_type_index" for the current hint or
can receive a notification whenever the value of this attribute is updated.
file:`/sys/bus/pci/devices/0000:00:04.0/workload_hint/`
Segment 0, bus 0, device 4, function 0 is reserved for the processor thermal
device on all Intel client processors. So, the above path doesn't change
based on the processor generation.
``workload_hint_enable`` (RW)
Enable firmware to send workload type hints to user space.
``workload_slow_hint_enable`` (RW)
Enable firmware to send slow workload type hints to user space.
``notification_delay_ms`` (RW)
Minimum delay in milliseconds before firmware will notify OS. This is
for the rate control of notifications. This delay is between changing
the workload type prediction in the firmware and notifying the OS about
the change. The default delay is 1024 ms. The delay of 0 is invalid.
The delay is rounded up to the nearest power of 2 to simplify firmware
programming of the delay value. The read of notification_delay_ms
attribute shows the effective value used.
``workload_type_index`` (RO)
Predicted workload type index. User space can get notification of
change via existing sysfs attribute change notification mechanism.
The supported index values and their meaning for the Meteor Lake
processor generation are as follows:
0 - Idle: System performs no tasks, power and idle residency are
consistently low for long periods of time.
1 – Battery Life: Power is relatively low, but the processor may
still be actively performing a task, such as video playback for
a long period of time.
2 – Sustained: Power level that is relatively high for a long period
of time, with very few to no periods of idleness, which will
eventually exhaust RAPL Power Limit 1 and 2.
3 – Bursty: Consumes a relatively constant average amount of power, but
periods of relative idleness are interrupted by bursts of
activity. The bursts are relatively short and the periods of
relative idleness between them typically prevent RAPL Power
Limit 1 from being exhausted.
4 – Unknown: Can't classify.
On processors starting from Panther Lake additional 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".
Performance Classification: If the workload exhibits more sustained or
performance residencies, it is classified as "performance".
This approach enables applications to ignore short-term workload
fluctuations and instead respond to longer-term power vs. performance
trends.
Residency thresholds for this classification are CPU generation-specific.
Classification is reported via bit 4 of the workload_type_index:
Bit 4 = 1: Power classification
Bit 4 = 0: Performance classification
linux-7.2.3/Documentation/driver-api/thermal/nouveau_thermal.rst
+96
View File
@@ -0,0 +1,96 @@
=====================
Kernel driver nouveau
=====================
Supported chips:
* NV43+
Authors: Martin Peres (mupuf) <martin.peres@free.fr>
Description
-----------
This driver allows to read the GPU core temperature, drive the GPU fan and
set temperature alarms.
Currently, due to the absence of in-kernel API to access HWMON drivers, Nouveau
cannot access any of the i2c external monitoring chips it may find. If you
have one of those, temperature and/or fan management through Nouveau's HWMON
interface is likely not to work. This document may then not cover your situation
entirely.
Temperature management
----------------------
Temperature is exposed under as a read-only HWMON attribute temp1_input.
In order to protect the GPU from overheating, Nouveau supports 4 configurable
temperature thresholds:
* Fan_boost:
Fan speed is set to 100% when reaching this temperature;
* Downclock:
The GPU will be downclocked to reduce its power dissipation;
* Critical:
The GPU is put on hold to further lower power dissipation;
* Shutdown:
Shut the computer down to protect your GPU.
WARNING:
Some of these thresholds may not be used by Nouveau depending
on your chipset.
The default value for these thresholds comes from the GPU's vbios. These
thresholds can be configured thanks to the following HWMON attributes:
* Fan_boost: temp1_auto_point1_temp and temp1_auto_point1_temp_hyst;
* Downclock: temp1_max and temp1_max_hyst;
* Critical: temp1_crit and temp1_crit_hyst;
* Shutdown: temp1_emergency and temp1_emergency_hyst.
NOTE: Remember that the values are stored as milli degrees Celsius. Don't forget
to multiply!
Fan management
--------------
Not all cards have a drivable fan. If you do, then the following HWMON
attributes should be available:
* pwm1_enable:
Current fan management mode (NONE, MANUAL or AUTO);
* pwm1:
Current PWM value (power percentage);
* pwm1_min:
The minimum PWM speed allowed;
* pwm1_max:
The maximum PWM speed allowed (bypassed when hitting Fan_boost);
You may also have the following attribute:
* fan1_input:
Speed in RPM of your fan.
Your fan can be driven in different modes:
* 0: The fan is left untouched;
* 1: The fan can be driven in manual (use pwm1 to change the speed);
* 2; The fan is driven automatically depending on the temperature.
NOTE:
Be sure to use the manual mode if you want to drive the fan speed manually
NOTE2:
When operating in manual mode outside the vbios-defined
[PWM_min, PWM_max] range, the reported fan speed (RPM) may not be accurate
depending on your hardware.
Bug reports
-----------
Thermal management on Nouveau is new and may not work on all cards. If you have
inquiries, please ping mupuf on IRC (#nouveau, OFTC).
Bug reports should be filled on Freedesktop's bug tracker. Please follow
https://nouveau.freedesktop.org/wiki/Bugs
linux-7.2.3/Documentation/driver-api/thermal/power_allocator.rst
+281
View File
@@ -0,0 +1,281 @@
=================================
Power allocator governor tunables
=================================
Trip points
-----------
The governor works optimally with the following two passive trip points:
1. "switch on" trip point: temperature above which the governor
control loop starts operating. This is the first passive trip
point of the thermal zone.
2. "desired temperature" trip point: it should be higher than the
"switch on" trip point. This the target temperature the governor
is controlling for. This is the last passive trip point of the
thermal zone.
PID Controller
--------------
The power allocator governor implements a
Proportional-Integral-Derivative controller (PID controller) with
temperature as the control input and power as the controlled output:
P_max = k_p * e + k_i * err_integral + k_d * diff_err + sustainable_power
where
- e = desired_temperature - current_temperature
- err_integral is the sum of previous errors
- diff_err = e - previous_error
It is similar to the one depicted below::
k_d
|
current_temp |
| v
| +----------+ +---+
| +----->| diff_err |-->| X |------+
| | +----------+ +---+ |
| | | tdp actor
| | k_i | | get_requested_power()
| | | | | | |
| | | | | | | ...
v | v v v v v
+---+ | +-------+ +---+ +---+ +---+ +----------+
| S |-----+----->| sum e |----->| X |--->| S |-->| S |-->|power |
+---+ | +-------+ +---+ +---+ +---+ |allocation|
^ | ^ +----------+
| | | | |
| | +---+ | | |
| +------->| X |-------------------+ v v
| +---+ granted performance
desired_temperature ^
|
|
k_po/k_pu
Sustainable power
-----------------
An estimate of the sustainable dissipatable power (in mW) should be
provided while registering the thermal zone. This estimates the
sustained power that can be dissipated at the desired control
temperature. This is the maximum sustained power for allocation at
the desired maximum temperature. The actual sustained power can vary
for a number of reasons. The closed loop controller will take care of
variations such as environmental conditions, and some factors related
to the speed-grade of the silicon. `sustainable_power` is therefore
simply an estimate, and may be tuned to affect the aggressiveness of
the thermal ramp. For reference, the sustainable power of a 4" phone
is typically 2000mW, while on a 10" tablet is around 4500mW (may vary
depending on screen size). It is possible to have the power value
expressed in an abstract scale. The sustained power should be aligned
to the scale used by the related cooling devices.
If you are using device tree, do add it as a property of the
thermal-zone. For example::
thermal-zones {
soc_thermal {
polling-delay = <1000>;
polling-delay-passive = <100>;
sustainable-power = <2500>;
...
Instead, if the thermal zone is registered from the platform code, pass a
`thermal_zone_params` that has a `sustainable_power`. If no
`thermal_zone_params` were being passed, then something like below
will suffice::
static const struct thermal_zone_params tz_params = {
.sustainable_power = 3500,
};
and then pass `tz_params` as the 5th parameter to
`thermal_zone_device_register()`
k_po and k_pu
-------------
The implementation of the PID controller in the power allocator
thermal governor allows the configuration of two proportional term
constants: `k_po` and `k_pu`. `k_po` is the proportional term
constant during temperature overshoot periods (current temperature is
above "desired temperature" trip point). Conversely, `k_pu` is the
proportional term constant during temperature undershoot periods
(current temperature below "desired temperature" trip point).
These controls are intended as the primary mechanism for configuring
the permitted thermal "ramp" of the system. For instance, a lower
`k_pu` value will provide a slower ramp, at the cost of capping
available capacity at a low temperature. On the other hand, a high
value of `k_pu` will result in the governor granting very high power
while temperature is low, and may lead to temperature overshooting.
The default value for `k_pu` is::
2 * sustainable_power / (desired_temperature - switch_on_temp)
This means that at `switch_on_temp` the output of the controller's
proportional term will be 2 * `sustainable_power`. The default value
for `k_po` is::
sustainable_power / (desired_temperature - switch_on_temp)
Focusing on the proportional and feed forward values of the PID
controller equation we have::
P_max = k_p * e + sustainable_power
The proportional term is proportional to the difference between the
desired temperature and the current one. When the current temperature
is the desired one, then the proportional component is zero and
`P_max` = `sustainable_power`. That is, the system should operate in
thermal equilibrium under constant load. `sustainable_power` is only
an estimate, which is the reason for closed-loop control such as this.
Expanding `k_pu` we get::
P_max = 2 * sustainable_power * (T_set - T) / (T_set - T_on) +
sustainable_power
where:
- T_set is the desired temperature
- T is the current temperature
- T_on is the switch on temperature
When the current temperature is the switch_on temperature, the above
formula becomes::
P_max = 2 * sustainable_power * (T_set - T_on) / (T_set - T_on) +
sustainable_power = 2 * sustainable_power + sustainable_power =
3 * sustainable_power
Therefore, the proportional term alone linearly decreases power from
3 * `sustainable_power` to `sustainable_power` as the temperature
rises from the switch on temperature to the desired temperature.
k_i and integral_cutoff
-----------------------
`k_i` configures the PID loop's integral term constant. This term
allows the PID controller to compensate for long term drift and for
the quantized nature of the output control: cooling devices can't set
the exact power that the governor requests. When the temperature
error is below `integral_cutoff`, errors are accumulated in the
integral term. This term is then multiplied by `k_i` and the result
added to the output of the controller. Typically `k_i` is set low (1
or 2) and `integral_cutoff` is 0.
k_d
---
`k_d` configures the PID loop's derivative term constant. It's
recommended to leave it as the default: 0.
Cooling device power API
========================
Cooling devices controlled by this governor must supply the additional
"power" API in their `cooling_device_ops`. It consists on three ops:
1. ::
int get_requested_power(struct thermal_cooling_device *cdev,
struct thermal_zone_device *tz, u32 *power);
@cdev:
The `struct thermal_cooling_device` pointer
@tz:
thermal zone in which we are currently operating
@power:
pointer in which to store the calculated power
`get_requested_power()` calculates the power requested by the device
in milliwatts and stores it in @power . It should return 0 on
success, -E* on failure. This is currently used by the power
allocator governor to calculate how much power to give to each cooling
device.
2. ::
int state2power(struct thermal_cooling_device *cdev, struct
thermal_zone_device *tz, unsigned long state,
u32 *power);
@cdev:
The `struct thermal_cooling_device` pointer
@tz:
thermal zone in which we are currently operating
@state:
A cooling device state
@power:
pointer in which to store the equivalent power
Convert cooling device state @state into power consumption in
milliwatts and store it in @power. It should return 0 on success, -E*
on failure. This is currently used by thermal core to calculate the
maximum power that an actor can consume.
3. ::
int power2state(struct thermal_cooling_device *cdev, u32 power,
unsigned long *state);
@cdev:
The `struct thermal_cooling_device` pointer
@power:
power in milliwatts
@state:
pointer in which to store the resulting state
Calculate a cooling device state that would make the device consume at
most @power mW and store it in @state. It should return 0 on success,
-E* on failure. This is currently used by the thermal core to convert
a given power set by the power allocator governor to a state that the
cooling device can set. It is a function because this conversion may
depend on external factors that may change so this function should the
best conversion given "current circumstances".
Cooling device weights
----------------------
Weights are a mechanism to bias the allocation among cooling
devices. They express the relative power efficiency of different
cooling devices. Higher weight can be used to express higher power
efficiency. Weighting is relative such that if each cooling device
has a weight of one they are considered equal. This is particularly
useful in heterogeneous systems where two cooling devices may perform
the same kind of compute, but with different efficiency. For example,
a system with two different types of processors.
If the thermal zone is registered using
`thermal_zone_device_register()` (i.e., platform code), then weights
are passed as part of the thermal zone's `thermal_bind_parameters`.
If the platform is registered using device tree, then they are passed
as the `contribution` property of each map in the `cooling-maps` node.
Limitations of the power allocator governor
===========================================
The power allocator governor's PID controller works best if there is a
periodic tick. If you have a driver that calls
`thermal_zone_device_update()` (or anything that ends up calling the
governor's `throttle()` function) repetitively, the governor response
won't be very good. Note that this is not particular to this
governor, step-wise will also misbehave if you call its throttle()
faster than the normal thermal framework tick (due to interrupts for
example) as it will overreact.
Energy Model requirements
=========================
Another important thing is the consistent scale of the power values
provided by the cooling devices. All of the cooling devices in a single
thermal zone should have power values reported either in milli-Watts
or scaled to the same 'abstract scale'.
linux-7.2.3/Documentation/driver-api/thermal/sysfs-api.rst
+433
View File
@@ -0,0 +1,433 @@
===================================
Generic Thermal Sysfs driver How To
===================================
Written by Sujith Thomas <sujith.thomas@intel.com>, Zhang Rui <rui.zhang@intel.com>
Copyright (c) 2008 Intel Corporation
0. Introduction
===============
The generic thermal sysfs provides a set of interfaces for thermal zone
devices (sensors) and thermal cooling devices (fan, processor...) to register
with the thermal management solution and to be a part of it.
This how-to focuses on enabling new thermal zone and cooling devices to
participate in thermal management.
This solution is platform independent and any type of thermal zone devices
and cooling devices should be able to make use of the infrastructure.
The main task of the thermal sysfs driver is to expose thermal zone attributes
as well as cooling device attributes to the user space.
An intelligent thermal management application can make decisions based on
inputs from thermal zone attributes (the current temperature and trip point
temperature) and throttle appropriate devices.
- `[0-*]` denotes any positive number starting from 0
- `[1-*]` denotes any positive number starting from 1
1. thermal sysfs driver interface functions
===========================================
1.1 thermal zone device interface
---------------------------------
::
struct thermal_zone_device *
thermal_zone_device_register_with_trips(const char *type,
const struct thermal_trip *trips,
int num_trips, void *devdata,
const struct thermal_zone_device_ops *ops,
const struct thermal_zone_params *tzp,
unsigned int passive_delay,
unsigned int polling_delay)
This interface function adds a new thermal zone device (sensor) to the
/sys/class/thermal folder as `thermal_zone[0-*]`. It tries to bind all the
thermal cooling devices registered to it at the same time.
type:
the thermal zone type.
trips:
the table of trip points for this thermal zone.
devdata:
device private data
ops:
thermal zone device call-backs.
.should_bind:
check whether or not a given cooling device should be bound to
a given trip point in this thermal zone.
.get_temp:
get the current temperature of the thermal zone.
.set_trips:
set the trip points window. Whenever the current temperature
is updated, the trip points immediately below and above the
current temperature are found.
.change_mode:
change the mode (enabled/disabled) of the thermal zone.
.set_trip_temp:
set the temperature of a given trip point.
.get_crit_temp:
get the critical temperature for this thermal zone.
.set_emul_temp:
set the emulation temperature which helps in debugging
different threshold temperature points.
.get_trend:
get the trend of most recent zone temperature changes.
.hot:
hot trip point crossing handler.
.critical:
critical trip point crossing handler.
tzp:
thermal zone platform parameters.
passive_delay:
number of milliseconds to wait between polls when performing passive
cooling.
polling_delay:
number of milliseconds to wait between polls when checking
whether trip points have been crossed (0 for interrupt driven systems).
::
void thermal_zone_device_unregister(struct thermal_zone_device *tz)
This interface function removes the thermal zone device.
It deletes the corresponding entry from /sys/class/thermal folder and
unbinds all the thermal cooling devices it uses.
::
struct thermal_zone_device
*thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
void *data,
const struct thermal_zone_of_device_ops *ops)
This interface adds a new sensor to a DT thermal zone.
This function will search the list of thermal zones described in
device tree and look for the zone that refer to the sensor device
pointed by dev->of_node as temperature providers. For the zone
pointing to the sensor node, the sensor will be added to the DT
thermal zone device.
The parameters for this interface are:
dev:
Device node of sensor containing valid node pointer in
dev->of_node.
sensor_id:
a sensor identifier, in case the sensor IP has more
than one sensors
data:
a private pointer (owned by the caller) that will be
passed back, when a temperature reading is needed.
ops:
`struct thermal_zone_of_device_ops *`.
============== =======================================
get_temp a pointer to a function that reads the
sensor temperature. This is mandatory
callback provided by sensor driver.
set_trips a pointer to a function that sets a
temperature window. When this window is
left the driver must inform the thermal
core via thermal_zone_device_update.
get_trend a pointer to a function that reads the
sensor temperature trend.
set_emul_temp a pointer to a function that sets
sensor emulated temperature.
============== =======================================
The thermal zone temperature is provided by the get_temp() function
pointer of thermal_zone_of_device_ops. When called, it will
have the private pointer @data back.
It returns error pointer if fails otherwise valid thermal zone device
handle. Caller should check the return handle with IS_ERR() for finding
whether success or not.
::
void thermal_zone_of_sensor_unregister(struct device *dev,
struct thermal_zone_device *tzd)
This interface unregisters a sensor from a DT thermal zone which was
successfully added by interface thermal_zone_of_sensor_register().
This function removes the sensor callbacks and private data from the
thermal zone device registered with thermal_zone_of_sensor_register()
interface. It will also silent the zone by remove the .get_temp() and
get_trend() thermal zone device callbacks.
::
struct thermal_zone_device
*devm_thermal_zone_of_sensor_register(struct device *dev,
int sensor_id,
void *data,
const struct thermal_zone_of_device_ops *ops)
This interface is resource managed version of
thermal_zone_of_sensor_register().
All details of thermal_zone_of_sensor_register() described in
section 1.1.3 is applicable here.
The benefit of using this interface to register sensor is that it
is not require to explicitly call thermal_zone_of_sensor_unregister()
in error path or during driver unbinding as this is done by driver
resource manager.
::
void devm_thermal_zone_of_sensor_unregister(struct device *dev,
struct thermal_zone_device *tzd)
This interface is resource managed version of
thermal_zone_of_sensor_unregister().
All details of thermal_zone_of_sensor_unregister() described in
section 1.1.4 is applicable here.
Normally this function will not need to be called and the resource
management code will ensure that the resource is freed.
::
int thermal_zone_get_slope(struct thermal_zone_device *tz)
This interface is used to read the slope attribute value
for the thermal zone device, which might be useful for platform
drivers for temperature calculations.
::
int thermal_zone_get_offset(struct thermal_zone_device *tz)
This interface is used to read the offset attribute value
for the thermal zone device, which might be useful for platform
drivers for temperature calculations.
1.2 thermal cooling device interface
------------------------------------
::
struct thermal_cooling_device
*thermal_cooling_device_register(char *name,
void *devdata, struct thermal_cooling_device_ops *)
This interface function adds a new thermal cooling device (fan/processor/...)
to /sys/class/thermal/ folder as `cooling_device[0-*]`. It tries to bind itself
to all the thermal zone devices registered at the same time.
name:
the cooling device name.
devdata:
device private data.
ops:
thermal cooling devices call-backs.
.get_max_state:
get the Maximum throttle state of the cooling device.
.get_cur_state:
get the Currently requested throttle state of the
cooling device.
.set_cur_state:
set the Current throttle state of the cooling device.
::
void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
This interface function removes the thermal cooling device.
It deletes the corresponding entry from /sys/class/thermal folder and
unbinds itself from all the thermal zone devices using it.
1.4 Thermal Zone Parameters
---------------------------
::
struct thermal_zone_params
This structure defines the platform level parameters for a thermal zone.
This data, for each thermal zone should come from the platform layer.
This is an optional feature where some platforms can choose not to
provide this data.
.governor_name:
Name of the thermal governor used for this zone
.no_hwmon:
a boolean to indicate if the thermal to hwmon sysfs interface
is required. when no_hwmon == false, a hwmon sysfs interface
will be created. when no_hwmon == true, nothing will be done.
In case the thermal_zone_params is NULL, the hwmon interface
will be created (for backward compatibility).
2. sysfs attributes structure
=============================
== ================
RO read only value
WO write only value
RW read/write value
== ================
Thermal sysfs attributes will be represented under /sys/class/thermal.
Hwmon sysfs I/F extension is also available under /sys/class/hwmon
if hwmon is compiled in or built as a module.
Thermal zone device sys I/F, created once it's registered::
/sys/class/thermal/thermal_zone[0-*]:
|---type: Type of the thermal zone
|---temp: Current temperature
|---mode: Working mode of the thermal zone
|---policy: Thermal governor used for this zone
|---available_policies: Available thermal governors for this zone
|---trip_point_[0-*]_temp: Trip point temperature
|---trip_point_[0-*]_type: Trip point type
|---trip_point_[0-*]_hyst: Hysteresis value for this trip point
|---emul_temp: Emulated temperature set node
|---sustainable_power: Sustainable dissipatable power
|---k_po: Proportional term during temperature overshoot
|---k_pu: Proportional term during temperature undershoot
|---k_i: PID's integral term in the power allocator gov
|---k_d: PID's derivative term in the power allocator
|---integral_cutoff: Offset above which errors are accumulated
|---slope: Slope constant applied as linear extrapolation
|---offset: Offset constant applied as linear extrapolation
Thermal cooling device sys I/F, created once it's registered::
/sys/class/thermal/cooling_device[0-*]:
|---type: Type of the cooling device(processor/fan/...)
|---max_state: Maximum cooling state of the cooling device
|---cur_state: Current cooling state of the cooling device
|---stats: Directory containing cooling device's statistics
|---stats/reset: Writing any value resets the statistics
|---stats/time_in_state_ms: Time (msec) spent in various cooling states
|---stats/total_trans: Total number of times cooling state is changed
|---stats/trans_table: Cooling state transition table
Then next two dynamic attributes are created/removed in pairs. They represent
the relationship between a thermal zone and its associated cooling device.
::
/sys/class/thermal/thermal_zone[0-*]:
|---cdev[0-*]: [0-*]th cooling device in current thermal zone
|---cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with
|---cdev[0-*]_weight: Influence of the cooling device in
this thermal zone
Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
the generic thermal driver also creates a hwmon sysfs I/F for each _type_
of thermal zone device. E.g. the generic thermal driver registers one hwmon
class device and build the associated hwmon sysfs I/F for all the registered
ACPI thermal zones.
Please read Documentation/ABI/testing/sysfs-class-thermal for thermal
zone and cooling device attribute details.
::
/sys/class/hwmon/hwmon[0-*]:
|---name: The type of the thermal zone devices
|---temp[1-*]_input: The current temperature of thermal zone [1-*]
|---temp[1-*]_critical: The critical trip point of thermal zone [1-*]
Please read Documentation/hwmon/sysfs-interface.rst for additional information.
3. A simple implementation
==========================
ACPI thermal zone may support multiple trip points like critical, hot,
passive, active. If an ACPI thermal zone supports critical, passive,
active[0] and active[1] at the same time, it may register itself as a
thermal_zone_device (thermal_zone1) with 4 trip points in all.
It has one processor and one fan, which are both registered as
thermal_cooling_device. Both are considered to have the same
effectiveness in cooling the thermal zone.
If the processor is listed in _PSL method, and the fan is listed in _AL0
method, the sys I/F structure will be built like this::
/sys/class/thermal:
|thermal_zone1:
|---type: acpitz
|---temp: 37000
|---mode: enabled
|---policy: step_wise
|---available_policies: step_wise fair_share
|---trip_point_0_temp: 100000
|---trip_point_0_type: critical
|---trip_point_1_temp: 80000
|---trip_point_1_type: passive
|---trip_point_2_temp: 70000
|---trip_point_2_type: active0
|---trip_point_3_temp: 60000
|---trip_point_3_type: active1
|---cdev0: --->/sys/class/thermal/cooling_device0
|---cdev0_trip_point: 1 /* cdev0 can be used for passive */
|---cdev0_weight: 1024
|---cdev1: --->/sys/class/thermal/cooling_device3
|---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
|---cdev1_weight: 1024
|cooling_device0:
|---type: Processor
|---max_state: 8
|---cur_state: 0
|cooling_device3:
|---type: Fan
|---max_state: 2
|---cur_state: 0
/sys/class/hwmon:
|hwmon0:
|---name: acpitz
|---temp1_input: 37000
|---temp1_crit: 100000
4. Export Symbol APIs
=====================
4.1. get_tz_trend
-----------------
This function returns the trend of a thermal zone, i.e the rate of change
of temperature of the thermal zone. Ideally, the thermal sensor drivers
are supposed to implement the callback. If they don't, the thermal
framework calculated the trend by comparing the previous and the current
temperature values.
4.2. thermal_cdev_update
------------------------
This function serves as an arbitrator to set the state of a cooling
device. It sets the cooling device to the deepest cooling state if
possible.
5. Critical Events
==================
On an event of critical trip temperature crossing, the thermal framework
will trigger a hardware protection power-off (shutdown) or reboot,
depending on configuration.
At first, the kernel will attempt an orderly power-off or reboot, but
accepts a delay after which it proceeds to do a forced power-off or
reboot, respectively. If this fails, ``emergency_restart()`` is invoked
as last resort.
The delay should be carefully profiled so as to give adequate time for
orderly power-off or reboot.
If the delay is set to 0, the emergency action will not be supported. So a
carefully profiled non-zero positive value is a must for the emergency
action to be triggered.
linux-7.2.3/Documentation/driver-api/thermal/x86_pkg_temperature_thermal.rst
+55
View File
@@ -0,0 +1,55 @@
===================================
Kernel driver: x86_pkg_temp_thermal
===================================
Supported chips:
* x86: with package level thermal management
(Verify using: CPUID.06H:EAX[bit 6] =1)
Authors: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reference
---------
Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013):
Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT
Description
-----------
This driver register CPU digital temperature package level sensor as a thermal
zone with maximum two user mode configurable trip points. Number of trip points
depends on the capability of the package. Once the trip point is violated,
user mode can receive notification via thermal notification mechanism and can
take any action to control temperature.
Threshold management
--------------------
Each package will register as a thermal zone under /sys/class/thermal.
Example::
/sys/class/thermal/thermal_zone1
This contains two trip points:
- trip_point_0_temp
- trip_point_1_temp
User can set any temperature between 0 to TJ-Max temperature. Temperature units
are in milli-degree Celsius. Refer to "Documentation/driver-api/thermal/sysfs-api.rst" for
thermal sys-fs details.
Any value other than 0 in these trip points, can trigger thermal notifications.
Setting 0, stops sending thermal notifications.
Thermal notifications:
To get kobject-uevent notifications, set the thermal zone
policy to "user_space".
For example::
echo -n "user_space" > policy