【关注我后续持续新增专题博文谢谢】上一篇我们讲了这一篇我们开始讲Android功耗系列专题理论之九芯片功耗问题分析方法一、芯片功耗问题分析方法高通平台电源控制架构解析高通平台的电源控制架构基于RPMhResource Power Manager-Hardened设计专注于动态电源管理涉及多个子系统对VDD_CX电压域的协同控制。以下是关键模块和交互逻辑的详细说明RPMh内部模块黄色框RPMh作为硬件强化的电源管理核心包含以下关键组件仲裁逻辑处理来自不同子系统的电源状态请求vote根据优先级和实时需求决策最终状态。时钟与电压调节器接口直接控制CX电压域的调节响应仲裁结果。睡眠与唤醒状态机管理芯片低功耗模式的进入与退出流程。与VDD_CX关联的模块淡绿色框VDD_CX是芯片关键电压域其状态直接影响性能与功耗。关联模块包括CPU子系统通过性能状态P-states请求调整电压以满足算力需求。GPU子系统根据图形负载动态投票以提升或降低电压。NPU/DSPAI与信号处理单元通过专用接口提交电压需求。内存控制器带宽敏感场景下触发电压调整以保障吞吐量。子系统投票机制红框各子系统通过以下流程影响VDD_CX状态投票请求生成子系统基于当前负载生成电源状态请求如Retention/Active/Turbo并通过硬件接口如AHB总线提交至RPMh。请求聚合与仲裁RPMh采用加权或优先级策略如CPU投票权重高于GPU合并冲突请求生成最终电压指令。电压域状态切换调节器根据仲裁结果调整VDD_CX电压同时触发时钟频率同步变化DVFS机制。典型场景示例高负载场景CPU与GPU同时提交Turbo投票RPMh将VDD_CX升至最高电压档位。空闲场景所有子系统进入Retention模式VDD_CX切换至低电压维持状态。调试与优化建议日志分析通过RPMh日志如Linux内核ftrace追踪投票来源及响应延迟。约束配置在设备树中定义子系统投票权重避免非关键模块过度影响电压。功耗建模利用QPST工具监测VDD_CX实时功耗优化投票阈值。通过电流拆解发现了CX电路的耗电存在增量就很有可能时发现DDR频率也存在差异。CX电路耗电与DDR频率差异分析CX电路耗电增量与DDR频率差异可能存在直接或间接关联以下是关键分析点和解决方法检查DDR频率配置通过系统日志或硬件监控工具如i2c-tools、sysfs接口确认当前DDR频率设置。频率升高可能导致CX电路供电需求增加。例如在Linux系统中可通过以下命令查看cat /sys/class/devfreq/*/cur_freq功耗与频率的数学模型DDR功耗与频率通常满足线性关系动态功耗公式为 P C × V² × f 其中P为功耗C为负载电容V为电压f为频率。频率提升直接导致功耗上升。使用示波器或逻辑分析仪测量DDR总线的实际时钟信号验证频率是否与软件配置一致。硬件层面的信号完整性问题如反射、串扰可能导致额外功耗。调整频率并监控功耗通过动态频率调节DFS逐步修改DDR频率同时记录CX电路电流变化。例如在嵌入式系统中可通过寄存器配置// 示例调整DDR控制器寄存器 *(volatile uint32_t *)0x1A00_0004 0x0001_2000; // 设置新频率排查电源管理ICPMIC交互检查PMIC为DDR和CX电路供电的轨电压是否随频率变化。某些PMIC会根据负载自动调整输出电压导致额外功耗。需验证PMIC配置寄存器中的电压-频率表VFT表。信号完整性分析使用眼图分析DDR信号质量。较差的信号完整性可能导致重传或纠错间接增加CX电路负担。确保阻抗匹配和终端电阻符合设计规范。DDR频率差异排查方法检查DDR控制器配置寄存器对比不同场景下的时钟设置参数确认是否存在动态调频策略导致频率波动。通过工具如示波器或逻辑分析仪捕获实际DDR时钟信号验证寄存器配置与实际输出是否一致。CX电压差异分析测量VDD_CX电源轨的实际电压值对比静态与负载场景下的波动范围。若电压异常需检查电源管理ICPMIC的配置参数包括电压调节器使能条件、负载调整率及反馈环路稳定性。子系统投票动作追踪通过芯片调试接口如JTAG或Trace捕获子系统间的硬件投票信号重点监测DDR和CX相关模块的交互时序。分析投票触发条件是否与频率/电压变化存在因果关系例如低功耗模式切换或性能需求变更。交叉验证方法同步记录DDR频率与VDD_CX电压的实时数据绘制时间轴曲线。若两者变化存在固定延迟或模式匹配可判定为协同调节机制导致需审查电源管理固件中相关策略表的配置逻辑。寄存器与日志检查提取电源管理单元PMU和DDR控制器的调试日志查找异常事件标志如超时、校准失败。核对寄存器默认值与实际写入值差异特别注意动态电压频率调整DVFS相关的控制位域。热分析与负载测试在高温、低温及常温环境下重复测试排除温度补偿机制干扰。施加阶梯式负载压力观察DDR与CX参数变化是否超出数据手册规定的容差范围。定位CX异常问题的方法通过短接Ps_hold抓取Ramdumps短接Ps_hold是一种快速触发Ramdumps的方法适用于没有T32调试环境的情况。抓取到的Ramdumps需要使用hansei脚本进行解析具体操作可参考文档《常用工具九:高通hansei脚本》。使用命令抓取rpmh_stats通过adb命令可以直接获取子系统状态信息无需触发Ramdumps。执行以下命令adb shell cat /sys/power/system_sleep/stats cat /sys/power/rpmh_stats/master_stats此命令会输出系统睡眠状态和RPMh主控统计信息帮助快速定位子系统异常。注意事项抓取Ramdumps需要设备进入特定状态可能涉及硬件操作需谨慎执行。rpmh_stats命令提供实时数据适合快速检查子系统健康状态但可能无法覆盖深层问题。建议结合两种方法先通过rpmh_stats初步排查再根据需要抓取Ramdumps深入分析。分析 RPMH 子系统状态的方法通过对比两个时间点的rpmh_stats数据可以判断子系统是否处于持续运行状态。以下是具体判断逻辑睡眠计数sleep count未增加正常情况下子系统在进入睡眠状态后sleep count会递增。若两次抓取的数据中sleep count未变化表明子系统未正常进入睡眠状态。最后退出时间sleep Last exited晚于最后进入时间sleep Last entered若sleep Last exited的时间戳大于sleep Last entered说明子系统在进入睡眠后未能成功退出或退出后立即重新进入运行状态。结合sleep count未增加可推断子系统持续活跃。操作步骤抓取初始状态记录第一次的rpmh_stats数据重点关注sleep count、sleep Last entered和sleep Last exited字段。间隔时间后二次抓取经过一定时间间隔后再次抓取rpmh_stats数据确保间隔足够长以观察状态变化例如数秒或更久。对比关键字段检查sleep count是否增加。若未增加可能存在异常。比较sleep Last exited与sleep Last entered的时间戳。若前者更大且sleep count未变则子系统持续运行。示例逻辑代码def check_subsystem_status(initial_stats, current_stats): if initial_stats[sleep_count] current_stats[sleep_count]: if current_stats[sleep_last_exited] current_stats[sleep_last_entered]: print(Subsystem is continuously active.) else: print(Subsystem may be stuck in an intermediate state.) else: print(Subsystem entered sleep normally.)注意事项时间间隔需合理设置过短可能导致误判。结合其他日志如内核日志进一步验证异常原因。某些子系统可能设计为常活跃状态需参考硬件规格确认预期行为。【关注我后续持续新增专题博文谢谢】下一篇讲解