GPU DVFS调频机制与排障：25ms采样、双阈值、OPP表

简介：这份资料围绕移动设备GPU动态电压频率调整（GPU DVFS）展开，面向嵌入式驱动开发、功耗优化与图形性能调优的初中级工程师，帮助理解GPU频率与电压如何随负载协同变化。内容涉及负载阈值判断、频率档位与电压表、时钟与PMIC协作、PTP-OD微调以及热限频回调等环节，并重点说明负载超过50%时升频、低于30%时降频的决策逻辑，以及升频前等待PMIC稳定的延时处理。资源为1个PDF文件，压缩包约681KB，篇幅紧凑，适合作为随手查阅的技术笔记或培训讲义底稿。已有680人学习下载，说明其在相关工程实践中有一定参考价值。读者可从中获得MT6755平台上从728MHz到350MHz各频率档位与电压组合的对照关系，以及驱动侧调频调压流程的整体框架，便于排查功耗异常、理解温控与频率限制的交互方式，并为后续移植或调试同类方案提供思路参考。

1. 负载不是「用量」，是「欠账」：GPU DVFS 到底在调什么

大多数人第一次接触 GPU DVFS，会默认它在做一件很直觉的事：GPU 越忙，频率越高。真正把这个机制拆开会发现并非如此——驱动手里并不存在一个「当前 GPU 使用率」的实时仪表，它每一轮只做一件事：把过去 25ms 里 GPU 处于忙碌状态的时间累加起来，除以窗口长度，得到一个 0 到 1 之间的比例，再拿这个比例去和两个阈值比较。所以它调的其实是「上一段时间的欠账」，而非「此刻的需求」。这个设计要解决的是移动设备上最现实的矛盾：渲染负载突发且抖动，而频率和电压的每一次跳变都要付出功耗、延时和稳定性代价。搞懂这套离散档位、双阈值、先压后频的机制，才能明白为什么同一颗芯片上，有的重载场景稳得住，有的却既掉帧又发烫。下面按「采样怎么算、档位怎么选、电压时序为什么这么排、硬件到底等多久」的顺序往下拆。

2. 25ms 采样与 50%/30% 双阈值：控制循环为什么长这样

这套机制的核心是一个定时触发的控制循环，而不是一个事件驱动的响应函数。它每 25ms 结算一次，算出负载，然后最多调整一档。理解了这三条约束（窗口长度、双阈值、单步爬坡），基本就理解了 GPU 调频的全部性格。

2.1 采样窗口：25ms 在权衡什么

窗口太短，单帧的抖动会被当成真实负载变化，频率在相邻两轮之间来回跳，用户感知到的就是帧率锯齿和功耗毛刺；窗口太长，重载场景启动时驱动反应不过来，先掉一波帧，等爬上去画面已经过去了。25ms 这个量级大致落在一到两帧之间：60fps 下一帧 16.7ms，30fps 下一帧 33ms，取中间值意味着单帧尖峰会被平滑掉，而持续两帧以上的负载抬升能被捕捉到。

还有一层容易被忽略的细节：这个定时器跟渲染帧并不锁相。它不知道「这一帧画完了」，只知道「时间到了」。好处是驱动不需要和图形栈做同步，代价是采样点落在帧中间时，忙碌时间的统计会有误差。常见的实现思路是用 GPU 硬件计数器累加忙碌周期，而不是靠软件打点，这样即使采样窗口跨越帧边界，统计出来的仍然是真实占用时间。这也解释了为什么这类负载值读出来总是介于 0 和 1 之间的小数，而不是某种百分比整数。

从控制论角度看，25ms 是一个采样周期，它的倒数就是这套闭环的控制频率——40Hz。对于一个以毫秒级响应为目标的场景，这个频率并不高，所以策略上必须靠「每次只走一档」来避免超调。如果一轮就允许跨三档，那窗口内的负载波动会被放大成频率的大幅震荡，反而更糟。

2.2 双阈值：50% 升、30% 降，中间 20% 是死区

如果只用一个阈值，比如「负载高于 40% 就升、低于 40% 就降」，那么负载恰好停在 40% 附近时，频率会在两档之间以 40Hz 的频率来回跳。这种抖动在示波器上看是方波，在用户手上看就是耗电飙升加机身发热，因为每一次跨电压域的跳变都要付 PMIC 建立时间。

双阈值就是标准的滞回（hysteresis）控制：超过 50% 才考虑升，低于 30% 才考虑降，中间那 20% 是死区，保持当前档位不动。死区越宽，频率越稳，但对负载变化的跟随越迟钝；死区越窄，跟随越紧，但抖动风险上升。20% 这个宽度是经验值，本质上是在「响应速度」和「跳变次数」之间画了一条线。

再叠加上「每轮最多一档」的斜率限制，就得到一个很有特点的行为：负载从 20% 突然冲到 90%，频率不会一步到位，而是每 25ms 爬一档。八档表爬满需要将近 200ms。这就是为什么冷启动一个大场景时，前几帧总是不太稳——不是驱动算错了，是它按设计就是这么慢。想改这个行为，要么缩短采样窗口，要么允许单轮多档，但两者都会把抖动风险带回来。

2.3 八档表与三档策略：表是全集，策略是子集

OPP 表里通常列了八档：728、650、598、520、468、429、390、351 MHz。但驱动运行时实际只会在其中三档之间跳，常见的是 728、520、351 这个组合。这个不对称是理解整套设计的关键：表是硬件能力的全集，给固定频率调试、热控策略、不同产品配置用；而运行时策略只取子集，是为了减少跳变次数。

把表按电压列重新排一下，规律就出来了：

三个电压值把八档切成三段。这意味着在同一个电压段内部换频率，PMIC 根本不用动，只需要改 PLL 分频，跳变成本极低；而跨电压段换频率，才需要走一整套「调压—等待—跳频」的流程。所以真正的「档位边界」不是频率边界，是电压域边界。三档策略正好对应三个电压域，每次跳变都跨域，看起来很亏，但因为跳变次数被压到最少，总体收益反而是正的。如果取八档，虽然有些跳变是「免费」的，但跳变频率会上去，稳定性反而下降。

这条推断也解释了另一个现象：为什么高负载场景下频率表看起来「只用了最高档」。因为一旦进了 1.125V 这个域，598 和 728 之间的切换几乎无成本，策略上没必要在段内做精细调节，直接顶到最高更简单。

2.4 用一段控制循环把决策讲清

把上面的规则写成伪代码，结构就很清楚了。注意这里用的是语义化命名，原厂接口通常带厂商前缀，去前缀后逻辑不变：

SAMPLE_MS = 25 # 采样窗口，驱动每 25ms 结算一次 UP_THRESHOLD = 0.50 # 负载高于此值，尝试升一档 DOWN_THRESHOLD = 0.30 # 负载低于此值，尝试降一档 MAX_STEP = 1 # 单轮最多跨几档，斜率限制 def dvfs_tick(now_ms, cur_level): if now_ms - last_sample < SAMPLE_MS: return cur_level # 未到结算点，保持不动 busy = gpu_busy_us_in_window() # 硬件计数器累加的忙碌时间 load = busy / ((now_ms - last_sample) * 1000.0) # 归一化到 0..1 if load > UP_THRESHOLD: next_level = min(cur_level + MAX_STEP, OPP_MAX) # 升一档，封顶 return apply_opp(next_level) # 走调压调频流程 if load < DOWN_THRESHOLD: next_level = max(cur_level - MAX_STEP, OPP_MIN) # 降一档，保底 return apply_opp(next_level) return cur_level # 落在死区，维持现状

load是核心输入，它由「忙碌微秒数 ÷ 窗口微秒数」得出，量纲归一化之后才能和阈值直接比较。MAX_STEP设成 1 是斜率限制，改成 2 或 3 会让爬坡更快、但抖动更强。OPP_MAX/OPP_MIN是策略层的上下界，通常由opp_max_freq这类接口在运行时改写，这也是后面排查问题时最常看的地方。apply_opp()才是真正碰硬件的函数，它的内部时序决定了这套机制安不安全，下一章专门拆它。

3. OPP 表与电压-频率配对：升压为什么必须先于升频

控制循环只决定「去哪一档」，真正危险的是「怎么过去」。频率和电压是一对绑定关系：频率越高，电路在单位时间内翻转越快，需要更高的电压才能保证信号在时钟周期内稳定建立。这条物理约束直接决定了升频和降频的时序不对称。

3.1 OPP 表的每一行是什么

一条 OPP 记录至少有三个字段：目标频率、目标电压、估算功耗。写成结构体大致是这样：

struct gpu_opp { unsigned int freq_khz; /* 目标频率，单位 kHz，如 728000 */ unsigned int volt_uv; /* 目标电压，单位 uV，如 1125000 */ unsigned int power_mw; /* 功耗模型估算值，热控和功率上限用 */ unsigned int level; /* 档位序号，0 为最低档 */ };

volt_uv用微伏而不是毫伏，是因为调压精度要求到毫伏以下——一颗芯片的电压余量往往只有几十毫伏，用毫伏做单位会把精度吃掉。power_mw通常不是实测值，而是由频率和电压平方的关系估算出来的模型值，它的用途不是显示，而是给热控算「这个档位还能跑多久」。

表里写的电压往往不是绝对值，而是「1.125 - delta」这种形式。这个 delta 就是下一节要讲的动态补偿量，它让同一条 OPP 表能适配不同工艺批次的芯片。

3.2 升频：先升压、等建立、再跳频

升频的正确顺序只有一种。如果先跳频再升压，中间会出现一个「高频 + 低压」的窗口，这个窗口里电路的时序余量为负，轻则计算出错、渲染花屏，重则直接挂死。所以驱动必须先把电压顶上去，等 PMIC 输出真正稳定，再让 PLL 切到新频率。

int gpufreq_target(unsigned int target_khz) { struct gpu_opp *new = opp_find_by_freq(target_khz); if (!new) return -EINVAL; if (new->freq_khz > cur->freq_khz) { /* 升频路径：电压先行 */ pmic_set_voltage(new->volt_uv); /* 1. 抬高电压 */ udelay(settle_us(new->volt_uv - cur->volt_uv)); /* 2. 等 PMIC 建立 */ clk_set_rate(gpu_clk, new->freq_khz * 1000); /* 3. 再切频率 */ } else { /* 降频路径：频率先行 */ clk_set_rate(gpu_clk, new->freq_khz * 1000); /* 1. 先降频率 */ pmic_set_voltage(new->volt_uv); /* 2. 再降电压 */ udelay(settle_us(cur->volt_uv - new->volt_uv)); /* 3. 等电压回落 */ } cur = new; return 0; }

三步的顺序不是风格问题，是安全边界。settle_us()的入参是电压差，因为建立时间和电压变化量成正比，这个换算关系下一章展开。udelay()是忙等，不能用可睡眠的延时，因为这段代码可能跑在不可睡眠的上下文里，而且等待时间只有十几微秒，调度器切一次上下文都不止这个数。

3.3 降频：先降频、再降压，顺序必须反过来

降频时如果先降压，同样会出现「低压 + 高频」的违例窗口，风险完全一样。所以降频路径必须先把频率降下来，让电路在宽松的时序下运行，再把电压收回去。这就是为什么升序和降序在代码里是两支不对称的分支，而不是一段对称的「设置电压、设置频率」。

这条规则有个容易翻车的变体：如果新旧两档在同一个电压域内（比如 728 降到 650，电压都是 1.125-delta），那么电压根本不用动，只需要改 PLL。这时候settle_us(0)应该返回 0，跳过等待。如果代码没做这个判断，每次段内切换都白等十几微秒，累积起来在重载场景里就是可观的浪费。判断「是否需要调压」应该放在pmic_set_voltage之前，而不是指望 PMIC 驱动自己去重。

3.4 PTP-OD：在同一条 OPP 上微调电压

同一条 OPP 表对不同芯片不一定最优。同一批 wafer 上，有的 die 漏电大、需要更高电压才稳，有的 die 体质好、可以降压省电。PTP-OD 就是干这个的：它不改频率，只根据芯片自身的工艺特征微调 VGPU。

对应到接口上，是一个独立的gpufreq_update_volt()，它的入参不是频率而是电压修正值，调用时机也和控制循环解耦——可以在开机校准阶段跑一次，也可以在温度变化时周期性刷新。这就是表里那个- delta的来源：基础电压减去一个运行时算出来的补偿量，最终写进 PMIC 寄存器的是补偿后的值。

这里有个设计取舍值得注意：PTP-OD 改的是「同一条 OPP 上的电压」，而不是「换一条 OPP」。如果把它做成换表，那每次校准都会触发一次跨域跳变，代价太大。做成电压微调，就可以在不惊动频率策略的前提下把功耗抠出来。代价是 OPP 表本身不再是唯一真相，实际电压要看运行时变量，这一点在排查时会咬人，第 5 章会专门讲。

4. PMIC 建立延时：0.5us/6.25mV 这个斜率是怎么用的

「延时 0.5us/6.25mV」这句话第一次看很容易读错，以为是一次固定延时。它其实是一个斜率：电压每变化 6.25mV，需要等 0.5 微秒。真实等待时间要用电压差去乘。

4.1 为什么延时是线性的

PMIC 的输出电压靠反馈环路调节，环路里有一个输出电容。电压变化量越大，电容充放电到新稳态所需的时间越长，在环路带宽固定的前提下，这个关系近似线性。所以厂商给出的不是「一次跳变等多久」，而是「每毫伏等多久」，驱动自己做乘法。这也解释了为什么单位写成「us/mV」而不是「us」——它描述的是器件的转换速率，不是某个具体动作的耗时。

6.25mV 这个步长本身也有讲究：它对应 PMIC 电压寄存器的步进精度。换句话说，0.5us 大致就是「调一格寄存器、等它稳住」的时间。这个数字是从硬件手册里来的，写死在驱动里，换一颗 PMIC 就得换一组常数。

4.2 算一次真实的跳变要等多久

拿最低档跳到最高档算一遍。351MHz 对应 0.93125V，728MHz 对应 1.125V 减去 delta。先忽略 delta，电压差是 1.125 - 0.93125 = 0.19375V，也就是 193.75mV。

按 6.25mV 一格算，193.75 / 6.25 = 31 格；31 × 0.5us = 15.5us。

这个数字很关键：15.5 微秒相对于 25 毫秒的采样窗口，占比不到千分之一。所以在当前参数下，PMIC 建立时间完全不是瓶颈，驱动里那几行udelay加起来也感知不到。但如果哪天把采样窗口缩到 200 微秒级别去做更激进的调频，15.5us 就占到了近 8%，这时调压延时会变成必须优化的对象——要么换成更快的 PMIC，要么把跨域跳变合并成批处理。

实际代码里settle_us()大致是这样：

/* 每 6.25mV 需要 0.5us，入参单位是 uV，所以要除以 6250 */ static inline unsigned int settle_us(unsigned int delta_uv) { if (delta_uv == 0) return 0; /* 同电压域，无需等待 */ return (delta_uv / 6250) / 2; /* 0.5us = 1/2 us，整数除避免浮点 */ }

用整数除是刻意的：内核态不方便用浮点，而且这里的精度要求本来就不高，少算半微秒比引入浮点运算划算。delta_uv == 0的短路分支就是 3.3 节提到的那条优化，段内跳变直接跳过等待。

4.3 时钟源切换：改频率不是改一个数字

频率由 PLL 决定，改频率就是改 PLL 的倍频/分频寄存器。但 PLL 在改参数的过程中会失锁，输出会短暂停振或者跳到不确定频率。如果 GPU 直接挂在这个 PLL 上，这段时间里整个图形流水线就是在跑飞。

常见的做法是「hopping」：先把 GPU 的时钟源切到一个稳定的备用时钟（晶振或者另一路常开的 PLL），在备用时钟上跑着，然后去改目标 PLL 的参数，等它锁定，再切回来。整个过程里 GPU 一直在跑，只是中间那段时间频率低了。这也是为什么升频的收益不是瞬间到账的——跳变本身有成本，成本大小取决于这段「低速运行」有多长。

理解了这一点，就能明白为什么策略层要尽量减少跳变次数。不是因为调压慢（15.5us 可以忽略），而是因为每次跳频都要经历一次时钟源切换，这段时间里的性能损失会累积。三档策略的价值在这里体现得最清楚。

4.4 软硬件边界：驱动只做决策，执行交给谁

把整条链路摊开，职责划分很干净：GPU 驱动负责统计负载、跑控制循环、决定目标档位、编排时序；MMPLL 负责把频率真正变过去；PMIC 负责把电压真正变过去。驱动不直接碰模拟电路，它只是往两个外设的寄存器里写值，然后等。

这条边界带来一个很重要的推论：所有「频率不对」的问题，要么出在决策层（负载算错、阈值配错、档位被限制），要么出在执行层（PLL 没切过去、PMIC 没写进去）。排查时先分清是哪一层，比盲目改参数有效得多。下一章的几条踩坑记录，基本都是按这个分类展开的。

5. 排查：GPU 调频不生效时的几类常见坑

这套机制的接口都暴露在/proc/gpufreq/下面，看起来很直观，但真出问题时，症状和原因往往对不上。下面几条是按「现象 → 原因 → 解决」整理的，基本覆盖了实际会遇到的大部分情况。

5.1 现象：频率完全不跟负载走

现象很直接：跑重载场景，读cat /proc/gpufreq/gpufreq_var_dump，当前频率一直趴在最低档不动，负载再高也不升。

原因通常是策略被关掉了，或者上限被压死了。DVFS 有一个总开关gpufreq_state，写 0 之后控制循环还在跑，但决策结果不会被执行，频率就固定在最后一次生效的值上。另一个更隐蔽的原因是gpufreq_opp_max_freq被写成了很低的值——它的语义是「驱动在不超过这个频率的档位里自己挑」，如果被写成 351000，那不管负载多高，选出来的都是 351MHz。

解决要按顺序来：先cat /proc/gpufreq/gpufreq_state确认是 1；再cat /proc/gpufreq/gpufreq_opp_freq看有没有被人为钉死；最后看gpufreq_opp_max_freq的上限。这三者优先级是固定频率 > 频率上限 > 动态策略，任何一层被改写，下层的决策都白算。我一般会先打个快照把三个值一起读出来，避免改了一个又被另一个盖住。

5.2 现象：钉死最高频后，帧率反而更差

为了排查掉帧，很多人第一反应是echo 728000 > /proc/gpufreq/gpufreq_opp_freq，把频率钉在最高档。结果发现帧率没提升，机身还更烫了，跑久了甚至比动态调频还卡。

原因是钉死频率绕过了整条负载判断链路，GPU 长时间跑在最高电压域，功耗直线上升，热控很快介入。热控不是去改频率，而是设一个功率上限，驱动在下一个采样点发现预算不够，会把档位往下压——于是你钉的频率被系统自己推翻了，而且推翻的过程比动态策略更粗暴，因为没有死区缓冲，容易在两个状态之间来回。另外，最高频不等于最高能效，很多场景里 GPU 是在等内存或等垂直同步，把核心频率顶满只是白烧电。

解决是用「限上限」代替「钉死」：echo 598000 > /proc/gpufreq/gpufreq_opp_max_freq，让驱动在不超过这个频率的范围里自己挑。这样既压住了峰值功耗，又保留了负载低时降频省电的能力。真要钉死做基准测试，就得同时把热控的功率上限放开，并且明确知道这是一次性测试状态，测完echo 0恢复。

5.3 现象：热控触发了，频率却纹丝不动

看日志能确认热控回调进来了，gpufreq_limited_power也被改写了，但gpufreq_var_dump里的频率没有任何变化，设备照样烫。

原因在于热控和调频是两条链路，中间隔着一个采样周期。热控做的是「设置 GPU 功率上限」，它不直接调gpufreq_target，而是通过回调通知驱动；驱动要等到下一个 25ms 结算点，才会把这个新预算纳入决策。所以从热控触发到频率真正下降，存在几十毫秒的滞后。如果负载恰好卡在死区里（30% 到 50% 之间），驱动判断「不需要动」，频率就真的不动，但功率预算已经被压低了，这个矛盾会一直挂着。

解决分两步：先cat /proc/gpufreq/gpufreq_power_dump确认功率模型里当前档位的估算功耗是否真的超过了limited_power设的值——如果没超，驱动不动是对的，问题在热控阈值设得太保守；如果超了却没降，那要看是不是被opp_freq钉死了，钉死状态下功率上限是压不动频率的，这是一对会打架的开关。

5.4 现象：改了 OPP 表里的电压，实测没变化

照着表把某一档的电压从 1.0V 改成 0.95V，重新烧录，读gpufreq_opp_dump确认表确实变了，但实测电流一点没降。

原因多半是 PTP-OD 在运行时把静态表覆盖了。表里的电压只是基础值，最终写进 PMIC 的是「基础值 - delta」，delta 由芯片自身的工艺校准算出来。你改表，改的是被减数，delta 没变，最终值可能只动了一点点，甚至因为校准逻辑里有钳位而被吃掉。另一种情况是电压调整有下限保护，低于某个值直接拒绝写入，但接口不返回错误，看起来像「改了没生效」。

解决是去看运行时变量而不是静态表：cat /proc/gpufreq/gpufreq_var_dump里通常能看到当前实际使用的电压值和补偿量，那才是真相。要做电压相关的实验，得先把 PTP-OD 的影响隔离掉，否则就是在跟一个会自动修正的系统较劲。这条是血泪经验——静态表是「设计意图」，运行时变量才是「实际发生」。

5.5 现象：开了调试日志，看不到跳变过程

echo 1 > /proc/gpufreq/gpufreq_debug之后跑了一遍重载场景，日志里只有零星几行，看不到预期的爬坡记录。

原因往往不是日志没开，而是压根没发生跳变。控制循环每 25ms 才结算一次，如果负载一直在死区里晃，或者场景持续时间太短（几百毫秒），那可能只够走两三档，日志自然稀疏。还有一种情况是日志级别只记录「决策结果」不记录「决策依据」，你看到频率变了，但不知道当时的负载是多少，没法判断这个决策对不对。

解决是把gpufreq_var_dump和gpufreq_debug配合起来看：前者给当前状态的快照，后者给变化的时间线，两边对时间戳才能还原出「当时负载多少、阈值判断走了哪条分支」。要复现问题，最好用能持续压满载的场景跑够几秒，短促的操作根本触发不了完整的爬坡过程。

6. 设计取舍：把决策权留在驱动，把预算权交给热控

这套机制里最值得琢磨的一个决定是：热控不直接改频率，只设功率上限。表面上看这是多绕了一步——热控明明可以直接把频率压到 351MHz，为什么要通过回调让驱动自己算？

因为频率不是可加的量，功率才是。同一个功率预算下，不同的负载特征需要不同的频率：一个持续满载的渲染任务，降频能实打实省功率；一个突发式的短任务，降频只会让它跑更久，总能耗反而可能上升。热控站在全局视角，它知道整颗芯片还剩多少热预算，但它不知道 GPU 此刻在干什么。驱动知道，所以决策权留在驱动，热控只负责给边界。这个分工让两套逻辑可以独立演进：热控策略换了，驱动不用改；调频算法换了，热控也不用改。

三种限制手段的定位也能看出同样的思路：

钉死频率是最强的，也是最危险的，因为它把闭环切成开环，系统失去自适应能力；限最高频是温和的，保留了闭环但收窄了搜索空间；限功率是最抽象的，它连频率都不提，只说「你只能用这么多」。这三种手段的强弱排序，本质上就是「干预程度」的排序。设计良好的系统应该尽量用弱手段，只在调试时动用强手段。

这套设计也有它的代价。功率模型是估算的，power_mw不准的时候，热控的预算和驱动的实际消耗会对不上，表现为「明明没超预算却降频」或者「超了还不降」。档位只有三档，能效曲线被粗粒度化了，中间那些最省电的工作点用不上。25ms 的采样窗口对交互式场景够用，但对云游戏这种要求帧级稳定的场景就偏慢。这些都是取舍，不是缺陷——把窗口缩到 5ms、把档位加到八档，抖动和功耗会立刻反噬。

从那以后我每次碰调频相关的问题，都会强制先走一遍「state → opp_freq → opp_max_freq → var_dump」这四个节点，把当前处于哪种干预状态确认清楚，再去看负载和阈值。因为绝大多数「调频坏了」的现场，最后都发现是某个开关被人手动改过，而不是算法本身出了问题。希望这套拆解帮到你，下次再看到频率不听话，至少知道该先怀疑哪一层。

本文还有配套的精品资源，点击获取