电源管理不是“省电开关”，而是一场精密的软硬共舞
你有没有遇到过这样的问题：
- 设备待机一夜，电量掉了15%？
- 游戏刚打到高潮，画面突然卡顿两秒，温度还烫手？
- 同一款固件烧进两块板子，一块续航三天，另一块撑不过一天？
这些表象背后，往往不是电池坏了、也不是代码有bug，而是电源管理这条“隐性神经”没被真正唤醒。它不像UART那样接线就能通信，也不像GPIO那样写个寄存器就亮灯——它藏在时钟树的毛细血管里，在电压轨的毫伏波动中，在CPU进入WFI前那0.3微秒的犹豫里。
今天，我们不讲PPT式的概念罗列，也不堆砌数据手册里的参数表格。我们从一个真实调试现场出发，一层层剥开现代嵌入式系统中那套看不见却无处不在的功耗调控机制：它如何决策？怎么执行？哪里容易踩坑？又该如何验证？
DVFS：不是调频，是给芯片“配呼吸节奏”
很多人把DVFS理解成“CPU太热了就降频”，这就像说“人累了就少喘气”一样危险——喘得太浅会缺氧，喘得太急会换气过度。DVFS真正的意义，是为芯片匹配一条动态、安全、可预测的功耗路径。
它到底在调什么？
核心就两个动作：
-改频率（f）：通过PLL或分频器调整时钟源，影响指令吞吐能力；
-调电压（V）：通过PMIC或片上LDO输出对应电压，支撑该频率下的稳定翻转。
但关键在于：V和f不能随便组合。CMOS电路有个铁律——电压不够，再低的频率也跑不稳；电压太高，哪怕空闲也在白烧漏电。所以SoC厂商会预先烧录一张OPP表（Operating Performance Point），比如：
| 索引 | 频率（MHz） | 电压（V） | 典型场景 |
|---|---|---|---|
| 0 | 2400 | 0.95 | AI推理峰值 |
| 1 | 1600 | 0.82 | 视频解码 |
| 2 | 800 | 0.68 | 后台消息同步 |
| 3 | 400 | 0.60 | 待机监听传感器 |
这张表不是理论值，而是芯片在量产批次、高低温、不同老化程度下实测验证过的“安全区”。跳过它直接写寄存器？轻则偶发hang死，重则加速老化甚至烧毁IO。
谁在做决定？又怎么落地？
在Linux系统中，这个决策链路是这样的：
应用负载 → kernel scheduler
