企业官网建设流程全解析

1. 功耗管理的隐形裁判：PM QoS 到底在管什么

做过嵌入式 Linux 功耗优化的朋友大概率遇到过这种场景：系统待机功耗死活降不下去，查了半天 CPU 频率、外设时钟、电源域，最后发现是某个驱动在初始化时悄悄拉高了一个约束，让整条低功耗路径根本走不通。这个“悄悄拉高约束”的机制，十有八九就是 PM QoS。

PM QoS，全称 Power Management Quality of Service，直译过来是“电源管理服务质量”。这个名字听起来有点抽象，你可以把它理解成一套功耗与性能之间的投票系统。系统里每个关心功耗或延迟的模块——CPU 调频器、网卡驱动、音频子系统、显示控制器——都可以通过 PM QoS 投出自己的一票，告诉内核“我至少需要多低的延迟”或者“我最多能接受多大的功耗”。内核汇总所有投票，取一个能满足所有人的折中值，再据此决定 CPU 该跑多快、哪些电源域该开、哪些该关。

它解决的核心问题是：功耗和性能天生矛盾，而不同模块的需求又互相冲突。比如音频播放要求 CPU 唤醒延迟极低，否则会爆音；而系统空闲时又希望 CPU 尽量睡死省电。没有 PM QoS 之前，驱动之间只能靠私有接口互相“打招呼”，耦合严重、容易打架。PM QoS 把这套协商机制标准化，让每个模块只管投自己的票，汇总和裁决交给框架。

这篇文章适合三类人看：一是正在做嵌入式 Linux 功耗优化的工程师，二是需要给驱动加功耗约束的 BSP 开发者，三是想搞懂内核功耗子系统整体架构的学习者。我会把 PM QoS 的框架结构、核心数据结构、API 用法、约束聚合逻辑，以及实际调试中踩过的坑，一条条拆开讲清楚。读完你至少能做到：看懂驱动里那些pm_qos_add_request到底在干什么，能自己给模块加约束，能在功耗异常时顺着 PM QoS 这条线排查下去。

2. 框架整体设计：两类约束、三层结构、一套聚合逻辑

2.1 为什么是“两类约束”而不是一套通用接口

PM QoS 在设计上做了一个很关键的切分：把约束分成全局约束和每设备约束两类。这个切分不是拍脑袋定的，背后有很实际的工程考量。

全局约束针对的是整个 SoC 层面的资源，典型代表就是 CPU DMA 延迟（PM_QOS_CPU_DMA_LATENCY）。为什么是 DMA 延迟？因为 CPU 从 idle 状态被唤醒的延迟，直接决定了 DMA 传输会不会丢数据。如果 CPU 睡得太深，唤醒要几百微秒，而 DMA 缓冲区又很小，数据就来不及搬走，直接溢出。所以任何对 DMA 延迟敏感的模块，都可以往这个全局约束上投票。

每设备约束则是针对某个具体设备的，比如某个网卡要求“我工作时 CPU 不能低于某个频率”，或者某个显示控制器要求“我刷新时内存带宽不能低于多少”。这类约束只对指定设备生效，不会影响全局。

提示：全局约束和每设备约束在代码里走的是两套不同的 API 和数据结构，别混用。全局约束用pm_qos_add_request系列，每设备约束用dev_pm_qos_add_request系列，前缀dev_就是区分标志。

2.2 三层结构：请求层、聚合层、通知层

从代码组织上看，PM QoS 可以拆成三层。

请求层是驱动直接打交道的部分，提供add_request、update_request、remove_request这些 API。驱动通过pm_qos_request或dev_pm_qos_request结构体来登记自己的需求。这一层的设计要点是：请求可以随时增删改，框架必须能正确处理生命周期，尤其是驱动卸载时忘记 remove 的情况。

聚合层是框架的核心，负责把所有请求汇总成一个当前有效值。全局约束的聚合相对简单，因为约束类型有限，每种类型维护一个目标值即可。每设备约束的聚合就复杂一些，因为一个设备可能同时有多个约束（频率、延迟、带宽），而且约束之间还有优先级和类型之分。

通知层负责在聚合值发生变化时，通知所有关心这个变化的模块。比如 CPU 调频器会注册一个 notifier，当 CPU DMA 延迟约束变化时，它收到通知后重新计算目标频率。通知层用的是内核标准的 notifier 机制，同步调用，所以 notifier 回调里不能做耗时操作。

2.3 约束聚合逻辑：取最严格的那个

聚合逻辑说起来简单：对于“上限型”约束，取所有请求里的最小值；对于“下限型”约束，取所有请求里的最大值。因为约束的本质是“不能超过”或“不能低于”，要满足所有人，就得取最严格的那个。

举个例子，三个驱动分别要求 CPU DMA 延迟不超过 100us、50us、200us，那聚合结果就是 50us，因为只有 50us 能满足那个要求最苛刻的驱动。反过来，如果三个驱动分别要求 CPU 频率不低于 800MHz、1GHz、600MHz，聚合结果就是 1GHz。

这个逻辑听起来理所当然，但实际实现时要处理几个细节：请求的优先级、默认值、以及“无请求”时的行为。全局约束在没有请求时通常返回一个默认值（比如PM_QOS_DEFAULT_VALUE），表示“没有特殊要求”。每设备约束在没有请求时则返回“无约束”，让设备可以自由进入低功耗状态。

3. 核心数据结构与 API：从 request 到 notifier 的完整链路

3.1 全局约束的数据结构长什么样

全局约束的核心结构是struct pm_qos_constraints，它描述了一种约束类型的所有信息。关键字段包括：

• list：挂载所有请求的链表头
• target_value：当前聚合后的目标值
• default_value：没有请求时的默认值
• type：约束类型，是上限型（PM_QOS_MAX）还是下限型（PM_QOS_MIN）
• notifiers：通知链，约束值变化时触发

每种全局约束类型（比如 CPU DMA 延迟）在初始化时会创建一个pm_qos_constraints实例，并注册到全局数组pm_qos_array里。驱动通过约束类型 ID 来找到对应的实例。

单个请求用struct pm_qos_request表示，里面最关键的是node（挂到链表上的节点）和pm_qos_class（约束类型 ID）。驱动调用pm_qos_add_request时，框架会分配一个请求结构，把请求值填进去，然后挂到对应约束的链表上，并重新计算聚合值。

3.2 每设备约束的额外复杂度

每设备约束的结构是struct dev_pm_qos，它挂在struct device上。一个设备可以有多个约束，所以dev_pm_qos里包含了一个约束数组，每个元素对应一种约束类型（频率、延迟、带宽等）。

每设备约束比全局约束多了一个概念：约束的优先级和类型。比如频率约束可以是“最小值”也可以是“最大值”，框架需要区分。另外，每设备约束还支持“标志位”，比如PM_QOS_FLAG_NO_POWER_OFF表示“这个设备不允许断电”，PM_QOS_FLAG_REMOTE_WAKEUP表示“这个设备可以远程唤醒”。

驱动给设备加约束的典型流程是：

struct dev_pm_qos_request req; int ret; ret = dev_pm_qos_add_request(dev, &req, DEV_PM_QOS_RESUME_LATENCY, 100); if (ret < 0) { /* 处理错误 */ }

这里DEV_PM_QOS_RESUME_LATENCY是约束类型，100是约束值（单位通常是微秒）。加完之后，设备的 resume latency 约束就生效了，电源管理核心在决定设备能否进入低功耗状态时会参考这个值。

3.3 notifier 机制：约束变化后谁来干活

约束值变化后，框架需要通知相关模块。全局约束用的是blocking_notifier_head，每设备约束用的是bus_notifier或设备自身的 notifier。注册 notifier 的典型代码是：

static int my_notifier_call(struct notifier_block *nb, unsigned long val, void *v) { /* val 是新的约束值，v 是约束类型相关数据 */ /* 根据新值调整硬件状态 */ return NOTIFY_OK; } static struct notifier_block my_nb = { .notifier_call = my_notifier_call, }; pm_qos_add_notifier(PM_QOS_CPU_DMA_LATENCY, &my_nb);

注意：notifier 回调是在持有锁的上下文里同步调用的，绝对不能在里面睡眠或做耗时操作。我见过有人在 notifier 里直接调用msleep，结果系统直接卡死。正确做法是在回调里标记一个 work，让工作队列去处理实际硬件操作。

4. 实操：给一个虚拟驱动加上 PM QoS 约束

4.1 场景设定与约束值计算

假设我们有一个虚拟的音频驱动，它通过 DMA 搬运音频数据。音频缓冲区大小是 4KB，采样率 48kHz，位深 16bit，双声道。我们来算一下它对 CPU DMA 延迟的要求。

每秒钟的数据量是 48000 × 2 × 2 = 192000 字节。4KB 缓冲区能撑的时间是 4096 / 192000 ≈ 21.3ms。也就是说，CPU 必须在 21.3ms 内醒来把数据搬走，否则就会欠载。考虑到安全余量，我们要求 CPU 唤醒延迟不超过 10ms，也就是 10000us。

这个值就是我们要往PM_QOS_CPU_DMA_LATENCY上投的票。注意单位是微秒，别写成毫秒，否则约束会松 1000 倍，等于没加。

4.2 完整驱动代码骨架

#include <linux/pm_qos.h> #include <linux/module.h> #include <linux/platform_device.h> struct my_audio_dev { struct device *dev; struct pm_qos_request qos_req; bool qos_active; }; static int my_audio_probe(struct platform_device *pdev) { struct my_audio_dev *adev; int ret; adev = devm_kzalloc(&pdev->dev, sizeof(*adev), GFP_KERNEL); if (!adev) return -ENOMEM; adev->dev = &pdev->dev; platform_set_drvdata(pdev, adev); /* 初始化时先不加约束，等真正开始播放再加 */ adev->qos_active = false; return 0; } static int my_audio_start_playback(struct my_audio_dev *adev) { if (adev->qos_active) return 0; /* 加上 CPU DMA 延迟约束：不超过 10000us */ pm_qos_add_request(&adev->qos_req, PM_QOS_CPU_DMA_LATENCY, 10000); adev->qos_active = true; /* 启动 DMA 传输 */ /* ... */ return 0; } static int my_audio_stop_playback(struct my_audio_dev *adev) { if (!adev->qos_active) return 0; /* 停止 DMA 传输 */ /* ... */ /* 移除约束，让系统可以进入更深度的低功耗状态 */ pm_qos_remove_request(&adev->qos_req); adev->qos_active = false; return 0; } static int my_audio_remove(struct platform_device *pdev) { struct my_audio_dev *adev = platform_get_drvdata(pdev); /* 驱动卸载时务必清理约束 */ if (adev->qos_active) pm_qos_remove_request(&adev->qos_req); return 0; }

这段代码的关键点在于：约束只在播放期间存在，播放结束立刻移除。很多驱动偷懒，在 probe 里加约束，remove 里才移除，结果设备即使空闲也拖着系统不让睡，功耗白白浪费。

4.3 验证约束是否生效

加完约束后，怎么确认它真的起作用了？最直接的方法是看 debugfs：

cat /sys/kernel/debug/pm_qos/pm_qos_summary

这个文件会列出所有全局约束的当前聚合值、默认值、以及每个请求的值。如果你看到PM_QOS_CPU_DMA_LATENCY的 target value 变成了 10000，说明约束生效了。

另一个方法是看 CPU idle 状态统计：

cat /sys/devices/system/cpu/cpu0/cpuidle/state*/usage

加约束前后，深度 idle 状态的使用次数应该会明显减少，因为 CPU 不敢睡太深了。

5. 常见问题与排查技巧实录

5.1 约束加了但功耗没变化

这是最常见的问题。原因通常有三种：一是约束类型选错了，比如该用PM_QOS_CPU_DMA_LATENCY却用了别的；二是约束值单位搞错了，把微秒当毫秒；三是约束根本没生效，因为对应的调频器或 idle 驱动没有注册 notifier。

排查顺序建议是：先看 debugfs 里的 target value 有没有变，没变说明请求没挂上；变了但功耗没变，说明没有模块响应这个约束，去检查 CPUFreq governor 和 cpuidle driver 是否注册了对应的 notifier。

5.2 驱动卸载后约束残留

如果驱动卸载时忘记pm_qos_remove_request，约束会一直挂在链表上，导致系统永远无法进入低功耗状态。更麻烦的是，如果驱动模块被卸载后重新加载，旧约束的指针可能已经失效，框架访问时会 oops。

提示：用devm_pm_qos_add_request可以自动管理生命周期，设备销毁时框架自动移除约束。但注意这个 API 在较老的内核版本里可能不存在，用之前先确认内核版本。

5.3 多个约束互相打架

当多个驱动同时加约束时，聚合逻辑会取最严格的值。这本身没问题，但如果两个驱动的约束值差距很大，可能导致系统频繁在高低功耗状态之间切换，反而增加功耗。这种情况需要从系统层面协调，比如让约束值接近的驱动共用同一个约束，或者用每设备约束代替全局约束，减少互相干扰。

5.4 常见问题速查表

5.5 独家避坑经验

我在实际项目里踩过最坑的一次，是给一个 USB 控制器加 resume latency 约束，值设成了 0。本意是“要求立即唤醒”，结果框架把 0 解释成“无约束”，约束完全没生效。后来查代码才发现，dev_pm_qos_add_request对 0 值有特殊处理，0 表示清除约束。正确的做法是设一个很小的非零值，比如 1us。

另一个坑是 notifier 的注册顺序。如果调频器在 PM QoS 框架初始化之前就注册了 notifier，可能收不到早期的约束变化。解决办法是在调频器初始化时主动读一次当前约束值，而不是只依赖 notifier。

6. 从框架到实战：PM QoS 在典型场景中的落地方式

6.1 CPU 调频场景：约束如何影响频率选择

CPUFreq 子系统是 PM QoS 最大的消费者之一。以schedutilgovernor 为例，它在计算目标频率时，会同时考虑 CPU 利用率、以及 PM QoS 的 CPU DMA 延迟约束。如果约束要求延迟不超过某个值，governor 会确保频率不低于某个下限，即使当前利用率很低。

这个联动关系是通过 notifier 实现的：PM QoS 约束变化时，通知 CPUFreq 重新评估频率。具体代码路径是pm_qos_update_target→blocking_notifier_call_chain→cpufreq_policy_notifier→cpufreq_update_policy。理解这条链路，对调试“为什么 CPU 频率降不下去”这类问题非常关键。

6.2 设备运行时电源管理场景：每设备约束的用法

设备的 runtime PM 和 PM QoS 是配合使用的。设备在runtime_suspend之前，会检查自己的 PM QoS 约束是否允许进入低功耗状态。如果约束要求“不允许断电”，runtime PM 就会跳过 suspend。

典型用法是网卡驱动：在数据传输期间，网卡会加一个PM_QOS_FLAG_NO_POWER_OFF约束，防止自己在传输中途被断电。传输结束后移除约束，允许 runtime PM 把网卡挂起。

6.3 系统级低功耗场景：全局约束的聚合效应

系统进入 suspend 之前，PM QoS 框架会检查所有全局约束。如果任何约束要求延迟低于某个阈值，系统可能无法进入最深的 suspend 状态。这就是为什么有时候明明所有驱动都空闲了，系统还是只能进s2idle而进不了deep。

排查这类问题时，/sys/kernel/debug/pm_qos/pm_qos_summary是第一手资料。它会告诉你哪个约束在阻止深度休眠，以及是哪个请求贡献了最严格的值。顺着请求的 owner 信息，就能找到对应的驱动。

6.4 约束值的动态调整策略

约束值不是一成不变的。比如音频驱动在播放高码率音频时可能需要更低的延迟，播放低码率时可以放宽。这时候可以用pm_qos_update_request动态调整：

pm_qos_update_request(&adev->qos_req, new_latency);

这个 API 会重新计算聚合值，如果新值比旧值宽松，系统可能立刻进入更低的功耗状态。动态调整的关键是及时性：该收紧时立刻收紧，该放宽时立刻放宽，不要拖到下一个周期。

7. 调试工具与内核配置要点

7.1 必须打开的配置项

要让 PM QoS 完整工作，内核配置里这几项必须打开：

• CONFIG_PM：电源管理核心
• CONFIG_PM_QOS：PM QoS 框架本身
• CONFIG_CPU_IDLE：CPU idle 驱动
• CONFIG_CPU_FREQ：CPU 调频
• CONFIG_PM_DEBUG和CONFIG_PM_ADVANCED_DEBUG：debugfs 支持

如果CONFIG_PM_QOS没开，所有pm_qos_*API 会变成空函数，编译能过但运行时什么都不做。这是新手最容易踩的坑之一。

7.2 debugfs 里的关键文件

PM QoS 在 debugfs 里暴露了几个文件，位置在/sys/kernel/debug/pm_qos/：

• pm_qos_summary：所有全局约束的汇总信息
• pm_qos_latency_tolerance：延迟容忍度相关
• 每设备约束可以通过/sys/kernel/debug/devices/下的设备目录查看

pm_qos_summary的输出格式大致是：

PM_QOS_CPU_DMA_LATENCY: target=10000 default=2000000000 requests: 10000 (owner: my_audio)

看到owner字段就能定位到具体驱动，非常方便。

7.3 ftrace 跟踪约束变化

如果 debugfs 不够用，可以用 ftrace 跟踪 PM QoS 的函数调用：

echo function > /sys/kernel/debug/tracing/current_tracer echo pm_qos_update_target > /sys/kernel/debug/tracing/set_ftrace_filter echo 1 > /sys/kernel/debug/tracing/tracing_on

这样每次约束变化都会记录调用栈，能清楚看到是谁在什么时候改了约束。

8. 几个容易混淆的概念澄清

8.1 PM QoS 和 runtime PM 的区别

这两个经常被搞混。简单说，runtime PM 管的是“设备要不要开”，PM QoS 管的是“设备开了之后性能不能低于某个线”。runtime PM 决定设备进入 suspend 还是 active，PM QoS 决定 active 状态下系统要提供多少性能。两者配合使用，但职责完全不同。

8.2 全局约束和每设备约束的选择

什么时候用全局约束，什么时候用每设备约束？我的经验是：如果约束影响的是整个 SoC 的公共资源（CPU、内存带宽、总线），用全局约束；如果只影响单个设备的行为，用每设备约束。全局约束影响面大，加之前要慎重；每设备约束影响面小，可以放心用。

8.3 约束值和实际性能的关系

约束值不是实际性能值，而是“最低要求”。比如 CPU DMA 延迟约束设成 10000us，不代表实际延迟就是 10000us，而是说系统会保证延迟不超过这个值。实际延迟可能远低于这个值，取决于当前系统状态。理解这一点，对设定合理的约束值很重要——不要设得过紧，否则会无谓地限制低功耗状态。

9. 我在实际项目中的几点体会

做功耗优化这些年，PM QoS 给我的最大感受是：它是一把双刃剑。用好了，能让系统在性能和功耗之间找到精确的平衡点；用不好，一个残留的约束就能让整个功耗优化前功尽弃。

我现在的习惯是，每加一个 PM QoS 约束，都要在代码注释里写清楚三件事：为什么需要这个约束、约束值是怎么算出来的、什么条件下应该移除。这三条写清楚了，后面维护的人就不会乱改，也不会忘记清理。

另外，约束值的设定一定要留余量。我见过有人把 DMA 延迟约束设成刚好等于缓冲区撑满的时间，结果系统稍微一忙就欠载。留 2 到 3 倍余量是比较稳妥的做法，既能保证功能，又不会过度限制低功耗。

最后分享一个排查小技巧：如果怀疑某个约束导致功耗异常，可以临时把约束值改成一个很大的数（比如INT_MAX），看功耗是否恢复。如果恢复了，说明就是这个约束的问题，再顺着 owner 信息去找具体驱动。这个方法简单粗暴，但在紧急排查时非常有效。