1. 为什么今天还要深挖 thermal framework它不是“温度监控”那么简单在嵌入式设备发热冒烟、手机CPU被热限频卡顿、服务器机柜风扇狂转却仍触发高温关机的现场很多人第一反应是“换个散热器”或“调高风扇转速”。但真正有经验的内核开发者会立刻打开drivers/thermal/目录——因为问题根源不在硬件表层而在 thermal framework 这套被严重低估的软件调控中枢。它不是 Linux 内核里一个可有可无的“温度读取模块”而是与 CPUFreq、GPUFreq、devfreq、cpuidle、powercap 等子系统深度耦合的功耗调控决策引擎。我带团队做过三款 SoC 的 thermal 适配一款 ARM64 工业网关在 -20℃~70℃宽温域下频繁误触发降频另一款车规级芯片在车载空调启停瞬间出现 thermal zone 状态抖动第三款 AI 加速卡在推理峰值时 thermal governor 切换延迟导致局部过热。三次问题根因全指向对 thermal framework 通用架构理解偏差——比如把 trip point 当作静态阈值硬编码却忽略了其与 cooling device 的动态映射关系又比如误以为 thermal_zone_device_register() 只是注册一个传感器实则它构建的是整套策略执行上下文。你手头的dmesg | grep -i thermal输出里那些thermal thermal_zone0: critical temperature reached日志背后是 thermal core 在毫秒级完成 sensor 采样 → trip 判定 → cooling device 绑定 → governor 调度 → state 更新 的完整闭环。本文不讲 API 函数原型不列代码行号而是用真实调试日志、驱动注册时序图文字描述、governor 切换状态机拆解带你重建 thermal framework 的骨架脉络。适合正在调试板级 thermal 驱动的嵌入式工程师、想搞懂thermal_zone_get_temp()底层行为的驱动新手、以及需要为自研芯片定制 thermal policy 的内核维护者。如果你只满足于echo 0 /sys/class/thermal/thermal_zone0/mode临时关闭 thermal那这篇文章可能超纲但如果你曾为thermal_zone_device_update()不触发 cooling device 而抓耳挠腮恭喜你找对地方了。2. thermal framework 的四层架构从硬件感知到策略执行的完整链路2.1 架构全景thermal core 是调度中枢不是数据搬运工thermal framework 的通用架构绝非简单的“传感器→判断→动作”线性流程。它采用分层解耦设计核心由thermal core内核态框架、thermal drivers硬件适配层、cooling devices执行单元和governors策略引擎四部分构成。这四者通过标准接口交互但各自职责边界清晰thermal core 不关心具体传感器怎么读温度也不决定风扇该转多快它只做三件事——统一管理 thermal zone 生命周期、协调 trip point 触发时机、调度 governor 执行冷却策略。我画过一张物理内存映射图来理解这种分工thermal core 就像工厂中央控制室thermal drivers 是各产线的传感器探头如tsadc、imx_thermalcooling devices 是流水线上的执行机构如cpufreq_cooling、fan_controlgovernors 则是不同产线的班组长step_wise、power_allocator。关键在于control roomthermal core不直接操作机器而是下发指令给班组长governor再由班组长指挥具体工人cooling device。这种设计让同一套 thermal core 可同时支持手机 SoC 的多 zone 温控、服务器的机箱风道协同、甚至 FPGA 的局部热区管理。举个反例某国产 RISC-V 芯片厂商最初把所有逻辑写进xxx_thermal_probe()里结果当客户要求增加 GPU 温控时不得不重写整个驱动——这就是没吃透架构分层的典型代价。2.2 thermal zone温度感知的最小逻辑单元不是物理传感器struct thermal_zone_device是 thermal framework 的核心数据结构但它常被误解为“对应一个温度传感器”。实际上一个 thermal zone 可能聚合多个传感器如 CPU 核心 GPU 壳体 PCB 板温也可能代表一个虚拟热区如thermal_zone_of_sensor通过 Device Tree 描述的逻辑区域。它的本质是热管理策略的施加对象。创建 thermal zone 的关键函数thermal_zone_device_register()接收的参数中ops指针定义了该 zone 如何获取温度.get_temp、如何设置被动冷却.set_trip_temp而bind数组则声明了哪些 cooling device 对本 zone 生效。这里有个极易踩坑的细节bind数组不是简单罗列 device 名称而是通过struct thermal_cooling_device *cdev指针与 cooling device 关联并指定THERMAL_TRIP_ACTIVE或THERMAL_TRIP_PASSIVE等触发类型。我在调试某款 Rockchip 平台时发现rk3399_thermal驱动中bind数组漏填了gpu_cooling设备指针导致 GPU 温度飙升时 CPU cooling device 被错误激活——问题根源不在 sensor 读数不准而在 zone 与 cooling device 的绑定关系缺失。thermal zone 的生命周期管理也值得深究thermal_zone_device_unregister()不仅释放内存还会遍历所有绑定的 cooling device调用其.unbind回调清理资源。若 driver 中忘记在 probe 失败时调用 unregister就会造成 thermal zone 泄漏cat /sys/class/thermal/下会出现残留的thermal_zoneX目录。2.3 cooling device冷却执行器的抽象不是风扇驱动本身struct thermal_cooling_device抽象的是“可被调控的功耗单元”而非具体硬件。常见类型包括cpufreq_cooling通过调节 CPU 频率降功耗、cpuidle_cooling通过延长 idle 时间降功耗、fan_control控制风扇转速、power_allocator分配功率预算。关键点在于cooling device 必须实现.get_max_state和.set_cur_state回调前者返回当前最大可设状态数如 cpufreq cooling 的 state 数等于可用频率档位数后者接收 0~max_state 范围内的整数值并执行对应动作。这里有个隐藏陷阱state 值并非线性映射。以cpufreq_cooling为例state0 表示最高频不冷却statemax_state 表示最低频最强冷却中间 state 值需通过freq_table查表转换为实际频率。我在移植qcom_cpufreq_cooling到新平台时因freq_table初始化顺序错误导致set_cur_state(1)实际设置了最高频——表面看 cooling device 注册成功实则策略完全反转。cooling device 与 thermal zone 的绑定通过thermal_zone_bind_cooling_device()完成该函数内部会检查 cooling device 的allowed_instances字段确保同一 cooling device 不被过度复用。例如cpufreq_cooling默认allowed_instances1若强行绑定到多个 thermal zone后续thermal_zone_device_update()将拒绝调度。2.4 governor冷却策略的决策大脑不是固定算法governor 是 thermal framework 的智能核心负责根据 thermal zone 状态选择 cooling device 的目标 state。内核默认提供step_wise、bang_bang、power_allocator三种 governor但它们的适用场景截然不同step_wise最常用采用渐进式调节。当温度超过 trip point 时按步长 increment 逐步提升 cooling device state低于 hysteresis 温度时按 decrement 逐步降低 state。其优势是避免震荡缺点是响应慢。我在调试工业相机模组时发现step_wise在环境温度骤升时 cooling device state 提升滞后 3 秒导致 sensor 过热损坏。bang_bang开关式控制温度超限即跳至最大 cooling state低于下限即归零。适合风扇等执行器但对 CPU 频率调控易引发性能抖动。power_allocator高级策略基于 power model 动态分配功率预算。需在 Device Tree 中配置dynamic-power-coefficient计算公式为P C * f^3 * V^2C 为系数f 为频率V 为电压。它能实现更精准的功耗控制但依赖准确的 power model 参数。governor 的切换通过thermal_gov_name属性控制如echo power_allocator /sys/class/thermal/thermal_zone0/governor。但注意切换 governor 时thermal core 会先调用原 governor 的.throttle回调清空状态再调用新 governor 的.throttle初始化。若新 governor 的初始化失败如power_allocator缺少 power model 数据系统将回退到step_wise并打印警告日志——这个机制保证了策略切换的鲁棒性。3. thermal framework 的初始化与运行时流程从内核启动到温度调控的每一步3.1 启动阶段thermal core 初始化与设备树解析thermal framework 的初始化始于thermal_init()函数它在fs_initcall级别被调用。该函数主要完成三件事注册 sysfs 接口/sys/class/thermal/、初始化全局链表thermal_tz_list存储所有 thermal zone、注册默认 governorstep_wise。真正的设备发现发生在 platform bus probe 阶段。以 ARM64 平台为例Device Tree 中的 thermal node 描述如下thermal-zones { cpu-thermal { polling-delay-passive 1000; polling-delay 2000; thermal-sensors tsadc; trips { throt: cpu-critical { temperature 105000; // 单位 m℃ hysteresis 2000; type critical; }; }; cooling-maps { map0 { trip throt; cooling-device cpu0_cooling THERMAL_NO_LIMIT THERMAL_NO_LIMIT; }; }; }; };内核解析此节点时of_thermal.c会调用thermal_zone_of_sensor_register()创建 thermal zone并通过thermal_zone_bind_cooling_device()绑定cpu0_cooling。这里的关键参数THERMAL_NO_LIMIT表示 cooling device 的 state 范围不受限制而THERMAL_TRIP_CRITICAL类型的 trip point 触发后将直接调用thermal_zone_device_critical()强制关机——这解释了为何criticaltrip 不经过 governor 调度。我在分析某款 i.MX8M 平台启动日志时发现thermal_zone_of_sensor_register()返回-EPROBE_DEFER原因是tsadc节点尚未 probe 完成。这提示我们thermal zone 的 probe 依赖 sensor driver 的就绪必须确保 Device Tree 中thermal-sensors引用的节点已正确定义 compatible 属性。3.2 运行时流程一次温度超限的完整处理链当温度传感器读数超过 trip point 时thermal framework 启动完整的调控流程。以step_wisegovernor 为例全过程如下Sensor 采样触发thermal_zone_device_update()被调用通常由 timer 或 interrupt 触发它读取tz-ops-get_temp(tz, temp)获取当前温度Trip 判定遍历tz-trips数组找到第一个temp trip-temperature的 trip pointGovernor 调度调用tz-governor-throttle(tz, trip)step_wise的 throttle 函数计算目标 statetarget_state min(current_state increment, max_state)Cooling device 执行遍历tz-cdevs对每个绑定的 cooling device 调用cdev-ops-set_cur_state(cdev, target_state)状态同步更新tz-last_temperature和tz-passive_delay为下次采样做准备。这个流程看似简单但存在多个性能瓶颈点。我在某次性能分析中发现thermal_zone_device_update()单次调用耗时达 15ms主因是get_temp()回调中包含 I2C 通信i2c_smbus_read_word_data()。解决方案是在 sensor driver 中实现温度缓存机制get_temp()优先返回缓存值仅当缓存超时如 500ms才触发 I2C 读取。另一个常见问题是set_cur_state()调用阻塞。例如fan_control的set_cur_state()若包含 PWM 寄存器写入而寄存器访问需等待总线空闲会导致 thermal thread 被挂起。正确做法是将耗时操作移至 workqueue 异步执行set_cur_state()仅提交 work 并立即返回。3.3 cooling device 注册与绑定从 cpufreq 到 fan 的完整链条cooling device 的注册流程揭示了 thermal framework 与其它子系统的深度集成。以cpufreq_cooling为例其注册入口cpufreq_cooling_register()会遍历所有 online CPU为每个 CPU 创建struct cpufreq_cooling_device调用thermal_cooling_device_register()注册 cooling device传入cpufreq_cooling_ops在cpufreq_cooling_ops.set_cur_state中通过cpufreq_frequency_table_target()查找对应频率档位并调用cpufreq_driver-target_index()设置。关键细节在于cpufreq_cooling的 state 映射state0 对应freq_table[0]最高频staten 对应freq_table[n]最低频。若freq_table未按频率降序排列set_cur_state()将设置错误频率。我在调试 RK3566 平台时发现rockchip_cpufreq的freq_table是升序排列导致cpufreq_cooling的 state 逻辑反转——修复方法是在cpufreq_cooling_register()中对freq_table进行逆序排序。fan 控制则体现另一种集成模式。pwm_fandriver 通过thermal_cooling_device_register()注册 cooling device其set_cur_state()将 state 值转换为 PWM 占空比。但注意fan 的 cooling capacity 并非线性。实验数据显示某 40mm 散热风扇在 state350% 占空比时风量仅为 state7100%的 35%因此step_wise的线性 increment 会导致低 state 区间冷却不足。解决方案是在pwm_fandriver 中实现非线性映射表或改用power_allocatorgovernor 配合风扇 power model。3.4 thermal sysfs 接口不只是读写文件而是调试利器/sys/class/thermal/下的每个thermal_zoneX目录都是调试 thermal framework 的窗口。关键文件作用如下temp读取当前温度单位 m℃触发tz-ops-get_temp()mode读写 thermal zone 工作模式enabled/disabled写disabled可临时禁用调控policy显示当前 governor 名称trip_point_X_temp读写第 X 个 trip point 的温度阈值emul_temp写入模拟温度值用于测试 trip 触发逻辑无需真实加热type显示 thermal zone 类型如cpu-thermal。这些接口不仅是用户控制入口更是内核调试工具。例如当怀疑thermal_zone_device_update()未被调用时可执行echo 1 /sys/class/thermal/thermal_zone0/emul_temp模拟温度超限观察dmesg是否输出Thermal event on thermal_zone0日志。若无日志则问题在 thermal zone 的 update 机制如 timer 未启动若有日志但 cooling device 未动作则问题在 binding 或 governor 调度。我在定位某款高通平台 thermal 失效问题时通过cat /sys/class/thermal/thermal_zone0/trip_point_0_temp发现值为0追查发现 Device Tree 中temperature属性被误写为0而非105000——这种低级错误在 sysfs 接口中一目了然。4. 实战调试从 dmesg 日志到源码级问题定位的完整路径4.1 日志分析读懂 thermal framework 的“语言”thermal framework 的日志是问题定位的第一手线索。关键日志模式及含义如下thermal thermal_zone0: critical temperature reached, shutting downcriticaltrip 触发系统即将关机。需立即检查trip_point_0_temp设置是否过低或 sensor 是否故障thermal thermal_zone0: failed to get temperature: -EIOget_temp()回调返回错误常见于 I2C 通信失败或 sensor 未就绪thermal thermal_zone0: unbinding cooling device cpu0_coolingcooling device 解绑可能因unbind回调执行失败thermal thermal_zone0: governor step_wise is not supported, using step_wisegovernor 切换失败回退到默认策略thermal thermal_zone0: trip point 0 (active) temperature: 85000trip point 注册成功温度单位为 m℃。我在处理某次量产问题时dmesg中反复出现failed to get temperature: -EIO但i2cdetect -l显示 I2C bus 正常。深入分析发现get_temp()回调中i2c_smbus_read_word_data()返回-EIO是因为 sensor 的 I2C 地址被其他 driver 占用。解决方案是在 sensor driver 的probe()函数中添加i2c_check_functionality()验证 bus 功能并在remove()中确保释放地址。4.2 源码级调试使用 ftrace 定位 thermal 调用链当日志无法定位问题时ftrace 是终极武器。启用 thermal 相关 trace event 的命令如下echo 1 /sys/kernel/debug/tracing/events/thermal/thermal_zone_trip_point_enable/enable echo 1 /sys/kernel/debug/tracing/events/thermal/thermal_zone_trip_point_disable/enable echo 1 /sys/kernel/debug/tracing/events/thermal/thermal_zone_device_update/enable echo 1 /sys/kernel/debug/tracing/events/thermal/thermal_cooling_device_set_state/enable cat /sys/kernel/debug/tracing/trace_pipeftrace 输出将显示每次 trip 触发、zone update、cooling device state 设置的精确时间戳和调用栈。例如某次调试中 ftrace 显示thermal_zone_device_update()被timer触发但thermal_cooling_device_set_state()从未调用。进一步检查发现tz-cdevs链表为空——根源在于thermal_zone_bind_cooling_device()调用失败而失败原因是cpu0_cooling设备尚未注册cpufreq_cooling_register()在 thermal zone probe 之后才执行。解决方案是在 Device Tree 中添加phandle依赖或在 thermal driver 中使用deferred probe机制。4.3 常见问题速查表从症状到根因的快速匹配症状可能根因排查步骤修复方案thermal_zone0/temp读数恒为 0get_temp()回调未实现或返回 0cat /sys/class/thermal/thermal_zone0/temp检查 driver 中ops-get_temp是否有效实现正确的 sensor 读取逻辑确保返回 m℃ 单位值cooling device 不响应 tripthermal_zone_bind_cooling_device()未调用或失败ls /sys/class/thermal/thermal_zone0/cdev*确认绑定目录是否存在检查 Device Treecooling-maps配置验证cooling-devicephandle 正确性governor 切换后无效果新 governor 初始化失败或未启用cat /sys/class/thermal/thermal_zone0/policy对比期望值检查 governor 依赖项如power_allocator需要 power model确保thermal_gov_name文件可写multiple thermal zones 互相干扰cooling deviceallowed_instances设置过小cat /sys/class/thermal/cooling_device*/cur_state观察 state 变化是否同步修改 cooling device driver增大allowed_instances值criticaltrip 触发后未关机trip-type配置错误或criticalhandler 被覆盖cat /sys/class/thermal/thermal_zone0/trip_point_0_type确认为critical检查 Device Treetype critical确保未被其它 driver 重写 trip type4.4 独家避坑技巧那些文档不会写的实战经验Trip point 温度单位陷阱Device Tree 中temperature属性单位是m℃毫摄氏度不是 ℃。写temperature 105表示 0.105℃这显然错误。必须写temperature 105000。我在早期调试中因单位混淆导致 thermal zone 在室温下就触发 trip——教训是所有温度值在代码中一律以int存储单位明确标注m℃。Passive trip 的 hysteresis 误区hysteresis仅对passive和activetrip 有效criticaltrip 无 hysteresis。若为criticaltrip 设置hysteresis内核会忽略该值。正确做法是criticaltrip 用于绝对安全边界passivetrip 用于主动降温。Cooling device state 范围校验set_cur_state()接收的 state 值必须在0到max_state之间。若 driver 未做范围检查传入非法值可能导致硬件异常。我在pwm_fandriver 中添加了WARN_ON(state cdev-max_state)并在set_cur_state()开头加入state min(state, cdev-max_state)。Thermal zone 名称冲突多个 thermal zone 使用相同 name如cpu-thermal会导致 sysfs 目录覆盖。内核通过thermal_zone_device_register()的name参数生成目录名建议在 name 中加入 SoC 型号前缀如rk3399-cpu-thermal。Timer polling delay 的权衡polling-delay过小如 100ms会增加 CPU 负载过大如 5000ms会导致响应延迟。实测表明对于手机 SoCpassivetrip 推荐polling-delay-passive 500criticaltrip 推荐polling-delay 100——这是在功耗与响应速度间的最佳平衡点。5. thermal framework 的扩展与定制为自研芯片构建专属热管理方案5.1 自定义 governor从 step_wise 到预测式调控当默认 governor 无法满足需求时开发自定义 governor 是必经之路。以某 AI 加速卡为例其功耗与温度呈强非线性关系step_wise的线性调节导致推理任务开始时温度骤升。我们开发了predictive_governor其核心思想是基于历史温度变化率预测未来温度提前调节 cooling device state。实现要点包括在struct thermal_zone_device中扩展struct predictive_data存储最近 5 次温度采样值及时间戳throttle()函数中计算温度变化斜率slope (temp_now - temp_prev) / (time_now - time_prev)若slope threshold则target_state current_state 2 * increment实现超前调控为避免误判引入滑动窗口平均机制仅当连续 3 次slope threshold才执行超前调节。该 governor 的注册方式与标准 governor 一致只需实现struct thermal_governor结构体并调用thermal_register_governor()。关键经验是自定义 governor 必须处理好并发安全throttle()可能在多个 CPU 上同时调用需使用tz-lock保护共享数据。5.2 多 zone 协同解决 SoC 热区耦合问题现代 SoC 中 CPU、GPU、NPU 温度相互影响单一 thermal zone 无法建模。解决方案是创建virtual thermal zone它不关联物理 sensor而是聚合多个物理 zone 的温度数据。例如static int virtual_tz_get_temp(struct thermal_zone_device *tz, int *temp) { int cpu_temp, gpu_temp, npu_temp; thermal_zone_get_temp(cpu_tz, cpu_temp); thermal_zone_get_temp(gpu_tz, gpu_temp); thermal_zone_get_temp(npu_tz, npu_temp); *temp max(cpu_temp, max(gpu_temp, npu_temp)); // 取最大值作为虚拟 zone 温度 return 0; }virtual zone 的 trip point 可设置为passive绑定所有相关 cooling device。这样当任一单元过热时系统可协同调控 CPU 频率、GPU 电压、NPU 时钟实现全局热平衡。我们在某款 5G 基站芯片上应用此方案将热节流事件减少 60%。5.3 用户空间干预通过 netlink 实现动态策略调整thermal framework 默认在内核态运行但某些场景需用户空间参与决策。例如车载系统需根据空调状态动态调整 thermal policy。我们通过netlinksocket 实现内核与用户空间通信内核侧在thermal_zone_device_update()后发送 netlink 消息携带当前 zone 温度、trip 状态用户空间thermalddaemon 接收消息结合车辆 CAN 总线数据如空调压缩机状态计算最优 cooling state用户空间通过sysfs写入cooling_device/cur_state或通过 ioctl 向内核发送策略指令。该方案的优势是策略逻辑可灵活更新无需重新编译内核。但需注意 netlink 消息队列溢出风险我们在内核侧添加了消息丢弃机制当队列满时优先保留最新消息。5.4 性能优化减少 thermal framework 的 runtime 开销thermal framework 的频繁采样会带来可观开销。优化手段包括采样频率分级criticaltrip 使用高频采样100mspassivetrip 使用低频采样2000ms通过polling-delay动态调整硬件加速采样利用 SoC 的硬件 thermal monitor如 ARM SCMI Thermal Protocol避免软件轮询状态缓存在thermal_zone_device中缓存最近温度值get_temp()优先返回缓存仅当缓存过期才触发硬件读取批处理更新将多个 thermal zone 的update()合并到单个 workqueue 中执行减少上下文切换。实测表明在某款 8 核 SoC 上通过上述优化thermal framework 的 CPU 占用率从 1.2% 降至 0.3%且温度响应延迟无明显增加。我在实际项目中发现thermal framework 的价值远不止于防止设备过热。它是一套完整的功耗调控基础设施其架构设计体现了 Linux 内核“分层抽象、松耦合、可扩展”的哲学。当你下次看到thermal_zone0目录时不妨想想这不仅是一个温度读数接口更是连接硬件感知、策略决策、执行调控的神经中枢。真正的内核功耗优化始于对 thermal framework 通用架构的透彻理解——而不是盲目调高风扇转速或降低 CPU 频率。