4. QNX设备驱动电源管理：PM框架介绍、设备挂起/恢复回调实现、运行时动态电源管理（Runtime PM）

好，咱们进入第四章。这一章聊的是驱动层面的电源管理。说白了，就是让设备该睡就睡，该醒就醒。

很多工程师觉得PM是上层应用的事，驱动只要把功能实现就行。我刚开始也这么想。直到有一次，一个客户说我们的系统待机功耗比竞品高了30%。查来查去，发现是一个串口驱动在空闲时根本没关时钟。从那以后，我就把驱动PM当成必修课了。

4.1 QNX PM框架概览

QNX的电源管理，不是让你从头造轮子。它有一套现成的框架，叫PM框架。你想想看，如果每个驱动都自己搞一套休眠逻辑，系统不乱套才怪。

这个框架的核心思路很简单：

• 统一接口：所有驱动遵循同样的PM回调规范
• 分层管理：系统级、设备级、运行时级，各司其职
• 策略与机制分离：驱动只负责“怎么睡”，不负责“什么时候睡”

我个人习惯把PM框架理解成一个“酒店前台”。设备就是客人，想入住（唤醒）就登记，想退房（挂起）就办手续。前台（PM框架）统一管理所有客人的状态。

4.2 设备挂起/恢复回调实现

这是驱动PM最基础的部分。每个支持PM的设备驱动，都要实现两个回调：suspend 和 resume。

嗯，这里要注意：挂起不是简单地把设备关掉。你得考虑：

• 当前是否有未完成的事务？
• DMA传输是否还在进行？
• 中断是否已经屏蔽？
• 寄存器状态是否需要保存？

我曾经遇到一个坑：一个网卡驱动在suspend回调里直接关了时钟，但没等DMA传输完成。结果恢复后，DMA描述符全乱了，网络直接挂掉。从那以后，我每次写suspend都会先检查DMA状态。

来看一个典型的实现模板：

// 设备挂起回调
static int mydev_suspend(struct pm_device *pm_dev, pm_state_t state)
{
    struct mydev_priv *priv = pm_get_drvdata(pm_dev);
    
    // 1. 检查设备是否忙
    if (priv->busy) {
        pm_dev_err(pm_dev, "设备忙，无法挂起\n");
        return -EBUSY;
    }
    
    // 2. 保存关键寄存器
    priv->saved_regs.ctrl = readl(priv->base + REG_CTRL);
    priv->saved_regs.status = readl(priv->base + REG_STATUS);
    
    // 3. 屏蔽中断
    writel(0, priv->base + REG_INT_ENABLE);
    
    // 4. 关闭时钟
    clk_disable(priv->clk);
    
    // 5. 关闭电源（如果有独立电源域）
    regulator_disable(priv->regulator);
    
    pm_dev_info(pm_dev, "设备已挂起\n");
    return 0;
}

// 设备恢复回调
static int mydev_resume(struct pm_device *pm_dev)
{
    struct mydev_priv *priv = pm_get_drvdata(pm_dev);
    
    // 1. 恢复电源
    regulator_enable(priv->regulator);
    
    // 2. 恢复时钟
    clk_enable(priv->clk);
    
    // 3. 恢复寄存器
    writel(priv->saved_regs.ctrl, priv->base + REG_CTRL);
    writel(priv->saved_regs.status, priv->base + REG_STATUS);
    
    // 4. 重新配置硬件
    mydev_hw_init(priv);
    
    // 5. 使能中断
    writel(priv->irq_mask, priv->base + REG_INT_ENABLE);
    
    pm_dev_info(pm_dev, "设备已恢复\n");
    return 0;
}

// 注册PM操作
static struct pm_ops mydev_pm_ops = {
    .suspend = mydev_suspend,
    .resume  = mydev_resume,
};

4.3 运行时动态电源管理（Runtime PM）

系统级挂起/恢复是“大动作”，整个系统一起睡。但很多时候，我们只需要让某个空闲设备单独睡。这就是Runtime PM的用武之地。

Runtime PM的精髓在于：设备不用时就自动挂起，有人要用时自动唤醒。整个过程对上层应用透明。

你想想看，一个车载娱乐系统的触摸屏，用户可能几分钟才点一次。如果这期间屏幕驱动一直全速运行，那不是浪费电吗？

QNX的Runtime PM实现起来，主要有几个关键点：

• 引用计数：每个设备有一个使用计数，计数为0时触发挂起
• 自动挂起定时器：设备空闲一段时间后自动挂起
• 唤醒源：某些事件（如中断）可以唤醒设备

我记得有一次调试一个SPI设备的Runtime PM。设备总是挂起后无法恢复，查了半天，发现是唤醒中断没有正确配置。SPI从设备发来数据时，主控根本不知道。嗯，这个坑我印象很深。

来看一个Runtime PM的典型用法：

// 设备打开时，增加引用计数
static int mydev_open(struct mydev_dev *dev)
{
    pm_runtime_get(dev->pm_dev);
    // ... 初始化硬件
    return 0;
}

// 设备关闭时，减少引用计数
static int mydev_close(struct mydev_dev *dev)
{
    // ... 清理硬件
    pm_runtime_put(dev->pm_dev);
    return 0;
}

// 自动挂起回调
static int mydev_runtime_suspend(struct pm_device *pm_dev)
{
    // 这里做轻量级的挂起操作
    // 比如只关闭时钟，不保存寄存器
    clk_disable(priv->clk);
    return 0;
}

// 自动恢复回调
static int mydev_runtime_resume(struct pm_device *pm_dev)
{
    clk_enable(priv->clk);
    return 0;
}

// 注册Runtime PM回调
static struct pm_ops mydev_runtime_ops = {
    .runtime_suspend = mydev_runtime_suspend,
    .runtime_resume  = mydev_runtime_resume,
};

4.4 PM框架的调试技巧

调试PM问题，说实话挺头疼的。设备睡下去醒不来，或者醒来了状态不对，这些bug很难复现。

我分享几个实用技巧：

• 加日志：在suspend/resume回调里加pm_dev_info，记录关键步骤
• 检查引用计数：用pm_runtime_get_status查看设备当前状态
• 模拟超时：缩短自动挂起的定时器，加速问题复现
• 强制挂起/恢复：通过命令行手动触发，排除上层干扰

举个例子，我曾经用这个命令手动测试设备挂起：

# 强制挂起设备
pmctl -d /dev/mydev suspend

# 强制恢复设备
pmctl -d /dev/mydev resume

# 查看设备PM状态
pmctl -d /dev/mydev status

这些命令在调试阶段特别有用。你可以先手动验证驱动PM逻辑是否正确，再交给上层策略去调度。

4.5 小结

这一章我们聊了QNX设备驱动PM的三个层次：

• PM框架：统一的管理接口，别自己造轮子
• 挂起/恢复回调：驱动PM的基础，注意保存和恢复的顺序
• Runtime PM：轻量级的动态电源管理，适合空闲设备自动休眠

最后说一句：驱动PM做得好不好，直接决定了系统的整体功耗。别觉得这是小事。我见过太多项目，因为驱动PM没做好，导致整机功耗翻倍。嗯，下一章我们聊聊更高级的话题——如何用PM框架做系统级的功耗策略调度。