Linux 内核功耗子系统(九):thermal framework 通用架构梳理

全景介绍

很多功耗问题，表面看是频率降不下来，往里看是温度约束没有进到正确的执行路径里。系统要回答的是：温度到了哪一档，应该限制谁，限制到什么程度。前面讲 devfreq 时，thermal 只是作为一个外部限制出现：温度升高以后，GPU、DDR、NPU 这类设备的可选最高频率会被压低。单看这一点，很容易把 thermal framework 理解成一个降频开关。这个理解会忽略掉 thermal 的架构位置。放到整机里看，thermal framework 处理的是一条闭环：温度从传感器进来，进入 thermal zone；zone 根据 trip point 判断当前热状态；governor 把热状态换算成 cooling state；cooling device 再把这个 state 转成具体动作。

这个动作可能是压低 CPUFreq 的 policy max，也可能是限制 GPU、DDR、NPU 的 devfreq 上限；也可能是 charger 限流、fan 提速，或者在 critical trip 下触发关机保护。这里要先把边界摆清楚。thermal framework 不直接处理 OPP、clock、regulator，也不替 CPU 或 GPU driver 写寄存器。它做的是把“温度已经到哪一档”翻译成“某个 cooling device 应该进入哪一档冷却状态”。至于这档状态最后对应哪个频率、电压、功耗预算、风扇转速或充电电流，由下游设备自己决定。这层间接性很重要，它把温控从单个 driver 里抽了出来。一个平台上可能有多个温区，也可能有多个发热源和散热手段。如果每个 driver 都自己判断温度、自己决定压频，整机策略很快会散掉。thermal framework 把温度、策略和执行对象连到一张图里，系统才有机会做统一约束。

架构设计：把温度采集、策略和冷却动作分开

thermal framework 要处理的重点，是让温度值进入整机功耗约束链路。CPU 过热可能要限制 CPUFreq，GPU 过热可能要限制 devfreq，电池或 PMIC 过热可能要限制充电电流，整板温度过高时还可能同时压多个设备。不同板子的传感器位置、散热条件、trip 阈值和冷却手段都不一样。如果这些逻辑散在各个设备 driver 里，温控路径会变成一堆局部判断，后面很难维护。所以 thermal 把这条路径拆成四个角色：sensor driver 负责拿到温度，thermal zone 负责表达温区状态，thermal governor 负责策略计算，cooling device 负责把冷却等级落到设备动作。

sensor driver 提供温度来源。它可以读 SoC 内部 TSADC，也可以读 PMIC、battery gauge、board sensor，或者通过 SCMI、固件接口拿温度。

thermal core 不关心温度来自 ADC、寄存器还是 firmware，它只要求 zone ops 能返回当前温度。thermal zone 描述一个被监控的温区。

SoC 上常见 CPU thermal zone、GPU thermal zone、NPU thermal zone、battery thermal zone、board thermal zone。每个 zone 有自己的温度、trip point、polling delay、mode 和 governor。zone 不是单纯的 sensor 别名，它是 thermal core 看待热状态的基本对象。

thermal governor 做策略计算。

• step_wise 会随着温度越过 trip 逐步提高 cooling state，温度回落后再逐步释放；

• power_allocator 会按功耗预算分配冷却压力；

• user_space 会把事件交给用户态策略服务。它们都只计算“该给多少冷却等级”，不直接碰硬件资源。

cooling device 执行冷却动作。CPUFreq cooling device 常见动作是限制 CPU policy 的最高频率；devfreq cooling device 会限制 GPU、DDR、NPU 等设备的可选频率；charger cooling device 可以限制充电电流；fan cooling device 可以提高转速。thermal core 最终调用的是 set_cur_state()，设备内部怎么把 state 变成硬件动作，由对应子系统处理。

核心对象

thermal 的对象关系是围绕 thermal zone 展开的。CPUFreq 以 policy 为中心，devfreq 以 device 为中心，thermal 则以温区为中心。一个 zone 可以绑定多个 cooling device，一个 cooling device 也可能参与多个 zone 的冷却。这组多对多关系，才是 thermal 比设备自己降频更复杂的地方。

• struct thermal_zone_device 是 thermal core 为一个温区建立的运行对象。它记录当前温度、上次温度、trip 数量、polling delay、thermal zone ops、governor、device 节点、锁和状态信息。CPU、GPU、battery、board sensor 都可以对应不同 thermal zone。驱动把温度交给 zone，后面的判断都围绕 zone 展开。

• struct thermal_trip 描述温度阈值。常见 trip 类型包括 passive、active、hot、critical。passive trip 通常用于性能限制；active trip 常用于风扇这类主动散热设备；critical trip 是硬保护路径，温度到这一档，系统要优先避免硬件损伤。struct thermal_governor 是温控策略对象。它根据 zone 温度、trip 状态和 cooling map 计算 cooling state。governor 不直接改 CPU 频率，也不直接控制 GPU 频率。它只决定某个 cooling device 应该进入哪个冷却等级。

• struct thermal_cooling_device 表示一个可被 thermal 调节的执行对象。它向 thermal core 暴露 get_max_state()、get_cur_state()、set_cur_state() 等接口。CPUFreq、devfreq、fan、charger 都可以注册成 cooling device。thermal core 不需要知道每类设备内部怎么调频、限流或调速。

• thermal_instance 描述 zone 和 cooling device 的绑定关系。device tree 里的 cooling-maps 会把某个 trip 和某个 cooling device 连接起来，并给出可用 cooling state 范围。thermal core 通过 instance 维护 zone、trip 和 cooling device 之间的关系。没有这层绑定，zone 只能知道自己热了，却不知道该通知谁。

注册路径：thermal zone 如何接入系统

thermal zone 通常由 sensor driver 或平台 thermal driver 注册。在 ARM SoC 上，驱动 probe 阶段一般会先准备温度采集资源。比如 TSADC 寄存器、ADC channel、clock、reset、interrupt，或者 firmware handle。资源准备好以后，再解析 device tree 里的 thermal-zones、trips 和 cooling-maps。

典型路径是先注册 thermal zone。sensor driver 提供get_temp()等 ops，thermal core 创建 thermal_zone_device。zone 注册以后，core 会解析 trip point，并根据 cooling-maps 去找对应的 cooling device。cooling device 的注册通常发生在各自子系统里。CPUFreq 可以注册 cpufreq cooling device，devfreq 设备可以注册 devfreq cooling device，charger 或 fan driver 也可以注册自己的 cooling device。

thermal core 不要求这些对象来自同一个 driver。温度来源和冷却手段，本来就可能分散在不同设备上。zone 和 cooling device 绑定以后，温度事件才有了出口。只有 thermal zone，没有 cooling device，系统只能知道温度变化，不能把温度变成性能限制。只有 cooling device，没有 cooling-map，thermal 也不知道该在哪个 trip 下调整它。温控要生效，三件事必须同时在场：zone 能读温度，trip 能判断状态，cooling-map 能找到执行对象。

温度更新路径：从 get_temp 到 set_cur_state

thermal 更新可以由轮询触发，也可以由硬件中断或 firmware 事件触发。入口不同，主线一样：读温度，比较 trip，调用 governor，更新 cooling device。理解这条路径，比记住每个结构体字段更重要。

第一步，thermal core 调用 zone ops 的 get_temp() 获取当前温度。温度单位通常是毫摄氏度。driver 返回的是某个 sensor 或 firmware 视角下的温度值。这个温度对应芯片哪个物理点、代表哪块区域的热状态，不由 thermal core 推断，而由平台热设计和 device tree 描述。

第二步，core 检查 trip point。当温度跨过 passive、active、hot 或 critical trip 时，zone 状态发生变化。passive trip 更偏性能约束，active trip 更偏主动散热，critical trip 更偏保护动作。trip 不是装饰字段，它决定温度变化从哪里开始变成系统动作。

第三步，governor 根据 zone 状态和 cooling map 计算 cooling state。以 step_wise 为例，温度超过 trip 后逐步提高 cooling state，温度回落后逐步降低 state。它不会一次性替设备选择具体频率，也不需要知道某个 OPP 对应多少电压。它调整的是 cooling device 的等级。

第四步，thermal core 调用 cooling device 的 set_cur_state()。对 cpufreq cooling 来说，这个 state 会转换为 CPU 最高频率限制。对 devfreq cooling 来说，这个 state 会转换为设备频率上限。对 fan 来说，state 可能对应转速档位。对 charger 来说，state 可能对应充电电流限制。这里容易混淆：thermal 更新路径不是另一套 CPUFreq 或 devfreq 调频路径。thermal 修改的是约束，最终频率切换仍然走 CPUFreq、devfreq、OPP、clock、regulator 或 firmware。

governor：温控策略不是硬件动作

thermal governor 的输入是温度和 trip 状态，输出是 cooling state。它不应该承担设备资源切换动作，也不应该理解每个 OPP 的电压、时钟和 regulator 细节。governor 位于 thermal zone 和 cooling device 之间，负责把热状态算成冷却压力。

step_wise 是最常见的策略。温度超过 trip 后，它逐级提高 cooling state；温度下降后，再逐级释放限制。这个策略不追求复杂模型，但路径清楚，适合很多 SoC 默认温控场景。嵌入式平台上，如果只是需要稳定地压住温度，它往往已经够用。power_allocator 更关注功耗预算。它会把温度控制看成热功耗分配问题，根据 thermal zone 的状态和模型，把可用功耗预算分给不同 cooling device。当 CPU 和 GPU 同时作为 cooling device 时，这类策略更有发挥空间。它处理的是多个发热源之间怎么分摊冷却压力。

user_space 把事件交给用户态。thermal core 负责通知，用户态 thermal daemon 或平台策略服务再决定如何处理。手机、车机、服务器平台经常会在内核 thermal 基础上叠加厂商策略。内核提供统一接口，平台策略可以放到用户态或固件侧继续细化。

fair_share 关注多个 cooling device 间的分摊。当一个 zone 绑定多个 cooling device 时，策略需要决定冷却压力怎么分配。不同平台的热设计差异很大，governor 只是策略入口，不替平台完成热设计。温控效果仍然取决于传感器位置、散热结构、trip 设计和 cooling map 配置。

cooling device：温控约束如何落到执行对象

cooling device 是 thermal framework 和其他子系统之间的连接点。thermal governor 只给出 cooling state，cooling device 把 state 转换成可执行动作。这个转换层很关键，因为 thermal core 不应该理解每个设备的调频细节。

CPUFreq cooling device 常见动作是限制 CPU policy 的最高频率。温度升高后，thermal 提高 cooling state。cpufreq cooling 把 state 映射为某个最大频率，再让 CPUFreq core 在后续频率选择中合并这个上限。schedutil 仍然可以根据负载请求频率，但请求结果不能超过 thermal 给出的限制。

devfreq cooling device 的路径类似。GPU、DDR、NPU、ISP 等设备注册 devfreq cooling 后，thermal state 会影响 devfreq 的可选频率范围。governor 仍然可以根据负载、带宽或 passive 关系给出目标频率，但 core 合并约束后，最终目标频率会被 thermal 上限裁剪。

charger cooling device 通常限制充电电流。电池或 PMIC 温度过高时，系统不一定只压 CPU 或 GPU。降低充电功率往往是更直接的控温手段。很多移动设备和嵌入式设备里，充电发热本身就是重要热源，thermal framework 可以把 charger 纳入统一 cooling device 模型。

fan cooling device 常见于带主动散热的平台。温度达到 active trip 后，thermal 可以提高 fan state。这个路径和 CPUFreq、devfreq 不同，动作是增加散热能力，不是压性能。critical trip 是保护路径。温度达到 critical 级别时，系统通常会触发关机或重启保护。这个动作不再是性能调节，而是避免硬件损伤。到这一层，系统优先级已经从“体验”切到“安全”。

与 CPUFreq、devfreq、PM QoS 的关系

thermal 和 CPUFreq、devfreq 的关系，不能简单说成“thermal 直接给设备降频”。更准确的说法是，thermal 是约束输入。它根据温度改变 CPUFreq policy 或 devfreq device 的可选性能范围。CPUFreq/devfreq core 仍然要合并 governor、用户策略、OPP、PM QoS、firmware、thermal 等约束，再交给 driver 执行。

CPUFreq 路径里，thermal cooling 通常压低 policy max。schedutil 可以继续根据 utilization 请求频率，但请求值会被 policy limit 和 thermal limit 裁剪。driver 最终执行哪个频率，还要看 OPP、transition latency、firmware 返回值和硬件限制。thermal 只是把“最高不能超过多少”放进 CPUFreq 的约束集合。

devfreq 路径里，thermal cooling 修改设备可用频率上限。GPU 或 DDR 的 devfreq governor 仍然根据 busy/total、带宽需求或 passive 关系计算目标频率。thermal 只影响可选范围，不替 governor 采样负载，也不替 driver 执行 target()。

PM QoS 的方向和 thermal 不同。thermal 多数时候压低性能上限，用来降低发热。PM QoS 常用来抬高性能下限或限制低功耗延迟，用来保证响应时间、吞吐或设备恢复延迟。两者会在 CPUFreq、devfreq、Runtime PM、CPUIdle 等路径中同时出现，最终由各自 core 合并。

调度器也会感知 thermal pressure。CPU 被 thermal 限频以后，如果调度器仍按原始 capacity 估算，任务放置会偏乐观。thermal pressure 会把热限制折算进 CPU capacity，影响 EAS、schedutil 和负载均衡。

thermal 不是单独的降频按钮。它是跨设备的温度约束来源，不替 CPUFreq、devfreq 或 OPP 做决策，但会改变这些子系统能看到的性能边界。

RK3588 thermal 链路示例

在 RK3588 这类 ARM SoC 上，thermal 链路通常从片内 TSADC 开始。TSADC driver 会准备寄存器、clock、reset、interrupt 等资源，把温度读取能力注册给 thermal core。thermal core 通过 zone ops 获取温度值，不需要理解 TSADC 通道背后的寄存器布局，也不需要知道某个采样点在芯片里的物理位置。

平台热设计主要落在 device tree 里。thermal-zones 描述温区，trips 描述温度阈值，cooling-maps 把 trip 和执行对象连起来。CPU、GPU、NPU、DDR、charger 是否参与温控，取决于板级 thermal 设计，以及对应设备是否注册了 cooling device。同一颗 RK3588，换一块散热结构不同的板子，trip 阈值、polling delay、cooling map 都可能不同，温控表现也会跟着变化。

CPU 侧如果绑定 cpufreq cooling，thermal state 会进入 CPUFreq policy 的上限约束。GPU、NPU、DDR 如果绑定 devfreq cooling，thermal state 会影响 devfreq 可选频率范围。后面的 OPP、clock、regulator、firmware 调用仍然由 CPUFreq 或 devfreq 路径完成。这条链路的边界比较清楚：

• • TSADC driver 提供温度来源，thermal core 不理解寄存器细节；
• • device tree 描述 zone、trip 和 cooling-map，把板级热设计交给 thermal core；
• • CPUFreq/devfreq cooling device 把 cooling state 转成性能上限；
• • 实际调频调压继续走 CPUFreq、devfreq、OPP、clock、regulator 或 firmware。
• 读 RK3588 的 thermal 设备树或驱动时，容易把 thermal zone、cooling state、CPUFreq policy max、devfreq target、OPP 电压点看成同一个动作。它们确实在同一条控温链路里，但职责不在同一层。thermal framework 负责温度状态和冷却等级，下游 DVFS 框架负责把约束合并到具体频率、电压和硬件切换路径里。

总结

thermal framework 把温度变成系统级功耗约束。

它以 thermal zone 为中心，连接 sensor driver、trip point、thermal governor 和 cooling device。

温度变化不会直接变成寄存器写入，它先变成 cooling state，再由 CPUFreq、devfreq、charger、fan 或 platform driver 转换成具体动作。

CPUFreq 和 devfreq 看到的是被 thermal 修改后的性能边界。CPUFreq governor 或 devfreq governor 仍然负责根据负载选择目标频率，OPP、clock、regulator、firmware 仍然负责执行硬件动作。

thermal 负责在温度升高时压低可选范围，在温度回落后释放约束。PM QoS、thermal、CPUFreq、devfreq 经常在同一条路径里相遇。PM QoS 更偏性能和延迟约束，thermal 更偏温度保护和功耗压制。最终系统运行在哪个频率、哪个 idle state、哪个 power state，是这些约束共同合并后的结果。

thermal 的主线可以压成一句话：温度先进入 thermal zone，经过 trip 和 governor 变成 cooling state，再通过 cooling device 改写其他子系统的性能边界。执行频率、电压、电流或风扇动作的，仍然是 CPUFreq、devfreq、charger、fan、OPP、clock、regulator 或 firmware。