1. 功耗调优概述
1.1 为什么功耗管理是嵌入式Linux的“生死线”
在嵌入式Linux系统中，功耗管理已从“可选项”变为“必选项”。无论是电池供电的物联网终端、智能穿戴设备，还是需要被动散热的工业控制器，功耗直接决定了产品的续航能力、散热成本与可靠性。一个未经调优的Linux系统，其静态功耗（漏电流+外设常开）与动态功耗（CPU频率/电压未匹配负载）往往比精心调优的系统高出30%~50%。
核心矛盾： Linux内核为通用计算设计，默认策略偏向“性能优先”；而嵌入式场景要求“按需供电、毫瓦必争”。驱动开发者必须从设备树到驱动协同，逐层接管功耗控制权。
1.2 功耗调优面临的四大挑战
| 挑战维度 | 具体表现 | 典型后果 |
|---|---|---|
| 硬件碎片化 | 不同SoC的电源域、时钟树、DVFS（动态电压频率调整）接口差异巨大 | 驱动代码难以复用，调优经验无法直接迁移 |
| 软件栈分层 | 功耗涉及设备树、驱动、PM子系统、调度器、固件等多层协同 | 单点优化易被其他层抵消，整体效果难以收敛 |
| 测量与归因困难 | 缺少硬件级功耗分解工具，软件功耗数据往往靠估算 | 无法精准定位“谁在耗电”，优化方向模糊 |
| 实时性与功耗冲突 | 深度睡眠/降频可能增加唤醒延迟或任务执行时间 | 交互类产品出现卡顿，工业场景错过控制周期 |
1.3 功耗调优的三大核心目标
- 降低平均功耗（Average Power）：延长电池续航，减少发热。关键手段包括动态调频调压（DVFS）、外设时钟门控、空闲时进入低功耗状态。
- 控制峰值功耗（Peak Power）：防止瞬间电流超过电源或散热设计上限。需通过电流限制、任务调度整形、频率钳位实现。
- 保证功耗与性能的帕累托最优：在满足业务性能指标（如帧率、网络吞吐、响应延迟）的前提下，最小化功耗。这是调优的终极目标。
调优黄金法则： 先测量，后优化；先静态，后动态；先外设，后CPU。不要盲目套用内核默认的“ondemand”或“powersave”调频策略，必须结合具体负载特征定制。
1.4 课程整体框架：从设备树到驱动协同的六层路径
本课程按照“由底向上、逐层深入”的原则，将功耗调优拆解为六个可执行的层次。每一层都对应具体的配置、代码或调试手段。
1.5 各层核心知识点速览
| 层次 | 核心知识点 | 关键工具/接口 |
|---|---|---|
| 第1层 | 功耗基线建立、电流/功率分解、tracepoint 分析 | powertop、perf、iio_hwmon、电流钳 |
| 第2层 | 设备树电源域、时钟、regulator 描述 | dtc、devicetree-spec、power-domains 绑定 |
| 第3层 | runtime PM 框架、autosuspend 延迟、时钟门控 | pm_runtime_* API、clk_disable_unused |
| 第4层 | cpufreq governor 选择、schedutil 机制、idle state | cpupower、sysfs cpuidle、trace_cpu_frequency |
| 第5层 | suspend/resume 路径、no_console_suspend、wakeup source | pm_test、/sys/power/state、wakeup_count |
| 第6层 | 多驱动协同、场景化调优、功耗与性能权衡 | ftrace、devfreq、自定义 governor |
常见误区： 很多开发者只关注第4层（CPU调频），却忽略了第2层（设备树电源域）和第3层（驱动运行时PM）。实际上，外设和SoC内部IP的功耗占比往往超过CPU，设备树中一个缺失的
power-domains 属性可能导致整个模块无法进入低功耗状态。
1.6 本课程的预期收益
- 掌握系统化的功耗调优方法论：不再“拍脑袋”改参数，而是基于测量数据逐层优化。
- 精通设备树功耗相关属性：能独立排查因设备树配置错误导致的漏电问题。
- 熟练使用 runtime PM 和 cpufreq 框架：在驱动中实现精细化的按需供电。
- 具备多驱动协同调优的实战能力：能处理真实产品中“WiFi 唤醒 + 传感器数据采集 + 系统休眠”的复杂功耗场景。
学习建议： 准备一块支持电流测量的开发板（如 BeagleBone Black 或 i.MX8M 系列），配合
powertop 和 perf 工具，边学边测。理论只有落到实际的电流波形上，才算真正掌握。