尧图网页设计 
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 等 governordrivers/soc/或arch/arm64/kernel/SoC 特定的 idle entry 实现如psci.c,cpu_psci.cdrivers/pci/pci-driver.cPCI 设备的runtime_suspend/resume注册点drivers/usb/core/driver.cUSB 设备的 PM 回调注入点。这种物理隔离保证了策略演进比如新增一种 suspend-to-idle 模式无需修改驱动框架升级比如电源域支持嵌套不影响策略逻辑驱动更新比如 USB PHY 加入新的 low-power mode也不必碰 PM Core 主干。我们来看三层如何协同完成一次典型的suspend-to-RAM2.1 策略层谁发起何时发起以什么模式发起策略层的核心是suspend_enter()函数kernel/power/suspend.c。它不关心“怎么关”只回答三个问题触发源是用户空间echo mem /sys/power/state还是内核事件如 lid close或是自动策略如 thermal throttle 触发目标状态memS3、diskhibernate、freezelightweight suspend每种状态对应不同的唤醒能力、恢复速度和功耗深度。约束条件当前是否有未完成的 I/O是否有设备拒绝 suspend-prepare()返回错误是否有唤醒源处于 active 状态关键点在于策略层永远不直接调用任何驱动的 suspend 回调。它只调用dpm_suspend_start()—— 这是框架层暴露给策略层的唯一入口。这个函数名里的dpmDevice Power Management已经暗示了它的角色设备电源管理的统一门面。2.2 框架层如何协调千差万别的设备框架层的中枢是struct dev_pm_infoinclude/linux/pm.h每个struct device都嵌入一个实例。它像一张动态状态表记录着runtime_statusDPM_ACTIVE,DPM_SUSPENDING,DPM_SUSPENDED,DPM_RESUMINGpower.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.cstatic 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、重置 GPIOruntime_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 debugecho 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、WFIclock-gating、WFIpower-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-idleS2Idle模式它不切断主电源只让 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比任何日志都直观。 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 等 governordrivers/soc/或arch/arm64/kernel/SoC 特定的 idle entry 实现如psci.c,cpu_psci.cdrivers/pci/pci-driver.cPCI 设备的runtime_suspend/resume注册点drivers/usb/core/driver.cUSB 设备的 PM 回调注入点。这种物理隔离保证了策略演进比如新增一种 suspend-to-idle 模式无需修改驱动框架升级比如电源域支持嵌套不影响策略逻辑驱动更新比如 USB PHY 加入新的 low-power mode也不必碰 PM Core 主干。我们来看三层如何协同完成一次典型的suspend-to-RAM2.1 策略层谁发起何时发起以什么模式发起策略层的核心是suspend_enter()函数kernel/power/suspend.c。它不关心“怎么关”只回答三个问题触发源是用户空间echo mem /sys/power/state还是内核事件如 lid close或是自动策略如 thermal throttle 触发目标状态memS3、diskhibernate、freezelightweight suspend每种状态对应不同的唤醒能力、恢复速度和功耗深度。约束条件当前是否有未完成的 I/O是否有设备拒绝 suspend-prepare()返回错误是否有唤醒源处于 active 状态关键点在于策略层永远不直接调用任何驱动的 suspend 回调。它只调用dpm_suspend_start()—— 这是框架层暴露给策略层的唯一入口。这个函数名里的dpmDevice Power Management已经暗示了它的角色设备电源管理的统一门面。2.2 框架层如何协调千差万别的设备框架层的中枢是struct dev_pm_infoinclude/linux/pm.h每个struct device都嵌入一个实例。它像一张动态状态表记录着runtime_statusDPM_ACTIVE,DPM_SUSPENDING,DPM_SUSPENDED,DPM_RESUMINGpower.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.cstatic 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、重置 GPIOruntime_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 debugecho 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、WFIclock-gating、WFIpower-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-idleS2Idle模式它不切断主电源只让 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比任何日志都直观。