Linux功耗子系统分层设计原理与实践-平芜编程栈

1. 为什么“功耗子系统”不是一堆补丁，而是一套精密的分层协议？

Linux 内核里最常被误解的模块之一，就是功耗管理（Power Management, PM）。很多人第一次接触它，是在调试一块嵌入式板卡——设备待机后电流没降下去，或者从 suspend 恢复时 USB 设备丢了；也有人在服务器上发现 CPU 频率死锁在 P0 状态，风扇狂转却压不住温度；还有人在 Android 设备上抓 trace，看到cpuidle进入状态后迟迟不退出，导致触摸响应延迟飙升。这些现象背后，看似是驱动写得不好、配置没调对，甚至归咎于硬件设计缺陷，但真正根子，往往扎在PM Core 的分层契约是否被严格遵守。

我做过三年车载 Linux 系统功耗优化，亲手调过从 i.MX8QXP 到高通 SA8155P 的多代平台。最深的体会是：功耗问题从来不是单点故障，而是分层接口失配的连锁反应。比如某次客户反馈“车辆熄火后 48 小时电池亏电”，我们查到最后，发现是 CAN 总线控制器驱动在runtime_suspend回调里漏掉了pm_runtime_put_sync()的配对调用——这行代码本身没错，但它破坏了 PM Core 定义的“引用计数生命周期契约”，导致整个设备树节点的电源域无法进入低功耗状态。而这个 bug 在开发阶段完全测不出来，因为测试环境没有模拟真实熄火断电场景。

这就是 PM Core 分层设计的底层逻辑：它不直接控制任何硬件，而是像交通信号灯系统一样，为所有参与功耗管理的模块（CPU、SoC、外设、总线）定义一套可验证、可追溯、可审计的协作协议。顶层是策略层（Policy），决定“什么时候该省电”；中间是框架层（Core），规定“怎么协商省电”；底层是执行层（Driver），负责“具体怎么关电”。三层之间通过明确的 API 边界和状态机流转进行解耦，任何一层的变更，只要不破坏接口语义，就不会波及其它层。

所以当你看到标题里“从 PM Core 看分层设计”，它绝不是在讲教科书式的抽象分层。它是在说：Linux 功耗子系统的生命力，恰恰来自它对“契约精神”的极致坚持——每个驱动注册进来的struct dev_pm_ops，每个 CPU idle state 的struct cpuidle_state，每个电源域的struct generic_pm_domain，都不是孤立的数据结构，而是 PM Core 协议栈上的一枚齿轮。齿轮咬合得越紧，系统功耗越稳；一旦某个齿轮齿形磨损（比如驱动返回了非法状态码），整个链条就会打滑，表现为各种诡异的功耗异常。

这也是为什么“分层设计”这个词，在 Linux 内核文档里出现频率极高，但在实际工程中却常被忽视。很多工程师习惯性地把pm_runtime_put_sync()当成一个“关设备电源”的函数来用，却忘了它本质是向 PM Core 提交一份“我已释放设备使用权”的声明；同样，__pm_runtime_idle()也不是“让设备休眠”，而是触发一次跨层协商：先检查引用计数，再通知所属电源域，最后才可能调用驱动的runtime_suspend回调。这种语义鸿沟，正是绝大多数功耗问题的温床。

提示：不要把pm_runtime_*系列 API 理解为“电源开关”，它们是资源使用权的声明与释放机制。就像你去图书馆借书，还书动作本身不销毁书籍，但它改变了图书管理员（PM Core）对这本书可借状态的判断。

2. PM Core 的三层骨架：策略、框架、执行，谁在指挥谁？

PM Core 的分层不是凭空画出来的架构图，而是由内核源码目录结构、编译依赖关系和初始化顺序共同铸就的硬性事实。我们直接看kernel/power/目录下的真实布局：

kernel/power/ ├── main.c ← PM Core 框架主入口，定义全局变量 & 初始化函数 ├── suspend.c ← suspend/resume 核心流程（策略层 + 框架层胶合） ├── hibernate.c ← 休眠流程（策略层实现） ├── wakeup.c ← 唤醒源管理（策略层基础设施） ├── qos.c ← 电源质量服务（策略层参数调节） ├── pm.c ← 设备级 runtime PM 框架（核心协议实现） ├── pm-domains.c ← 电源域管理（框架层关键抽象） ├── pm-sleep.c ← sleep 状态通用处理（策略层基础） └── ...

注意这个目录里没有一个驱动文件，也没有任何芯片特定代码。它纯粹是协议引擎。真正的执行者，分散在各处：

drivers/base/power/：设备模型层的 PM 支撑（如runtime.c,main.c），实现dev_pm_ops的调度；
drivers/cpuidle/：CPU idle 策略与驱动适配（如governors/下的 ladder、menu 等 governor）；
drivers/soc/或arch/arm64/kernel/：SoC 特定的 idle entry 实现（如psci.c,cpu_psci.c）；
drivers/pci/pci-driver.c：PCI 设备的runtime_suspend/resume注册点；
drivers/usb/core/driver.c：USB 设备的 PM 回调注入点。

这种物理隔离，保证了策略演进（比如新增一种 suspend-to-idle 模式）无需修改驱动，框架升级（比如电源域支持嵌套）不影响策略逻辑，驱动更新（比如 USB PHY 加入新的 low-power mode）也不必碰 PM Core 主干。我们来看三层如何协同完成一次典型的suspend-to-RAM：

2.1 策略层：谁发起？何时发起？以什么模式发起？

策略层的核心是suspend_enter()函数（kernel/power/suspend.c）。它不关心“怎么关”，只回答三个问题：

触发源：是用户空间echo mem > /sys/power/state？还是内核事件（如 lid close）？或是自动策略（如 thermal throttle 触发）？
目标状态：mem（S3）、disk（hibernate）、freeze（lightweight suspend）？每种状态对应不同的唤醒能力、恢复速度和功耗深度。
约束条件：当前是否有未完成的 I/O？是否有设备拒绝 suspend（->prepare()返回错误）？是否有唤醒源处于 active 状态？

关键点在于：策略层永远不直接调用任何驱动的 suspend 回调。它只调用dpm_suspend_start()—— 这是框架层暴露给策略层的唯一入口。这个函数名里的dpm（Device Power Management）已经暗示了它的角色：设备电源管理的统一门面。

2.2 框架层：如何协调千差万别的设备？

框架层的中枢是struct dev_pm_info（include/linux/pm.h），每个struct device都嵌入一个实例。它像一张动态状态表，记录着：

runtime_status：DPM_ACTIVE,DPM_SUSPENDING,DPM_SUSPENDED,DPM_RESUMING
power.disable_depth：禁用 runtime PM 的嵌套计数（防止误关）
power.runtime_error：最近一次 runtime 操作的错误码（用于故障定位）
power.usage_count：当前活跃引用计数（决定能否进入 suspend）

当dpm_suspend_start()被调用，它启动一个两阶段遍历：

第一阶段：prepare

按设备树拓扑逆序（child → parent）遍历所有设备；
对每个设备调用device_prepare()→dev->driver->pm->prepare()；
此回调允许驱动做不可逆准备（如保存寄存器上下文、关闭时钟门控），但不能真正切断电源；
若任一设备返回错误，整个 suspend 流程立即中止。

第二阶段：suspend

按设备树拓扑正序（parent → child）遍历；
对每个设备调用__device_suspend()→dev->driver->pm->suspend()；
此时才真正执行电源关闭、时钟停振等操作；
每个设备的状态被原子更新为DPM_SUSPENDED。

这个“prepare + suspend”两阶段设计，是框架层最精妙的容错机制。它确保：即使某个子设备 suspend 失败，其父设备的 prepare 已完成的状态也能被安全回滚（通过device_complete()），避免设备处于半死不活的中间态。

2.3 执行层：驱动如何正确签署这份“功耗契约”？

执行层的契约体现在struct dev_pm_ops的四个 mandatory 回调（suspend,resume,freeze,thaw）和两个 optional 回调（prepare,complete）。很多驱动开发者只实现suspend/resume，这是危险的简化。

我们以一个真实的 UART 驱动为例（drivers/tty/serial/8250/8250_port.c）：

static const struct dev_pm_ops serial8250_dev_pm_ops = { SET_SYSTEM_SLEEP_PM_OPS(serial8250_suspend, serial8250_resume) SET_RUNTIME_PM_OPS(serial8250_runtime_suspend, serial8250_runtime_resume, serial8250_runtime_idle) };

注意SET_RUNTIME_PM_OPS宏展开后，实际注册了三个函数：

runtime_suspend: 关闭 UART 时钟、保存 FIFO 状态、设置 GPIO 为低功耗模式；
runtime_resume: 恢复时钟、重载 FIFO、重置 GPIO；
runtime_idle:最关键——它不执行任何硬件操作，只检查port->idle标志和uart_console(port)是否为 console。如果是 console，立即返回-EBUSY，阻止 runtime suspend。

这个runtime_idle的存在，就是执行层对框架层契约的尊重：它告诉 PM Core，“我是否可以进入 idle” 不是由框架决定的，而是由设备自身业务逻辑决定的。框架层只负责传递这个决策，并根据返回值决定是否继续调用runtime_suspend。

注意：runtime_idle的返回值有严格语义：
0：同意进入 idle，框架将调用runtime_suspend；
-EBUSY：拒绝，框架停止对该设备的 runtime PM 操作；
其他负值：表示临时性错误，框架会稍后重试。

这种设计让驱动拥有最终裁决权，同时又把裁决逻辑标准化，避免了“每个驱动自己搞一套 idle 判断”的混乱局面。

3. 分层失配的典型现场：一个 UART 驱动引发的 suspend 链式崩溃

理论讲完，我们来复现一个真实踩过的坑。这个案例发生在某款基于 RK3399 的工业网关上，现象是：系统执行echo mem > /sys/power/state后，屏幕黑屏但串口无输出，dmesg日志卡在PM: suspend entry (deep)，再也无法响应任何按键或网络请求。

3.1 排查起点：从 suspend 流程日志切入

首先启用 PM debug：

echo 1 > /sys/module/suspend/parameters/verbose echo 'subsys:pm' > /sys/kernel/debug/dynamic_debug/control

然后触发 suspend，观察dmesg输出。关键线索出现在：

[ 1234.567890] PM: suspend entry (deep) [ 1234.567891] PM: Syncing filesystems ... done. [ 1234.567892] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 1234.567893] OOM killer disabled. [ 1234.567894] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 1234.567895] PM: suspend devices ... [ 1234.567896] usb 1-1: suspend [ 1234.567897] mmc0: suspend [ 1234.567898] serial 3f800000.serial: suspend [ 1234.567899] serial 3f800000.serial: suspend returned 0 [ 1234.567900] serial 3f800000.serial: suspend finished [ 1234.567901] platform 3f800000.serial: suspend [ 1234.567902] platform 3f800000.serial: suspend returned -16

注意最后一行：platform 3f800000.serial: suspend returned -16。-16是EBUSY错误码。这意味着 platform 设备（即 UART 控制器的父设备）在->suspend()回调里主动拒绝了 suspend 请求。

3.2 深挖根源：Platform 设备的 suspend 回调为何返回 EBUSY？

查看 RK3399 UART 平台驱动（drivers/tty/serial/8250/8250_rockchip.c），其rk3399_serial_suspend函数如下：

static int rk3399_serial_suspend(struct platform_device *pdev, pm_message_t state) { struct uart_8250_port *up = dev_get_drvdata(&pdev->dev); struct uart_port *port = &up->port; if (port->console && console_trylock()) { console_unlock(); return -EBUSY; // ← 就是这里！ } serial8250_suspend_port(up); return 0; }

这段代码的本意是：如果当前 UART 是 kernel console，就禁止 suspend，防止 suspend 过程中丢失重要 log。但问题在于——它违反了 PM Core 的分层契约。

按照契约，console 的占用状态应该在runtime_idle阶段就被识别并返回-EBUSY，从而阻止runtime_suspend被调用。而这里却在system suspend的suspend阶段才检查，属于“事后诸葛亮”。更严重的是，console_trylock()的调用本身就有风险：在 suspend 上下文中尝试获取 console lock，极易引发死锁（因为 suspend 流程本身可能正在打印 log）。

3.3 链式反应：EBUSY 如何导致整个 suspend 卡死？

PM Core 对suspend回调返回EBUSY的处理逻辑是：立即中止当前设备树分支的 suspend，并向上级设备（parent）报告失败。上级设备收到子设备失败后，会尝试complete自己的 prepare 阶段，然后放弃自己的 suspend。

但在 RK3399 平台上，UART 控制器（platform 3f800000.serial）的 parent 是socbus 设备，而socbus 的 suspend 回调又依赖于所有子设备成功 suspend。于是整个socbus suspend 失败，进而导致socbus 的 parent（通常是arm-pmu或cpuidle）也无法 suspend，最终cpuidle_enter()被阻塞，CPU 无法进入 deepest C-state，系统就僵在 suspend 流程的中间态。

3.4 修复方案：回归分层契约

正确的修复不是简单删掉console_trylock()，而是把 console 占用检查前移到runtime_idle阶段：

static int rk3399_serial_runtime_idle(struct device *dev) { struct uart_8250_port *up = dev_get_drvdata(dev); struct uart_port *port = &up->port; // 在 runtime idle 阶段就检查 console 占用 if (port->console && console_is_locked()) return -EBUSY; return 0; } // 同时移除 suspend 回调里的 console 检查 static int rk3399_serial_suspend(struct platform_device *pdev, pm_message_t state) { struct uart_8250_port *up = dev_get_drvdata(&pdev->dev); serial8250_suspend_port(up); return 0; }

这样，当 UART 作为 console 被占用时，runtime_idle会提前返回-EBUSY，框架层就不会再调用runtime_suspend，更不会走到system suspend的suspend阶段。整个流程干净利落，符合分层设计的预期。

经验总结：任何需要“业务逻辑判断”的功耗决策，必须放在runtime_idle或prepare阶段，绝不能拖到suspend阶段。suspend回调的唯一职责，是执行确定性的硬件操作。

4. 理解分层，就是理解 Linux 内核的“治理哲学”

PM Core 的分层设计，表面看是技术架构，深层却是 Linux 内核社区几十年演化出的分布式协作治理哲学。它解决的不是一个技术问题，而是一个社会性问题：如何让全球数万名开发者，在不互相干扰的前提下，共同维护一个超过3000万行代码的巨型软件？

我们对比一下传统单体式功耗管理的困境：

强耦合：驱动直接操作寄存器关电，PM 逻辑散落在各处；
无审计：无法追踪“谁在什么时候关了哪个电源域”；
难调试：一个驱动的 bug 可能导致整个系统 suspend 失败，但日志里只显示suspend returned -16；
零复用：ARM 平台的 idle 代码无法用在 x86 上，反之亦然。

而 PM Core 的分层，本质上是一种接口即法律的治理模式：

策略层是立法机构：定义 suspend/hibernate 的宪法性原则（如“必须保证唤醒源可用”）；
框架层是司法系统：提供统一的执法流程（prepare/suspend/complete），确保所有设备按同一套程序接受审查；
执行层是公民守法：每个驱动作为“公民”，只需签署dev_pm_ops这份契约，承诺在runtime_idle里如实申报状态，在suspend里严格执行指令。

这种模式带来的好处是惊人的：

4.1 可预测性：功耗行为成为可验证的数学命题

当所有设备都遵循同一套状态机，整个系统的功耗路径就变成了一张有向无环图（DAG）。我们可以用pm_trace工具生成完整的 suspend/resume 调用链：

# 开启 trace echo 1 > /sys/power/pm_trace echo mem > /sys/power/state # 崩溃后重启，读取 last_kmsg 中的 trace dmesg | grep "PM:" | head -50

输出类似：

PM: Starting suspend... PM: Preparing devices for suspend... PM: Suspending devices... PM: device 3f800000.serial: preparing PM: device 3f800000.serial: prepared PM: device 3f800000.serial: suspending PM: device 3f800000.serial: suspended PM: device soc: suspending ...

每一行都是一个确定的状态跃迁。如果某行缺失，说明某个设备的 prepare/suspend 没被调用；如果某行重复出现，说明状态机循环了。这种可追溯性，是单体式设计永远无法提供的。

4.2 可组合性：新硬件接入只需“填空”，无需“重写”

假设你要为一颗全新的 RISC-V SoC 添加 CPU idle 支持。在旧模式下，你得重写整个 idle loop、时钟管理、中断路由。而在 PM Core 框架下，你只需做三件事：

在drivers/cpuidle/cpuidle-riscv.c中实现riscv_cpuidle_init()，注册struct cpuidle_driver；
为每个 CPU core 实现struct cpuidle_state数组，描述 WFI、WFI+clock-gating、WFI+power-gating 等状态；
在arch/riscv/kernel/process.c的cpu_startup_entry()中调用cpuidle_enter()。

框架层自动处理：状态选择（governor）、唤醒源注册（wakeup interrupt）、统计（/sys/devices/system/cpu/cpuidle/state*/usage）。你甚至不需要碰kernel/power/下的任何一行代码。

4.3 可进化性：策略升级不伤筋动骨

Linux 5.10 引入了suspend-to-idle（S2Idle）模式，它不切断主电源，只让 CPU 进入 deepest C-state，靠 timer 和 IRQ 唤醒。这个新模式的加入，没有修改任何一个驱动的dev_pm_ops，只是在策略层新增了一个enter_s2idle()函数，并在suspend_enter()里根据state参数选择调用路径。所有现有驱动，一夜之间就获得了 S2Idle 支持。

这就是分层设计的终极价值：它把变化关进笼子里。策略变，框架不动；框架变，驱动不动；只有当接口语义改变时（如新增一个 mandatory 回调），才需要驱动升级。这种稳定性，是 Linux 能在 30 年间持续演进的根本保障。

我的体会：读 PM Core 源码，与其说是学功耗技术，不如说是学一种大型开源项目的协作范式。它告诉你，真正的工程能力，不在于写出多炫酷的算法，而在于设计出能让成千上万人安心协作的接口契约。

5. 动手验证：用最简代码看清分层脉络

光说不练假把式。我们用一个极简的 platform driver，亲手演示三层如何咬合。目标：创建一个虚拟设备dummy_pm_dev，它在runtime_idle里随机返回EBUSY或0，观察 PM Core 如何响应。

5.1 编写 dummy_pm_dev 驱动（drivers/misc/dummy_pm.c）

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/pm.h> #include <linux/random.h> static int dummy_runtime_idle(struct device *dev) { int ret; get_random_bytes(&ret, sizeof(ret)); ret = abs(ret) % 2; // 50% 概率返回 0 或 1 dev_info(dev, "runtime_idle: returning %s\n", ret ? "EBUSY" : "OK"); return ret ? -EBUSY : 0; } static int dummy_runtime_suspend(struct device *dev) { dev_info(dev, "runtime_suspend: called\n"); return 0; } static int dummy_runtime_resume(struct device *dev) { dev_info(dev, "runtime_resume: called\n"); return 0; } static const struct dev_pm_ops dummy_pm_ops = { SET_RUNTIME_PM_OPS(dummy_runtime_suspend, dummy_runtime_resume, dummy_runtime_idle) }; static struct platform_driver dummy_pm_driver = { .probe = platform_device_register_simple, .remove = platform_device_unregister, .driver = { .name = "dummy_pm_dev", .pm = &dummy_pm_ops, .owner = THIS_MODULE, }, }; static struct platform_device *dummy_pdev; static int __init dummy_pm_init(void) { int ret; dummy_pdev = platform_device_register_simple("dummy_pm_dev", -1, NULL, 0); if (IS_ERR(dummy_pdev)) return PTR_ERR(dummy_pdev); ret = platform_driver_register(&dummy_pm_driver); if (ret) platform_device_unregister(dummy_pdev); return ret; } static void __exit dummy_pm_exit(void) { platform_driver_unregister(&dummy_pm_driver); platform_device_unregister(dummy_pdev); } module_init(dummy_pm_init); module_exit(dummy_pm_exit); MODULE_LICENSE("GPL");

5.2 编译加载并观察行为

编译进内核或作为 module 加载后，执行：

# 启用 runtime PM echo auto > /sys/devices/platform/dummy_pm_dev.0/power/control # 触发 runtime idle echo 0 > /sys/devices/platform/dummy_pm_dev.0/power/autosuspend # 查看 dmesg dmesg | tail -20

你会看到类似输出：

[ 1234.567890] dummy_pm_dev 0000:00:00.0: runtime_idle: returning OK [ 1234.567891] dummy_pm_dev 0000:00:00.0: runtime_suspend: called [ 1234.567892] dummy_pm_dev 0000:00:00.0: runtime_idle: returning EBUSY [ 1234.567893] dummy_pm_dev 0000:00:00.0: runtime_idle: returning OK [ 1234.567894] dummy_pm_dev 0000:00:00.0: runtime_suspend: called

注意：runtime_suspend只在runtime_idle返回0时被调用。这正是框架层在执行契约——它不信任驱动的“口头承诺”，只认runtime_idle的返回值。

5.3 修改驱动，制造分层失配

现在，我们故意破坏契约：在dummy_runtime_suspend里添加一个return -EBUSY;：

static int dummy_runtime_suspend(struct device *dev) { dev_info(dev, "runtime_suspend: called, but returning EBUSY!\n"); return -EBUSY; // ← 故意破坏 }

重新加载驱动，再次触发：

dmesg | tail -20

输出变为：

[ 1234.567890] dummy_pm_dev 0000:00:00.0: runtime_idle: returning OK [ 1234.567891] dummy_pm_dev 0000:00:00.0: runtime_suspend: called, but returning EBUSY! [ 1234.567892] dummy_pm_dev 0000:00:00.0: suspend returned -16 [ 1234.567893] dummy_pm_dev 0000:00:00.0: failed to suspend async: error -16

看到failed to suspend async了吗？这就是框架层对违约行为的惩罚：它把runtime_suspend的失败，标记为async操作失败，并记录错误。虽然设备没真正挂掉，但整个 runtime PM 流程被标记为异常，后续的 autosuspend 会更加保守。

这个实验清晰地表明：分层不是纸面上的漂亮架构，而是运行时强制执行的纪律。框架层像一个严厉的裁判，时刻盯着每个驱动是否遵守runtime_idle→runtime_suspend的先后顺序和返回值约定。

最后一个小技巧：要快速定位某个设备的 PM 状态，别翻/sys/power/下的迷宫，直接用cat /sys/devices/.../power/runtime_status。它实时显示active,suspending,suspended,resuming，比任何日志都直观。