Linux Power Management 子系统：从 suspend/resume 到 Runtime PM、PM QoS
做 Linux 驱动或 BSP 时，电源管理问题通常不是一句“进 suspend 了”就能解释清楚的。
同样是省电，echo mem > /sys/power/state是整机进入睡眠；pm_runtime_put_autosuspend()是单个设备在运行态下自动降功耗；CPUIdle 是 CPU 在没有任务时挑一个合适的 C-state；CPUFreq/Devfreq 是运行中根据负载调频；PM QoS 则经常反过来告诉内核“别睡太深， latency 顶不住”。
这些机制都属于 Linux Power Management，但它们解决的问题完全不同。本文按一条主线把它们串起来：先分清 system-wide PM 和 working-state PM，再看 suspend/resume 的路径、wakeup IRQ 的处理方式，最后回到 Runtime PM、CPUIdle、DVFS 和 PM QoS。
1. 先分清两类 PM：整机睡眠和运行态省电
Linux 内核文档把电源管理分成两种高层策略：
| 策略 | 典型场景 | 核心目标 | 常见机制 |
|---|---|---|---|
| System-wide power management | 系统长时间不用，要进入睡眠 | 让整个系统进入一个全局低功耗状态，用户态停止运行 | freeze、standby、mem、disk、system suspend/resume |
| Working-state power management | 系统仍在工作，但某些 CPU 或设备暂时不用 | 在不停止整个系统的前提下降低局部功耗 | Runtime PM、CPUIdle、CPUFreq、Devfreq、OPP、GenPD、PM QoS |
原资料里把这两类称为Static和Dynamic。更准确地说，Static关注“系统整体已经不活跃时怎么省电”，Dynamic关注“系统还在运行时，短暂空闲或负载变化时怎么省电”。
不要把这两类混在一起看。system suspend会冻结用户态、停止设备、关 CPU、进入平台 sleep state；Runtime PM 不会冻结用户态，它只管理单个设备的运行态 idle；CPUIdle 甚至是每个 CPU 在 idle loop 里根据预测挑一个睡眠深度。
2. System suspend：从/sys/power/state到平台固件
用户态触发系统睡眠最常见的入口是/sys/power/state：
cat/sys/power/statecat/sys/power/mem_sleepechofreeze>/sys/power/stateechomem>/sys/power/stateechodisk>/sys/power/state几个常见 sleep state 的差异可以先这样记：
| 状态 | 常见名字 | 大致动作 | 唤醒代价 |
|---|---|---|---|
freeze | Suspend-to-Idle / S2Idle | 纯软件 suspend：冻结用户态、暂停 timekeeping、设备进低功耗，CPU 进最深 idle | 最小 |
standby/shallow | Power-on suspend | 在 S2Idle 基础上 offline nonboot CPU，挂起底层系统功能 | 中等 |
mem/deep | Suspend-to-RAM / STR | RAM 自刷新，其他大部分模块掉电，通常需要平台/固件配合 | 较大 |
disk | Hibernation / STD | 内存镜像写入持久化存储后掉电，唤醒时重新加载镜像 | 最大 |
在嵌入式 ARM/ARM64 SoC 上，mem/deep往往会走到平台相关的 suspend hook，再通过 PSCI 调用进入 ATF/固件，由固件完成最后的掉电或低功耗状态切换。也就是说，Linux PM core 负责通用流程，平台代码和固件负责最后那一段 SoC 相关动作。
简化后的 suspend 路径可以看成这样：
echo mem > /sys/power/state -> pm_suspend() -> enter_state() -> suspend_prepare() -> suspend notifiers -> freeze user processes -> freeze freezable kernel threads -> suspend_devices_and_enter() -> dpm_suspend_start() -> device ->prepare() -> device ->suspend() -> suspend_enter() -> device ->suspend_late() -> suspend_device_irqs() -> device ->suspend_noirq() -> disable_nonboot_cpus() -> syscore_suspend() -> platform suspend_ops->enter()Resume 基本按相反方向回来：
platform wakeup -> syscore_resume() -> enable_nonboot_cpus() -> device ->resume_noirq() -> resume_device_irqs() -> device ->resume_early() -> device ->resume() -> device ->complete() -> thaw tasks -> resume notifiers这个流程里有三个分界点特别重要：
| 分界点 | 发生了什么 | 驱动要注意什么 |
|---|---|---|
| freezer 之后 | 用户态和可冻结内核线程不再正常运行 | 不要在 late 阶段还依赖用户态服务 |
| late 之后、noirq 之前 | 设备大多已经 quiesce，随后 IRQ handler 会被屏蔽 | 会和中断竞争的寄存器保存、唤醒配置要放对阶段 |
| 平台 enter 之前 | nonboot CPU offline，syscore 已 suspend | 平台 hook 里通常只剩很少的内核上下文可用 |
3. 为什么 suspend 前要 freeze 进程
Freezer 不是为了“让系统看起来安静一点”，而是为了避免用户态或部分内核线程在设备 suspend 时继续访问硬件。
官方 freezer 文档里有几个关键点：
| 对象 | freeze 方式 | 驱动相关影响 |
|---|---|---|
| 用户态进程 | freezer 启动后，通过类似信号路径让任务进入冻结状态 | 用户态不会继续通过 ioctl、mmap、sysfs 等路径碰设备 |
| 可冻结内核线程 | 线程必须主动set_freezable()并周期性调用try_to_freeze()或使用wait_event_freezable() | 驱动私有线程如果会直接访问设备，要么用 freezer，要么用更精确的锁/状态机同步 |
| 不可冻结内核线程 | 默认不会 freeze | 不能假设所有内核线程都停了 |
这解释了一个常见问题：如果 resume 回调里调用request_firmware()，可能会卡住或超时。因为用户态还没完全回来，提供 firmware 的用户态进程可能仍处在冻结阶段。驱动需要的 firmware 应该在 suspend 前准备好，或者用合适的 notifier 提前处理。
4. 设备 PM 回调：不是所有动作都塞进suspend()
struct dev_pm_ops是设备驱动和 PM core 之间最常见的接口：
structdev_pm_ops{int(*prepare)(structdevice*dev);void(*complete)(structdevice*dev);int(*suspend)(structdevice*dev);int(*resume)(structdevice*dev);int(*suspend_late)(structdevice*dev);int(*resume_early)(structdevice*dev);int(*suspend_noirq)(structdevice*dev);int(*resume_noirq)(structdevice*dev);int(*runtime_suspend)(structdevice*dev);int(*runtime_resume)(structdevice*dev);int(*runtime_idle)(structdevice*dev);};写驱动时可以按阶段分配职责：
| 阶段 | 典型职责 | 不适合做什么 |
|---|---|---|
prepare() | 阻止新的 child device 注册；处理 direct-complete 判断 | 不要直接把设备打到低功耗 |
suspend() | 停 I/O、停队列、保存主要上下文、必要时配置 wakeup | 不要长时间阻塞 |
suspend_late() | 做 suspend 后半段，通常是保存剩余状态、关闭部分资源 | 不要再依赖 Runtime PM 继续调度 |
suspend_noirq() | 在普通 action IRQ handler 不会再运行后，处理会和中断竞争的状态 | 不要做需要普通中断完成的等待 |
resume_noirq() | 在 IRQ action handler 恢复前，把设备恢复到能识别中断来源的状态 | 不要假设完整业务 I/O 已恢复 |
resume_early() | 撤销 late 阶段动作 | 不要过早唤醒用户可见业务流 |
resume() | 恢复设备正常 I/O 能力 | 不要忘记 Runtime PM 状态一致性 |
complete() | 撤销 prepare 阶段动作；处理 direct-complete 后续 | 不要假设所有设备都走过完整 suspend/resume |
一个实用判断是：如果某段代码可能和中断处理函数抢同一组寄存器，它通常不应该放在普通suspend()里，而要考虑 late/noirq 阶段。反过来，如果某段代码需要睡眠、需要用户态、需要复杂依赖，它就不应该放到 noirq 之后。
5. Wakeup source：能中断，不等于能唤醒系统
资料里的触摸屏唤醒案例很典型：设备平时有普通中断，系统 suspend 后又希望“双击屏幕”能唤醒整机。驱动里通常会看到这些接口：
/* 声明设备具备 wakeup 能力，并启用 wakeup source */device_init_wakeup(dev,true);staticintfoo_suspend(structdevice*dev){structfoo*foo=dev_get_drvdata(dev);if(device_may_wakeup(dev))enable_irq_wake(foo->irq);return0;}staticintfoo_resume(structdevice*dev){structfoo*foo=dev_get_drvdata(dev);if(device_may_wakeup(dev))disable_irq_wake(foo->irq);return0;}这里最容易混淆的是enable_irq_wake()和IRQF_NO_SUSPEND：
| 机制 | 作用 | 关键区别 |
|---|---|---|
enable_irq_wake() | 把某条 IRQ 配置成系统 wakeup IRQ | 目标是唤醒系统，平台可能要把信号路由到专门的唤醒逻辑 |
IRQF_NO_SUSPEND | suspend/resume 周期内不被suspend_device_irqs()关闭 | 只能说明这条 IRQ suspend 时仍可触发，不保证能唤醒系统 |
官方文档明确强调：IRQF_NO_SUSPEND不等价于系统唤醒。如果目标是把系统从 sleep state 拉回来，要使用enable_irq_wake()。同一个设备上通常也不应该同时混用IRQF_NO_SUSPEND和enable_irq_wake()，因为二者在 suspend 后是否执行普通 interrupt handler 的语义是冲突的。
再看 wakeup IRQ 的时序：
suspend_late 完成 -> suspend_device_irqs() -> wakeup IRQ 保持特殊 armed 状态 -> 系统进入 sleep -> 设备触发 wake signal -> PM core 记录 wakeup event，启动 resume -> resume_noirq / resume_device_irqs() -> 设备正常 IRQ handler 才适合恢复完整处理所以双击唤醒这类驱动不要假设“中断来了就可以马上访问所有硬件资源”。如果 IRQ 线程可能在 resume 尚未完成时跑起来，常见做法是只记录 wake 事件，或者在 threaded IRQ/workqueue 中等待一个 resume completion，并且一定要带 timeout，避免 PM 路径被驱动自己卡死。
6. Runtime PM：系统醒着，设备也可以睡
System suspend 是整机级别的状态迁移；Runtime PM 是设备级别的运行态 idle 管理。
Runtime PM 的典型模型是 use count：
staticintfoo_open(structinode*inode,structfile*file){structfoo*foo=container_of(inode->i_cdev,structfoo,cdev);pm_runtime_get_sync(foo->dev);return0;}staticintfoo_release(structinode*inode,structfile*file){structfoo*foo=container_of(inode->i_cdev,structfoo,cdev);pm_runtime_mark_last_busy(foo->dev);pm_runtime_put_autosuspend(foo->dev);return0;}staticconststructdev_pm_opsfoo_pm_ops={SET_RUNTIME_PM_OPS(foo_runtime_suspend,foo_runtime_resume,foo_runtime_idle)};pm_runtime_get_sync()表示“我要用设备，确保它恢复到 active”；pm_runtime_put_autosuspend()表示“我暂时不用了，过一段 autosuspend delay 后可以进 runtime suspend”。当 use count 归零且策略允许时，PM core 会调用runtime_suspend()；再次使用时调用runtime_resume()。
Runtime PM 的价值在于它不影响用户态整体运行，也不要求整个系统进入 sleep。摄像头、I2C/SPI 外设、GPU、显示管线、USB 控制器等，都可以在系统醒着时按需关闭 clock、regulator 或 power domain。
不过 Runtime PM 和 System PM 会相遇。系统进入 suspend 时，某个设备可能已经 runtime-suspended。驱动要决定：保持它 suspend 状态直接跨过系统睡眠，还是先 runtime resume 回来再配置系统 wakeup。这个决策没有通用答案，取决于硬件 wake 能力和子系统约束。
7. CPUIdle、CPUFreq、OPP：CPU 省电不是一个按钮
运行态 CPU 电源管理至少要分两件事：
| 子系统 | 管什么 | 典型问题 |
|---|---|---|
| CPUFreq | CPU 忙的时候跑多快，也就是 P-state / 频率电压选择 | 当前负载需要多少算力 |
| CPUIdle | CPU 没任务时睡多深，也就是 C-state 选择 | 预计能睡多久，允许多大唤醒延迟 |
CPUFreq 由 core、governor 和 driver 组成。governor 根据利用率估计需要的性能，driver 负责把请求落到硬件。很多 SoC 上 CPUFreq/Devfreq 最后都会落到 OPP，也就是一组频率、电压二元组：
{ 300 MHz, 1.0 V } { 800 MHz, 1.2 V } { 1 GHz, 1.3 V }OPP 的意义不是“频率列表”这么简单，而是把“这个频率至少需要多少电压”结构化，供 CPUFreq、Devfreq、thermal、regulator、clock 等模块协同使用。
CPUIdle 关注的是另一件事：当 scheduler 发现某个 CPU 没有 runnable task，CPU 会进入 idle loop。CPUIdle governor 会结合几个条件选择 idle state：
| 条件 | 为什么重要 |
|---|---|
| 下一次 timer event 还有多久 | 睡太深可能还没省回成本就被 timer 叫醒 |
| idle state 的 target residency | 进入该状态至少要待多久才划算 |
| idle state 的 exit latency | 从该状态醒来最坏要多久 |
| PM QoS latency limit | 有业务声明低延迟要求时，不能选超过限制的深睡眠 |
所以“系统耗电高”不一定是 CPUFreq 没降频，也可能是 CPUIdle 被某个 PM QoS 请求限制，只能进浅 C-state；也可能是频繁 timer/IRQ 让 CPU 根本睡不久。
8. PM QoS：它不是省电按钮，而是约束系统别省过头
PM QoS 的名字容易误导。它不是直接省电的机制，而是性能约束接口。它告诉内核：在省电时要满足某些 latency、throughput 或 device-specific 限制。
最常见的是 CPU latency QoS。内核维护一组请求，并把有效值聚合出来。对 CPU latency 来说，聚合值通常取所有请求里的最小值，因为最严格的 latency 约束必须被满足。
用户态可以通过保持/dev/cpu_dma_latency打开的方式提交约束：
int32_tlatency_us=100;intfd=open("/dev/cpu_dma_latency",O_WRONLY);write(fd,&latency_us,sizeof(latency_us));/* fd 保持打开期间，请求持续有效；关闭 fd 后请求自动清理 */设备也有自己的 PM QoS：
structdev_pm_qos_requestqos_req;dev_pm_qos_add_request(dev,&qos_req,DEV_PM_QOS_RESUME_LATENCY,500);dev_pm_qos_update_request(&qos_req,1000);dev_pm_qos_remove_request(&qos_req);这类约束会影响 Runtime PM、GenPD governor、CPUIdle state 选择等策略。比如音频播放需要稳定低延迟时，系统可能不能让 CPU 进入 exit latency 很大的深 C-state；某个设备 resume latency 受限时，它所在的 power domain 可能不能轻易 power off。
9. 调试 suspend/resume 时按层切，不要一把抓
调试 PM 问题最怕从整条链路同时猜。更好的办法是按层拆：
| 现象 | 优先检查 |
|---|---|
写/sys/power/state后直接失败 | dmesg里 PM core 报错、freezer 是否失败、哪个 device callback 返回错误 |
| 能 suspend 但马上醒 | wakeup source、/proc/interrupts、/sys/kernel/debug/wakeup_sources、ACPI/SoC wake IRQ |
| suspend 卡住 | device suspend callback 是否阻塞、是否在 noirq 后等待普通中断、是否请求用户态资源 |
| resume 后设备不可用 | resume_noirq/early/resume 阶段是否恢复寄存器、clock/regulator、IRQ 状态 |
| 运行态功耗高 | CPUIdle state、PM QoS 请求、timer/IRQ 唤醒频率、Runtime PM use count |
常用命令可以先准备这些：
dmesg-T|grep-iE'PM:|suspend|resume|wakeup|freez|irq'cat/sys/power/statecat/sys/power/mem_sleepcat/sys/power/wakeup_countfind/sys/devices-path'*/power/wakeup'-printmount-tdebugfs none /sys/kernel/debugcat/sys/kernel/debug/wakeup_sourcescat/proc/interruptscat/sys/devices/system/cpu/cpuidle/current_drivercat/sys/devices/system/cpu/cpuidle/current_governor_ro如果内核打开了CONFIG_PM_DEBUG，还可以用/sys/power/pm_test按层测试：
cat/sys/power/pm_testechofreezer>/sys/power/pm_testechomem>/sys/power/stateechodevices>/sys/power/pm_testechomem>/sys/power/stateechonone>/sys/power/pm_testfreezer -> devices -> platform -> processors -> core是逐步深入的。哪一级失败，就先看那一级之前刚引入的动作，不要一开始就怀疑全部驱动或整个平台固件。
10. 写驱动时的 PM checklist
最后给一个驱动侧 checklist：
| 问题 | 建议 |
|---|---|
| 设备是否能作为系统唤醒源 | probe 时用device_init_wakeup()；suspend/resume 中按device_may_wakeup()配置enable_irq_wake()/disable_irq_wake() |
| suspend 回调是否会等用户态 | 不要在 suspend 后半程依赖用户态；firmware 等资源提前准备 |
| 是否在 noirq 阶段等待普通 IRQ | 避免；普通 action handler 已被屏蔽 |
| 是否有 runtime PM | system PM 回调要考虑设备已经 runtime-suspended 的情况 |
| 是否共享 power domain | 不要只看单设备，GenPD 可能因为同域其他设备或 QoS 不能 power off |
| 是否有低延迟业务 | 检查 PM QoS 请求，CPUIdle/Runtime PM 可能因此被限制 |
| resume 后硬件是否可能被重置 | 对 deep sleep/平台 suspend 要能完整 reinit，不能只假设寄存器保持 |
把 Linux PM 看成一条链会很乱。更好的心智模型是：system-wide PM 负责“整机什么时候睡、怎么睡、怎么醒”；working-state PM 负责“系统醒着时，哪些局部资源可以按需降功耗”；PM QoS 则是在二者之间不断加约束，防止省电策略破坏 latency、throughput 或设备恢复时间。
调 suspend/resume 时，先定位自己站在哪一层，再看对应的接口和时序。这样问题会小很多。
参考资料
- 本地资料：
/Users/josephcooper/Downloads/Linux Kernel Power Management.docx - Linux Kernel Documentation: Power Management Strategies
- Linux Kernel Documentation: System Sleep States
- Linux Kernel Documentation: System Suspend Code Flows
- Linux Kernel Documentation: Device Power Management Basics
- Linux Kernel Documentation: System Suspend and Device Interrupts
- Linux Kernel Documentation: Freezing of tasks
- Linux Kernel Documentation: Runtime Power Management Framework for I/O Devices
- Linux Kernel Documentation: PM Quality Of Service Interface
- Linux Kernel Documentation: CPU Idle Time Management
- Linux Kernel Documentation: CPU Performance Scaling
- Linux Kernel Documentation: Operating Performance Points Library
- Linux Kernel Documentation: Device Frequency Scaling
- Thara Gopinath / Viresh Kumar: Linux Kernel Power Management: An Overview
- LoyenWang: Linux Suspend 流程分析
- hello_yj: Linux resume 流程