企业官网建设流程全解析

1. 为什么 runtime PM 是内核功耗管理里最“狡猾”的一块拼图

你翻过 Linux 内核文档，大概率在Documentation/power/目录下见过runtime_pm.txt这个文件——它不长，不到两千行，但几乎每个嵌入式驱动工程师、SoC 芯片验证人员、甚至 Android BSP 开发者都曾被它卡住超过 8 小时。它不像cpuidle那样只管 CPU 停顿，也不像cpufreq那样只调频率；它干的是件更精细、更隐蔽、也更容易出错的事：在设备“不用”的瞬间，悄无声息地关掉它的电源，等它“要用了”，再零延迟唤醒——整个过程对上层驱动和用户空间完全透明。

这就是 runtime PM 的核心价值：它不是靠系统整体休眠（suspend-to-RAM）来省电，而是把功耗控制颗粒度从“整机级”细化到“单个外设级”。一个 USB 摄像头闲置时自动断电，一块 PCIe SSD 在无 IO 时进入 D3cold，一个 I2C 温度传感器每 30 秒采样一次、其余时间彻底断电——这些都不是靠应用层轮询或定时器硬控实现的，而是由内核在设备模型（device model）层面统一调度、原子化管理的结果。

我做过三款 ARM64 平台的低功耗网关产品，其中一款在待机功耗测试中，仅靠启用 runtime PM 就让整机静态功耗从 187mW 降到 92mW，降幅超 50%。这不是靠降低主频或关闭 CPU 核心实现的，而是因为：

• 两路千兆以太网 PHY 在链路断开后 200ms 内自动进入低功耗模式；
• SPI Flash 控制器在完成固件加载后立即切断 VCCQ 供电；
• HDMI CEC 接口控制器在未检测到遥控信号的 5 秒后，主动关闭其内部 PLL 和 IO 电源域。

这些动作全部由 runtime PM 子系统自动触发，无需驱动额外编写电源管理逻辑，也不依赖用户空间 daemon 干预。它真正实现了“设备即电源节点”的理念——每个 struct device 都自带一个 struct dev_pm_info，里面藏着一个 refcount、一个 usage_count、一个 suspend_status、一个 autosuspend_delay，还有四个关键回调函数指针（prepare、suspend、resume、complete）。这组结构体就像给每个硬件设备装上了智能电闸，而 runtime PM 就是那个永不疲倦的配电房调度员。

所以，当你看到标题《Linux 内核功耗子系统（七）：runtime pm功能梳理》时，别把它当成又一篇泛泛而谈的文档复述。它实际是在拆解一套内核级的、基于引用计数的、异步可中断的、与设备生命周期强绑定的动态电源门控机制。它解决的不是“能不能省电”，而是“如何在不破坏设备功能、不引入竞态、不拖慢响应的前提下，让省电这件事自动发生”。

适合谁读？如果你正在调试某块摄像头模组在 standby 状态下仍耗电 12mA，或者发现 USB 设备插拔后无法恢复供电，又或者在用cat /sys/devices/platform/xxx/power/runtime_status查看状态时总显示suspended却收不到中断——那你不是在看一篇技术文章，你是在找一把能打开电源黑盒的钥匙。

2. runtime PM 的设计哲学：不是“开关”，而是“状态流”

很多人初学 runtime PM，第一反应是：“不就是调用pm_runtime_suspend()和pm_runtime_resume()吗？”——这是典型误区。runtime PM 的本质不是一组 API，而是一套状态机 + 引用计数 + 延迟队列 + 异步工作流的组合体。它的设计逻辑完全围绕“设备何时可用、何时可停、停多久、谁说了算”展开，而不是简单粗暴的“开/关”指令。

2.1 四个核心状态及其流转条件

runtime PM 定义了设备的四种运行时状态，全部记录在dev->power.status中：

提示：RPM_SUSPENDING和RPM_RESUMING是瞬态中间状态，不可长期停留。如果某个设备卡在这两个状态超过 5 秒（默认 timeout），内核会打印 warning 并尝试强制超时处理——这往往是驱动 suspend/resume 回调阻塞或死锁的直接证据。

状态流转不是线性单向的。例如，一个设备处于RPM_SUSPENDED状态时，若此时有中断到来（如 GPIO 触发的 wakeup event），内核会自动触发 resume 流程，无需驱动干预。这种“事件驱动唤醒”能力，正是 runtime PM 区别于传统手动电源管理的关键。

2.2 引用计数：谁在用，谁负责供电

runtime PM 的核心调度依据是dev->power.usage_count，这是一个带符号的 atomic_t 计数器。它的增减规则极其严格：

• pm_runtime_get()：原子递增 usage_count，若原值 ≤ 0，则触发 resume 流程（异步）；
• pm_runtime_get_sync()：原子递增 usage_count，若原值 ≤ 0，则同步等待resume 完成后再返回；
• pm_runtime_put()：原子递减 usage_count，若结果为 0 且 autosuspend 已启用，则启动 suspend 延迟计时；
• pm_runtime_put_sync()：原子递减 usage_count，若结果为 0 且 autosuspend 已启用，则同步执行suspend 流程。

这个计数器的设计意图非常明确：只要有一个模块（驱动、子系统、甚至用户空间 ioctl）持有该设备的引用，设备就必须保持供电；只有当所有引用都被释放，且满足空闲条件，才允许挂起。

举个真实案例：某款工业相机驱动在 open() 时调用pm_runtime_get_sync(dev)，确保 sensor 和 ISP 通电；在 close() 时调用pm_runtime_put_sync(dev)。但如果在 read() 过程中，V4L2 子系统又调用了pm_runtime_get(dev)（用于保证 DMA buffer 访问期间供电稳定），那么即使 close() 执行完毕，usage_count 仍为 1，设备不会挂起。直到 V4L2 完成帧传输并调用pm_runtime_put(dev)，计数归零，autosuspend 倒计时才真正开始。

注意：pm_runtime_get()和pm_runtime_put()必须成对出现，且不能在中断上下文调用（因可能 sleep）。我在调试某款音频 codec 时，曾因在 IRQ handler 中误调pm_runtime_get()导致 hard lockup——因为该函数内部可能触发 workqueue 调度，而中断上下文禁止 sleep。

2.3 autosuspend：让挂起“等一等”，避免抖动

直接在 usage_count 归零后立刻 suspend，会导致高频设备（如触摸屏、加速度计）频繁启停，既增加唤醒延迟，又产生电源噪声。为此，runtime PM 引入了autosuspend_delay机制：

• 每个设备可通过dev->power.autosuspend设置延迟毫秒数（默认 -1，表示禁用 autosuspend）；
• 当 usage_count 归零时，内核启动一个struct delayed_work，延时autosuspend_delay后再执行 suspend；
• 若在此期间有新的pm_runtime_get()到达，则 cancel 该 work，并重置倒计时。

这个 delay 不是固定值，而是可动态调整的。例如，Android 的PowerManagerService会根据系统负载、屏幕状态、电池电量，通过 sysfs 接口（/sys/devices/.../power/autosuspend）实时修改各设备的 delay 值。我实测过：当手机进入 Doze 模式时，蓝牙 HCI 设备的 autosuspend_delay 会被设为 5000ms；而一旦检测到 BLE 广播包，该值立即降为 100ms，确保快速响应。

2.4 wakeup capability：让设备自己决定“能不能被叫醒”

并非所有设备都支持被外部事件唤醒。runtime PM 通过dev->power.can_wakeup和dev->power.wakeup字段管理这一能力：

• can_wakeup是布尔标志，由驱动在 probe 时设置（如device_set_wakeup_capable(dev, true)）；
• wakeup是一个struct wakeup_source *，代表该设备的唤醒源对象，包含 name、active count、expire time 等；
• 当设备处于 suspended 状态，且can_wakeup == true，则其 IRQ 可以触发__pm_wakeup_event()，进而调用pm_runtime_resume()。

这里有个关键细节：wakeup capability 必须在 suspend 前就准备好。如果驱动在 suspend 回调中才调用enable_irq_wake()，而此时设备电源已断，GPIO 中断控制器可能无法捕获信号。正确做法是在 probe 阶段就配置好 wakeup source，并在 suspend 回调中仅做最小化操作（如保存寄存器、关闭时钟）。

我曾遇到一块 STM32H7 的 USB OTG 设备，在 suspend 后无法被 host 枚举唤醒。查到最后发现：驱动在usb_otg_suspend()中调用了disable_irq(otg->irq)，但没调用enable_irq_wake(otg->irq)—— 导致内核认为该 IRQ 不具备 wakeup 能力，直接忽略其触发。修复方案很简单：在 probe 末尾添加enable_irq_wake(otg->irq)，并在 suspend 中移除disable_irq()调用。

3. 实操核心：从驱动注册到状态观测的完整链路

光懂理论不够，真正落地时，你得亲手把 runtime PM “接进”一个驱动里，并能准确观测其行为。下面以一个典型的 I2C 温度传感器（如 TMP102）为例，展示从初始化到验证的全流程。

3.1 驱动初始化阶段：声明能力、注册回调

// drivers/i2c/busses/i2c-tmp102.c static int tmp102_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct tmp102_data *data; int ret; data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; i2c_set_clientdata(client, data); >static int tmp102_runtime_suspend(struct device *dev) { struct i2c_client *client = to_i2c_client(dev); struct tmp102_data *data = i2c_get_clientdata(client); int ret; /* 1. 禁用连续转换模式（停止 ADC 采样）*/ ret = i2c_smbus_write_word_data(client, TMP102_REG_CONFIG, TMP102_CFG_SHUTDOWN); if (ret) return ret; /* 2. 关闭 VDD（如果硬件支持）——注意：此操作必须在 I2C 通信完成后 */ regulator_disable(data->vdd); /* 3. 关闭时钟（如果使用专用 clock）*/ clk_disable_unprepare(data->clk); dev_dbg(dev, "runtime suspend completed"); return 0; } static int tmp102_runtime_resume(struct device *dev) { struct i2c_client *client = to_i2c_client(dev); struct tmp102_data *data = i2c_get_clientdata(client); int ret; /* 1. 使能时钟 */ ret = clk_prepare_enable(data->clk); if (ret) return ret; /* 2. 使能 VDD */ ret = regulator_enable(data->vdd); if (ret) goto err_clk_disable; /* 3. 等待电源稳定（典型值 100us~1ms，查阅 datasheet）*/ usleep_range(100, 200); /* 4. 重写 config 寄存器，恢复连续转换模式 */ ret = i2c_smbus_write_word_data(client, TMP102_REG_CONFIG, TMP102_CFG_CONTINUOUS); if (ret) goto err_regulator_disable; dev_dbg(dev, "runtime resume completed"); return 0; err_regulator_disable: regulator_disable(data->vdd); err_clk_disable: clk_disable_unprepare(data->clk); return ret; }

注意事项：

• suspend 回调中严禁调用可能 sleep 的函数（如msleep()、wait_event_timeout()），因为该回调在 workqueue 上执行，且可能被中断上下文触发。必须用usleep_range()或硬件 busy-wait。
• resume 回调中必须检查所有资源获取是否成功，失败时要清理已分配资源（如上面的err_regulator_disable分支），否则下次 resume 可能因资源冲突失败。
• 所有 I2C 通信必须在电源稳定后进行。TMP102 datasheet 明确要求：VDD 上升至 1.8V 后，需等待至少 100μs 才能访问寄存器。

3.3 用户空间观测：用 sysfs 和 debugfs 看清每一帧状态

内核为 runtime PM 提供了丰富的观测接口，无需改代码、无需 recompile，即可实时诊断：

（1）基础状态查询

# 查看设备当前 runtime 状态 $ cat /sys/devices/platform/80860F09:01/i2c-0/0-0048/power/runtime_status active # 查看 usage_count 和 autosuspend_delay $ cat /sys/devices/platform/80860F09:01/i2c-0/0-0048/power/usage_count 1 $ cat /sys/devices/platform/80860F09:01/i2c-0/0-0048/power/autosuspend 3000 # 强制触发 suspend（用于测试） $ echo auto > /sys/devices/platform/80860F09:01/i2c-0/0-0048/power/control $ cat /sys/devices/platform/80860F09:01/i2c-0/0-0048/power/runtime_status suspended

（2）深度诊断：启用 PM debug log

# 开启 runtime PM 相关 debug 信息（需 CONFIG_PM_DEBUG=y） $ echo 1 > /sys/module/suspend/parameters/pm_debug_messages $ dmesg -c # 清空旧日志 $ cat /sys/devices/platform/80860F09:01/i2c-0/0-0048/power/runtime_status active # 此时 dmesg 会输出： # [ 123.456789] tmp102 0-0048: pm_runtime: resuming device # [ 123.457890] tmp102 0-0048: pm_runtime: device resumed

（3）wakeup source 监控

# 查看系统所有 wakeup source 活跃状态 $ cat /sys/power/wakeup_count 12345 # 查看具体设备的 wakeup 状态 $ cat /sys/devices/platform/80860F09:01/i2c-0/0-0048/power/wakeup enabled # 查看 wakeup event 统计（需 CONFIG_PM_SLEEP_DEBUG=y） $ cat /d/wakeup_sources name active_count event_count wakeup_count expire_count active_since tmp102_0-0048 0 12 12 0 0

实操技巧：当发现设备无法 suspend 时，先检查usage_count是否为 0。如果不是，用lsof或fuser查看哪些进程打开了该设备的 sysfs 节点；如果是 0，再检查autosuspend值是否为 -1（禁用），或power/control是否被设为on（强制常开）。我曾遇到一个 case：power/control被 udev rules 错误地设为on，导致所有 I2C 设备永久供电，功耗居高不下。

4. 常见问题与排查技巧实录：那些让你熬夜的 runtime PM Bug

在实际项目中，runtime PM 相关问题往往表现为“设备莫名耗电”、“唤醒失败”、“suspend 卡死”等表象，背后原因却千差万别。以下是我在多个芯片平台（ARM64/ARM32/RISC-V）上踩过的坑，按发生频率排序，附带定位方法和修复方案。

4.1 问题速查表：症状、原因、验证命令、修复要点

4.2 典型案例深度复盘：USB Host Controller 的 autosuspend 失效

现象：某 Intel Bay Trail 平台，USB 2.0 Host Controller（xhci_hcd）在插入 U 盘后，拔出 U 盘 5 秒，runtime_status仍为active，usage_count=1，功耗无下降。

排查过程：

1. cat /sys/bus/usb/devices/1-0:1.0/power/usage_count→ 输出1
2. lsof /sys/bus/usb/devices/1-0:1.0/→ 无进程占用
3. cat /sys/bus/usb/devices/1-0:1.0/power/autosuspend→ 输出-1（禁用！）
4. 检查驱动源码drivers/usb/host/xhci-pci.c，发现xhci_pci_probe()中未调用pm_runtime_set_autosuspend_delay()
5. 进一步发现：xhci_pci_probe()调用了pm_runtime_enable()，但xhci_plat_probe()（用于 platform device）却漏掉了 autosuspend 设置

根因：该平台 USB controller 以 platform device 方式注册，而xhci_plat_probe()函数中，pm_runtime_enable()被调用，但pm_runtime_set_autosuspend_delay()被遗漏。导致内核使用默认值 -1，autosuspend 功能实质关闭。

修复补丁：

--- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -123,6 +123,7 @@ static int xhci_plat_probe(struct platform_device *pdev) pm_runtime_enable(dev); + pm_runtime_set_autosuspend_delay(dev, 2000); pm_runtime_allow(dev);

验证：打上补丁后，拔出 U 盘，2 秒后runtime_status变为suspended，usage_count=0，平台待机功耗下降 15mW。

4.3 高级调试技巧：用 ftrace 抓取 runtime PM 事件流

当 sysfs 信息不足以定位问题时，ftrace 是终极武器。以下命令可捕获完整的 runtime PM 状态变迁：

# 启用 pm event trace $ echo 1 > /sys/kernel/debug/tracing/events/power/rpm_callback/enable $ echo 1 > /sys/kernel/debug/tracing/events/power/rpm_status/enable $ echo 1 > /sys/kernel/debug/tracing/events/power/rpm_resume/enable $ echo 1 > /sys/kernel/debug/tracing/events/power/rpm_suspend/enable # 开始 trace $ echo 1 > /sys/kernel/debug/tracing/tracing_on # 执行你的操作（如插拔设备、读取 sensor） $ cat /sys/class/i2c-adapter/i2c-0/0-0048/temp1_input # 停止 trace 并查看 $ echo 0 > /sys/kernel/debug/tracing/tracing_on $ cat /sys/kernel/debug/tracing/trace

输出示例：

xhci_hcd-1010 [000] d... 12345.678901: rpm_resume: dev=0000:00:14.0 xhci_hcd-1010 [000] d... 12345.678923: rpm_callback: dev=0000:00:14.0 fn=resume xhci_hcd-1010 [000] d... 12345.678945: rpm_status: dev=0000:00:14.0 status=active ... xhci_hcd-1010 [000] d... 12348.123456: rpm_suspend: dev=0000:00:14.0 xhci_hcd-1010 [000] d... 12348.123478: rpm_callback: dev=0000:00:14.0 fn=suspend xhci_hcd-1010 [000] d... 12348.123490: rpm_status: dev=0000:00:14.0 status=suspended

提示：ftrace 输出中rpm_callback行告诉你哪个回调被调用，rpm_status行告诉你状态变更结果。如果看到rpm_suspend事件，但后续没有rpm_callback: fn=suspend，说明 suspend 回调根本没执行——大概率是 driver 没注册回调，或pm_runtime_enable()未调用。

5. runtime PM 与内核其他子系统的协同关系：它不是孤岛

runtime PM 从不单独存在。它像一条暗河，贯穿于内核设备模型、电源管理框架、中断子系统、甚至热管理模块之中。理解它与其他子系统的耦合点，是写出健壮驱动的前提。

5.1 与设备模型（Device Model）的深度绑定

struct device是 runtime PM 的载体。每个 device 都内置struct dev_pm_info power，而该结构体的生命周期与 device 本身完全一致。这意味着：

• device_register()时，power结构体被初始化（usage_count=0,status=RPM_SUSPENDED）；
• device_del()时，pm_runtime_disable()被隐式调用，防止 dangling reference；
• device_shutdown()（系统关机时）会遍历所有 device，强制调用pm_runtime_force_suspend()。

因此，任何绕过 device_register() 的设备注册方式（如 legacy platform device without proper struct device）都会导致 runtime PM 失效。我曾在一个老项目中，看到驱动直接操作ioremap()得到的寄存器地址，而不注册struct device，结果无论怎么调pm_runtime_*，usage_count始终为 0，状态永不变化。

5.2 与 suspend-to-RAM（S2RAM）的协作逻辑

当系统执行echo mem > /sys/power/state进入 S2RAM 时，runtime PM 并非被 bypass，而是进入“强制模式”：

• 内核首先对所有 device 调用pm_runtime_force_suspend()，无视usage_count和autosuspend_delay；
• 若某个 device 的runtime_suspend回调返回-EBUSY，内核会打印 warning，但继续向下执行（S2RAM 不会因此失败）；
• resume 时，内核调用pm_runtime_force_resume()，同样无视当前状态。

这种“force”机制保证了 S2RAM 的可靠性，但也带来风险：如果 driver 的force_suspend未正确处理硬件状态，resume 后设备可能无法工作。因此，优秀的 driver 应在runtime_suspend和force_suspend中复用同一套硬件关闭逻辑，仅在force_suspend中增加对 critical state 的保存。

5.3 与 thermal subsystem 的联动

现代 SoC 的 thermal governor（如step_wise）在检测到温度过高时，会主动降低设备性能。对于支持 runtime PM 的设备，thermal subsystem 可以直接调用pm_runtime_put_sync()来“软关闭”设备，而非粗暴地降低频率。例如：

• 当 CPU 温度 > 85°C，thermal governor 调用pm_runtime_put_sync(&gpu_dev)，让 GPU 进入 suspended 状态；
• 当温度回落至 75°C，再调用pm_runtime_get_sync(&gpu_dev)恢复。

这种联动需要 driver 在runtime_resume()中检查 thermal state，并决定是否真正恢复 full performance。我在调试某款 Mali GPU 驱动时，发现它在 resume 后直接全速运行，导致温度再次飙升——修复方案是在 resume 回调中读取thermal_zone_get_temp()，若温度仍高，则只恢复 50% 频率，直到 thermal governor 显式通知。

5.4 与 Regulator Framework 的配合

struct regulator是电压域的抽象。runtime PM 的suspend回调中，regulator_disable()是标准操作；而resume回调中，regulator_enable()必须在 I2C/SPI 通信之前完成。但 regulator framework 本身也有一套 runtime PM 逻辑：

• regulator_enable()内部会调用pm_runtime_get_sync()获取其 parent（如 PMIC device）的供电；
• 如果 PMIC device 自身也启用了 runtime PM，那么regulator_enable()可能触发 PMIC 的 resume 流程。

这就形成了跨层级的 runtime PM 依赖链。如果某一级 regulator 的 parent 未正确 enable runtime PM，整个链路就会卡死。我遇到过一个 case：WiFi 模块的 VDDIO 由 PMIC 的 LDO1 供电，而 LDO1 的 parent（PMIC I2C adapter）未调用pm_runtime_enable()，导致regulator_enable(wifi_vddio)永远阻塞在pm_runtime_get_sync()上。

解决方案：在 PMIC driver 的 probe 中，不仅要pm_runtime_enable()自身，还要确保其所有 child regulator 都能被正确管理。内核提供了regulator_bulk_enable()和regulator_bulk_disable()，它们会自动处理父子依赖，比单个 regulator 操作更安全。

6. 性能与功耗的平衡术：如何设定最优 autosuspend_delay

autosuspend_delay 不是越小越好，也不是越大越省电。它是一个需要根据硬件特性、应用场景、用户体验三维权衡的参数。设定不当，轻则增加唤醒延迟，重则引发功能异常。

6.1 延迟设定的黄金法则

• 传感器类设备（温度、加速度、光照）：delay = 1000 ~ 5000 ms
  理由：采样间隔通常为 100ms~1s，过短 delay 会导致频繁启停；过长则浪费电。TMP102 典型采样周期 250ms，设为 3000ms 较合理。

• 通信类设备（USB、PCIe、SDIO）：delay = 5000 ~ 30000 ms
  理由：需容忍突发流量。USB HID 设备（键盘/鼠标）设为 5000ms；PCIe SSD 设为 15000ms，避免小 IO 导致反复唤醒。

• 显示类设备（LCD、HDMI）：delay = 0（禁用 autosuspend）或 60000+ ms
  理由：用户感知敏感。HDMI CEC 设备可设为 0（即pm_runtime_put_sync()后立即 suspend），但 LCD panel 必须设为大值，否则屏幕闪烁。

• 存储类设备（eMMC、UFS）：delay = 10000 ~ 60000 ms