2. Linux内核功耗管理框架

Linux内核的功耗管理并非由一个单一的模块完成，而是由四个核心子系统分工协作，形成一个从CPU到设备、从系统级到运行时级的完整闭环。理解这四个子系统的职责与协作关系，是进行驱动开发功耗优化的基础。

2.1 四大子系统职责总览

2.2 子系统协作关系：从系统级到设备级

四个子系统并非孤立运行，它们通过内核的 PM QoS 框架和 通知链（notifier chain） 紧密耦合。下图展示了典型的协作流程：

2.3 协作机制详解：PM QoS与通知链

四大子系统之间的协作主要通过以下两个核心机制实现：

• PM QoS (Power Management Quality of Service)： 一个全局的约束传递框架。例如，当某个设备通过Runtime PM要求“CPU频率不得低于1.2GHz”时，PM QoS会向CPUFreq子系统传递一个频率下限约束，阻止CPUFreq将频率降至该值以下。
• 通知链 (Notifier Chain)： 用于事件广播。例如，当CPUIdle准备进入深度C-State时，会通过通知链告知Device PM子系统“CPU即将离线”，Device PM据此决定是否允许该设备进入休眠。

2.4 协作流程示例：音频播放场景

以音频播放为例，展示四个子系统如何协同工作：

1. Runtime PM： 音频驱动检测到播放开始，调用 pm_runtime_get_sync() 唤醒音频编解码器（Codec）硬件。
2. PM QoS： 音频驱动注册一个CPU频率约束（例如最低1.0GHz），确保CPU有足够算力处理音频数据。
3. CPUFreq： 收到PM QoS约束后，将CPU频率提升至1.0GHz以上，并选择 schedutil Governor 根据负载动态微调。
4. CPUIdle： 由于CPU正在处理音频中断，空闲时间变短，CPUIdle的 menu Governor 会避免选择深度C-State，只使用浅度睡眠（C1），以降低唤醒延迟。
5. Device PM： 如果用户按下电源键触发系统休眠，Device PM会先调用音频驱动的 suspend() 回调，保存硬件状态并停止DMA传输。

2.5 子系统职责对比表

2.6 驱动开发中的协作注意事项

正确的做法是：

• 在 runtime_resume() 中根据设备实际需求注册PM QoS约束。
• 在 runtime_suspend() 中释放所有约束。
• 使用 dev_pm_qos_add_request() 替代全局 pm_qos_add_request()，实现设备级粒度控制。

// 示例：音频驱动中注册/释放PM QoS约束
#include <linux/pm_qos.h>

static struct dev_pm_qos_request freq_qos_req;

static int audio_runtime_resume(struct device *dev)
{
    // 注册频率下限约束：最低1.0GHz
    dev_pm_qos_add_request(dev, &freq_qos_req,
                           DEV_PM_QOS_MIN_FREQUENCY,
                           1000000); // 单位：kHz
    // ... 唤醒硬件 ...
    return 0;
}

static int audio_runtime_suspend(struct device *dev)
{
    // 释放频率约束
    dev_pm_qos_remove_request(&freq_qos_req);
    // ... 挂起硬件 ...
    return 0;
}