电源管理与 suspend/resume
这页讲的是：设备和系统不是只有“开着工作”这一种状态，Linux 还要考虑省电、空闲、挂起、恢复，以及哪些硬件应该先睡、哪些必须后睡。学这页的重点，是理解电源管理不是附加优化，而是设备生命周期的一部分。
这块是什么
电源管理与 suspend/resume，讲的是 Linux 如何在系统空闲或用户明确要求时，让设备和整机进入更省电的状态，又如何在需要时把它们有序唤醒恢复。它不仅关乎耗电，更关乎恢复后设备还能不能继续正确工作。
可以把它理解成：不是把整栋楼直接一键断电再通电，而是要按楼层、设备和依赖关系安排谁先关灯、谁先断电、谁恢复时必须最先醒来。
它负责什么
管理设备空闲与省电
- 设备不用时可以降功耗或暂时停下来
- 减少无意义能耗
- 让移动设备和服务器都能更合理管理功耗
- 把“忙的时候快、闲的时候省”做成系统能力
组织整机挂起与恢复
- 系统挂起前要安排设备逐步进入合适状态
- 恢复时又要按顺序拉起
- 避免恢复后设备半死不活
- 让 suspend/resume 不至于变成碰运气
处理依赖与时序
- 有些设备依赖总线、时钟、电源域或别的设备
- 不能随便想睡就睡、想醒就醒
- 驱动要配合系统整体电源管理策略
- 让省电和可用性之间保持平衡
为什么电源管理不是简单开关机
| 如果想得太简单 | 会怎样 | 真正麻烦在哪 |
|---|
| 觉得空闲就直接关 | 可能会把仍被依赖的设备过早停掉。 | 设备之间常有依赖关系和恢复顺序。 |
| 觉得恢复就是重新打开 | 很多状态、缓冲和寄存器关系可能已经丢了。 | 恢复后要重新建立“还能正确工作”的现场。 |
| 觉得只影响省电 | 实际上还会影响稳定性、延迟和设备可用性。 | 省电和性能、可恢复性要一起权衡。 |
| 觉得只有笔记本在乎 | 服务器、嵌入式、移动设备都有自己的功耗和空闲管理需求。 | 这是一套普遍系统能力，不是某类机器的附属功能。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| runtime PM | 设备在系统运行过程中就可以按空闲状态单独省电的一类思路。 |
| suspend | 整机或更大范围进入低功耗状态前的有序停靠过程。 |
| resume | 从低功耗状态恢复后，让设备重新进入可用状态的过程。 |
| 依赖顺序 | 哪些设备能先睡、哪些必须后睡，恢复时又该谁先醒。 |
| 状态恢复 | 省电回来以后，不只是电重新通了，还要保证逻辑现场重新成立。 |
为什么重要
- 它解释了为什么驱动不仅要会启动设备，还要会把设备安全睡下再叫醒。
- 很多“睡眠后设备失灵”或“恢复后偶发异常”问题，根子都在这里。
- 理解这层后，你会更容易把设备生命周期从“初始化一次”升级成“长期管理关系”。
- 它让你看到性能、能耗、稳定性并不是分开的三件事。
常见误解
- 误解一：电源管理只是优化项。实际上很多平台上它是设备能否稳定工作的必修课。
- 误解二：挂起恢复只是系统级动作。实际上每个驱动、每个设备都可能要参与其中。
- 误解三：恢复成功就说明逻辑都没问题。实际上很多 bug 只会在恢复后的后续运行中慢慢暴露。
它不负责什么
- 它不替代 probe/remove，但会把设备生命周期从启动/退出扩展到睡眠/恢复。
- 它不单独解决资源清理问题，但常与中断、DMA、时钟、队列和对象状态一起联动。
- 它不只关乎省电数字，更关乎状态一致性和恢复正确性。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| 设备模型与驱动框架 | 电源管理深深依赖驱动与设备的生命周期组织方式。 |
| probe、remove 与资源清理 | 挂起恢复虽然不是卸载，但同样要处理停用、恢复和资源状态切换。 |
| 中断 / DMA / 队列 | 设备睡下和醒来前后，这些路径都可能需要暂停、恢复或重新同步。 |
| 引用计数 / 生命周期 | 设备暂时睡下不等于对象消失，很多关系仍然活着，只是进入了不同状态。 |
读完这页后，你应该能回答
- 为什么电源管理不是“关掉再打开”这么简单？
- 为什么 suspend/resume 需要和驱动生命周期、依赖顺序一起理解？
- 为什么恢复后的正确性往往比进入低功耗本身更难保证？
后面适合继续问：runtime PM 和整机 suspend 在思路上有什么差别？为什么很多 bug 只在恢复之后才出现？设备恢复时最容易漏掉哪类现场重建？