Linux 内核功耗子系统(十二):PM QoS framework框架梳理

全景介绍

低功耗设计里经常遇到一个矛盾：系统想省电，但业务不能接受太长的响应延迟。CPUIdle 想进入深度 idle 状态，Runtime PM（运行时电源管理）想把设备挂起，CPUFreq 或 devfreq（设备频率调节）想把频率降下来，这些动作都能省电，但都可能带来恢复延迟、吞吐量下降或者响应抖动。

PM QoS（Power Quality of Service，电源质量服务） 处理的就是这类边界问题。

它不是一个直接执行省电动作的框架，也不是 CPUIdle、CPUFreq、Runtime PM 的替代品。它提供一套约束管理机制，让驱动、子系统或者用户态进程声明自己能接受的 latency（延迟）、frequency（频率）或者设备恢复边界。执行低功耗动作的框架做决定前会读取这些约束，判断当前动作是否允许。

所以 PM QoS 要放在约束传播链路里理解：需求方提交 request（请求） → PM QoS framework 聚合 request → 执行方读取聚合结果 → 再决定能不能进入某个低功耗状态。

实际情况

PM QoS 容易被误解成"打开之后更省电"。实际方向通常相反：PM QoS 大多数时候是在阻止过于激进的低功耗动作。

• • 音频播放期间，系统可能需要较低的 CPU/DMA 响应延迟
• • 相机预览期间，某些设备不能随便 runtime suspend（运行时挂起）
• • 网络高吞吐场景下，太低频率可能影响数据处理能力
• • 显示链路在高刷新阶段，也可能需要设备保持较短恢复路径

这类需求如果不进入统一约束框架，每个子系统都会自己做一套判断，最后很难解释为什么 CPU 睡不深、设备不挂起、频率降不下来。PM QoS 的价值不是替执行框架做决定，而是把这些业务约束变成执行框架能读取的统一边界。

很多功耗问题表面看起来像是执行方异常：CPUIdle 进不了深度 idle、Runtime PM 不发生 suspend、genpd（generic power domain，通用电源域）不掉电、CPUFreq/devfreq 不降频。实际上第一步应该先问：是不是还有哪条 QoS request 处在生效状态。

抽象对象

PM QoS 核心对象可以分成 request（请求）、constraint（约束）、notifier（通知器）三类，再按作用范围分出系统级 QoS、设备级 QoS 和 frequency QoS。我们结合 Linux 源码定义来理解：

核心对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// include/linux/pm_qos.h

/* 1. request：需求方提交的一条约束 */
struct pm_qos_request {
struct plist_node node;  // 挂到对应 constraint 的链表上
    int              data;   // 约束值，比如 latency 限制数值
    ...
};

/* 2. constraint：一组同类 request 聚合后的结果 */
struct pm_qos_constraints {
struct plist_head    requests;        // 所有 request 挂在这里
    int            default_value;    // 默认值，没有 request 时用这个
    int            no_constraint;   // 完全没有约束时的取值
    int            *target;         // 当前聚合结果，输出给执行方
    ...
};

/* 3. notifier：约束变化通知，让执行方重新评估 */
struct blocking_notifier_head *notifier;

• • request：代表需求方提交的一条约束。需求方可以是驱动、子系统，也可以是用户态进程。request 不是一次性写入的变量，它有完整生命周期：add（添加）、update（更新）、remove（移除）。源码里用 plist_node 把 request 挂到 constraint 的链表上，方便聚合计算。
• • constraint：保存一组同类 request，聚合计算出当前生效的约束值。latency 类约束通常取更严格（更小）的值，frequency min/max 也有各自聚合方式：min 取最大值，max 取最小值。
• • notifier：约束变化时通知监听者。某些执行路径或者平台模块需要在 QoS 变化时重新评估当前状态，就可以监听对应 constraint 更新。

按作用范围分类

系统级 PM QoS

常见入口是 CPU/DMA latency 约束。定义在 kernel/power/qos.c 全局：

1
2

struct pm_qos_constraints cpu_dma_constraints;

它影响系统从低功耗状态响应 CPU 或者 DMA 事件的延迟边界，CPUIdle 会参考它裁剪深度 idle 状态。

设备级 PM QoS（per-device）

绑定到具体 struct device，定义在 include/linux/pm_qos.h：

1
2
3
4
5
6
7

struct dev_pm_qos {
struct pm_qos_constraints latency;       // resume latency 约束
struct pm_qos_constraints latency_noirq;  // 无锁上下文 resume latency 约束
struct pm_qos_constraints flags;        //  PM 标志约束
    ...
};

它约束设备恢复延迟、激活延迟容忍或者 PM 标志，更多影响 Runtime PM、设备 suspend/resume、genpd 和驱动自己的电源状态选择。

frequency QoS（频率 QoS）

处理频率边界，定义在 include/linux/freq_qos.h：

1
2
3
4
5
6

struct freq_constraints {
struct pm_qos_constraints max_freq;  // 最高频率约束
struct pm_qos_constraints min_freq;  // 最低频率约束
    ...
};

CPUFreq 和 devfreq 可以通过 freq_qos 聚合 min/max request，形成当前允许的频率区间。

模型

PM QoS 模型可以压缩成三段：需求方 → 约束框架 → 执行方。

1. 1. 需求方提交约束：来源可以是内核驱动、子系统，也可以是用户态服务。约束可能是 CPU/DMA latency，也可能是某个设备的 resume latency（恢复延迟），或是频率下限、频率上限这类边界。
2. 2. 约束框架保存 request，并按约束类型计算聚合值：这个聚合不是记录最近一次写入，而是根据 constraint 语义取 min、max 或者其他有效值。约束变化时，framework 可以通过 notifier 通知关注者，让执行方重新评估状态。
3. 3. 执行方读取约束：CPUIdle、Runtime PM、genpd、CPUFreq、devfreq 这些路径在做低功耗决策时，读取当前约束，把不满足条件的动作排除掉。

这里一定要分清边界：PM QoS 不负责让 CPU 进入 idle 状态，CPUIdle governor（选择策略）仍然负责选 state；PM QoS 也不直接切频率，CPUFreq/devfreq 的频率选择仍然由 governor、policy、OPP（Operating Performance Point）和 firmware 完成。它只提供约束边界，最终决定还是留给原来的执行框架。

数据流

PM QoS 的数据流从 request 提交开始：

系统级 latency 场景下，内核驱动可以调用 pm_qos_add_request() 添加 request，也可以通过 pm_qos_update_request() 更新值，最后用 pm_qos_remove_request() 移除。用户态则常见通过 /dev/cpu_dma_latency 写入 latency 值，fd（文件描述符）关闭时 request 自动移除。

per-device 场景下，request 绑定到具体 device。驱动或子系统通过 dev_pm_qos 接口提交设备恢复延迟、flags 或者 latency tolerance。Runtime PM 和设备 PM 路径在准备 suspend/resume 时会读取这些约束。

frequency 场景下，freq_qos 通常挂在 cpufreq policy 或 devfreq 相关对象上。min request 用来抬高最低频率，max request 用来压低最高频率。多个 request 聚合后形成当前有效频率区间。

执行方读取聚合结果后，不是"照着 PM QoS 执行动作"，而是把它作为候选动作的过滤条件：

• • CPUIdle 会排除 exit latency 超过约束的 state
• • Runtime PM 会结合 usage_count、wakeup、设备依赖和 QoS 判断能否挂起
• • CPUFreq/devfreq 会把目标频率限制在有效区间内

如果平台由 SCMI/CPPC/vendor firmware 接管，Linux 发出的请求流到 firmware 后还可能继续被处理。Linux 只能看到请求、回读和统计，固件内部为什么拒绝或裁剪，需要平台文档或 vendor trace 才能确认。

运行

PM QoS 运行的重点是 request 生命周期。

• • add：表示场景开始。比如音频开始播放、相机开始预览、网络进入低延迟传输、显示链路进入高刷状态，驱动或用户态服务添加一条 QoS request，声明当前阶段不能接受太长延迟或者太低频率。
• • update：表示场景变化。同一个业务阶段内，约束可能从严格变宽松，也可能从宽松变严格。例如缓冲阶段要求低 latency，稳定播放阶段可以放宽；高帧率阶段需要较高最低频率，普通帧率阶段可以降低 request。
• • remove：表示场景结束。场景结束后必须移除 request，或者恢复默认值。fd 关闭、驱动 remove、runtime error unwind、业务停止路径都应该保证 request 被释放。

很多功耗问题不是没有 QoS 机制，而是 request 生命周期没有闭合。低功耗框架看到的只有当前聚合值，不知道这条 request 是否还对应着活跃场景。一个忘记释放的 CPU/DMA latency request，就足够让 CPUIdle 长期进不了深度状态。

RK3588 上 PM QoS 配置与约束理解

RK3588 作为 ARM 通用 SoC，PM QoS 配置主要落在 CPUIdle、Runtime PM、CPUFreq 三个路径，结合 device tree 和内核配置理解：

1. 系统级 CPU/DMA latency 约束配置

RK3588 内核源码中，CPU/DMA latency 约束入口默认打开，配置选项：

1
2
3

CONFIG_PM_QOS=y
CONFIG_PM_QOS_FLAGS=y

这个配置不需要改，默认 defconfig 已经打开。关键是用户态怎么加约束：

用户态程序可以通过 /dev/cpu_dma_latency 接口添加约束：

1
2
3
4
5
6

int fd = open("/dev/cpu_dma_latency", O_RDWR);
int latency = 100; // 单位：微秒，允许最大退出延迟 ≤ 100us
write(fd, &latency, sizeof(latency));
// 使用过程中保持 fd 打开，关闭 fd 自动移除 request
close(fd);

• • 理解：只要 fd 不关闭，这个 request 就一直生效，会排除所有 exit latency > 100us 的 CPUIdle 深度状态
• • RK3588 上音频驱动默认会在播放时添加这个约束，所以播放音频时 CPU 经常进不了深度 idle 是正常现象

2. 设备级 dev_pm_qos 约束配置

RK3588 每个 device 可以在 probe 阶段绑定 dev_pm_qos 请求，dts 里也能配置默认 resume latency：

1
2
3
4
5

&usb {
    status = "okay";
    qos-resume-latency-us = <500>; // 默认恢复延迟不超过 500us
};

内核驱动里动态添加：

1
2
3

dev_pm_qos_add_request(&dev->dev, &dev->qos_req,
    DEV_PM_QOS_RESUME_LATENCY, 500);

• • 理解：Runtime PM 尝试 suspend 设备前，会比较当前聚合 resume latency 约束，如果驱动要求的 latency 比当前约束更严格，就不允许 suspend。
• • RK3588 上摄像头、USB、PCIe 设备常见这类约束，打开设备后就不让 Runtime PM 挂起，保证响应速度。

3. 频率约束 freq_qos 配置

RK3588 CPUFreq 对 freq_qos 支持默认打开，驱动可以添加 min/max 频率约束：

1
2

freq_qos_add_min_freq_request(policy, &data->qos_req, 1000000);

• • 理解：min request 会把最低频率抬高到 1GHz，即使负载很低，CPUFreq 也不能把频率降到 1GHz 以下，保证显示管线刷新延迟满足要求。
• • RK3588 显示驱动在高刷模式下常用这个约束，保证帧率稳定。

4. 约束条件怎么理解

PM QoS 约束本质是"不允许什么"，不是"要求做什么"：

• • PM_QOS_CPU_DMA_LATENCY = 100：不允许 exit latency > 100us 的 idle 状态，不是要求所有 idle 状态延迟都到 100us
• • DEV_PM_QOS_RESUME_LATENCY = 50：不允许 resume latency > 50us 的 suspend，不是要求 resume 必须到 50us
• • freq_qos_min = 1000000：不允许频率 < 1GHz，不是要求频率必须稳定 1GHz

理解这个逻辑很重要：PM QoS 只是给执行框架画了一条不能越界的线，具体选什么动作还是执行框架决定。

总结

PM QoS 是低功耗路径里的约束管理框架。

它不负责省电动作，不负责选 idle 状态，不负责调频，也不负责 runtime suspend。它做的就是收集 request、计算聚合约束、向执行框架提供当前边界。

理解 PM QoS，可以抓三条线：

• • request 来源：谁提交了约束，是驱动、子系统，还是用户态进程。
• • constraint 聚合：多个 request 如何形成当前有效 latency 或者 frequency 边界。
• • 执行方读取：CPUIdle、Runtime PM、genpd、CPUFreq/devfreq 如何用这个边界裁剪低功耗动作。

PM QoS 是低功耗设计里"隔离变化"的经典设计：需求方只管声明约束，执行方只管读取边界，框架做聚合转发，双方不需要直接耦合。正是这个设计，让它能串联起系统中各个不相关的低功耗请求，成为功耗决策的公共约束入口。

在 RK3588 这类 ARM SoC 上，只要掌握 request 生命周期和约束语义，大部分奇怪的功耗问题就能找到原因：为什么 CPU 睡不深？为什么设备挂不起来？为什么频率降不下来？先看 PM QoS，大部分时候问题就在这里。