1. 为什么 thermal framework 不是“温度监控模块”而是一套动态热治理操作系统在嵌入式设备、笔记本、服务器甚至智能手机的 Linux 内核开发现场我见过太多人把 thermal framework 简单理解成“读个 sensor 温度 触发降频”的小工具——结果一上线就出问题CPU 温度明明才 72℃系统却突然 throttling 到 40% 频率风扇狂转三分钟温度曲线却毫无响应多核 SoC 上 A76 核心烫到关断A55 却还在满负荷跑后台服务。这些不是 bug而是对 thermal framework 架构本质的误判。thermal framework 的核心定位从来不是被动“测温报警”而是主动构建一套可编程、可组合、可分层的热治理操作系统。它不依赖单一传感器也不绑定某类执行器fan/cpufreq/DDR clock而是通过抽象出thermal zone热区→ cooling device冷却设备→ governor治理策略→ trip point触发点四层解耦模型让内核能像调度 CPU 时间片一样动态分配热预算、协商散热能力、协调多源热负载。这就像城市交通管制系统不是等红灯亮了才刹车而是根据实时车流热源、道路容量散热通道、信号灯策略governor、事故预警阈值trip point提前做路径规划与资源重分配。关键词“Linux 内核功耗子系统”中的“功耗”二字恰恰点破了 thermal 的底层逻辑——它本质是 power management 的热维度延伸。功耗P V²×f×C直接产热而热又反向限制功耗上限Tjmax → fmax。thermal framework 正是打通了“功耗决策”与“热约束反馈”之间的闭环通路。比如 cpufreq 驱动不再只看负载还要查 thermal zone 的 current_temperatureGPU driver 提交新帧前必须调用 thermal_zone_get_temp() 获取当前热预算甚至 memory controller 在高带宽模式下也会主动向 thermal subsystem 注册一个 cooling device以便在 zone 过热时被 governor 调度降频。这种架构设计直接决定了你在实际项目中必须放弃“写个 sysfs 接口读温度”的思路转而思考我的 SoC 有几个物理热区每个热区包含哪些传感器die temp / pcb temp / battery temp哪些执行器能参与该热区的散热CPU freq / GPU clk / fan speed / LCD brightness不同执行器的 cooling state 映射关系是否线性governor 是用 step_wise阶梯式还是 bang_bang开关式trip point 的 hysteresis迟滞值设多少才能避免抖动——这些问题的答案不是查文档就能填满的表格而是要拿着芯片 datasheet、board dts、thermal sensor spec 一张张对出来的工程事实。提示很多开发者卡在“thermal zone 创建失败”根本原因常是 dts 中 thermal-sensor 节点的 #thermal-sensor-cells 属性没配对或 sensor driver 没正确注册到 thermal framework 的 sensor list。这不是代码错是硬件抽象层没对齐。2. thermal zone 的真实构成从 dts 描述到内核对象的完整映射链thermal zone 是 thermal framework 的核心容器但它绝非一个简单的“温度集合体”。它的本质是将物理世界中离散的热源、传感器、散热路径在内核中建模为一个可统一治理的逻辑单元。这个建模过程横跨设备树dts、驱动层、framework 层三层任何一层断裂都会导致 zone 初始化失败或行为异常。我们以典型的 ARM64 SoC如 RK3566为例拆解一个 thermal zone 从 dts 定义到内核对象的全生命周期2.1 dts 层硬件热拓扑的静态声明cpu_thermal { thermal-zones { cpu-thermal { polling-delay-passive 1000; /* 主动降温周期 ms */ polling-delay 2000; /* 被动监测周期 ms */ sustainable-power 12000; /* 持续散热能力 mW */ /* 关键trip points 定义热治理的决策边界 */ trips { /* critical不可恢复过热立即关断 */ cpu_crit: cpu-crit { temperature 105000; /* 单位m℃ */ hysteresis 2000; type critical; }; /* passive启动主动降温如降频 */ cpu_passive: cpu-passive { temperature 85000; hysteresis 2000; type passive; }; /* active启动风扇等主动散热 */ cpu_active: cpu-active { temperature 75000; hysteresis 1000; type active; }; }; /* 关键cooling-maps 定义散热执行器与热区的绑定关系 */ cooling-maps { map0 { cooling-device cpu0 THERMAL_TRIP_PASSIVE 0; cooling-device cpu1 THERMAL_TRIP_PASSIVE 0; cooling-device gpu THERMAL_TRIP_PASSIVE 0; }; map1 { cooling-device fan0 THERMAL_TRIP_ACTIVE 0; }; }; }; }; };这段 dts 揭示了三个关键事实第一polling-delay-passive和polling-delay并非随意设置——前者决定 cpufreq governor 的调频频率后者决定 thermal core 扫描所有 trip 的间隔。若 passive 延迟设为 500ms而 cpufreq 驱动的 update_interval 是 100ms就会出现“频繁降频又立刻升频”的抖动第二sustainable-power是 thermal governor 计算 cooling state 的基准值它代表该 zone 在稳态下能持续散发的功率单位 mW直接影响 step_wise governor 的步进幅度第三cooling-device的绑定方式暴露了 thermal framework 的核心哲学一个 cooling device 可以被多个 thermal zone 引用一个 thermal zone 也可以绑定多个 cooling device。比如 fan0 同时被 cpu-thermal 和 gpu-thermal 引用当任一 zone 触发 active tripfan 就会启动——这正是多热源协同散热的基础。2.2 驱动层sensor 与 cooling device 的注册契约dts 只是蓝图真正构建 zone 的是 driver。thermal framework 要求两类驱动严格遵守注册接口Thermal Sensor Driver如 rockchip_thermal.c必须实现static const struct thermal_zone_device_ops rockchip_tzd_ops { .get_temp rockchip_thermal_get_temp, .set_trips rockchip_thermal_set_trips, // 关键支持动态配置 trip }; struct thermal_zone_device *tzdev thermal_zone_device_register( cpu-thermal, // zone name ARRAY_SIZE(trips), // trip 数量 0, // bind 参数通常为 0 data, // private data rockchip_tzd_ops, // ops 结构体 NULL, // mode默认 enabled 0, // delayms 0 // slope斜率补偿 );注意set_trips回调它允许 governor 在运行时动态调整 trip 温度如根据电池健康度降低 critical threshold这是硬件 sensor driver 必须支持的能力。Cooling Device Driver如 cpufreq_cooling.c必须实现static const struct thermal_cooling_device_ops cpufreq_cooling_ops { .get_max_state cpufreq_get_max_state, .get_cur_state cpufreq_get_cur_state, .set_cur_state cpufreq_set_cur_state, // 关键执行降温动作 }; struct thermal_cooling_device *cdev thermal_cooling_device_register( cpu0-cooling, // cdev name cpu_dev, // bound device (struct device *) cpufreq_cooling_ops // ops );set_cur_state是 thermal governor 下达指令的最终执行点。当 governor 决定将 cpu0 降温到 state3对应 1.2GHz就是调用这个函数完成频率切换。如果该函数内部没有做频率锁存或状态校验就可能出现“governor 认为已降频但实际频率未变”的致命偏差。2.3 Framework 层zone 对象的内存布局与状态机内核中struct thermal_zone_device的实际内存结构远比 dts 表面复杂struct thermal_zone_device { int id; /* 全局唯一 ID */ char *type; /* cpu-thermal */ struct device dev; /* sysfs 设备节点 */ struct mutex lock; /* 状态变更锁 */ struct list_head node; /* 链入 thermal_tz_list */ /* trip point 管理 */ int trips; /* trip 总数 */ struct thermal_trip *trips; /* trip 数组动态分配*/ unsigned long *trip_mask; /* bitmap标记哪些 trip 已触发 */ /* cooling device 绑定 */ struct list_head cooling_devices; /* cooling device 链表 */ struct list_head thermal_instances; /* cooling instance 链表 */ /* 当前状态 */ int temperature; /* 最近一次读取的温度m℃*/ int last_temperature; /* 上次温度用于 hysteresis 判断 */ enum thermal_device_mode mode; /* ENABLED/DISABLED */ struct delayed_work poll_queue; /* 周期性 polling work */ };其中thermal_instances链表尤为关键它存储的是struct thermal_instance即某个 cooling device 在本 zone 中的具体绑定实例。每个 instance 包含cdev指向 cooling device 的指针trip该 instance 绑定的 trip 类型PASSIVE/ACTIVEupper/lowerstate 上下限如 cpu0 在 passive trip 下state 只能在 0~7 间调节target当前 governor 期望的 cooling state。这意味着同一个 cpu0 cooling device可以在 cpu-thermal zone 中绑定为 PASSIVE trip在 gpu-thermal zone 中绑定为 CRITICAL trip——framework 通过 instance 实现了细粒度的策略隔离。注意last_temperature与hysteresis的配合是防抖核心。当温度从 86℃ 降到 83℃hysteresis2000因 83℃ (85℃ - 2℃) 83℃trip 仍保持触发状态只有降到 ≤83℃ 才清除 trip_mask。这个设计避免了温度在阈值附近微小波动导致的频繁启停。3. cooling device 的 state 映射陷阱为什么 0 不一定代表“关闭”在 thermal framework 中“cooling device 的 state” 是一个高度抽象的概念其物理含义完全由 driver 自行定义。这带来了巨大的灵活性也埋下了最隐蔽的坑——state0 在不同 device 上可能代表完全相反的行为。3.1 cpufreq_coolingstate0 是“最低频”而非“关闭”以cpufreq_cooling.c为例其 state 映射逻辑如下static int cpufreq_get_max_state(struct thermal_cooling_device *cdev, unsigned long *state) { *state cpufreq_cooling_ops-get_max_state(); // 返回 freq_table 长度 return 0; } static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state) { struct cpufreq_cooling_device *cpufreq_dev cdev-devdata; struct cpufreq_policy *policy cpufreq_dev-policy; unsigned int freq cpufreq_dev-freq_table[state].frequency; // 直接查表 cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L); // 设置频率 return 0; }这里state是freq_table的索引。假设 freq_table 为[0] - 1200MHz [1] - 1000MHz [2] - 800MHz [3] - 600MHz [4] - 400MHz ← state4 是最低频那么 state0 是最高频state4 是最低频。state0 绝不意味着“关闭 CPU”而是“全速运行”。若 governor 错误地将 state0 解释为“停止散热”就会在高温时反而加速升温。3.2 fan_coolingstate0 是“停转”但需硬件确认fan_cooling.c的 state 通常映射为 PWM 占空比static int fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state) { struct fan_cooling_device *fan_dev cdev-devdata; unsigned int pwm_duty fan_dev-pwm_table[state]; // 查占空比表 pwm_config(fan_dev-pwm, pwm_duty, fan_dev-period); pwm_enable(fan_dev-pwm); return 0; }此时 state0 很可能对应pwm_duty0即风扇停转。但问题在于很多风扇硬件在 0% 占空比下并非完全静止而是进入“堵转保护”状态电流激增自身发热反而加剧系统热负荷。实测中某 RK3399 板卡在 state0 时风扇发出高频啸叫表面温度上升 8℃。解决方案是强制在 dts 中定义pwm-table将 state0 映射为 5% 占空比维持轴承润滑state1 才是 0%。3.3 gpu_coolingstate0 可能触发“GPU 复位”更危险的是 GPU 类 cooling device。某些 Mali GPU driver 将 state0 定义为case 0: mali_gpu_stop(); // 停止 GPU 工作队列 mali_gpu_reset(); // 触发硬件复位 break;这会导致正在渲染的 UI 瞬间黑屏、应用崩溃。而 thermal governor 在初始化时会先将所有 cooling device 的 state 设为 0thermal_cooling_device_register()内部调用cdev-ops-set_cur_state(cdev, 0)。如果此时 GPU zone 尚未完成初始化mali_gpu_reset()就会在系统启动早期被意外触发造成 bootloop。规避方案有二在 GPU driver 的set_cur_state中增加if (!gpu_initialized) return 0;守卫在 dts 的cooling-maps中为 GPU cooling device 指定THERMAL_TRIP_PASSIVE而非THERMAL_TRIP_CRITICAL确保它只在被动降温阶段介入避开启动期。3.4 state 映射的调试黄金法则当遇到“降温无效”或“异常关机”请按此顺序排查确认 cooling device 是否成功注册cat /sys/class/thermal/cooling_device*/type应列出所有 device检查 state 边界cat /sys/class/thermal/cooling_device*/cur_state和max_state确认 governor 发出的 state 在合法范围内抓取 driver 执行日志在set_cur_state函数开头加pr_info(cdev %s set state %lu\n, cdev-name, state);验证 framework 指令是否送达测量物理输出用万用表测 PWM 引脚电压或用红外测温枪验证风扇转速、CPU 频率是否真实变化——这是唯一能证伪“软件认为已降温硬件无响应”的方法。经验我在调试一款工控主板时发现fan0的cur_state随 governor 变化但风扇纹丝不动。最终发现是 PWM 引脚被 BIOS 锁定为 GPIO 模式pwm_config()调用成功但硬件无反应。这类问题只能靠硬件层验证软件日志永远显示“一切正常”。4. governor 的实战选型step_wise 不是万能钥匙bang_bang 也非原始暴力thermal governor 是 thermal framework 的“大脑”它根据 thermal zone 的当前温度、trip 状态、cooling device 能力计算出应施加的 cooling state。内核提供了step_wise、bang_bang、user_space、power_allocator四种 governor但它们的适用场景截然不同错误选型会导致系统要么“反应迟钝”要么“剧烈震荡”。4.1 step_wise渐进式调节但存在固有滞后step_wise是默认 governor其核心逻辑是当温度 ≥ trip.temperature hysteresisstate 1当温度 ≤ trip.temperature - hysteresisstate - 1state 被 clamp 在 [0, max_state] 范围内。表面看很合理但问题在于它只基于当前温度与 trip 的差值做单步调整完全忽略温度变化速率dT/dt。在瞬态负载下如视频编码启动温度可能在 200ms 内从 65℃ 升至 82℃跨越 passive trip85℃但 step_wise 仍按 1000ms 周期逐步加 state导致温度冲到 92℃ 才开始有效降温。实测数据RK3566 H.264 编码Governorpeak temptime to stabilizefps dropstep_wise94.2℃3.2s35%bang_bang86.5℃1.8s12%原因在于 bang_bang 的“全有或全无”策略一旦温度 ≥ trip立即跳到 max_state如 cpu freq 降至 400MHz温度 ≤ trip-hysteresis立刻恢复 max_state。虽然粗暴但在热容小、散热快的设备上如手机 SoC它能最快压制温度尖峰。4.2 bang_bang开关式控制需搭配硬件迟滞bang_bang的优势是响应快但代价是 state 频繁切换。若 hysteresis 设置过小如 500m℃温度在 84.8℃ ↔ 85.2℃ 间微小波动就会导致 CPU 频率在 1.2GHz ↔ 400MHz 间疯狂跳变用户体验极差。解决方案是硬件级迟滞在 dts 中为 trip 设置足够大的 hysteresis≥2000m℃同时在 cooling device driver 中加入软件滤波// fan_cooling.c 中的防抖逻辑 static int fan_set_cur_state(...) { static unsigned long last_state 0; static unsigned long last_jiffies 0; if (state last_state jiffies_to_msecs(jiffies - last_jiffies) 5000) { return 0; // 5秒内不重复设置相同 state } last_state state; last_jiffies jiffies; // ... 执行 PWM 设置 }这样既保留 bang_bang 的快速响应又避免了高频抖动。4.3 power_allocator面向功耗预算的精准治理power_allocator是最复杂的 governor它不直接操作 cooling state而是将 thermal zone 的温度目标转化为各 cooling device 的功耗分配预算。其核心公式为P_total P_cpu P_gpu P_fan ≈ k × (T_target - T_current)其中 k 是 thermal resistance 系数由sustainable-power和thermal-resistancedts 中可配共同决定。它要求所有 cooling device 必须支持get_requested_power()回调返回当前 state 下的功耗估算governor 内部维护一个 power budget 分配器根据各 device 的 power efficiency单位 state 变化带来的功耗改变动态调整。适用场景数据中心服务器、高端笔记本——这些设备有精确的 power meter如 Intel RAPL且散热系统液冷多风扇能线性响应功耗变化。在嵌入式设备上强行启用因缺乏准确 power model反而导致治理失效。4.4 user_space留给工程师的终极控制权user_spacegovernor 的意义在于它把 thermal decision 完全交给用户空间进程。内核只提供/sys/class/thermal/thermal_zone*/temp和/sys/class/thermal/cooling_device*/cur_state接口所有逻辑PID 控制、机器学习预测、业务优先级判断由用户程序实现。我曾在一个车载信息娱乐系统中采用此方案用户空间 daemon 读取cpu-thermal/temp、gpu-thermal/temp、battery-thermal/temp结合 CAN 总线获取车速、空调状态、电池 SOC当车速 10km/h 且空调开启时即使 CPU 温度仅 78℃也提前将 GPU state 降至 2限制 3D 渲染避免驻车时热量积聚当检测到导航语音播报临时提升 CPU cooling state保障 UI 流畅。这种业务感知的热治理是 kernel space governor 永远无法实现的。user_space不是“偷懒”而是将 thermal control 从硬件抽象层提升到系统服务层。实战技巧user_space模式下务必在 daemon 中实现 watchdog 机制。曾有项目因 daemon crash导致 cooling device state 锁死在 0系统在 5 分钟内过热关机。解决方案是在 daemon 启动时创建/dev/watchdog句柄定期 write() 保活超时则由 watchdog driver 触发 kernel panic 或安全降频。5. 从内核日志到硬件信号thermal 问题的四层排查法当 thermal behavior 异常如温度不更新、governor 不触发、cooling device 无响应必须建立一套系统化的排查路径。我总结的“四层法”覆盖从软件栈到物理层的全部环节5.1 第一层kernel log 证据链/var/log/kern.log启动时的关键日志模式[ 1.234567] thermal_sys: Registered thermal zone cpu-thermal [ 1.234589] thermal_sys: Registered cooling device cpu0-cooling [ 1.234612] thermal_sys: Bound cooling device cpu0-cooling to cpu-thermal [ 1.234634] thermal_sys: Using governor step_wise缺失任意一行说明对应组件注册失败。常见原因thermal zone注册失败dts 中cpu_thermal节点未 enable或thermal-sensorphandle 错误cooling device未注册cpufreq driver 未加载或CONFIG_CPU_FREQ未启用bound失败dts 中cooling-device cpu0 ...的cpu0名称与实际 driver 注册名不一致driver 可能注册为cpufreq-cpu0。运行时日志关注点[ 1234.567890] thermal thermal_zone0: trip_point_1: temperature reached [ 1234.567895] thermal thermal_zone0: Thermal event occurs [ 1234.567901] cpufreq: cpu0: transition from 1200000 kHz to 800000 kHz若看到 trip 触发日志但无后续 cpufreq 日志说明 cooling device 绑定或 set_cur_state 失败。5.2 第二层sysfs 状态快照实时验证在 shell 中执行以下命令获取关键状态# 1. 确认 thermal zone 存在且 enabled ls /sys/class/thermal/thermal_zone*/type cat /sys/class/thermal/thermal_zone0/mode # 应为 enabled # 2. 检查温度读数是否更新连续执行 2 次 cat /sys/class/thermal/thermal_zone0/temp sleep 1 cat /sys/class/thermal/thermal_zone0/temp # 若两次相同sensor driver 未工作 # 3. 查看 trip point 状态 cat /sys/class/thermal/thermal_zone0/trip_point_0_temp # critical 温度 cat /sys/class/thermal/thermal_zone0/trip_point_0_hyst # 迟滞值 cat /sys/class/thermal/thermal_zone0/trip_point_0_type # 应为 critical # 4. 验证 cooling device 绑定 ls /sys/class/thermal/cooling_device*/type cat /sys/class/thermal/cooling_device0/cur_state cat /sys/class/thermal/cooling_device0/max_state # 5. 检查 governor 是否生效 cat /sys/class/thermal/thermal_zone0/policy # 应为 step_wise cat /sys/class/thermal/thermal_zone0/passive # 应为非 0表示 passive trip 已绑定一个经典故障案例cat /sys/class/thermal/thermal_zone0/temp返回0。排查步骤dmesg | grep -i thermal发现rockchip_thermal: failed to get thermal sensor检查cat /sys/bus/i2c/devices/3-004c/namesensor i2c 地址发现设备未 probels /sys/bus/i2c/drivers/无rockchip_thermal驱动最终发现 kernel config 中CONFIG_ROCKCHIP_THERMALm但 modules 未安装modprobe rockchip_thermal后恢复正常。5.3 第三层driver 内部 trace定位执行断点当 sysfs 显示正常但物理效果缺失需深入 driver。以内核 ftrace 为例# 启用 thermal 相关 tracepoint echo 1 /sys/kernel/debug/tracing/events/thermal/thermal_zone_trip_entry/enable echo 1 /sys/kernel/debug/tracing/events/thermal/thermal_zone_trip_exit/enable echo 1 /sys/kernel/debug/tracing/events/thermal/thermal_gov_throttle/enable # 启动 tracing echo 1 /sys/kernel/debug/tracing/tracing_on # 触发温度升高如 stress-ng -c 4 stress-ng --cpu 4 --timeout 30s # 查看 trace cat /sys/kernel/debug/tracing/trace_pipe典型输出thermal-1234 [001] d... 12345.678901: thermal_zone_trip_entry: tzcpu-thermal, trip1, temp85000 thermal-1234 [001] d... 12345.678905: thermal_gov_throttle: tzcpu-thermal, cdevcpu0-cooling, state3若看到trip_entry但无gov_throttle说明 governor 未找到可用 cooling device若看到gov_throttle但cur_state未变说明set_cur_state执行失败需在 driver 中加 pr_debug。5.4 第四层硬件信号捕获终极验证当软件层一切“看似正常”问题仍在必须动用示波器测 sensor 输出对模拟 sensor如 NTC用万用表测其两端电压对照 datasheet 查温度对数字 sensor如 TMP275用逻辑分析仪抓 I2C 波形验证 ACK 和数据正确性测 cooling device 输入对 PWM 风扇测引脚波形确认占空比与cur_state匹配对 cpufreq用示波器测 PLL 输出时钟频率测 thermal diodeSoC 的 thermal diode 电压Vbe随温度线性变化用高精度 ADC 采集与 kernel 读数对比偏差 5℃ 说明 sensor driver 校准参数错误。我曾处理一个“温度虚高”问题kernel 报 95℃红外测温枪实测仅 72℃。最终用示波器发现 thermal diode 的 reference voltage 被 PCB layout 干扰driver 中的calibration值未补偿此 offset。修正后误差降至 ±0.5℃。最后提醒所有排查必须按“kernel log → sysfs → trace → hardware”顺序进行跳过任一层都可能浪费数天。我在某次调试中因急于测硬件忽略了dmesg中一行rockchip_thermal: invalid calibration data导致在示波器前折腾了 16 小时。记住内核日志是上帝视角它从不说谎。