去年调一块带双核 RISC-V 核心的板子，整机待机功耗比参考值高出将近三分之一。功率计和逻辑分析仪查了半天，发现 CPU 确实执行了 WFI，主频却一直停在标称值附近——固件层的 CPPC 例程没有被正确调用，内核 cpufreq 也根本没有把“闲下来”的信号传给电源域。那天晚上我意识到，RISC-V 的低功耗设计从来不是某一层独立能搞定的事，而是 WFI 指令、SBI 规范和 Linux cpufreq 三方共同拼起来的完整链路。
这篇文章就围绕这条链路来写。我会先讲清楚 WFI、SBI CPPC、cpufreq 各自管什么，再展开 Linux 内核里它们是怎么对接的，最后把我实际调板、调参数、排故障的一些经验和盘托出。适合正在做 RISC-V 板级适配、固件开发或内核移植的工程师参考。已经有一定 Linux 基础、但对 RISC-V 电源管理还不熟的朋友，也可以从这套介绍里快速建立整体认知。
1. 先理清控制链路：WFI、SBI CPPC 和 cpufreq 到底是怎么分工的
很多刚接触 RISC-V 低功耗的人，第一反应是“让 CPU 空闲就执行 WFI，让 CPU 跑快就改主频 CSR”。实际产品里根本没这么简单。WFI 只是让处理器停止取指等待中断，属于硬件指令层面的“原地待命”；调频调压则是整个 SoC 电源域的管理，需要固件和内核配合；而内核里还要有一套策略来决定什么时机该降频、降多少、多快降。这三者各管一段，缺一环都会出问题。
1.1 WFI：CPU 的“原地待命”状态
WFI 全称 Wait For Interrupt，是 RISC-V 架构里最基础的省电指令。执行 WFI 之后，当前 hart 会停止取指，直到一个可被响应的中断到来才恢复执行。它不负责关闭时钟，不负责跌电压，更不负责缓存维护，只是让处理器核心本身停下来。
内核里真正做功耗管理的 cpuidle 子系统，会把 WFI 包装成一种 CPUidle 状态。更深层的睡眠可能涉及关闭 PLL、切断电源域，这些通常需要 M-mode 固件和平台电源管理控制器协同，不在 WFI 指令本身的能力范围内。所以准确地说，WFI 是“让 CPU 别再干活”的那一步，而“干活期间跑多快”由 cpufreq 管。
1.2 SBI CPPC：让内核通过固件去调频率
SBI 全称 Supervisor Binary Interface，是 RISC-V 系统里 S-mode 内核和 M-mode 固件之间的一套标准调用约定。内核想要让固件做点特权操作，比如读写电源管理寄存器，就得通过 ecall 陷入 M-mode，由固件来执行。
CPPC 是 Collaborative Processor Performance Control 的缩写，原本是 ACPI 里的概念，RISC-V 把它引入到 SBI 规范中。它的核心思想是：内核不直接操作具体频率寄存器，而是告诉固件“我希望 CPU 达到什么样的性能水平”，由固件决定如何调压、调频、切换电源状态。这样内核不需要关心每个平台的微架构细节，固件也不需要暴露自己的 DVFS 私密寄存器。
1.3 cpufreq：内核里面那套“性能调度逻辑”
Linux 内核中管理 CPU 频率的框架叫 cpufreq。它负责定义频率范围、维护 governor 策略、执行频率变更操作。最常见的 governor 是 schedutil，它会根据调度器的负载信号实时计算目标频率，然后通过 cpufreq 驱动下发给硬件。
在这套协同模型里，cpufreq 驱动是承上启下的那一环：上面要响应 governor 的调频请求，下面要通过 SBI 的 CPPC 扩展把“期望性能”传给固件。固件再真正去改时钟树和电压调节器。整个过程对 Linux 内核来说，是“我告诉你目标，你负责实现”的协作关系，这也是 CPPC 名字里 Collaborative 这个词的由来。
2. WFI 空闲态的工程细节：不是执行一条指令就完事
我在实际调试中最常看到的问题，是对 WFI 的语义理解太粗糙。很多人以为写了 WFI 就一定进入低功耗，实际上 WFI 的行为受中断状态、特权级、平台实现三重影响。搞清楚这些细节，才能真正用好它。
2.1 指令语义和中断的微妙关系
RISC-V 规范里，WFI 的语义是：如果当前没有已使能且正在等待的中断，hart 会挂起，直到某个中断变得“已使能且 pending”；但如果在执行 WFI 时已经存在一个使能且 pending 的中断，WFI 可能立即返回，甚至不需要进中断处理程序。
这就带来两个实际影响。第一，软件需要处理“伪唤醒”的情况，也就是 WFI 执行完，发现根本没有紧急任务，还得回去继续睡。第二，如果中断控制器和处理器核的中断使能状态配置不当，可能导致 CPU 永远等不到唤醒中断，系统出现“假死”。我见过有些平台把外设中断配成 level 触发，中断处理完却没清掉硬件状态，WFI 每次都被同一事件立即唤醒，CPU 实际忙了一整夜。
2.2 Linux cpuidle 如何把 WFI 变成 idle state
Linux 的 cpuidle 框架会定义若干 idle state，每个 state 有关联的进入函数、唤醒延迟、功耗特征。RISC-V 上最简单的状态就是直接执行 WFI，很多平台还会提供 snooze 状态，后者本质上是忙等待，不真正睡，换来的是极低的唤醒延迟。
选哪个状态、睡多久，由 cpuidle governor 根据过去一段时间的 idle 情况决定。这里有个容易被忽略的配置：target_residency。如果这个值设得太小，CPU 会频繁“睡下去又立刻被唤醒”，唤醒开销大于省下的功耗，反而亏电；设得太大，浅空闲段宁可忙等也不用 WFI，同样耗电。调这个参数需要实测平台的中断到达频率和唤醒延迟，不能拍脑袋。
2.3 空闲路径上容易被忽略的唤醒开销
WFI 的唤醒延迟本身通常不高，但完整路径不止这一条。从 wakeup 源产生中断，到中断控制器把信号送达 hart，再到 hart 恢复取指、进入 Linux 中断处理、调度器决定运行哪个任务，这中间的每一环都有开销。如果平台为了省电把中断控制器也深度睡眠，那唤醒延迟可能是微秒级到百微秒级的差别。
调试功耗问题时，我一般先用 trace 把 cpu_idle 和 cpu_frequency 事件同时抓出来，观察“WFI 进睡”和“中断唤醒”之间的实际延迟。如果发现 WFI 频繁被同一个 IPI 唤醒，多半是调度器或内核 tick 在捣乱；如果发现睡下去之后很久才有响应，就检查中断路由和电源域配置，不要一上来就怀疑 WFI 指令有问题。
3. SBI CPPC 规范拆解：寄存器集合与调用流程
CPPC 对不少人来说是相对新的东西，尤其是从传统 ARM Linux 世界转过来的人，更容易把它和老的 PSCI 及 OPP 机制混淆。这里我把 SBI CPPC 的模型拆开讲。
3.1 为什么要绕到 M-mode 去调频
有人会问：频率寄存器通常只是普通 memory-mapped 或 CSR，内核直接写不行吗？短期看可以，长期看问题很大。不同厂商的调频实现完全不同，有些需要与电源管理控制器做握手，有些需要分多步切换时钟源，有些还涉及 thermal 和硬件反馈闭环。如果 Linux 内核直接操作这些寄存器，每换一个 SoC 就要改一次驱动里的寄存器映射，适配成本很高。
SBI CPPC 把这一切封装在 M-mode 固件后面。内核通过一组标准化的“CPPC 寄存器访问”接口表达意图，固件负责在内部把它翻译成具体的硬件操作序列。这样内核驱动代码可以是平台无关的，而固件则成为唯一需要了解硬件细节的地方。
3.2 CPPC 寄存器组里到底放了什么
SBI CPPC 规范里定义了一系列逻辑寄存器，大致可以分三类：
- 能力描述类：比如最高性能、标称性能、最低非线性性能、最低性能等。这些寄存器告诉内核“这颗 CPU 能跑到什么程度，以及各档位的大致容量”。
- 性能控制类：比如期望性能（desired performance）、能耗性能偏好（energy performance preference）。内核写这些寄存器来表达控制意图。
- 性能反馈类：比如性能反馈、参考性能计数器。固件会实时更新这些值，内核可以读回来了解实际执行性能。
需要特别说明，“性能”在这套体系里是抽象数字，不一定是频率值。它可能代表 P-state 编号，也可能是某种归一化性能指标。内核要做的只是读能力描述、写期望值、读反馈值，具体硬件怎么响应，完全由固件决定。
3.3 一次 SBI CPPC 调频的完整请求流程
结合 Linux 内核的时间线，一次典型的调频请求长这样：
- schedutil governor 根据调度器负载计算出一个目标性能值。
- 内核 cpufreq 驱动把目标值封装成一次 CPPC 寄存器写操作。
- S-mode 通过 ecall 触发 SBI 调用，进入 M-mode。
- 固件校验该平台是否支持 CPPC，以及目标性能值是否合法。
- 固件将期望性能翻译成实际的频率、电压控制序列，操作时钟控制器和 PMIC。
- 调用返回，内核更新当前频率状态，后续可通过反馈寄存器确认实际效果。
这个过程看起来简单，但对固件实现的要求很高。尤其是在混合调压和 DVFS 握手存在延迟的情况下，固件不能等所有硬件稳定后才返回，否则内核侧 latency 会高到 governor 不敢尝试调频。合理做法是固件快速下发命令并返回，硬件在后台异步完成切换，反馈寄存器周期性地把结果暴露给内核。
4. Linux cpufreq 与 SBI CPPC 的协同：从 governor 到固件的一跳
讲了规范和原理，接下来是最容易卡壳的地方：Linux 侧到底怎么把 CPPC 用起来，以及和传统 OPP 方案比有哪些差异。
4.1 policy 初始化和频率范围确定
内核 cpufreq 驱动初始化时，首先要为每个 CPU 或每个 policy 确定可用频率范围。传统 OPP 方案直接读 devicetree 里的 operating-points 表，列出一档一档的离散频率。CPPC 方案则倾向于通过能力描述寄存器来构造一个性能范围，内核可能把它转换为连续可调的性能区间。
这里有一个很关键的概念：policy 的 min 和 max 不是简单对应“最低频率”和“最高频率”，而是对应“内核允许固件在什么性能区间内自主活动”。在多核平台上，同一个 policy 内所有 CPU 共享时钟域，所以初始化的重点是找到共同的性能边界。我调试时见过某个平台四核中一个核的 CPPC 能力描述与其他三个不一致，结果整个 policy 的最高性能被拉到最低档，性能腰斩。这种问题读日志很难发现，必须主动去读每个核的 capability 值做对比。
4.2 fast_switch 路径如何做到低延迟调频
传统 cpufreq 调频过程往往要走 workqueue 或 kthread，延迟在毫秒级，这在负载变化剧烈的场景下不够用。现代内核提出了 fast switch 路径：在调度器上下文里直接调用驱动提供的快速调频函数，避免线程切换和额外开销。RISC-V 上，SBI CPPC 驱动天然适合这种模式，因为一次 ecall 是同步调用，不需要等异步完成。
不过 fast_switch 也不是没有代价。首先，驱动要确保当前上下文可以安全执行 ecall，不能随意睡眠或加锁。其次，如果固件实现得太慢，fast_switch 反而会拖累调度器的负载计算，因为调度路径被同步阻塞了。实测中我会建议固件层面把 CPPC 写操作控制在几十微秒内，否则宁可走传统慢路径，也别把调度器卡死。
4.3 与传统 OPP/DT 方案的现实对比
| 维度 | 传统 OPP / DT 方案 | SBI CPPC 方案 |
|---|---|---|
| 频率描述 | 离散的 OPP 表 | 抽象性能范围/寄存器 |
| 硬件控制 | 内核直接操作时钟/PMIC | 固件通过 M-mode 操作 |
| 平台适配 | 每个平台改 devicetree 和 clock driver | 固件内部实现，内核驱动通用 |
| 调频粒度 | 受限于 OPP 档位 | 理论上连续可调 |
| 反馈机制 | 内核自己读实际频率 | 固件提供性能反馈寄存器 |
| 调试难度 | 直观、容易看频率表 | 需要理解抽象性能和固件策略 |
不要以为 CPPC 一定比 OPP“高级”。在简单嵌入式场景里，OPP 方案更直观，出问题时定位快。CPPC 的价值主要体现在多核复杂 SoC、服务器级 DVFS 和硬件闭环调压场景：内核不需要知道频率表，固件可以根据 thermal、电流、老化等因素动态调整内部状态，这是静态 OPP 做不到的。
5. 实测验证与调优心得：让这套协同跑得又快又稳
理论和驱动代码都落地之后，真正见真章的是实测。RISC-V 的电源管理调试，难点不在某一层，而在于三层之间的信息不对称。下面是我的实际操作经验。
5.1 用 trace 观察频率和 idle 的联动关系
调试电源管理问题，我通常第一步是抓 trace。把 cpufreq 和 cpuidle 两类的 tracepoint 一起打开，例如：
trace-cmd record -e cpufreq:* -e cpu_idle:* -e sched_switch sleep 30 trace-cmd report --cpu sort观察几个关键点：idle 进入次数和退出原因是否匹配；每次 WFI 唤醒之后，cpufreq 是否马上有调频动作；调频是升频还是降频，目标性能变化是否与负载变化同步。很多功耗异常在实际中表现为“idle 大量命中，但频率一直保持高位”，这种大概率是 governor 或反馈机制的问题，而不是 idle 路径的问题。
如果手里有功率计，最好把功耗曲线和 CPU 频率曲线叠加看。只凭数据推测很容易误判：频率高不一定费电，可能是在快速响应突发任务后立刻降回低点；频率低也不一定省电，可能是反复在高低之间震荡，每次都付出调压切换的转换损耗。
5.2 我遇到的几个常见问题和排障思路
第一类是 SBI 调用返回不支持。最常见原因是固件版本太老，没有实现 CPPC 扩展。这时内核日志会提示 cpufreq 初始化失败，然后回退到无驱动状态。检查方法是用启动日志确认 do_probe 过程中的 SBI 扩展探测结果。对策是升级固件，或者暂时回退到 OPP 方案。
第二类是反馈性能值剧烈抖动。反馈寄存器的主要作用是让内核了解实际执行性能，但如果固件反馈更新频率太低，或者反馈值本质上是被多个核共享的，内核拿到的数据就可能忽高忽低。schedutil 对这种噪声很敏感，表现为频率来回跳动。我的做法是在读取反馈值后加软件滤波，或者在 BSP 配置里把 governor 的计算周期拉长一点点，换取稳定性。
第三类是 WFI 伪唤醒导致 idle 命中率极低。这个在前面提过，经常表现为休眠进程不断被打断。排查时先数一下是哪个中断唤醒的，可以用/proc/interrupts或者 perf 统计。如果是 IPI，多半是其他核在发调度请求；如果是外设，检查中断是否被错误配置成了 level 触发，或者中断控制器没有被正确 mask。
下面是我常用的一组排查思路，按顺序执行：
- 确认固件 SBI 版本和 CPPC 扩展是否被探测到。
- 挂载 debugfs，查看 cpuidle state 的 usage 和 residency 累计数据。
- 用 trace 对比唤醒中断来源和 cpufreq 目标性能变化。
- 检查 dmesg 里是否有 cpufreq 初始化失败或 SBI 错误。
- 如果反馈抖动严重，先用 performance governor 固定最高频，确认硬件稳定后再转 schedutil。
5.3 设计参数上的取舍建议
最后聊聊参数取舍。功耗调优没有万能答案，但有几个原则可以省掉不少试错。
一方面，cpuidle 的 target_residency 要按真实中断分布来设。中断密集的实时场景，宁可用 snooze 让 CPU 保持可运行状态；中断稀疏的待机场景，才能放心进入 WFI。如果一个系统同时存在两类负载，可以考虑让中断密集的核和后台空闲核分别配置不同 governor 参数，不要一刀切。
另一方面，cpufreq 的转换延迟描述要尽量贴近固件真实行为。如果固件内部调频需要 100 微秒，而内核以为只需要 10 微秒，schedutil 就会在负载抖动时过度激进去调频，最终性能没变好，反而多耗电。这类问题我建议让固件厂商提供不同功率状态之间的真实切换时间表，而不是只给一个最高频和最低频的响应时间。
还有一点：CPPC 的“期望性能”和“实际反馈”之间不是实时相等的。固件可能因为 thermal、电流限制或者多核共享电源域，短暂无法满足期望值。内核侧要接受这种偏差，不要把反馈值直接当作校准后的频率来处理，否则就会在 cpufreq stats 里看到一堆对不上的数字。
这套三层协同的设计，本质上是把一个复杂的 DVFS 问题分解成“硬件指令层、固件服务层、内核策略层”。我在实际调板中的最大体会是，当你把 WFI 的唤醒语义、SBI 调用的封装方式、cpufreq 的策略路径都分别理解清楚后，真正出问题时就能飞快地定位到底该看 CPU 硬件、固件还是内核日志，而不是对着一个功耗异常数值瞎猜。如果后续打算做更细的异构核心调度或者热管理联动，这套链路就是你继续往上搭的地基。
