做嵌入式功耗优化的人大概率都遇到过这一幕主控已经顺利进入系统睡眠电流计却还是多出那么几毫安拿示波器一路摸过去最后停在某个传感器上——它从头到尾都在满电待机。system suspend 解决不了这种局部浪费因为为了照顾一颗外设把整个 SoC 拉起来再整体睡一遍代价实在太大。这正是 runtime PMRuntime Power Management的战场。作为 Linux 内核功耗子系统里最核心的设备级电源管理机制runtime PM 要解决的只有一个问题让单个设备在没人用的时候自动下电在被需要的时候自动唤醒。这篇文章按系列惯例排到第七篇专门把它单独拉出来梳理一遍内容包括状态机、核心 API、驱动实现路径、与系统睡眠的协同以及我在实际开发中碰到的排障心得适合驱动工程师、BSP 开发者和正在啃内核源码的人参考。1. runtime PM 真正要解决的问题设备级的按需供电1.1 系统睡眠管不住的单设备空闲功耗先明确一个前提system suspend系统睡眠是全局操作它要把所有设备冻结、把 CPU 停掉、把 DDR 切到自刷新整个流程往往要几十到几百毫秒。如果你的业务只是“每 100ms 读一次温湿度传感器”为了这一颗传感器把整机反复睡眠唤醒既不划算也不现实。但它不工作的时候硬件明明可以自己进入低功耗模式问题是没有人去触发这件事。系统睡眠好比整栋楼统一拉闸runtime PM 则像每个房间单独安装的智能开关房间没人开关自动断开有人推门进来灯自动亮。这个比喻虽然简单但基本抓住了 runtime PM 在设备模型里的定位——它挂在 Linux 设备模型上和 probe、suspend、resume 这些生命周期是同一套体系只是作用对象从“全系统”缩小到了“单个设备”。1.2 省电空间到底有多大一笔值得算的账讲道理之前先算账。假设一颗 I2C 温湿度传感器正常工作电流 1mA供电电压 3.3V一直供电的功耗是 3.3mW。如果它支持睡眠模式睡眠电流做到 5µA运行时功耗只有 16.5µW直接差了 200 倍。更具体一点这颗传感器每 100ms 采一次样每次采样耗时 2ms也就是 98% 的时间都在空闲。如果不做 runtime PM这 98% 的时间里它一直在满电流供电浪费掉的能量非常客观。嵌入式产品做待机电流预算的时候往往不是主控吃掉了多少而是“一堆本来可以睡的设备都没有睡”每一路都差那么零点几毫安加起来就把整机待机电流推高了。当然runtime PM 不是免费的。设备从 suspend 到 resume 需要时间和能量如果启停频率太高省下的电可能还不够唤醒开销甚至影响用户体验。所以内核提供了 autosuspend 这种延迟决策机制把“是否需要挂起”的判断延后一段时间避免频繁启停的抖动。这块后面专门讲。1.3 什么情况下不该用 runtime PM不是所有设备都适合接入 runtime PM我一般按下面几个标准快速判断唤醒延迟能不能接受。比如触控屏用户手指一碰就得立刻响应如果 driver 的 resume 路径要几十毫秒体验会很差。开关功耗有没有交叉点。如果设备睡眠电流和活跃电流只差 10%但每次开关都要付出额外的协议开销省下来的意义不大。硬件是否支持独立断电。有些设备虽然有个 sleep 寄存器但外部供电轨上没有可控开关软件把设备“挂起”了、硬件还在耗电这种属于假 suspend后面排障部分会细说。一句话总结runtime PM 适合“大部分时间空闲、唤醒成本可控、硬件确实能省电”的设备。判断清楚再用否则只是给驱动代码增加复杂度。2. 状态机与核心数据结构搞懂 usage_count 才算入门2.1 runtime_status 的四个状态与迁移路径runtime PM 的核心是一个小型状态机状态定义在include/linux/pm.h里enum rpm_status { RPM_ACTIVE 0, RPM_RESUMING, RPM_SUSPENDED, RPM_SUSPENDING, };正常路径是RPM_ACTIVE --(put_sync/autosuspend timer)-- RPM_SUSPENDING --(回调成功)-- RPM_SUSPENDED RPM_SUSPENDED --(get_sync/异步resume)-- RPM_RESUMING --(回调成功)-- RPM_ACTIVE为什么要单独定义 SUSPENDING 和 RESUMING 这两个中间态因为设备的 runtime suspend/resume 回调可能很慢比如要通过 I2C 给外设写命令、要等供电轨稳定。在状态切换期间其他 CPU 可能正好也来访问这个设备如果没有中间态两个请求就会打架。框架用这两个中间态配合等待队列保证“一个设备同一时间只允许一个状态迁移在进行”。实际写驱动时有个很容易踩的坑你在 runtime_suspend 回调里读runtime_status看到的不是 RPM_SUSPENDED而是 RPM_SUSPENDING。内核里runtime_status表示的是“当前正在发生什么”不是“最终停在什么状态”。很多新手在回调里判断 status 以为自己写错了其实没有。2.2 usage_count谁是设备的“占用人”usage_count是 runtime PM 所有机制里最核心的一个字段。它的语义很像饭店包间的人数计数有人进门包间 1 人有人离开 -1 人只有人数归零服务员才会允许关灯保洁。对应到 API 上pm_runtime_get_sync()会把 count 1pm_runtime_put_sync()会把 count -1。框架只有在usage_count 0时才允许设备进入 runtime suspend。也就是说只要还有代码在“占用”这个设备设备就绝不允许被偷偷下电。这个设计非常关键。它解决了驱动开发里最头疼的并发问题中断处理函数正在读设备寄存器此时另一个线程把设备 suspend 了那中断里访问的就是一个已经断电的设备轻则读到垃圾数据重则触发总线错误。占用计数相当于给每个访问者发了一张“我正在用”的凭证。围绕 usage_count 还有两个相关字段child_count记录还有多少个子设备处于 active 状态。默认情况下父设备要等所有子设备都 suspend 之后才允许自己 suspend。这符合电源树的实际情况你不可能在子设备还在跑的时候把父设备的电源切断。ignore_children这是一个例外开关置 1 后父设备不等待子设备。某些场景下需要忽略层级约束比如两个子系统其实共用供电轨、彼此没有独立关系这个开关可以减少不必要的耦合。2.3 disable_depth 与 runtime_auto两个全局开关要分清disable_depth和runtime_auto经常被混在一起但它们管的事完全不同。维度disable_depthruntime_auto作用整个 runtime PM 功能的总开关“自动挂起”策略的开关0 时表现所有 runtime 操作被拒绝返回 -EACCES设备允许手动 suspend/resume但不会在引用归零后自动挂由谁修改pm_runtime_enable / pm_runtime_disablesysfs 的 power/control或 pm_runtime_allow / pm_runtime_forbid典型场景驱动 probe 之前关闭remove 后关闭调试时想临时禁止某设备自动睡眠disable_depth初始值是 1也就是说新设备默认处于“runtime PM 关闭”状态。驱动在 probe 里调用pm_runtime_enable(dev)才把它打开remove 时再调pm_runtime_disable(dev)关掉。如果pm_runtime_enable被重复调用内核会打印错误提示因为disable_depth减到负数说明驱动逻辑本身混乱了。runtime_auto则控制“空闲后是否自动挂”。默认是 1也就是设备引用计数归零之后框架会自动触发挂起流程。把power/control写成on会把 runtime_auto 关掉设备就算没人用也会一直保持 active这在调试硬件问题时很好用。2.4 runtime_error框架很记仇如果设备的 runtime_suspend 或 runtime_resume 回调返回了错误框架不会装作无事发生而是把错误码记在设备的runtime_error字段里。之后几乎所有 runtime 调用都会快速失败相当于设备进入了“一票否决”状态。这个设计是为了避免反复尝试一个注定失败的操作浪费功耗和时间。恢复的办法是调用pm_runtime_set_active()或pm_runtime_set_suspended()重新校正状态框架会顺便清除错误的标记。3. API 使用姿势同步、异步、autosuspend 怎么选runtime PM 的 API 看着多其实可以按几个维度分类同步还是异步、是否改变引用计数、是否触发真正的状态转换。下面按实际使用场景来讲。3.1 同步家族get_sync / put_sync同步接口是驱动里最常用的API计数变化行为典型场景pm_runtime_get_sync1立即唤醒设备到 activeprobe 后第一次访问外设前pm_runtime_put_sync-1立即尝试 idle → suspend访问结束、且当前线程不介意阻塞pm_runtime_resume不变立即唤醒设备事件驱动的临时唤醒pm_runtime_suspend不变立即请求挂起主动下电如按键息屏用的时候有一个非常容易误判的细节pm_runtime_get_sync()返回 1 不表示失败。它的返回值语义是0 表示本次调用真的执行了 resume1 表示设备本来就已经处于 active什么都没做负数才是错误。我见过好几个同事用ret pm_runtime_get_sync(); if (ret) { ... }这样的写法把返回 1 当成异常处理结果驱动功能正常但日志里整天飘错误信息。正确姿势是判断ret 0。3.2 异步家族get / put不带_sync后缀的pm_runtime_get()和pm_runtime_put()是异步版本。它们只负责更新引用计数真正的状态迁移通过内核的pm_wq工作队列异步执行。异步接口的适用场景很明确中断上下文、持锁路径、或者你不想因为一次 resume 阻塞当前线程。比如驱动在定时器回调里检查设备状态如果发现设备还在 suspended需要唤醒它读数据这时候用pm_runtime_get()把请求丢给工作队列更安全。但要注意“异步”不等于“乱序”。内核在rpm_suspend和rpm_resume路径上有请求合并机制同一个设备不会在工作队列里堆积多个 suspend 请求也不会出现 suspend 还没执行完又排一个 suspend 进去的重复状态。它会根据设备当前状态和 pending 标志自动判断该跳过的跳过该等待的等待。3.3 只动计数get_noresume / put_noidlepm_runtime_get_noresume()和pm_runtime_put_noidle()是两组特殊接口只改引用计数完全不触发状态迁移。这两个接口在中断处理里非常好用。经典的配合是这样的中断上半部用pm_runtime_get_noresume(dev)把 count 先占住防止设备在中断处理期间被其他路径判定为空闲而挂起真正的唤醒放到线程化中断threaded irq里用pm_runtime_get_sync()完成处理完数据后用pm_runtime_put()放掉引用。为什么要分两步因为pm_runtime_get_sync()可能会睡眠比如通过 I2C 唤醒一个外设而硬中断上下文绝对不能睡眠。先用 noresume 占用计数是“告诉自己人别乱动设备”的临时保险等到了允许睡眠的上下文再执行真正的唤醒。3.4 autosuspend把“是否该挂”的决策推迟前面提到如果设备每次 put 后立刻 suspend下次访问又立刻 resume反复上下电的功耗和延迟可能比一直挂着还差。autosuspend 就是为这种情况准备的。pm_runtime_use_autosuspend(dev); pm_runtime_set_autosuspend_delay(dev, 200); /* 200ms */ /* 之后每次访问完 */ pm_runtime_mark_last_busy(dev); pm_runtime_put_autosuspend(dev);流程是这样的pm_runtime_put_autosuspend()减少引用计数后不会立刻调用 suspend而是启动一个定时器定时器时长就是上面的 200ms。定时器到期时框架检查last_busy字段如果这段时间内没有新的访问mark_last_busy没被更新说明设备确实空闲了这时才真正执行 suspend如果中间又有访问定时器会重新起算。我通常在触摸屏、网卡这类“用起来很频繁但每次间隔不规律”的设备上用 autosuspend。触摸屏如果每次手指抬起就立刻挂起下一次触摸又要几十毫秒唤醒用户能明显感觉到卡顿设一个 500ms 的延迟既保证大部分时间在睡眠又不会打断操作体验。3.5 生命周期管理enable 和 set_active 的顺序驱动里最标准的初始化顺序是这样pm_runtime_set_active(dev); /* 先把状态校正为 active */ pm_runtime_enable(dev); /* 打开 runtime PM */为什么要先set_active再enable因为新设备的runtime_status默认是 SUSPENDED如果不先校正为 activeenable之后框架会认为设备正处于挂起状态后面的一些调用行为会不符合预期。先校正状态、再打开开关相当于“先把灯打开再通电”逻辑上更通顺。有些驱动在 probe 过程中就要访问外设这时还需要一个临时占用的技巧pm_runtime_get_noresume(dev); /* ... probe 期间各种初始化、寄存器访问 ... */ pm_runtime_put_noidle(dev); pm_runtime_enable(dev);先占一次引用防止 probe 过程中设备被外部路径误判为空闲而触发 suspend等初始化完成再放掉最后 enable。这个模式在真实驱动里很常见理解它比死记顺序更重要。4. 从 put 到真正下电一次 runtime suspend 的完整旅程4.1 同步路径上的调用链以pm_runtime_put_sync(dev)为例把一次 runtime suspend 的完整路径拆开看pm_runtime_put_sync(dev) - __pm_runtime_idle(dev, RPM_GET_PUT) - rpm_idle(dev, RPM_GET_PUT) - rpm_check_suspend_allowed(dev) /* 检查 usage_count 0、disable_depth 0、子设备状态等 */ - dev-bus-runtime_idle 或 dev-pm_domain-ops-runtime_idle - rpm_suspend(dev) - dev-power.runtime_status RPM_SUSPENDING - dev-bus-runtime_suspend - 最终落到 driver 的 dev_pm_ops.runtime_suspend 回调 - 回调成功 - dev-power.runtime_status RPM_SUSPENDED - 更新 suspended_jiffies 等统计字段rpm_check_suspend_allowed()是前置检查的关键函数它的判断项包括usage_count是否归零、disable_depth是否为 0、设备当前状态是否允许挂起、子设备是否都已经 suspend。任何一个条件不满足suspend 请求就会被拒绝函数返回对应错误码。4.2 runtime_idle 回调的真正用途很多驱动只实现了runtime_suspend和runtime_resume忽略了runtime_idle这确实不影响功能但理解runtime_idle能帮你搞懂框架的设计思路。rpm_idle阶段是 suspend 之前的“最后一道咨询”。如果设备注册了runtime_idle回调且返回 0框架会继续往下执行 suspend如果runtime_idle返回非 0框架会停止本次自动挂起把决策权交回给驱动。什么情况下你会想让runtime_idle返回非 0比如设备有自己更复杂的睡眠策略不想走框架默认的自动挂起路径或者设备空闲后需要先做一轮清理清理完再决定是不是挂。autosuspend 本质上就是框架帮你实现了一个“自带定时器的 runtime_idle 策略”所以用了 autosuspend 之后驱动里通常就不要再自己实现runtime_idle否则两套逻辑会冲突。4.3 设备、总线、驱动三层的回调接力有一个细节经常让刚接触的人困惑为什么 runtime_suspend 回调不是直接调用驱动注册的函数而是从bus-runtime_suspend开始绕一圈因为内核把“设备的电源管理”分成了三层职责总线层负责协议和标准层面的电源管理。比如 PCI 设备要先进入 D3hot 状态、USB 设备要送挂起命令这些是总线协议规定的不是某个驱动私有的逻辑。驱动层负责设备自身的功耗行为。比如某个传感器挂起前要写哪个寄存器、要不要关内部振荡器。电源域PM Domain负责更大范围的供电协同。比如一个 power domain 下挂了多个设备要等所有设备都 suspend 完域本身才能掉电。rpm_suspend会先走bus-runtime_suspend总线实现里再通过pm_generic_runtime_suspend()这类辅助函数逐层往下透传最终调到驱动注册的dev_pm_ops.runtime_suspend。这个接力机制保证了协议要求和大局协同不会被某个驱动破坏。4.4 回调失败时发生了什么如果驱动或总线的runtime_suspend回调返回错误框架不会让设备停留在 SUSPENDING 中间态而是把状态回滚到 ACTIVE并且把错误码记录到runtime_error。这也解释了为什么runtime_suspend回调里不要返回值暧昧返回一个负错误码框架会认为挂起失败后续还会基于这个错误拒绝一段时间内的其他操作。如果你只是“这次不想挂”正确的做法是返回-EAGAIN或-EBUSY之类的可重试错误并在日志里留一句说明避免无人值守的功耗优化变成无声的失败。4.5 resume 的反向路径resume 路径和 suspend 完全对称方向相反pm_runtime_get_sync(dev) - __pm_runtime_resume(dev, RPM_GET_PUT) - rpm_resume(dev) - 如果设备正被其他 CPU 挂起先等待 - dev-power.runtime_status RPM_RESUMING - dev-bus-runtime_resume - 最终落到 driver 的 runtime_resume 回调 - 回调成功 - dev-power.runtime_status RPM_ACTIVE - 更新 active_jiffies 统计这里要注意“等待”行为如果一个 CPU 正在执行设备的 runtime_suspend 流程另一个 CPU 同时调用pm_runtime_get_sync()后者会通过等待队列阻塞直到前者的挂起流程结束、再执行唤醒。这也是为什么pm_runtime_get_sync()不能在原子上下文里调用——它真的会睡眠。5. 与系统睡眠的协同该配合的配合该避免的冲突5.1 direct-complete让 runtime suspend 的设备搭便车系统睡眠流程里有一个叫 direct-complete 的优化如果设备在进入系统睡眠时已经处于 runtime suspended 状态并且没有未处理的唤醒需求系统 PM 框架可以跳过这个设备的常规 suspend/resume 回调因为设备状态本来就是睡着的系统睡眠对它来说只是“继续睡”。这个机制让“做好了 runtime PM 的驱动”在系统睡眠时的开销变得很小。但它的前提是设备的 runtime_suspend 路径必须完整可靠比如已经把寄存器状态保存好、外设时钟和供电都处理干净。如果你只是把 runtime suspend 当成“往寄存器里写一个 0”而没有真正保存状态direct-complete 会让系统睡眠期间设备处于一种“半睡不睡”的危险状态。5.2 系统 suspend/resume 时驱动怎么衔接很多驱动在系统 suspend 和系统 resume 回调整体上依赖pm_runtime_force_suspend()和pm_runtime_force_resume()。static int xxx_suspend(struct device *dev) { return pm_runtime_force_suspend(dev); } static int xxx_resume(struct device *dev) { return pm_runtime_force_resume(dev); }pm_runtime_force_suspend()的语义是不管当前引用计数是多少直接执行 runtime_suspend 回调然后把状态强制设为 SUSPENDED。pm_runtime_force_resume()则反向强制唤醒执行 runtime_resume 回调把状态设回 ACTIVE。这套机制适合那些“系统睡眠行为和运行时睡眠行为很接近”的设备反正系统要睡了设备也该睡runtime 路径正好把这活干了。需要注意的是force_suspend不等于“万事大吉”如果系统睡眠还会切断某些供电轨驱动必须在 runtime_suspend 回调里把内部状态保存完整否则 wakeup 后寄存器全乱。5.3 唤醒源与 runtime PM 怎么搭配设备进入 runtime suspend 后外部事件要能把设备唤醒。这就要靠 wakeup source 机制。常见配置device_init_wakeup(dev, true); dev_pm_set_wake_irq(dev, irq_num);在 runtime_suspend 回调里把唤醒功能打开在 runtime_resume 回调里把唤醒功能关掉。要注意的一件事runtime resume 和系统唤醒是两条独立路径。设备在 runtime suspend 状态下收到中断中断会先触发设备的 runtime resume如果此时系统处于睡眠状态中断还要同时把整个系统唤醒。这两条路径的时序和锁完全不一样写驱动时不要混用否则很容易出现中断丢了或者唤醒失败。5.4 与 device link 的配合防止“A 醒了 B 还没醒”runtime PM 场景下特别容易出现一种依赖问题设备 A 的 runtime_resume 回调里要访问设备 B但 B 还处于 runtime suspended于是 A 就挂在总线事务上。解法是设备链接device linkdevice_link_add(consumer, supplier, DL_FLAG_RPM_ACTIVE);加了DL_FLAG_RPM_ACTIVE标志后内核会在 supplier 设备 runtime resume 时同步处理 consumer 的运行时依赖避免出现“A 需要 B 工作、B 却还睡着”的状态。这个机制对复杂驱动树尤其重要比如音频 codec 依赖 I2C 控制器、Wi-Fi 芯片依赖 SDIO 控制器少了这层关系你在单设备调试时一切正常一进系统级功耗优化就频繁死锁或超时。6. 实战排障sysfs 观察、典型坑与真实案例6.1 先用 sysfs 给设备做“体检”排查 runtime PM 问题我的第一步永远是读 sysfs它比加 printk 快得多cat /sys/devices/platform/xxx/power/runtime_status # 当前状态 cat /sys/devices/platform/xxx/power/runtime_usage # 引用计数 cat /sys/devices/platform/xxx/power/control # auto / on / off cat /sys/devices/platform/xxx/power/runtime_suspended_time cat /sys/devices/platform/xxx/power/runtime_active_timeruntime_status告诉你设备现在停在哪runtime_usage告诉你有没有人还占着设备不放runtime_suspended_time和runtime_active_time分别统计设备在两种状态下累计的时间如果一段待机时间里 suspended_time 接近 0说明设备就没怎么睡过。control是一个很实用的调试开关。写成on相当于告诉内核“强制 active禁止自动挂起”写成auto恢复自动挂起。调试某个外设功耗时我经常先把所有设备的 control 设成 on确认整机电流基线然后逐个改成 auto看哪个设备切换后电流有明显下降一眼就能圈出“没实现 runtime PM 或者实现有问题”的驱动。6.2 案例一runtime_status 显示挂起了电流纹丝不动有一次调一颗 I2C 传感器runtime_status已经是suspended但整板待机电流没变化。一开始以为是 sensor 硬件不支持深度睡眠后来发现runtime_suspend回调里只给传感器发了一条 sleep 命令供电的 LDO 和一路时钟根本没有关。这种问题的典型表现就是“软件状态挂了、硬件还在烧电”。排查思路是沿供电链路走一遍用regulator_is_enabled()检查每个 regulator 状态用 clk_enable 的状态确认时钟最后发现 LDO 的引用计数始终没放掉。修复很简单在runtime_suspend里加regulator_disable()、clk_disable()在runtime_resume里反向恢复。这也是我反复强调“要沿供电链检查”的原因。runtime PM 只是一个软件框架它只负责控制状态机真正省电的是把电源、时钟这些硬件资源全部释放干净。回调跑完不代表电真的断了。6.3 案例二中断上下文调用 get_sync直接 scheduling while atomic另一个高频事故中断处理函数里写了pm_runtime_get_sync()设备第一次产生中断就崩dmesg 里打BUG: scheduling while atomic。原因是pm_runtime_get_sync()会睡眠等待设备 resume尤其设备要走 I2C 或 SPI 这类慢速总线时等一个事务完成可能要几十微秒到几毫秒。中断上下文不允许睡眠于是直接触发调度异常。修复方案在前面 3.3 已经写过硬中断里用pm_runtime_get_noresume()占引用把真正的pm_runtime_get_sync()放到线程化中断或 workqueue 里执行。6.4 案例三重复 enable 打印错误状态纠不回来驱动在 probe 里调pm_runtime_enable()如果同样的 device 被 probe 了两次第二次 enable 就会触发内核错误提示因为disable_depth已经减到 0 了。这种问题常见于驱动支持设备热插拔、或者 probe 失败后 retry 的场景。解决办法是在驱动退出路径上严格对称enable对应disableget对应put不能在 probe 失败分支里遗漏清理。6.5 这些年沉淀下来的一份检查清单最后给一份我 review 驱动时常用的 runtime PM 检查清单基本可以覆盖八成的问题返回值判断只看ret 0不要把返回 1 当错误。probe 里先pm_runtime_set_active()再pm_runtime_enable()顺序别反。每个pm_runtime_get_sync()/pm_runtime_get()都必须在错误路径和正常路径上成对释放。runtime_suspend回调里不要调用任何可能触发设备自身 resume 的函数否则递归起来非常难看。确认设备有真正可控的电源或时钟路径软件挂起不等于硬件断电。中断上下文只用pm_runtime_get_noresume()唤醒交给线程上下文。和系统睡眠配合时先确认设备是否适合走 direct-complete 快路径再决定要不要用pm_runtime_force_suspend()。依赖其他设备的运行时电源状态务必用device_link_add(..., DL_FLAG_RPM_ACTIVE)建立显式依赖。我自己的习惯是拿到一块新板子先把所有外设的power/control统统写成auto挂机测一整夜电流然后对每个设备看runtime_suspended_time占比。这个动作做一遍哪些驱动有真功耗、哪些只是写了个空回调立刻一清二楚。runtime PM 不算复杂但它是那种“纸面上一看就懂、实际跑起来到处是坑”的机制多花点时间把状态机和调用链吃透后面调功耗功课时能少走很多弯路。