第1章电源管理基础

一、电源管理基础：设备树电源管理节点概述、电源管理框架、Linux内核电源管理子系统

各位同学，咱们今天聊聊电源管理。说实话，我刚开始做嵌入式Linux那会儿，对电源管理这块儿是有点怵的。总觉得那是底层硬件工程师的事，跟咱搞软件的没啥关系。直到有一次，我负责的一个物联网终端设备，电池续航死活达不到客户要求的三个月……嗯，从那以后，我才真正开始重视设备树里的那些电源管理节点。

说白了，电源管理就是让系统在“干活”和“休息”之间找到最佳平衡点。你想想看，一个嵌入式设备，大部分时间可能都在待机，如果这时候CPU还在全速运转，那电池肯定撑不住。所以，我们需要一套机制，告诉系统什么时候该睡，什么时候该醒，睡多深，醒多快。这套机制，在Linux里就是电源管理子系统，而设备树就是它的“指挥手册”。

1.1 设备树电源管理节点概述

设备树里的电源管理节点，说白了就是硬件的“电源属性说明书”。每个外设、每个电源域、每个 regulator，都需要在设备树里描述清楚。我个人习惯，拿到一块新板子，第一件事就是先看它的设备树电源节点，这能帮你快速理解整个板的供电架构。

一个典型的电源管理节点长这样：

// 一个简单的 regulator 节点
reg_vcc_3v3: regulator@0 {
    compatible = "regulator-fixed";
    regulator-name = "vcc_3v3";
    regulator-min-microvolt = <3300000>;
    regulator-max-microvolt = <3300000>;
    regulator-always-on;
    regulator-boot-on;
    gpio = <&gpio1 16 GPIO_ACTIVE_HIGH>;
    enable-active-high;
};

这里我解释一下几个关键属性：

regulator-name：给这个电源轨起个名字，方便调试时识别。我在项目中习惯用“vcc_xxx”这种命名方式，一目了然。
regulator-min-microvolt / regulator-max-microvolt：电压范围。如果是固定电压，两个值设成一样就行。
regulator-always-on：这个属性告诉内核，这个电源永远不要关。比如某些关键外设的供电，关了就出大事。
regulator-boot-on：启动时就要打开。我遇到过一个问题，某个传感器因为没加这个属性，系统启动后它没电，驱动 probe 失败，折腾了半天才发现是电源没开。

注意： 我曾经踩过一个坑——把 regulator-always-on 和 regulator-boot-on 搞混了。always-on 是永远不关，boot-on 只是启动时打开，之后系统可以关掉它。如果你的设备需要一直供电，两个都要加上，或者只加 always-on（它隐含了 boot-on 行为）。

1.2 电源管理框架

Linux内核的电源管理框架，其实可以理解成三个层次：

系统级电源管理：比如 suspend-to-RAM、hibernate 这些全局操作。
设备级电源管理：单个设备的 runtime PM，设备不用时就关掉。
CPU 级电源管理：cpuidle、cpufreq 这些，控制 CPU 的睡眠状态和频率。

这三层是相互配合的。举个例子，系统要进入 suspend 状态，首先 CPU 要进入 idle，然后逐个设备 suspend，最后整个系统进入低功耗模式。反过来，唤醒的时候，先恢复系统，再逐个 resume 设备，最后 CPU 恢复运行。

我个人觉得，理解这个框架的关键在于“状态机”。每个设备、每个电源域都有自己的状态，系统通过设备树知道这些状态之间的转换条件。比如，某个设备在 suspend 时，它的供电 regulator 要不要关？关掉之后，唤醒时 regulator 的启动延迟是多少？这些信息，都得在设备树里配好。

核心思想： 电源管理框架的本质，就是“什么时候该做什么事，以及做这件事需要多少时间”。设备树就是把这些“什么时候”和“多少时间”告诉内核的载体。

1.3 Linux内核电源管理子系统

Linux内核的电源管理子系统，主要包含以下几个模块：

模块名称	功能描述	设备树相关
PM Core	电源管理核心框架，提供 suspend/resume 流程	定义系统唤醒源、电源状态
Runtime PM	设备运行时电源管理，自动开关设备	配置设备的 runtime 状态、延迟时间
Regulator	电压调节器框架，管理供电电压	描述 regulator 的电压范围、使能方式
Clock	时钟管理框架，控制设备时钟	描述时钟源、频率、门控
CPUIdle	CPU 空闲状态管理	配置 CPU 的睡眠状态和唤醒延迟
CPUFreq	CPU 频率动态调整	配置 OPP（Operating Performance Points）

这里我重点说一下 Regulator 框架。它是我在实际项目中打交道最多的一个。Regulator 框架的核心是“消费者-供给者”模型。每个设备（消费者）需要多少电压，由哪个 regulator（供给者）提供，都在设备树里描述。

举个例子：

// 消费者设备引用 regulator
uart0: serial@10000000 {
    compatible = "my-uart";
    reg = <0x10000000 0x1000>;
    vdd-supply = <&reg_vcc_3v3>;  // 引用上面定义的 regulator
    clocks = <&clk_uart0>;
    clock-names = "baud";
};

这里 vdd-supply 就是告诉内核：这个 UART 设备的工作电压由 reg_vcc_3v3 这个 regulator 提供。当 UART 驱动 probe 时，内核会自动去获取这个 regulator，并确保它处于开启状态。

小技巧： 我在调试电源问题时，经常用 /sys/kernel/debug/regulator/regulator_summary 这个文件。它能列出所有 regulator 的状态、电压、消费者等信息。配合 cat /sys/kernel/debug/regulator/<regulator_name>/ 下的各个文件，基本能定位 90% 的供电问题。

下面这张图，是我自己总结的电源管理框架关系图，帮你理清各个模块之间的联系：

从这张图你能看出来，设备树在整个电源管理框架中处于“承上启下”的位置。它向上为 PM Core、Runtime PM 等模块提供硬件配置信息，向下描述硬件的能力和约束。说白了，没有设备树，内核就不知道你的硬件支持哪些电源状态，也就没法做有效的电源管理。

总结一下： 电源管理基础这块，核心就是理解“设备树是硬件电源能力的描述者，内核电源管理框架是这些能力的调度者”。你配好了设备树，内核就知道怎么省电；你配错了，轻则功能异常，重则系统睡死过去再也醒不来。我当年就遇到过因为一个 regulator 的 enable 极性配反，导致系统 suspend 后 regulator 被关掉，结果唤醒时设备没电，直接死机。这种问题，查起来特别痛苦。

好了，这一章的内容就到这里。记住，电源管理不是一蹴而就的，需要你在实际项目中不断调试、优化。下一章我们会深入具体的设备树电源节点配置，到时候我会分享更多实战中的“坑”和技巧。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

一、电源管理基础：设备树电源管理节点概述、电源管理框架、Linux内核电源管理子系统

1.1 设备树电源管理节点概述

1.2 电源管理框架

1.3 Linux内核电源管理子系统