一、背景
在科技發展日新月異的如今，隨着設備性能越來越強勁，設備中各個器件工作時產生的熱量也越來越高。而移動設備發熱是影響用戶體驗的重要因素，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等溫控算法也一直在不斷演進；相信未來的移動終端產品在發熱方面會有越來越好的表現。