1、Linux电源管理全景：从ACPI到设备树，电源管理框架概览

各位好，我是老李。做嵌入式Linux开发十几年了，电源管理这块一直是让我又爱又恨的领域。爱的是，调通一次休眠唤醒，那种成就感不亚于让火箭上天；恨的是，一旦出了问题，排查起来简直要命。

今天咱们开始这门《Linux休眠唤醒机制深度剖析》的第一课。说白了，就是先搭个架子，让你对整个电源管理世界有个全景认识。别急着钻细节，先看地图再走路，这是我个人的习惯。

1.1 为什么需要电源管理？

你想想看，手机、平板、智能手表，哪个不是靠电池活着？就算服务器，电费也是一笔不小的开销。电源管理要解决的核心问题就两个：省电和响应快。

但这两者往往是矛盾的。省电就要让设备睡大觉，响应快就得让它时刻待命。怎么平衡？这就是Linux电源管理框架要干的事。

我在项目中遇到过一款工业平板，电池续航只有2小时，客户要求至少8小时。后来通过优化休眠策略，硬是拉到了10小时。嗯，这就是电源管理的价值。

1.2 两大阵营：ACPI vs 设备树

Linux电源管理有两个主要流派，就像武林中的少林和武当。一个是ACPI，一个是设备树（Device Tree）。

特性	ACPI	设备树
主要平台	x86（PC、服务器）	ARM、RISC-V（嵌入式）
描述方式	AML字节码 + 表	文本文件（.dts）
运行时修改	支持（通过BIOS/UEFI）	通常需重新编译
复杂度	高（功能丰富）	中（简洁明了）

ACPI（Advanced Configuration and Power Interface）是x86平台的标配。它用一套复杂的表来描述硬件，包括电源状态、设备拓扑、热管理等等。说白了，ACPI就是硬件和操作系统之间的翻译官。

设备树则是嵌入式领域的宠儿。它用简单的文本文件描述硬件，内核启动时解析这些信息。我刚开始从x86转到ARM时，看到设备树文件觉得太简陋了，后来才发现——简单就是美。

1.3 电源管理框架的层次结构

Linux电源管理框架，说白了就是一层一层的抽象。从最底层的硬件，到最上层的用户空间，每一层都有自己的职责。

用户空间（sysfs、pm-utils、systemd）
    ↑↓
内核PM核心（PM Core）
    ↑↓
设备驱动PM（suspend/resume回调）
    ↑↓
平台相关层（ACPI、设备树、ATF）
    ↑↓
硬件（SoC、PMIC、外设）

这个结构我画过无数次了。每次调试休眠问题，都要从最上层一路查到最底层。有一次，一个设备唤醒不了，查了三天，最后发现是PMIC的寄存器配置错了。嗯，这种坑踩多了，你就知道每一层都不能忽视。

1.4 关键概念：系统睡眠状态

Linux定义了多种睡眠状态，从浅睡到深睡，功耗越来越低，唤醒时间越来越长。

• Suspend-to-Idle（S2Idle）：最浅的睡眠，CPU进入空闲状态，但内存保持供电。唤醒最快，但省电最少。
• Standby（S1）：CPU停止执行，但缓存和寄存器保持。现在用得少了。
• Suspend-to-RAM（S3/STR）：最常用的休眠方式。CPU掉电，内存自刷新。唤醒后从恢复向量开始执行。
• Suspend-to-Disk（S4/STD）：也叫休眠。把内存内容写到磁盘，然后完全断电。唤醒时从磁盘恢复。
• Power-off（S5）：完全关机。

1.5 设备驱动中的电源管理回调

每个设备驱动都需要实现电源管理回调。这些回调告诉内核：设备在休眠前要做什么，唤醒后要做什么。

static int my_device_suspend(struct device *dev) {
    // 保存设备状态
    // 关闭设备时钟
    // 通知其他依赖设备
    return 0;
}

static int my_device_resume(struct device *dev) {
    // 恢复设备时钟
    // 恢复设备状态
    // 重新初始化硬件
    return 0;
}

static const struct dev_pm_ops my_device_pm_ops = {
    .suspend = my_device_suspend,
    .resume  = my_device_resume,
};

这段代码看起来简单，但实际写起来坑很多。比如，保存状态时要注意顺序，恢复时要注意依赖关系。我见过一个同事，在suspend里关了时钟，但忘了保存寄存器，结果resume后设备直接罢工。

1.6 设备树中的电源管理描述

在设备树中，电源管理信息通常通过以下方式描述：

&uart0 {
    status = "okay";
    clocks = &clk_uart0, &clk_uart0_gate;
    clock-names = "uart", "gate";
    wakeup-source;  // 支持唤醒
    power-domains = &pd_core;
};

这里的关键是wakeup-source属性。它告诉内核：这个设备可以在系统休眠时接收唤醒事件。没有这个属性，内核不会为它启用唤醒功能。

我记得有一次，客户说触摸屏无法唤醒系统。我一看设备树，果然少了wakeup-source。加上之后，问题解决。这种小细节，往往就是成败的关键。

1.7 电源管理框架的核心组件

Linux电源管理框架包含多个子系统，它们协同工作：

• PM Core：核心调度器，管理休眠唤醒流程。
• Runtime PM：运行时电源管理，设备不用时自动关闭。
• Clock Framework：时钟管理，控制设备时钟开关。
• Regulator Framework：电压调节器管理，控制设备供电电压。
• Power Domain：电源域管理，一组设备共享电源。
• Wakeup Source：唤醒源管理，跟踪哪些设备可以唤醒系统。

这些组件之间的关系，有点像乐高积木。你可以根据需要组合使用。但要注意，组合越多，调试越复杂。

1.8 实际项目中的经验之谈

做了这么多年，我总结了几条电源管理的铁律：

1. 先确认硬件支持：别在软件上浪费时间，先看芯片手册。
2. 从简单开始：先实现S2Idle，再挑战S3，最后考虑S4。
3. 日志是王道：开启PM调试日志，很多问题一目了然。
4. 测试要全面：反复休眠唤醒，各种场景都要覆盖。

1.9 本章小结

好了，这一章我们走马观花地看了一遍Linux电源管理的全景。从ACPI到设备树，从系统睡眠状态到设备驱动回调，从核心组件到实际经验。说白了，就是让你对整个框架有个整体认识。

下一章，我们会深入系统睡眠状态的实现细节，看看内核到底是怎么让设备睡着的，又是怎么叫醒的。到时候，我会拿出一些实际代码，咱们一起分析。

记住，电源管理不是一蹴而就的。慢慢来，多实践，你也能成为专家。