3、Linux内核电源管理框架：Runtime PM与系统睡眠模型

好，咱们今天聊聊Linux内核的电源管理框架。说实话，这部分内容在车载Linux开发中，是绕不开的核心。我最早接触这块时，也被各种术语搞得晕头转向——Runtime PM、系统睡眠、suspend-to-RAM……后来在项目里踩过几次坑，才慢慢理清了脉络。

今天我就把这三个核心知识点掰开揉碎了讲：Runtime PM的核心机制、struct dev_pm_ops结构体、以及系统睡眠模型。你想想看，搞懂了这些，车载系统的休眠唤醒基本就拿下了一半。

3.1 Runtime PM（运行时电源管理）核心机制

Runtime PM，说白了就是设备不用时就自动关掉，要用时再自动打开。它跟系统级别的休眠不一样——系统休眠是整个系统一起睡，Runtime PM是单个设备自己管自己。

我在做车载信息娱乐系统时，遇到过一个问题：屏幕背光明明已经关了，但功耗还是居高不下。后来一查，是触摸屏的Runtime PM没配好，设备一直处于active状态。嗯，这就是典型的Runtime PM没生效。

3.1.1 核心思想

Runtime PM的核心理念就三个动作：

• suspend：设备空闲时，自动挂起
• resume：设备需要时，自动唤醒
• get/put：引用计数管理，决定何时挂起

我习惯把Runtime PM想象成一个「智能开关」——它通过引用计数来判断设备是否空闲。当所有使用者都释放了设备（put），内核就自动触发suspend；当有新的使用者（get），就自动resume。

3.1.2 关键API

咱们直接看代码，这是最常用的几个接口：

// 启用Runtime PM
pm_runtime_enable(dev);

// 禁止Runtime PM
pm_runtime_disable(dev);

// 获取设备，增加引用计数，唤醒设备
pm_runtime_get_sync(dev);

// 释放设备，减少引用计数，允许挂起
pm_runtime_put_sync(dev);

// 设置设备为active状态
pm_runtime_set_active(dev);

// 设置设备为suspended状态
pm_runtime_set_suspended(dev);

3.1.3 工作流程

Runtime PM的工作流程其实很简单：

1. 设备驱动调用pm_runtime_get_sync()，引用计数+1
2. 如果设备当前是suspended状态，自动调用resume回调
3. 设备开始工作
4. 工作完成后，调用pm_runtime_put_sync()，引用计数-1
5. 如果引用计数降到0，内核启动一个定时器（默认50ms）
6. 定时器到期后，如果引用计数仍为0，调用suspend回调

这里有个细节要注意——定时器延迟。为什么要延迟？因为设备可能很快又被使用，频繁suspend/resume反而更耗电。这个延迟时间可以通过pm_runtime_set_autosuspend_delay()调整。

3.2 struct dev_pm_ops 结构体详解

这个结构体，是电源管理的「总调度中心」。所有设备的电源管理回调，都挂在这个结构体上。

咱们直接看定义：

struct dev_pm_ops {
    // 系统睡眠回调
    int (*suspend)(struct device *dev);
    int (*resume)(struct device *dev);
    int (*freeze)(struct device *dev);
    int (*thaw)(struct device *dev);
    int (*poweroff)(struct device *dev);
    int (*restore)(struct device *dev);

    // Runtime PM回调
    int (*runtime_suspend)(struct device *dev);
    int (*runtime_resume)(struct device *dev);
    int (*runtime_idle)(struct device *dev);
};

你可能会问：怎么这么多回调？其实分两类：

回调类别	回调名称	触发场景
系统睡眠	suspend/resume	系统进入/退出Suspend-to-RAM
系统睡眠	freeze/thaw	系统进入/退出Suspend-to-Idle
系统睡眠	poweroff/restore	系统休眠（hibernate）
Runtime PM	runtime_suspend	设备空闲时自动挂起
Runtime PM	runtime_resume	设备需要时自动唤醒
Runtime PM	runtime_idle	设备空闲，询问是否要挂起

3.2.1 回调的调用时机

我举个例子你就明白了。假设你有一个车载摄像头驱动：

• 当系统按下电源键休眠时，调用suspend回调，关闭摄像头电源
• 当系统唤醒时，调用resume回调，重新初始化摄像头
• 当摄像头长时间没被使用（比如倒车影像关闭后），调用runtime_suspend，关闭摄像头
• 当再次需要摄像头时（比如挂倒挡），调用runtime_resume，快速唤醒

3.2.2 如何注册

在驱动中，通常这样使用：

static const struct dev_pm_ops my_camera_pm_ops = {
    .suspend = my_camera_suspend,
    .resume = my_camera_resume,
    .runtime_suspend = my_camera_runtime_suspend,
    .runtime_resume = my_camera_runtime_resume,
};

struct platform_driver my_camera_driver = {
    .driver = {
        .name = "my_camera",
        .pm = &my_camera_pm_ops,
    },
    .probe = my_camera_probe,
    .remove = my_camera_remove,
};

嗯，这里有个小技巧——如果你只实现了Runtime PM回调，没实现系统睡眠回调，那系统睡眠时设备会怎样？答案是：内核会尝试调用runtime_suspend作为系统suspend的替代。但我不建议依赖这个行为，最好显式实现所有需要的回调。

3.3 系统睡眠模型：Suspend-to-RAM vs Suspend-to-Idle

车载Linux中，最常见的两种睡眠模型就是Suspend-to-RAM（STR）和Suspend-to-Idle（STI）。它们的区别，说白了就是一个「睡得深」，一个「睡得浅」。

3.3.1 Suspend-to-RAM（挂起到内存）

这是最常用的深度睡眠模式。系统将上下文保存到内存中，然后关闭大部分外设和CPU电源，只保留内存供电。

特点：

• 功耗极低，通常只有几十毫瓦
• 唤醒延迟较大，约几十到几百毫秒
• 唤醒后需要重新初始化外设

我在车载项目中，STR主要用于长时间停车场景。比如车辆熄火后，系统进入STR，只保留CAN总线唤醒功能。当检测到车门解锁信号时，系统快速唤醒。

3.3.2 Suspend-to-Idle（挂起到空闲）

这是较浅的睡眠模式。CPU进入WFI（Wait For Interrupt）状态，但外设保持供电。

特点：

• 功耗较高，约几百毫瓦到几瓦
• 唤醒延迟极低，微秒级
• 外设状态保持，无需重新初始化

STI适合短时间待机场景。比如等红绿灯时，系统进入STI，当导航提示音需要播放时，几乎无延迟地唤醒。

对比项	Suspend-to-RAM	Suspend-to-Idle
功耗	极低（~50mW）	较低（~500mW）
唤醒延迟	几十~几百ms	微秒级
外设状态	掉电，需重新初始化	保持供电，状态保留
适用场景	长时间停车	短时间待机

3.3.3 如何选择

我个人的经验是：不要只用一种模式。车载系统应该根据场景动态切换：

• 车辆熄火后5分钟内 → Suspend-to-Idle（方便快速响应）
• 车辆熄火超过5分钟 → Suspend-to-RAM（省电）
• 检测到电池电量低 → 直接Suspend-to-RAM

3.4 小结

好了，今天的内容就到这里。总结一下：

• Runtime PM是设备级别的自动电源管理，通过引用计数控制suspend/resume
• struct dev_pm_ops是电源管理回调的集合，系统睡眠和Runtime PM共用一套结构体
• Suspend-to-RAM深度睡眠，适合长时间待机；Suspend-to-Idle浅度睡眠，适合短时间待机

下一章，咱们会深入讲设备树中的电源管理配置，以及如何在实际项目中调试电源管理问题。到时候我会分享一个我调试车载摄像头唤醒延迟的真实案例，保证让你有收获。

公众号:蓝海资料掘金营，微信deep3321