做 Linux 驱动或 BSP 时电源管理问题通常不是一句“进 suspend 了”就能解释清楚的。同样是省电echo mem /sys/power/state是整机进入睡眠pm_runtime_put_autosuspend()是单个设备在运行态下自动降功耗CPUIdle 是 CPU 在没有任务时挑一个合适的 C-stateCPUFreq/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/resumeWorking-state power management系统仍在工作但某些 CPU 或设备暂时不用在不停止整个系统的前提下降低局部功耗Runtime PM、CPUIdle、CPUFreq、Devfreq、OPP、GenPD、PM QoS原资料里把这两类称为Static和Dynamic。更准确地说Static关注“系统整体已经不活跃时怎么省电”Dynamic关注“系统还在运行时短暂空闲或负载变化时怎么省电”。不要把这两类混在一起看。system suspend会冻结用户态、停止设备、关 CPU、进入平台 sleep stateRuntime PM 不会冻结用户态它只管理单个设备的运行态 idleCPUIdle 甚至是每个 CPU 在 idle loop 里根据预测挑一个睡眠深度。2. System suspend从/sys/power/state到平台固件用户态触发系统睡眠最常见的入口是/sys/power/statecat/sys/power/statecat/sys/power/mem_sleepechofreeze/sys/power/stateechomem/sys/power/stateechodisk/sys/power/state几个常见 sleep state 的差异可以先这样记状态常见名字大致动作唤醒代价freezeSuspend-to-Idle / S2Idle纯软件 suspend冻结用户态、暂停 timekeeping、设备进低功耗CPU 进最深 idle最小standby/shallowPower-on suspend在 S2Idle 基础上 offline nonboot CPU挂起底层系统功能中等mem/deepSuspend-to-RAM / STRRAM 自刷新其他大部分模块掉电通常需要平台/固件配合较大diskHibernation / 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 offlinesyscore 已 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*foodev_get_drvdata(dev);if(device_may_wakeup(dev))enable_irq_wake(foo-irq);return0;}staticintfoo_resume(structdevice*dev){structfoo*foodev_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_SUSPENDsuspend/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 countstaticintfoo_open(structinode*inode,structfile*file){structfoo*foocontainer_of(inode-i_cdev,structfoo,cdev);pm_runtime_get_sync(foo-dev);return0;}staticintfoo_release(structinode*inode,structfile*file){structfoo*foocontainer_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、OPPCPU 省电不是一个按钮运行态 CPU 电源管理至少要分两件事子系统管什么典型问题CPUFreqCPU 忙的时候跑多快也就是 P-state / 频率电压选择当前负载需要多少算力CPUIdleCPU 没任务时睡多深也就是 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 taskCPU 会进入 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_us100;intfdopen(/dev/cpu_dma_latency,O_WRONLY);write(fd,latency_us,sizeof(latency_us));/* fd 保持打开期间请求持续有效关闭 fd 后请求自动清理 */设备也有自己的 PM QoSstructdev_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 IRQsuspend 卡住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-iEPM:|suspend|resume|wakeup|freez|irqcat/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 PMsystem 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.docxLinux Kernel Documentation: Power Management StrategiesLinux Kernel Documentation: System Sleep StatesLinux Kernel Documentation: System Suspend Code FlowsLinux Kernel Documentation: Device Power Management BasicsLinux Kernel Documentation: System Suspend and Device InterruptsLinux Kernel Documentation: Freezing of tasksLinux Kernel Documentation: Runtime Power Management Framework for I/O DevicesLinux Kernel Documentation: PM Quality Of Service InterfaceLinux Kernel Documentation: CPU Idle Time ManagementLinux Kernel Documentation: CPU Performance ScalingLinux Kernel Documentation: Operating Performance Points LibraryLinux Kernel Documentation: Device Frequency ScalingThara Gopinath / Viresh Kumar: Linux Kernel Power Management: An OverviewLoyenWang: Linux Suspend 流程分析hello_yj: Linux resume 流程