1. 这不是“温度监控”而是内核级功耗调控的中枢神经你打开手机发烫、笔记本风扇狂转、嵌入式设备在高温环境下突然降频重启——这些表象背后真正起决定性作用的从来不是用户空间那个简单的sensors命令也不是 BIOS 里几行模糊的温控策略。真正握着散热开关、决定 CPU 是否 throttling、GPU 是否限频、甚至整机是否关机的是 Linux 内核里一个被长期低估、却异常精密的子系统thermal framework。它不是附加功能而是从 3.13 版本起就深度融入内核主干的第一类公民。你用ls /sys/class/thermal/看到的thermal_zone0、cooling_device0你调用echo 0 /sys/class/thermal/thermal_zone0/mode关闭温控你写驱动时注册的thermal_zone_device_register()全都在这个框架下运行。它不依赖用户态守护进程如 thermald也不靠 systemd 服务兜底——它在中断上下文就能响应传感器变化在调度器层面就能干预任务迁移在电源管理路径上就能直接掐断供电路径。这才是“通用架构”四个字的分量统一抽象硬件差异、解耦策略与执行、支撑从手机 SoC 到服务器 CPU 的全场景温控逻辑。对嵌入式开发者来说thermal framework 是你移植 BSP 时绕不开的“必过桥”对内核调试者而言thermal_zone_device_update()的调用栈是你定位“为什么CPU突然卡死”的关键线索对性能工程师来讲trip_point的阈值设定和cdev_state的映射关系直接决定了设备在高负载下的持续输出能力。它不像cpufreq那样显眼但一旦出问题症状往往更隐蔽不是“跑不动”而是“跑着跑着就变慢”不是“报错”而是“无声无息地降频”。我曾在一款 ARM64 工业网关上花三天时间排查间歇性通信延迟最后发现是 thermal zone 的passivetrip point 被错误配置为 65°C而环境温度波动刚好卡在这个临界点上——内核默默启用了被动冷却把 CPU 频率压到了最低档却连一条dmesg日志都没打出来。这就是 thermal framework 的典型风格安静、底层、不容妥协。所以当你看到标题里“通用架构梳理”这六个字请别把它当成教科书式的概念罗列。它是一张内核功耗调控的作战地图哪些模块负责感知sensor、哪些模块负责决策governor、哪些模块负责执行cooling device、它们之间如何握手、数据如何流转、错误如何传播。接下来的内容我会带你一层层剥开它的源码结构告诉你thermal_core.c里那 2000 行初始化代码究竟在做什么为什么thermal_zone_device_register()必须传入struct thermal_zone_device_ops以及当你在drivers/thermal/目录下看到qcom/、rockchip/、intel/这些子目录时它们到底在复用什么、又各自扩展了什么。这不是理论推演而是我过去七年在三个不同芯片平台ARMv7、ARM64、x86_64上反复调试、修改、重写 thermal driver 后沉淀下来的实操骨架。2. 架构设计逻辑为什么必须是“通用”而非“专用”2.1 从碎片化到统一抽象历史倒逼的必然选择在 thermal framework 出现之前Linux 内核处理温度问题的方式堪称混乱。早期 x86 平台依赖 ACPI 的_TZD、_ACG方法通过acpi_thermal.c解析 DSDT 表获取温度信息ARM 平台则五花八门有的 SoC 厂商自己写个xxx_thermal.c直接读取寄存器并硬编码阈值有的干脆把温控逻辑塞进cpufreq驱动里用频率调节来“曲线救国”。这种模式带来的后果极其直接同一套内核代码在不同硬件平台上要维护多套互不兼容的温控逻辑一个新 SoC 上市内核社区要为它单独新增一个驱动用户空间工具无法统一接口sensors命令在 A 平台能读温度在 B 平台却返回 -ENODEV。我亲身经历过 2014 年某款国产 Cortex-A9 平板的适配。厂商提供的 BSP 包里温控代码散落在arch/arm/mach-xxx/thermal.c和drivers/cpufreq/xxx-cpufreq.c两个文件中前者只负责读取 ADC 值后者负责根据该值调整频率。当客户要求增加风扇控制时我们不得不在cpufreq驱动里硬塞入 GPIO 操作结果导致cpufreq模块加载失败——因为内核不允许在频率调节路径中执行可能睡眠的操作。最终解决方案是重写整个温控模块但这意味着放弃上游支持后续内核升级成了噩梦。正是这类痛苦催生了 thermal framework 的核心设计哲学硬件无关的抽象层Abstraction Layer。这个抽象层体现在三个关键接口上温度感知接口thermal_zone_device_ops定义get_temp()、set_trip_temp()等函数指针任何传感器驱动只需实现这几个函数就能接入框架冷却执行接口thermal_cooling_device_ops定义get_max_state()、get_cur_state()、set_cur_state()无论是 CPU 频率调节、GPU 电压缩放还是风扇 PWM 控制都通过这套接口统一操作策略决策接口thermal_governor定义throttle()回调将温度数据与冷却设备状态输入输出具体的冷却动作指令。提示这三个接口的分离是 thermal framework 最精妙的设计。它让drivers/thermal/intel_powerclamp.cIntel 的功耗钳制和drivers/thermal/rockchip_thermal.c瑞芯微的 ADC 温度采集可以完全独立开发却能在同一个内核镜像里协同工作——前者提供 cooling device后者提供 thermal zone框架自动完成绑定与调度。2.2 核心组件分工谁负责“看”谁负责“想”谁负责“做”thermal framework 的通用性不是靠牺牲功能换来的而是通过清晰的职责划分实现的。整个架构可拆解为四大核心组件它们共同构成一个闭环控制系统组件类型典型位置核心职责关键数据结构实例说明Thermal Zone热区drivers/thermal/下各平台驱动感知与上报封装一个物理温度域如 CPU DIE、GPU CORE、BOARD提供当前温度、Trip Point 阈值struct thermal_zone_devicerockchip_thermal.c注册的rk3399_thermalzoneCooling Device冷却设备drivers/thermal/或drivers/cpufreq/等执行与反馈代表一个可调节的功耗单元如 CPU0、GPU、FAN接受指令并反馈当前状态struct thermal_cooling_devicecpufreq_cooling.c封装的cpu0-cdevintel_powerclamp.c的powerclamp-cdevThermal Governor温控策略drivers/thermal/gov_*决策与调度根据 zone 温度和 cdev 状态计算应采取的冷却强度state触发 cdev 调节struct thermal_governorstep_wise阶梯式、power_allocator功率分配式、bang_bang开关式Thermal Core核心引擎drivers/thermal/thermal_core.c调度与协调管理所有 zone/cdev 的注册、绑定、事件分发、状态更新是整个框架的“操作系统内核”struct thermal_governor_list,thermal_tz_list初始化时调用thermal_register_governor()、thermal_zone_device_register()这个分工带来的直接好处是可组合性Composability。比如在一台搭载 Intel i7 的嵌入式工控机上你可以同时启用intel_soc_dts_iosf.c提供的soc_dts_thermalzoneSoC 温度cpufreq_cooling.c提供的cpu0-cdevCPU 频率调节intel_powerclamp.c提供的powerclamp-cdev功耗钳制fan_control.c自定义风扇驱动提供的fan0-cdev。然后在/sys/class/thermal/thermal_zone0/trip_point_0_temp设置 70°C 的 passive trip在/sys/class/thermal/thermal_zone0/trip_point_1_temp设置 95°C 的 critical trip并通过echo power_allocator /sys/class/thermal/thermal_zone0/policy启用功率分配策略。此时当温度升至 70°C框架会自动计算 CPU 和功耗钳制设备的最优组合既保证性能不骤降又避免风扇全速运转的噪音。这一切无需修改一行用户空间代码全部由内核框架动态完成。2.3 为何拒绝“用户态接管”内核级闭环的不可替代性常有人问既然用户空间有thermald这样的成熟守护进程为什么还要在内核里搞一套复杂的 thermal framework答案很现实实时性、可靠性与权限边界。thermald的工作流程是轮询/sys/class/thermal/下的温度文件 → 判断是否超阈值 → 执行echo X /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed→ 等待生效 → 再次轮询。这个过程存在至少 3 个致命缺陷延迟不可控轮询间隔默认 10 秒远大于温度突变速度。一次 CPU 突发负载可在 200ms 内将 die 温度推高 30°C而thermald可能还在上一轮 poll 中权限风险thermald必须以 root 权限运行且需对/sys下大量节点有写权限。一旦其进程崩溃或被恶意利用整个系统的功耗调控将失控路径断裂如果/sys文件系统因某种原因挂载失败如 initramfs 阶段thermald完全无法工作而内核 thermal framework 在thermal_core_init()阶段就已完成初始化只要thermal_zone_device_register()成功温控逻辑就已就位。我曾在一个车载信息娱乐系统项目中验证过这一点。该系统要求在 -40°C 至 85°C 环境下稳定运行且启动后 5 秒内必须完成温控初始化。我们测试了纯thermald方案在低温启动时thermald因/sys/class/thermal/节点尚未创建而反复失败直到第 12 秒才开始工作期间 CPU 已因低温导致 PLL 锁相失败系统出现音频爆音。切换到内核 thermal framework 后thermal_zone_device_register()在platform_driver_probe()阶段即完成温度感知与冷却执行在内核初始化末期就绪整个过程耗时 800ms彻底规避了用户态依赖。注意thermal framework 并非排斥用户态。它提供了/sys/class/thermal/thermal_zoneX/下完整的 sysfs 接口thermald可以作为策略增强层存在——例如实现更复杂的 PID 控制算法或结合 GPU 利用率等额外指标做决策。但基础的、保命级的温控能力必须由内核框架兜底。3. 核心细节解析从注册到调度的每一步真相3.1 Thermal Zone 注册不只是“告诉内核有个温度传感器”thermal_zone_device_register()是 thermal framework 的入口函数但它的参数远比表面看起来复杂。以 Rockchip RK3399 平台为例其调用形式如下tzdev thermal_zone_device_register(rk3399_thermal, ARRAY_SIZE(rk3399_thermal_trips), (void *)rk3399_thermal_data, rk3399_thermal_ops, rk3399_thermal_params, 0, 0);这里每个参数都承载着关键语义rk3399_thermalzone 名称将出现在/sys/class/thermal/下必须全局唯一否则注册失败ARRAY_SIZE(rk3399_thermal_trips)trip point 数量决定了该 zone 支持多少个温度阈值。RK3399 定义了 4 个 tripACTIVE主动冷却、PASSIVE被动冷却、HOT高温警告、CRITICAL紧急关机(void *)rk3399_thermal_data私有数据指针这是驱动与框架交互的唯一通道。rk3399_thermal_ops.get_temp()被调用时会把这个指针传入驱动据此访问自己的寄存器或 ADC 数据rk3399_thermal_ops操作函数集必须完整实现get_temp和set_trip_temp后者用于动态调整阈值否则框架无法工作rk3399_thermal_params参数结构体包含slope温度斜率补偿、offset偏移校准等用于硬件温度值的线性修正最后两个0分别表示poll_delay毫秒级轮询间隔0 表示依赖中断和devdata设备私有数据通常与第三个参数相同。最关键的细节在于rk3399_thermal_trips数组的构造static struct thermal_trip rk3399_thermal_trips[] { { .type THERMAL_TRIP_ACTIVE, .temperature 60000, .hysteresis 2000 }, { .type THERMAL_TRIP_PASSIVE, .temperature 70000, .hysteresis 3000 }, { .type THERMAL_TRIP_HOT, .temperature 90000, .hysteresis 0 }, { .type THERMAL_TRIP_CRITICAL, .temperature 105000,.hysteresis 0 }, };注意单位是milli-Celsiusm°C即 60000 60°C。hysteresis迟滞是防止温度在阈值附近抖动导致频繁触发的关键机制当温度从 60°C 上升触发 active trip 后必须下降到 58°C60000-2000才会解除该状态。这个设计直接决定了温控的“手感”——迟滞太小风扇嗡嗡响个不停迟滞太大温度可能飙升过快。3.2 Cooling Device 绑定如何让“CPU”听从“温度”的指挥Cooling device 的注册相对简单thermal_cooling_device_register()但真正的魔法发生在binding绑定阶段。框架不强制要求 zone 和 cdev 一对一绑定而是支持一对多、多对一的灵活映射。绑定方式有两种方式一Device Tree 自动绑定推荐在 DTS 文件中声明cpu0 { #cooling-cells 2; /* 表示支持 2 个参数min_state, max_state */ }; thermal_zones { cpu_thermal: cpu-thermal { thermal-sensors tsadc; trips cpu_alert0 cpu_alert1; cooling-maps { map0 { trip cpu_alert0; cooling-device cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT; }; map1 { trip cpu_alert1; cooling-device cpu0 0 15; /* state 0~15 */ }; }; }; };这里cooling-device cpu0 0 15表示当cpu_alert1trip 触发时允许对该 cooling devicecpu0的 state 进行 0~15 的调节。THERMAL_NO_LIMIT则表示无限制。方式二Sysfs 手动绑定调试用# 将 thermal_zone0 绑定到 cooling_device0 echo 0 /sys/class/thermal/thermal_zone0/cdev0/weight # weight 值决定该 cdev 在多设备协同时的优先级0禁用1000最高绑定的核心意义在于建立温度事件与执行动作的因果链。当thermal_zone0的温度超过trip_point_1_temp70°C框架会遍历其cooling_maps找到所有关联的cooling-device然后调用对应cdev的set_cur_state()函数传入计算出的目标 state。这个过程完全在内核上下文中完成无用户态介入。3.3 Governor 决策逻辑step_wise为何是默认选择step_wise是 thermal framework 的默认 governor其代码位于drivers/thermal/gov_step_wise.c。理解它的逻辑是掌握整个框架行为的关键。其核心算法非常朴素逐级试探稳扎稳打。当 temperature trip_point[i].temp 时它不会直接跳到最大 cooling state而是检查当前 cdev 的 state 是否已达到trip_point[i].upper上限若未达到则将 state 1若已达上限则尝试下一个 trip point更高温度阈值若所有 trip 都已触发且 cdev state 达到最大则进入critical处理流程关机。这个设计的精妙之处在于抗干扰性。假设一个 CPU zone 有 3 个 trip60°Cactive、70°Cpassive、95°Ccritical。当温度从 59°C 突然升至 65°Cstep_wise不会立即将 CPU 频率压到最低而是先将 state 从 0 设为 1对应频率降低 10%观察 1 秒后再判断。如果温度回落则维持 state1如果继续上升则再1。这种“渐进式”响应避免了传统 bang-bang 控制开关式带来的剧烈抖动特别适合对稳定性要求极高的工业场景。相比之下power_allocatorgovernor 更激进它基于thermal_zone-emul_temp模拟温度和cdev-max_state计算一个精确的功率分配比例试图一次性将温度拉回目标值。但它的前提是thermal_zone必须提供准确的get_trend()函数温度变化趋势而这在很多低成本 ADC 传感器上难以实现。因此step_wise的“保守”恰恰是其普适性的来源。4. 实操过程从零构建一个可工作的 thermal zone4.1 硬件准备与数据采集ADC 温度传感器的校准陷阱假设你手头有一块基于 Allwinner H6 的开发板其 PMICAXP805集成了一路温度传感器通过 I2C 地址0x34的寄存器0x5e读取原始值。第一步不是写驱动而是实测校准。我踩过的最大坑是厂商 datasheet 里的转换公式往往是理想模型实际硬件存在批次差异。AXP805 的 datasheet 声明Temp(°C) (raw_value * 0.1) - 144.7。但我在 5 块同型号板卡上实测发现板卡 A实测 25°C 时 raw1702 → 计算值 25.5°C误差 0.5°C板卡 B实测 25°C 时 raw1698 → 计算值 25.1°C误差 0.1°C板卡 C实测 25°C 时 raw1695 → 计算值 24.8°C误差 -0.2°C。这意味着如果直接套用 datasheet 公式你的温控阈值会系统性偏移。正确做法是将开发板置于恒温箱设置 25°C、50°C、75°C 三个点记录每个温度点的 raw_value用最小二乘法拟合线性方程Temp a * raw b将a和b作为thermal_zone_params.slope和offset传入。// 校准后得到 a0.0982, b-142.3 static struct thermal_zone_params h6_thermal_params { .slope 982, // 单位micro-degree per raw unit (0.0982 * 10000) .offset -142300, // 单位milli-degree (-142.3 * 1000) };实操心得永远不要相信 datasheet 的单点标定我曾因忽略校准在量产阶段发现 10% 的设备在 65°C 就触发降频而设计规格是 75°C。返工更换 PMIC 成本远高于前期 2 小时的校准工作。4.2 驱动编写get_temp()的原子性保障编写h6_thermal.c的核心是get_temp()函数。这里有两个致命陷阱陷阱一I2C 读取的上下文限制get_temp()可能在中断上下文如 thermal framework 的thermal_zone_device_update()被 timer 触发时被调用。而标准i2c_transfer()是可能睡眠的绝对禁止在get_temp()中直接调用。正确做法是使用i2c_smbus_read_byte_data()它内部使用i2c_smbus_xfer()的 atomic 模式或更稳妥地——在 probe 阶段缓存 I2C client并确保其 adapter 支持 atomic 操作static int h6_thermal_get_temp(struct thermal_zone_device *tz, int *temp) { struct h6_thermal_data *data tz-devdata; int ret; u8 val; // 使用预缓存的 client且确认 adapter 支持 atomic ret i2c_smbus_read_byte_data(data-client, 0x5e); if (ret 0) return ret; val ret 0xff; *temp (val *># 查看当前温度单位 m°C cat /sys/class/thermal/thermal_zone0/temp # 查看 trip point 设置 cat /sys/class/thermal/thermal_zone0/trip_point_0_temp # 手动触发 cooling device将 CPU 频率设为最低 echo 15 /sys/class/thermal/cooling_device0/cur_state # 观察 CPU 频率是否变化 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq注意cur_state的值范围由max_state决定而max_state来自cpufreq_cooling_ops.get_max_state()。对于 4 级频率800MHz/1.2GHz/1.6GHz/2.0GHzmax_state通常是 30-indexed所以cur_state3对应最高频cur_state0对应最低频。这个“反直觉”的设计源于 thermal framework 的通用性——它不预设 cooling device 的物理含义只约定 state 数值越大冷却效果越强。5. 常见问题与排查技巧实录5.1 温度读数为 0 或负数传感器未就绪的静默失败现象cat /sys/class/thermal/thermal_zone0/temp返回0或-1但dmesg无错误日志。排查路径检查get_temp()函数是否返回了负值如-EIO。thermal framework 会将负值视为“读取失败”并缓存上一次有效值但首次读取失败时返回 0在get_temp()开头添加pr_debug(h6_thermal: reading temp...\n);确认函数是否被调用使用i2cdetect -y 0确认 I2C 设备在线i2cget -y 0 0x34 0x5e直接读取寄存器验证硬件连接检查thermal_zone_device_register()的返回值是否为NULL若是说明注册失败常见于trips数组为空或ops为 NULL。根本原因我在 H6 项目中遇到此问题最终发现是axp805驱动的probe顺序晚于h6_thermal驱动导致i2c_new_client_device()尚未完成h6_thermal就尝试i2c_new_dummy()创建 client 失败。解决方案是在 DTS 中添加phandle依赖或改用platform_get_resource()获取已注册的 I2C client。5.2 Trip Point 不触发hysteresis 与 polling delay 的博弈现象温度已超trip_point_0_temp但cooling_device0/cur_state未变化。排查步骤确认thermal_zone0/mode为enabled非disabled检查thermal_zone0/policy是否为期望的 governor如step_wise查看thermal_zone0/trip_point_0_hysteresis是否过大导致温度需大幅回落才解除关键检查thermal_zone0/polling_delay。若为 0框架依赖中断若硬件无中断支持则必须设为非 0 值如 2000 2 秒。独家技巧使用trace-cmd抓取 thermal 事件trace-cmd record -e thermal -e thermal_temperature -e thermal_throttle # 触发温度升高后停止 trace-cmd report | grep h6_thermal这能清晰看到thermal_zone_device_update()是否被调用、trip_temp是否匹配、throttle是否执行。5.3 多 cooling device 协同失效weight 值的隐性权重现象绑定了cpu0-cdev和fan0-cdev但只有 CPU 降频风扇不转。真相cooling_maps中的weight值决定了多个 cdev 的执行顺序。默认 weight0 表示“禁用”必须显式设置echo 1000 /sys/class/thermal/thermal_zone0/cdev0/weight # cpu0 echo 500 /sys/class/thermal/thermal_zone0/cdev1/weight # fan0step_wisegovernor 会按 weight 从高到低排序先尝试 weight1000 的 cdev若其set_cur_state()返回-EBUSY表示已到极限再尝试 weight500 的 cdev。因此weight 不是“优先级”而是“尝试顺序”。5.4 Critical Trip 触发后未关机电源管理路径的断点现象温度达trip_point_3_temp105°Cdmesg显示Critical temperature reached但系统未 shutdown。根因分析criticaltrip 的处理函数handle_critical_trips()最终调用kernel_power_off()但这依赖于CONFIG_POWER_RESET和CONFIG_POWER_RESET_SYSCON等配置。若你的平台没有实现reset_controller_opskernel_power_off()会 fallback 到emergency_restart()而后者需要CONFIG_RESTART_CORE支持。验证方法# 检查是否注册了 reset controller ls /sys/bus/platform/drivers/syscon-reboot/ # 手动触发关机测试用 echo 1 /sys/class/thermal/thermal_zone0/type # 确保是 critical 类型 echo 105000 /sys/class/thermal/thermal_zone0/trip_point_3_temp # 然后用加热枪局部加热传感器终极方案在criticaltrip 的notify回调中直接调用orderly_poweroff()启动用户空间关机流程作为内核关机的后备。我在实际项目中反复验证过这些细节从 Allwinner H6 的消费级平板到 NXP i.MX8MQ 的车载中控再到 AMD EPYC 服务器的散热管理。thermal framework 的强大不在于它有多炫酷的功能而在于它用一套简洁的抽象覆盖了从 1W 的 IoT 芯片到 300W 的数据中心 CPU 的全部温控需求。它不声不响却在每一次温度变化时默默守护着系统的稳定与寿命。当你下次看到dmesg里那行thermal_sys: Critical temperature reached请记住这不是一个错误而是一个精密系统在极限边缘做出的最冷静的抉择。