3. Linux电源管理子系统总览
车载Linux的电源管理不是单一驱动，而是一套横跨“性能—功耗—热—时钟—电压”的协同子系统。它既要保证座舱、ADAS、T-Box等业务在需要时获得足够算力，又要在停车、待机、远程唤醒等场景下把静态电流压到最低。理解这套体系，关键是先建立一张“组件地图”：谁负责调频、谁负责休眠、谁负责按需上电、谁负责全局睡眠，以及它们如何通过Regulator、Clock、OPP这些底层资源耦合在一起。
核心原理：从“全局睡眠”到“按需省电”的分层
Linux电源管理可以按作用域分为三层。最上层是System PM，面向整机睡眠与唤醒，典型状态包括Suspend-to-RAM（STR）、Suspend-to-Disk（STD）和Runtime PM的全局配合。它通过/sys/power/state触发，依次执行设备挂起、系统级冻结、平台休眠和唤醒源配置。中间层是Runtime PM，面向单个设备在系统运行期间的按需上电与空闲下电，例如摄像头、以太网PHY、PCIe控制器在无业务时自动进入低功耗状态。最下层是CPUFreq与CPUIDLE，分别管理CPU的频率/电压和空闲状态深度，直接决定动态功耗与漏电功耗。
这三层不是孤立的。System PM进入睡眠前，会先让Runtime PM把各设备置于低功耗；CPUFreq在系统活跃时根据负载选择OPP；CPUIDLE在CPU空闲时选择C-State；而每一次频率或状态切换，都要通过Regulator调整电压、通过Clock门控时钟。因此，电源管理本质上是一个“策略—资源—硬件”的闭环。
核心组件与职责
- CPUFreq：调频框架，通过governor（schedutil、ondemand、performance、powersave）选择目标频率，再由driver写入硬件。车载场景常用schedutil，与调度器负载信号联动。
- CPUIDLE：空闲状态管理，决定CPU进入WFI、Retention、Powerdown等C-State的深度。深度越深，省电越多，但唤醒延迟越大。
- Runtime PM：设备级按需电源管理，核心是引用计数与
pm_runtime_get/put，配合autosuspend延迟下电。 - System PM：全局睡眠/唤醒框架，管理冻结进程、设备挂起顺序、唤醒源与唤醒锁。
- Regulator：电压/电流调节框架，负责LDO、DCDC、PMIC的输出使能与电压选择，支持电压域约束。
- Clock：时钟框架，负责PLL、分频器、门控时钟的使能与频率设置，是功耗的第一道开关。
- OPP：Operating Performance Point，描述“频率—电压”对及其可用性，是CPUFreq、Devfreq与Regulator之间的契约。
组件协作关系图
下图给出车载SoC中电源管理子系统的典型拓扑：上层策略通过OPP表驱动CPUFreq/Devfreq，CPUIDLE与Runtime PM分别处理CPU空闲和设备空闲，System PM统一编排全局睡眠；所有频率与状态切换最终落到Clock与Regulator，再作用于CPU、GPU、DDR、外设等硬件电源域。
方法流程：一次调频与一次睡眠的路径
以CPUFreq为例，当调度器发现CPU负载升高，schedutil governor会计算目标频率，通过OPP表找到对应的电压，再调用Regulator设置电压、Clock设置频率，最后写入CPU频率寄存器。若目标频率需要更高电压，必须先升压再升频；降频时则先降频再降压，避免欠压。这一顺序是电源管理中最容易出错的细节之一。
# 查看当前CPUFreq策略与频率
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
# 查看OPP表
cat /sys/kernel/debug/opp/opp_summary
# 查看Runtime PM状态
cat /sys/bus/platform/devices/*/power/runtime_status
# 触发系统睡眠
echo mem > /sys/power/stateSystem PM的流程则更复杂：用户写入mem后，内核先冻结用户进程与内核线程，再按设备树顺序调用各设备的suspend回调；Runtime PM会把活跃设备逐个下电；随后关闭非唤醒时钟与稳压器，配置唤醒源，最后CPU进入低功耗状态。唤醒时按相反顺序恢复。若某个设备未正确实现Runtime PM，System PM可能因引用计数未归零而失败。
案例与场景：车载座舱的待机省电
某座舱项目要求熄火后30分钟内静态电流低于5mA。排查发现，系统进入STR后电流仍为28mA。通过cat /sys/kernel/debug/pm_genpd/pm_genpd_summary发现Camera电源域未关闭，原因是Camera驱动在probe时调用了pm_runtime_get_sync但未配对pm_runtime_put，导致引用计数始终为1。修复后，Camera在无预览时自动进入Runtime Suspend，STR电流降至4.2mA。这个案例说明：System PM的省电效果，高度依赖Runtime PM的正确性。
常见误区与复盘清单
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 只调CPUFreq，忽略OPP电压 | 高频欠压，系统不稳定 | 通过OPP表联动Regulator，先升压后升频 |
| Runtime PM引用计数不配对 | 设备无法下电，待机电流偏高 | get/put成对，使用autosuspend |
| CPUIDLE只选最深状态 | 唤醒延迟大，音频卡顿 | 按业务延迟约束选择C-State |
| System PM忽略唤醒源配置 | 无法远程唤醒或误唤醒 | 明确enable_irq_wake与唤醒锁 |
| Clock未门控就关Regulator | 模块异常或漏电 | 先关Clock，再关Regulator |
/sys/kernel/debug/pm_genpd、/sys/kernel/debug/opp、/sys/power/wakeup_count和powertop定位“谁在阻止睡眠”。在车载场景中，还要关注CAN、LIN、以太网PHY等唤醒源的误触发。总体来看，CPUFreq、CPUIDLE、Runtime PM、System PM、Regulator、Clock、OPP共同构成Linux电源管理的骨架。掌握它们之间的依赖顺序与作用域，才能在车载项目中既保住性能，又守住静态电流指标。