企业官网建设流程全解析

搞ARM SoC的电源管理，很多时候像在走钢丝。既要满足应用场景下的极致性能，又要控制住功耗发热，尤其到了ARMv9/v8时代，系统级电源管理架构早已不是简单的“睡不睡、醒不醒”问题，而是一整套从硬件到固件再到OS的协同设计。这篇文章我会把ARMv9/v8体系下的Power Management System Architecture拆开，从PSCI、DVFS、CPUidle到设备树配置、SCMI协议、系统Suspend/Resume，结合自己做过的项目和一些踩坑经历，尽量讲得通俗、实操。

基于标题“[A-41]ARMv9/v8-电源管理系统架构(Power Management System Architecture)”，这确实是个系统性的工程话题，适合嵌入式底层开发、BSP工程师、以及对SoC功耗调优感兴趣的读者。我会在这里把整体设计思路、关键节点、代码层面的配置方法以及常见的调试排障经验整理出来。

1. 电源管理系统架构的整体设计与核心思路

1.1 为什么要上升到“架构”层面

很多人对电源管理的理解停留在“CPU空闲了就WFI”或者“跑个cpufreq调频”的层面。这些确实属于电源管理的一部分，但在ARMv9/v8体系下，电源管理的范围要宽得多。现代SoC里CPU只是消耗主体之一，GPU、NPU、DDR、互连总线、外设的电源域和时钟域，都需要在运行时动态管理。再加上多核异构、大小核拓扑、安全与非安全世界的切换，电源管理必须有一套可以扩展、可管理、可迁移的架构，而不是靠驱动里写死几个脚本。

ARM的电源管理系统架构，就是围绕“状态定义、状态迁移、资源划分、接口协议、系统集成”这几个维度搭建的体系。它在硬件上有电源域（Power Domain）、时钟域（Clock Domain）、电压轨（Voltage Rail）的概念，在固件层有PSCI和SCMI，在内核侧有CPUidle、Cpufreq、Devfreq、Perf Domain等框架，形成一个完整的垂直栈。

理解这套架构，首先要建立两个视角：一是分级视角，也就是从电源状态到硬件动作之间要过多少层抽象；二是角色视角，也就是谁决定进入低功耗状态、谁执行这个动作、谁感知功耗变化。整个系统的优雅程度，取决于这几层之间协作的严密性。

1.2 从ARMv8到ARMv9，电源架构演进了什么

ARMv8时代，电源管理的主要载体是PSCI，它定义了一套标准的电源管理调用接口，把CPU的开关、挂起、系统重启等操作从特权软件下沉到EL3固件。这样做的直接好处是：操作系统不再需要知道具体的寄存器细节，只需要通过SMC指令调用标准函数即可。

到了ARMv9，基础没变，但在安全性、弹性和虚拟化支持上提出了更高要求。比如FF-A（Firmware Framework for Armv8-A/Armv9-A）统一了不同固件组件之间的通信方式，电源管理相关的消息传递也可以跑在FF-A的框架之上。与此同时，SCMI（System Control and Management Interface）被更广泛地用于与平台管理处理器（SCP）通信，管理DVFS、时钟和电源域。ARMv9还强调对RME（Realm Management Extension）支持下的资源隔离，电源管理的状态机也需要为世界切换留出正确决策空间。

1.3 架构中各方角色的分工

简单来讲，电源管理架构中有三个主要参与者。

• OS/内核：负责策略层面的决策，比如根据负载决定要不要调频、要不要进入idle、要进多深的idle。内核的Linux cpuidle和cpufreq框架是策略实现的核心。
• 固件/EL3：负责机制层面的执行，包括PSCI调用的处理、CPU hotplug、挂起流程、系统重启等。TF-A（Trusted Firmware-A）是这一层最常见的实现。
• 平台管理处理器SCP/MCU：负责真正的硬件微操作，包括电压调节、时钟切换、电源域门控，甚至包括一些热管理策略。它通过SCMI与AP侧通信。

这三者之间，典型的通信路径是：内核cstate决策->CPUidle调PSCI suspend->EL3固件处理->通过SCMI通知SCP->SCP操作寄存器完成下电/上电。任何一层出错、时序不对或者接口约定不匹配，都会直接表现为功耗异常、卡死或者系统无法唤醒。

2. PSCI与CPU低功耗状态机制的底层原理

2.1 PSCI：电源管理的“系统调用”

PSCI的全称是Power State Coordination Interface。在ARMv7时代，不同的SoC有各自的CPU_OFF、CPU_ON实现方式，Linux kernel要适配各种平台特性，很繁琐。ARMv8后整机统一规定使用PSCI作为电源管理接口，从0.2到1.0、1.1，功能范围逐步扩大。

PSCI定义了几个核心调用，最常见的是：

• CPU_SUSPEND
• CPU_OFF
• CPU_ON
• AFFINITY_INFO
• SYSTEM_SUSPEND
• SYSTEM_OFF
• SYSTEM_RESET

其中CPU_SUSPEND可以附带一个电源状态参数（power_state），描述要进入的层级别（core级、cluster级、system级），以及状态类型（standby、retention、power down等）。这里要特别注意：PSCI协议规定，当某个core调用CPU_SUSPEND进入断电状态后，它自己不能主动恢复执行，必须依赖其他在线core或者硬件中断唤醒机制。

实际项目中，我经常看到有人在移植新板卡时，直接把其他平台的PSCI节点复制过来，结果发现idle进不去或者唤醒后系统卡死。原因往往就是电源状态参数里的亲和层级（Affinity Level）和状态ID跟当前平台的硬件电源域拓扑不匹配。

2.2 CPUidle框架与cstate状态等级

Linux内核的CPUidle框架负责管理CPU的空闲状态，也就是cstate。在ARM平台上，每个cstate对应一个底层的PSCI power state。

以常见的设计为例，一个ARMv8/ARMv9四核CPU可能会定义这几个cstate：

• C1（WFI）：只执行等待中断指令，实际上不会真正断电，主要是省指令流功耗。
• C2（core power down）：该CPU核心掉电，但L2和cluster还保持供电。
• C3（cluster power down）：整个cluster掉电，L2可能保持或掉电，具体看硬件设计。
• C6（system power down）：整个系统挂起，内存可能进入自刷新。

CPUidle框架会根据内核的调度空闲情况、唤醒延迟容忍度以及目标状态的residency要求，动态选择进入哪个cstate。这里有个关键参数叫target_residency，意思是必须预估自己能空闲多久，如果空闲时间小于这个阈值，进入更深状态反而是亏本的，因为唤醒开销比省下的功耗还大。

2.3 WFI与WFET的细节不可忽视

在ARMv8/v9体系里，WFI（Wait For Interrupt）是最基础的低功耗等待指令，但不代表WFI就是不耗电。如果在cpu_ops和idle管理中出现问题，比如把中断挂在了一个已断电的GIC redistributor上，那么核心睡着之后就再也醒不过来了。

ARMv8.2引入了WFET（Wait For Event with Timeout），ARMv9也继续沿用类似机制。这类指令允许带一个超时时间，在某些场景下，比裸用WFI更安全。比如在CPU进入深度idle之前，想要确保唤醒中断源有效，用超时机制兜底会减少死等风险。我在项目里通常建议：新平台刚开始适配时，先保证C1正确，再逐步尝试C2/C3，不要一上来就追最深状态。

2.4 唤醒源与电源域的一致性

CPU要进入断电状态，硬件上必须保证负责唤醒这个核的中断控制器（GIC）仍然能工作，特别是GIC Redistributor的电源域，不能跟着CPU core一起被关掉。这是ARM电源管理里非常容易踩坑的点。

有些SoC的GIC redistributor供电属于core power domain，有些属于separate always-on domain。如果设计不当，可能出现：系统深度idle时，GIC redistributor掉电，外部中断无法送达，核心永远无法唤醒，最终触发看门狗。排查这种问题，要仔细核对SoC的电源域划分图，同时配合trace工具观察进入idle前后的GIC寄存器访问是否正常。

3. DVFS调频调压与OPP表的设计落地

3.1 频率与电压的不解之缘

动态电压频率调整（DVFS）几乎已经是所有ARM SoC的标配。DVFS的核心思想是：性能需求低时，降低CPU/GPU频率和电压，功耗按电压的平方关系下降，收益极其明显。

但频率和电压不是独立变化的。频率提高，供电电压也要相应提高，以保证时序收敛。因此SoC厂商会提供一组“工作点”，每个工作点包括频率、电压、可能还有额外的性能/泄漏补偿参数，这组工作点就是OPP（Operating Performance Point）。

在内核里，OPP表通常定义在设备树中，通过operating-points-v2节点描述。比如：

cpu0_opp_table: opp-table-0 { compatible = "operating-points-v2"; opp-shared; opp-1000000000 { opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <850000>; opp-supported-hw = <0x0f>; }; opp-1800000000 { opp-hz = /bits/ 64 <1800000000>; opp-microvolt = <975000>; opp-supported-hw = <0x0f>; }; };

这里opp-supported-hw做硬件版本控制很重要。不同硅片版本（revision）的SoC，可支持的频率点有差异，这块表如果配错，将会导致硅片在超出规格的电压/频率下运行，轻则稳定性问题，重则烧毁芯片。

3.2 cpufreq框架中的驱动选择与调频策略

Linux的cpufreq框架分两个方向：一个是调整频率的平台相关部分（cpufreq driver），一个是指挥如何调的策略部分（cpufreq governor）。

在ARM平台上，cpufreq driver通常使用cpufreq-dt驱动，它会从设备树解析CPU的OPP表，并通过时钟框架和regulator框架去调节时钟频率与供电电压。另一个常见做法是通过SCMI接口让SCP执行调频，这时使用scmi-cpufreq或者scmi-cpufreq的变种。

governor方面，从旧版的interactive、ondemand，到现在主流的schedutil。schedutil与调度器直接集成，可以根据每个CPU的利用率实时计算目标频率，响应快，能效表现通常更优，也是目前在ARM大小核平台上比较推荐的默认governor。

在调试DVFS问题时，可以先写死一个频率点做稳定性验证，比如：

echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor echo 1800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed

如果固定频率下系统稳定，但自动调频时出现死机或者任务卡顿，就可以针对性查看OPP跳变频率、电压切换时序，以及regulator的瞬态响应是否满足要求。

3.3 CPU调频与DSU/互连频率的协同

单独调CPU频率并不够，还要考虑总线频率、DSU（DynamIQ Shared Unit）频率和内存频率。ARM大小核架构中，DSU包含L3和互连逻辑，它的电压域往往与CPU簇关联。有些平台的CPU频率提升到最高档时，必须同步提高DSU频率，否则跨核通信和L3访问会变成瓶颈，反而削弱性能。

此时内核的arm_dsu设备或者互连调频（interconnect scaling）需要配合起来。常见的做法是：在cpufreq的target_index回调里，同时设置CPU、DSU和总线频率，形成“套餐式”调频方案。这块如果只调CPU而忽略DSU，跑测试时会看到单核性能怪异的低，很多时候并不是CPU核心不够强，而是DSU/总线的频率拖了后腿。

设备树里描述CPU频率和DSU频率关联的方式，常见是给cluster对应的power domain或者使用dynamic-power-coefficient来辅助能耗模型。不过后者更多是给调度器算能耗用，不能解决协同调频的根本问题。

3.4 功耗测量与能效模型

做DVFS调优，一定要建立定量的功耗概念。市面上的开发板基本都有电流采样电阻，可以通过板载ADC或外接功率分析仪抓取不同频率点下的电流数据。我通常的做法是：

1. 固定频率，关闭屏幕和外设，让DDR自刷新，跑idle基线。
2. 固定频率，跑特定负载（比如dhrystone或者glmark2），测量满载电流。
3. 记录每个OPP下满载与idle的功率差，画出一条“能效比曲线”。

然后把这些数据反馈到设备树或者能耗模型中，比如内核的EM（Energy Model）框架。ARM的调度器EAS（Energy-Aware Scheduling）就是依赖EM数据来决策任务调度和大小核迁移的。如果EM数据不准，EAS做出来的调度决策就是错误的，可能频繁把任务搬到大核，功耗不降反升。

4. 系统级低功耗与SoC电源域软件实现

4.1 Suspend to RAM与hibernate的区别

CPUidle管的是CPU空闲状态，系统级挂起则是把整个系统置入一种极低功耗状态，通常叫Suspend to RAM（S3），在ARM平台上可能叫SYSTEM_SUSPEND。进入该状态前，系统要冻结用户空间、暂停设备、关闭非唤醒外设，然后把内存置为自刷新，CPU集群和大部分外设掉电，只保留唤醒源相关模块供电。

相比S3，hibernate（S4）则把内存镜像写入存储介质后整机断电，恢复时再从镜像加载。由于ARM平台对内存映射和设备初始化的强依赖性，hibernate在ARM上的恢复流程要更复杂，必须保证恢复时所有设备重新初始化到位，这块不建议刚接触ARM电源管理的人优先去碰，先把S3跑稳定更重要。

4.2 设备树中电源域（Power Domain）的控制

在Linux设备树中，power-domains属性用于描述设备和电源域之间的所属关系。例如：

mmc0: mmc@fe000000 { compatible = "arm,pl180"; power-domains = <&pd_mmc0>; };

这里的pd_mmc0通常对应一个genpd（Generic Power Domain）实例。在内核中，genpd框架统一管理电源域，通过pm_runtime接口控制设备的电源。对于需要保持唤醒能力的设备，要确保其所属电源域不会被关闭。

常见的坑是：某个外设挂在一个“系统掉电时会关闭”的电源域，但驱动没有实现runtime PM，没有在进入suspend前正确配置唤醒源，导致唤醒失败。我在调试过程中会重点排查设备树中每个power-domains节点到GIC唤醒通路之间的关系。

4.3 SCMI协议与SCP协同

SCMI是一个更上层的固件接口协议，用于AP和SCP（System Control Processor）之间的通信。它把时钟管理、电源域管理、性能管理（DVFS）、传感器管理等抽象成一个个协议，例如：

• SCMI_BASE
• SCMI_POWER_DOMAIN
• SCMI_PERFORMANCE
• SCMI_CLOCK
• SCMI_SENSOR

在支持SCMI的平台上，内核可以直接把dvfs的请求封装成SCMI消息发给SCP，由SCP统一调度时钟、电压、电源域。这种设计的好处是SoC供应商可以把时序敏感的电源控制逻辑放在SCP固件中，AP侧只做策略决定，不用去操作具体寄存器。

实现层面，Linux内核的SCMI驱动来源于drivers/firmware/arm_scmi/，设备树中要声明scmi节点以及对应的scmi_dvfs、scmi_power等协议通道。我在适配SCMI平台时，遇到过因为SCMI通道中断号配置错误，导致消息无响应的问题。排查方法是先用内核提供的scmi_debugfs或协议里面对应的get_version命令，确认基础通信是否正常。

4.4 热管理与电源管理的耦合

为什么热管理要放进电源管理架构里来谈？因为动态控制频率和电压，结果会直接影响SoC温度。反过来，温度传感器读到的数据，也会通过cpufreq的热限制机制（thermal throttle）影响频率。两者是一个闭环。

ARM平台上最常见的方案是：板卡上放置多个温度传感器，通过devicetree注册到thermal-zones节点，然后配置thermal trip点，例如60度开始降频、80度触发强劲降频、90度直接关机保护。

用lm-sensors或thermal_zone0的sysfs节点能够实时监控温度：

cat /sys/class/thermal/thermal_zone0/temp cat /sys/class/thermal/cooling_device0/cur_state

在功耗和性能调优时，如果发现同一负载下温度偏高，除了检查散热，也要检查DVFS调频策略是否过于激进。有时候看似CPU频率不高，但因为电压过高，功耗依然很大，这时调整regulator的电压标定值会有明显收益。

5. 实操调试方法与常见问题排查

5.1 用ftrace和tracefs追踪idle和频率变化

排查电源管理问题时，ftrace是最常用的工具。它可以跟踪CPU热插拔、cpuidle进入退出、cpufreq调频等事件。

开启方法大致如下：

echo 0 > /sys/kernel/debug/tracing/tracing_on echo function_graph > /sys/kernel/debug/tracing/current_tracer echo cpuidle:cpuidle_enter cpufreq:cpufreq_target > /sys/kernel/debug/tracing/set_event echo 1 > /sys/kernel/debug/tracing/tracing_on

trace输出里可以看到每个CPU进入哪个cstate、停留时间、退出原因。配合trace-cmd和kernelshark可以直观看出CPUidle切换是否过于频繁，以及是否有CPU长期卡在深状态导致中断延迟异常。

调频事件的追踪则能看到目标频率与实际频率的差异。如果请求频率是一回事，硬件实际运行频率是另一回事，极度容易引发时序问题，这时候要去查时钟驱动和SCP固件是否正确回应了调频请求。

5.2 高负载场景下，系统莫名重启怎么办

这种问题通常要被严肃对待。先从以下几点排查：

1. 供电瞬态：CPU突然跳到最高频，瞬间电流冲击可能导致电压跌落，触发复位。查看PMIC的瞬态响应、PCB走线，必要时在软件上限制调频步进，分多步慢慢升频。
2. 温度保护：确认是否触发了thermal shutdown，读取/sys/class/thermal/thermal_zone*/temp，以及在崩溃前的内核日志中搜索thermal相关消息。
3. OPP表配置错误：某个频点对应的电压低于硬件需求，高负载时时序不稳定。可将该OPP的电压抬高，再做长时间压力测试。
4. 缓存一致性问题：在大小核平台，如果CPU对某段内存的访问权限或缓存状态管理有问题，高负载场景下死锁概率会增加。这会表现为随机死机而非固定频率死机，排查时要开启CONFIG_DEBUG_SPINLOCK等内核调试选项。

5.3 唤醒源配置常见遗漏

在系统suspend后，无法通过按键唤醒，是最常被报告的问题之一。常见原因包括：

• GPIO唤醒线没有在设备树中配置wakeup-source。
• 外设的电源域没有被正确保持。
• GIC在系统挂起状态下被关闭。
• 唤醒中断被嵌套在了禁用的普通中断中。

调试时先在U-Boot或者最小化系统里测试同样的外设能否唤醒，以区分是硬件还是软件问题。然后检查内核中使用irq_set_irq_wake的调用，以及/proc/interrupts中被标记为唤醒的中断情况。

5.4 CPUidle的target_residency参数调整经验

我遇到过一些平台，在默认参数下CPU总是倾向于进入过深的idle状态，导致隔壁核唤醒它时需要几十微秒甚至上百微秒。这种延迟对网络游戏、音频处理这类对调度延迟敏感的应用是无法接受的。

解决方案有两个方向：

1. 调整cpuidle相关参数，比如/sys/devices/system/cpu/cpuidle/下各状态节点的target_residency和exit_latency，把它调大一些，让CPU更“懒”一点，不要轻易进入深状态。
2. 通过PM_QOS框架设置要求的唤醒延迟，例如让音频驱动设置一个比较小的latency预算，内核会自动屏蔽不满足条件的更深idle状态。这种基于QoS的自适应机制是现代SoC电源管理里很重要的一个环节，做产品时一定不要忽略。

5.5 固件层与内核层接口版本不一致的坑

ARM平台上的固件和内核是独立开发的，PSCI版本不匹配是常见坑。比如内核期望PSCI 1.0，但固件只支持0.2，或者反过来。在启动早期，内核会通过psci_check_mode做兼容检查，如果版本低于所需，会直接拒绝相关功能，或者限制深度idle的使用。

调试时可以用以下命令查看当前PSCI版本：

cat /sys/firmware/devicetree/base/psci/version

或者通过SMC直接调用PSCI_VERSION指令来看。如果发现固件版本过旧，需要升级TF-A或者对应SoC的ATF BL31镜像。还有一点要注意：PSCI调用使用的function_id在不同版本里可能有所差异，尤其是CPU_SUSPEND和SYSTEM_SUSPEND这类复合功能的参数约定，一定要以SoC手册为准。

5.6 常见问题速查表

下面整理一份我实际调试中常用的问题定位表格，方便对照排查。

5.7 实际调试工具集推荐

除了前面提到的ftrace，手头常备的还有：

• perf stat -e power/energy-*：查看CPU能耗预估
• cpupower：管理调频governor，查看硬件频率
• dmesg：重点过滤cpu_cooling、thermal、regulator等关键词
• crash或kdump：死机后抓取内核转储，分析最后进入的电源状态
• logic analyzer：测量SWD或GPIO信号，确认硬件时序

工具的熟练度在排查复杂电源问题时非常关键。只有把内核层面的trace和硬件层面的波形结合起来，才能快速定位“软件以为自己在调频，但硬件根本没响应”的这类深层问题。

6. 我的一些项目经验与调优心得

6.1 一开始别贪深，先保住稳定基线

很多新人在拿到开发板后喜欢直接开启最深idle、最高频率进行“性能测试”，结果一跑就死，然后怀疑硬件有问题。实际上，电源管理的每一步都是“一个状态一棵雷”。我的经验是分阶段验证：

1. 先关闭所有自动调频和深度idle，确保系统全速运行稳定。
2. 把DVFS打开，固定voltage，只测两三个低频点。
3. 逐步开放高频点和升降频节奏，跑长时间压力测试。
4. 最后才开启深度idle和suspend/resume测试。

这个过程看起来保守，但能帮你在第一时间区分问题出在DVFS、idle还是suspend路径上，避免所有变量搅在一起。

6.2 记录“异常前的最后一次状态”

调试电源管理问题最怕的是死机后无从下手。尤其是深度idle失败导致的挂起，很多情况下连串口都没有输出，因为唤醒源没有把CPU唤醒。所以从项目一开始就应该保留一个独立的调试串口，并且开启earlyprintk或earlycon。这样即便内核在启动电源状态切换时发生问题，也能看到最后一条日志。

同时在死机前，尽量让系统打印出当前CPU的频率、idle状态、regulator电压、温度等关键信息。可以写一个定期记录脚本或者内核sysrq工具，帮助追溯异常前的状态。

6.3 仔细看ERRATA和SoC手册

ARM官方和各SoC厂商的芯片手册，都会列出电源管理相关的ERRATA。很多平台的深度idle或者调频都有已知勘误，比如某些版本在特定条件下不能进入cluster power down，否则L2数据会丢失。这些ERRATA如果不看，只靠做实验去踩坑，效率极低，也容易把正确的配置误判为软件bug。

建议每个项目启动前，梳理SoC的勘误表，把涉及电源管理的条款单独摘出来，做成一个“可用的idle状态/频率点/电压点”的检查清单。这样在配置设备树时就有了权威依据，而不是靠猜。

6.4 从功耗数据反推配置好坏

做电源管理最终要回归到功耗数字。用功率分析仪在固定场景下记录整机功耗，比如待机、播放视频、运行多核负载，然后对比每次软件改动后的功耗曲线。如果某次改动后性能相同但功耗下降了5%，这就是正向收益；如果性能掉了10%但功耗只降了2%，那就说明配置不合理。

另外，很多团队最容易忽略的是“不用时的功耗”，也就是idle和suspend下的泄漏功耗。ARMv9 SoC因为晶体管密度大，泄漏不可忽视，这时候依赖DVFS降频可能还不够，还需要结合retention、power gating以及AVS（Adaptive Voltage Scaling）等手段去压榨最后几个毫瓦。AVS技术在手机端很多SoC上已经是标配，它根据芯片体质自动微调电压，目的是在保证良率和可靠性前提下尽可能降低电压功耗。

6.5 团队协作中要约定接口文档

电源管理系统架构涉及硬件设计、固件、内核、BSP多个团队的协作，如果没有明确的接口约定，很容易各做各的。我建议项目在早期就建立如下约定：

• 设备树里idle状态命名规则。
• PSCI power_state参数含义的文档化。
• cpufreq governor默认选择。
• 热限制策略阈值。
• 唤醒源配置的标准模板。

这些约定即使不形成复杂文档，只写成一份简短的README，也能在后续调试中节省大量沟通成本。

6.6 从一个真实的“调优案例”说起

之前有款双核A55的IoT产品，电池供电，待机功耗目标定在20mW以内。刚开始拿到板子时，纯待机功耗是80mW。经过一系列排查，发现主要问题有三个：一是CPUidle的C1状态entry过于频繁，导致CPU无法真正进入C2，power gate一直不生效；二是板上一颗USB Hub芯片没进入suspend；三是DDR频率始终跑在满频，没有根据负载降频。

针对这三个问题，我分别做了调整：把C1的target_residency调大，让系统尽早进入C2；在USB驱动里加上runtime PM和suspend处理；给DMC设备挂上devfreq，并配置对应的调频策略。最终待机功耗稳定在了18mW。整个过程中没有碰到“玄学”问题，都是配置粒度太粗、没把每个模块管到位造成的。

6.7 对新手的三句话建议

如果你刚开始接触ARMv9/v8电源管理架构，我给你三句话：

• 先把PSCI和CPUidle跑通，再看DVFS和SCMI，顺序不能乱。
• 所有idle状态和频率点，都要能解释“为什么是这个参数”，不能照抄。
• 遇到死机不要慌，先固化变量，再逐层放开功能，定位问题的边界。

电源管理不是一个“打开某个开关”就能做完的事，它需要持续的测量、对比和迭代。系统的稳定性和功耗收益，是在一遍遍跑压力、一遍遍看trace、一遍遍调参数中打磨出来的。只要把架构理解了，把工具链和排查路径跑顺，再复杂的电源问题也能找到头绪。

最后，在做这套架构设计时，一定要把低功耗的验证计划放到项目排期的最前面，不要最后才烧主板测功耗。等到功能全部做完再回头优化电源，那时候延迟、唤醒、稳定性的代价会让你非常头疼。