“热散由心静，凉生为室空” - linux温控的那些事儿

一、背景

在科技发展日新月异的如今，随着设备性能越来越强劲，设备中各个器件工作时产生的热量也越来越高。而移动设备发热是影响用户体验的重要因素，SoC 等硬件芯片也会因过热而造成系统不稳定，甚至缩减芯片寿命，“如何给设备降温“成为了当下一个重要的课题。

移动终端结构紧凑，内部空间可说是寸土寸金，这就使得台式机上风冷、水冷等常规硬件散热手段在手机上没有用武之地，软件温控成了控制设备发热的关键武器。毕竟无法“小扇引微凉，悠悠夏日长”，那就得操作系统发挥主观能动性，“热散由心静，凉生为室空”，减少不必要的活动，控制自身的发热量。接下来我们一起去看一看Linux为了降温都做了哪些事。

二、Linux温控框架

LinuxThermal Framework是Linux系统下温度控制相关的一套架构，主要用来控制系统运行过程中各个器件所产生的热量，使设备温度维持在一个安全、舒适的范围。

从系统不同层级的角度可以划分为以下三个部分：

• Userspace(用户空间):表现形式为sysfs文件节点。路径为sys/class/thermal/，thermal_zone设备为thermal_zone[n]文件目录, cooling_device设备为cooling_device[n]文件目录。用户空间的软件可以通过访问thermal class的文件来获取到各个温区当前的温度以及温控触发点等信息，如果具有某些权限，甚至可以通过设置冷却设备下的状态值来更改温控的策略。目录下的各个文件的作用与意义下一节再详述。

• Kernelspace(内核空间):核心为thermal_core。获取温度的设备抽象为thermal_zone_device, 控制温度的设备抽象为thermal_cooling_device,温控策略抽象为thermal_governor。

• Hardware(硬件层):thermal_zone -> tsens0, tsens1, …，硬件上的温控传感器及热敏电阻等被软件抽象为温区; cooling_device -> cpu, gpu, battery, …，可以通过调整自身状态来达到温度控制的IP被软件抽象为冷却设备。

三、Thermal Zone（温区）与Cooling Device（冷却设备）

图2为某款移动终端SOC的温度传感器布局图，片上有28颗传感器，分别监控各个子系统的当前温度。同样在PCB上还包含有多个热敏电阻(NTC), 这些NTC通过算法的计算后可以获得手机主板上各个区域的温度。

软件上将这些tsensor及ntc等可以获取温度的设备描述为thermal zone, 在代码中以dts的形式来描述。

• 示例代码：

• polling-delay-passive:温控发生时的轮询周期。

上文配置为0，代表不使用轮询方式，通过tsensor中断触发温控。

• polling-delay:温控未发生时轮询周期。

• thermal-governor:该温区发生温控时所使用的算法。

上文选择为”user_space”算法，下一节将详述该算法。

• thermal-sensors:对应的tsensor。

上文配置为”tsens0 1”代表使用tsens0这个温度传感器的通道1。

• trips:温控触发点。

其中”active-config0”为该温区的温控触发点。

temperture为触发温度，上文中的配置为(125000) / 1000 = 125度发生温控；

hysteresis为滞后温度，上文配置为”1000”, 表示当该温区温度下降到(125 – 1000/1000) = 124度时解除温控。

type配置为”passive”，即当温控发生后，轮询周期改为使用polling-delay-passive。

上述为thermal_zone在编码阶段的描述形式。当操作系统运行后，thermal_zone在用户空间以sysfs文件形式呈现。

• available_policies:可选择的温控算法。

• type:该温区的名称。

如上文中的“aoss-0-usr”，”cpu-0-0-usr”等dts node名称。

• temp:该温区的当前温度。

trip_point_0_type/trip_point_0_temp/trip_point_0_hyst:触发点0的名称/触发温度/滞后温度。

如上文中的”active-config0”, “temperature”,“hysteresis”。

现在我们已经将tsensor跟NTC以thermal_zone的形式注册到系统中，可以实时的监控设备各个子系统的发热状况。当温度超过所设阈值时，将会上报中断，接下来就是冷却设备的表演时刻了。这些可以通过控制自己的状态达到降温效果的设备，操作系统将其抽象为cooling_device（冷却设备）。像cpufreq, devfreq等driver在初始化的时候会调用of_thermal.c提供的接口在thermal_core中注册cooling device。

• 实例代码：
  

• polling-delay-passive:温控发生时的轮询周期。

上文配置为0，代表不使用轮询方式，通过tsensor中断触发温控。

• polling-delay:温控未发生时轮询周期。

• thermal-governor:该温区发生温控时所使用的算法。

上文选择为”user_space”算法，下一节将详述该算法。

• thermal-sensors:对应的tsensor。

上文配置为”tsens0 1”代表使用tsens0这个温度传感器的通道1。

• trips:温控触发点。

其中”active-config0”为该温区的温控触发点。

temperture为触发温度，上文中的配置为(125000) / 1000 = 125度发生温控；

hysteresis为滞后温度，上文配置为”1000”, 表示当该温区温度下降到(125 – 1000/1000) = 124度时解除温控。

type配置为”passive”，即当温控发生后，轮询周期改为使用polling-delay-passive。

上述为thermal_zone在编码阶段的描述形式。当操作系统运行后，thermal_zone在用户空间以sysfs文件形式呈现。

• available_policies:可选择的温控算法。

• type:该温区的名称。

如上文中的“aoss-0-usr”，”cpu-0-0-usr”等dts node名称。

• temp:该温区的当前温度。

• trip_point_0_type/trip_point_0_temp/trip_point_0_hyst:触发点0的名称/触发温度/滞后温度。

如上文中的”active-config0”, “temperature”,“hysteresis”。

现在我们已经将tsensor跟NTC以thermal_zone的形式注册到系统中，可以实时的监控设备各个子系统的发热状况。当温度超过所设阈值时，将会上报中断，接下来就是冷却设备的表演时刻了。这些可以通过控制自己的状态达到降温效果的设备，操作系统将其抽象为cooling_device（冷却设备）。像cpufreq, devfreq等driver在初始化的时候会调用of_thermal.c提供的接口在thermal_core中注册cooling device。

• 实例代码：
  

• cooling-maps：

该温区对应到的冷却设备列表。

• cpu00_cdev：

冷却设备的名称。

• trip:该冷却设备对应的温区温控触发点。

上文中，“cpu00_cdev“对应的触发点为”cpu00_config”，即当”cpu-0-0-step”这个温区达到110度时，触发冷却操作。

• cooling-device:对应的真正执行冷却操作的设备及最大/最小状态，格式为< phandle of device, min_state,max_state>。

上文中配置为”cpu0_isolate 11“，即达到该触发点时，对CPU0进行isolate。

当操作系统运行后，cooling_device同样以sysfs文件形式在用户空间呈现

• cur_state:该cooling_device的当前cooling state。

• max_state:该cooling_device的最大cooling state。

• type:该cooling device的名称。

四、Thermal Governor(温控算法)

Thermal Governor即温控算法，解决温控发生时，如何选择cooling state的问题。

当前可用的governor包括：

• bang_bang

• step_wise

• low_limits

• user_space

• power_allocator

• bang_bang governor:

由于bang_bang governor是用在使用风扇散热的设备中的算法。

首先我们需要确定throttle即温控是否触发。这包括了两种情况，第一种为当前温度大于温控阈值，第二种为当前温度小于温控阈值但是大于滞后温度(温控解除温度)，并且是处于降温的过程中。

bang_banggovernor的降温策略跟它的名字一样简单，可以用一句话来概括:
当throttle发生，打开风扇；当throttle解除，关闭风扇。

• step_wise governor:

step_wise算法在计算target cooling state的过程中，除了需要知道是否throttle,还添加了一个参考条: trend。trend顾名思义即温升趋势，Linux Thermal Framework定义了三种trend type，即上升（RAISING）,下降（DROPPING）与稳定(STABLE)。

step_wise governor对于cooling_state选择的策略：

当throttle发生且温升趋势为上升，使用更高一级的cooling state;

当throttle发生且温升趋势为下降，不改变cooling state；

当throttle解除且温升趋势为上升，不改变cooling state；

当throttle解除且温升趋势为下降，使用更低一级的cooling state；

step_wise governor是每个轮询周期逐级提高冷却状态，是一种相对温和的温控策略。

• low_limit governor:

移动设备在温度比较低的情况下同样会存在诸如无法充电等问题，所以low_limitgovernor应运而生，这个特殊的温控算法用于低温环境下的设备加热。
它的温控策略基本上就是反向的step_wise，在这里就不进一步展开叙述了，感兴趣的同学可以自行查看kernel源码。

• user_space governor:

user_spacegovernor是通过uevent将温区当前温度，温控触发点等信息上报到用户空间，由用户空间软件制定温控的策略。

• power_allocator governor:

power_allocatorgovernor即IPA算法，是由ARM 在2015年提交及纳入Linuxkernel mainline。

IPA（Intelligent PowerAllocator）模型的核心是利用PID控制器，ThermalZone的温度作为输入，可分配功耗值作为输出，调节Allocator的频率和电压值。由于篇幅所限，具体的温控策略不再详述。

五、后续Linux thermal发展方向

如何控制移动终端发热，在性能与功耗之间取得绝佳的平衡，一直以来都是各大移动芯片与终端厂商持续努力的方向；而在开源社区，像IPA等温控算法也一直在不断演进；相信未来的移动终端产品在发热方面会有越来越好的表现。