RFC-0230：Fucsia 中的“挂起到空闲”状态

摘要

此 RFC 提议添加对一种系统功耗级别（挂起到空闲状态）的支持，以及对从此状态恢复的支持。本文档介绍了 Fuchsia 的挂起到空闲流程的概要要求和设计。这是第一级 RFC，用于定义整个流程和设计。我们将发布更多 RFC 或设计文档，介绍每个模块的实现详情。

电源管理的关键在于，在系统处于非活跃使用状态时将其切换到较低功耗级别，并在需要时将其恢复为完全正常运行状态。系统级别可以与 ACPI S 状态进行比较。不同类型的系统对功耗和唤醒延迟有不同的要求，这些要求会决定系统可以转换到的“系统功耗级别”。在系统处于完全开启（或活动）状态时，通过关闭系统的某些部分或将其切换到较低功耗级别来管理系统的电源，称为运行时电源管理。

定义一组标准系统功耗级别并仅实现这些定义的级别并不能帮助实现尽可能提高功耗效益和遵守系统恢复时间延迟时间的目标。一些操作系统也尝试过对运行时电源管理进行改进，但尚未实现全部电源优势。

为了解决此问题，Fuchsia 将使用其集中式电源框架来实现精细级电源管理。本文件中所用的“电源框架”一词是指负责制定和实施政策决策的所有电源管理组件。系统的每个子设备（SoC/外围设备/总线/等中的部分）都可以自由定义它可以进入的任意数量的电源级别（以及相应的唤醒延迟时间），并将其发布到电源框架。电源框架将发挥重要作用，通过做出明智的政策决策并加以实施，将系统或系统的某些部分置于低功耗水平。电源框架将根据从用户空间系统组件收到的信息（例如请求将系统切换到较低功耗级别并保证唤醒时间）、开发板配置信息（支持的系统功耗级别、每个级别的唤醒时间和唤醒功能）以及系统的当前功耗级别（例如每个子设备的级别、其唤醒延迟时间、其电源资源依赖项和其 I/O 队列）采取行动。

示例：

1. 功耗框架会收到来自用户空间中的系统组件的请求，以将系统切换到较低的功耗级别，并确保保证 500 毫秒的恢复时间。功耗框架会了解所有子设备的电源级别以及部分或全部唤醒延迟时间。根据这些信息，功耗框架可能会决定仅将辅助 CPU 切换到离线状态、将音频扬声器（而非麦克风）切换到离线状态、将 Wi-Fi 切换到某种低功耗模式，并将显示屏切换到较低的刷新率。之所以执行这些操作，是因为它们可以在 500 毫秒内恢复为完全正常运行。它无法将其余子设备切换到较低的功耗级别，因为它们可能需要保持开启状态，或者其唤醒延迟时间大于 500 毫秒。

2. 由于没有活跃的用户互动，功耗框架会收到来自用户空间中的系统组件的请求，以将系统切换到更低的功耗级别。电源框架没有退出其将系统引入的较低功耗级别的恢复时间要求。电源框架可能会决定让系统进入“挂起到空闲”状态，然后随着时间的推移，尽可能转换为“挂起到 RAM”状态。这些是一些定义明确的 Fuchsia 系统功耗级别，电源框架会知晓这些级别并据之采取行动。

设计初衷

随着 Fuchsia 扩展到支持不同类型的电池供电产品，电源管理是一项必不可少的功能。本文档专门介绍了 Fuchsia 将系统切换到“挂起到空闲”状态并恢复为完全活跃状态的所有方面。采用的设计原则如下：

1. 驱动程序和组件可以通过实现定义良好的协议和接口来实现“电源感知”。此 RFC 中未定义确切接口。详细设计文档中将对此进行讨论。

2. 驱动程序和组件对系统级更改不敏感。

3. 该设计将纳入基础架构，以实现未来任何类型的电源政策强制执行（例如其他系统电源级别转换、运行时电源管理），而无需更改驱动程序代码。

这需要 Fuchsia 的各个层参与此 RFC 中介绍的明确定义的功能。此 RFC 不包含有助于测量各种系统功耗级别的系统功耗和性能所需的所有指标。

利益相关方

主持人：James Robinson jamesr@google.com

Reviewers:

• Carlos Pizano cpu@chromium.org
• Christopher Anderson cja@google.com
• Justin Mattson jmatt@google.com
• Kyle Gong kgong@google.com
• Mukesh Agrawal quiche@google.com
• Nick Maniscalco maniscalco@google.com
• Onath Dillinger claridge@google.com
• Suraj Malhotra surajmalhotra@google.com

咨询了：

• Christopher Anderson cja@google.com
• Justin Mattson jmatt@google.com
• Nick Maniscalco maniscalco@google.com
• Onath Dillinger claridge@google.com
• Suraj Malhotra surajmalhotra@google.com

社交：

我们已与扩展的 Power 团队讨论过此设计（Fuchsia 的各种模块的负责人，例如内核、驱动程序、驱动程序框架、组件框架和 Power 框架，都属于 Power 团队）。

要求

当系统想要节省电量并使用可用的低功耗级别时，Fuchsia 应实现向更低功耗系统级别的转换（具体取决于架构，可能是 ACPI S-state 或任何专有方式），并遵循来自用户空间系统组件的功耗管理请求。此 RFC 以“挂起到空闲”系统功耗级别为目标。针对“挂起到空闲状态”和“恢复”的基本要求如下：

1. Fuchsia 应从用户空间系统组件获取提示，并根据系统的功能和状态做出自己的选择（进入“挂起到空闲”状态）。

2. 如果用户空间提供了恢复延迟时间要求，Fuchsia 应遵循相同的要求。如果未提供恢复延迟时间，Fuchsia 应以尽可能短的恢复延迟时间进入“挂起到空闲”状态。

3. Fuchsia 应提供一种获取特定于开发板的配置的方法，以定义允许将系统从“挂起到空闲”状态恢复为完全活动状态的子设备中断。

4. 与其他操作系统相比，挂起到空闲状态功能的功耗应相当或更低。

5. Fuchsia 应根据用户空间组件的要求公开 CPU、内存和子设备的运行状况和指标，以便进行调试、功耗测量和制定政策决策。

6. Fuchsia 应提供一种方法，以便根据适当定义的电源依赖项对各个组件的操作进行排序。

7. Fuchsia 应在遵循电源级别更改的子设备和拒绝/忽略该请求的子设备上公开遥测数据。当更改请求被拒绝时，子设备可以选择发送和记录原因，以便用于调试和微调功耗。

8. Fuchsia 驱动程序应使用适当的定义接口提供其电源元素的相关信息。

设计

挂起到空闲状态是一种低功耗系统级别，许多操作系统都支持。每种操作系统对此低功耗级别的定义各不相同。在 Fuchsia 中，我们选择采用可实现最佳省电效果且符合上述要求的定义。此功耗级别定义基于但不限于 ACPI 等标准规范中的定义。根据 ACPI 规范中的定义，S1 被定义为低唤醒延迟休眠状态。规范中提供了多个示例实现。Fuchsia 的“挂起到空闲”功能旨在尽可能接近某种 ACPI S1 状态实现。

以下是规范的摘录，详细介绍了我们要实现的实现。

In this ACPI S1 implementation, all system context is preserved
except CPU caches. Before entering S1, the system caches are flushed and the
hardware is expected to

1. Place processor in stop grant state.

2. Stop the processor input clock, placing the processor into the stop clock
state.

3. Placing system memory into a self-refresh or suspend-refresh state.
Refresh is maintained by the memory itself or through some other reference
clock that is not stopped during the sleeping state.

4. Stopping all system hardware clocks (asserts standby signal to system
PLL)

Normally the RTC will continue running. In this case, all clocks in the
system have been stopped (except for the RTC). Hardware must reverse the
process (restarting system clocks) upon any enabled wake event whereby
OSPM must first invalidate the CPU caches and then transition back
into the working state.

不同的操作系统会根据 ACPI 规范的定义，以自己的方式实现“挂起到空闲”状态。本文档概述了“挂起到空闲”的设计，并讨论了 Fuchsia 如何改进。简而言之，Fuchsia 将按如下方式实现“挂起到空闲”状态，这与未完全实现下表中的其他操作系统相比具有优势。

子设备电源状态转换示例：

Considering a sub-device can support power levels as follows;

0 - off state with wake latency to fully functional being at most 650 ms
1 - higher power level with wake latency being at most 500 ms
2 - higher power level with wake latency being at most 450 ms
3 - higher power level with wake latency being at most 100 ms

If Fuchsia receives a request to go to low power state and the resume time
to be <=500ms, it can choose to take down the sub-device to level 2.

与其他操作系统的广泛比较：

Linux 内核不提供用于向驱动程序查询电源状态信息（例如唤醒延迟时间、精细的电源转换状态和各个状态的电源消耗）的方法。它不提供从固件/开发板驱动程序中获取此信息的方法。Linux 不会将任何政策决策纳入其内核层作为设计原则，以便将专有且无法开源的代码保留在 Linux 内核之外。Android 和 Ubuntu 等基于 Linux 的操作系统会基于 Linux 内核提供的电源管理功能构建其电源管理功能。它们只能根据查询并提供给用户空间的最少信息执行操作。缺少唤醒延迟时间和功耗等详细信息，限制了基于 Linux 的操作系统充分发挥节省电量和延长电池续航时间的潜力。例如，Android 电源管理旨在作为 Linux 电源管理的封装容器。它创建了多项电源政策和功能（例如“提前挂起框架”“唤醒锁定机制”），以便获享电源优势。但它仍在努力解决延长电池续航时间和缩短系统恢复时间等问题。

另一方面，Windows 会从驱动程序查询功能电源状态的唤醒延迟时间，这些状态可由驱动程序选择性提供。这有助于 Windows 进行积极的运行时功耗管理。Windows 驱动程序无需开源，因此供应商可以创建嵌入专有信息的驱动程序。但是，Windows 不会收到任何特定于开发板的配置，这会限制自定义运行时电源政策决策，并且可能会导致存在多个驱动程序版本，每个版本中都嵌入了专有特定于开发板的配置。

Fuchsia 将整合这两种操作系统的经验教训，并确保解决已知的设计问题。Fuchsia 需要考虑许多硅芯片限制和差异，才能做出正确的决策。

a) 每个芯片都有自己的电源轨管理、时钟树管理、CPU 状态管理和 RTC 时钟管理设计。Fuchsia 应具备基础架构，以提供信息来做出适当的政策决策。

b) Fuchsia 应为驱动程序提供基础架构，以便驱动程序定义不同的功耗级别，并允许它们在这些级别之间进行转换，而不是采用固定功耗级别（例如 ACPI D 状态 [D0、D0i1/2/3、D1、D2 和 D3]）。

c) Fuchsia 应为驱动程序提供基础架构，以便报告唤醒延迟时间和对其他驱动程序的依赖项等电源配置。为了进行积极的功耗管理，功耗框架需要访问这些信息。这有助于我们在其他操作系统尝试对此类信息进行改进以做出与电源相关的系统级决策时占据优势。

高级设计

启动/设置：

功耗框架将是第一个从用户空间中的系统组件接收低功耗模式请求的 Fuchsia 模块。如需执行该命令，Power Framework 应配备

1. 整个系统的电源拓扑

   功率框架需要创建或接收功率拓扑图并拥有该图。这样，电源框架就可以将子设备置于较低的电源级别。有关构建电源拓扑图的最终设计将在“电源框架”设计文档中进行讨论。以下信息对于创建和维护电源拓扑图可能会很有用。

   a) 组件依赖项 DAG：

   在 DFv2 中，所有驱动程序都是组件，并且组件管理器具有驱动程序和其他组件的“capability graph”（功能图）。此依赖项图可作为 Power Framework 构建电源拓扑图的良好输入。驱动程序管理器和组件管理器交换的是系统视图的不同方面。最后，组件管理器将成为组件依赖项图的所有者，并将其用作单一可信来源。Power Framework 应提供查询或访问此类信息的方法。不过，对于功耗框架，此图表还不够。

   b) 电源元素依赖项信息：

   电源拓扑结构必须捕获不同子设备的电源级别之间的关系，并保持对此的动态感知。在任何给定时间点，它都必须确保满足给定设备的电源依赖项。目前，组件和驱动程序拓扑结构都无法做到这一点。

2. 驱动程序和组件的当前状态

   应将驱动程序存在性和功耗级别变化的运行时信息传达给功耗框架。例如，即插即用可以引入新驱动程序并终止某些驱动程序实例。某些子设备可能无法正常运行，并且相应的驱动程序可能已不存在。某些驱动程序可以实现智能关闭设备中会影响运行时功耗管理的部分。

   所有电源级别更改都应传达给电源框架。其中一些可能是组件管理器或驱动程序管理器提供的运行时信息，而另一些可能是驱动程序直接报告的信息。

3. 系统状态，例如 CPU、内存、时钟和电源状态。（选答）

   除了上述所有信息之外，电源框架还可以访问 CPU、时钟树、内存和电源轨的状态等信息，这有助于做出正确的决策，以安全可靠的方式挂起系统。相应的驱动程序或内核会公开接口，供电源框架查询当前功耗等级，以及在挂起和恢复期间执行一组活动的系统调用。

4. 接收特定于板级的静态配置和特定于产品的配置。

5. 接收针对挂起到空闲和恢复的用户配置，例如唤醒功能和恢复延迟时间。

6. 在转换到较低功耗级别之前，请确定唤醒功能。

   功耗框架可以列出能够通过其有权访问的各种配置从不同系统低功耗级别唤醒的子设备。知道/了解自己可以从低功耗级别唤醒系统的驱动程序可以注册其中断，以便使用 Power Framework 实现唤醒功能。电源框架将使用此信息以及板级配置、产品配置和用户空间配置来确定哪些子设备具有唤醒功能，并与内核进行相同的通信。

以下是 init/startup 的概要流程。

暂停到空闲状态进入流程：

功耗框架将负责通过与 Fuchsia 模块（例如组件管理器、驱动程序管理器）以及 Zircon 通信，将整个系统切换到或切换出任何给定的系统功耗级别。如果用户空间请求的模式/状态/功耗级别不受支持，功耗框架可以选择拒绝该请求。每项模式/状态/功耗级别条目都需要按特定顺序执行一组不同的操作。

这里讨论的具体模式是“挂起到空闲”模式，这是一种低功耗模式。此模式是一种唤醒延迟时间较短的睡眠状态。出于以下原因，功耗框架需要维护组件和整个系统的状态机。

1. 进入和退出某种模式的决策或拒绝模式转换的决策均由 Power Framework 在内部处理。

2. 当系统已处于给定模式且电源框架收到将系统切换到其他模式的请求时，电源框架需要知道状态机及其转换，以便将系统切换到新模式。

3. 某些转换可能不会成功，系统模式也可能不会更改。此类情况应由 Power Framework 处理。电源框架应了解每次模式转换后的模式/功耗级别。

当 Fuchsia 选择进入“挂起到空闲”模式以节省电源/电池电量时，电源框架将拥有包含电源拓扑的系统的最新视图。Power Framework 会决定哪些组件需要过渡到低功耗级别，并调用接口进行过渡。这要求所有组件和驱动程序都注册并实现接口，以更改框架定义的电源级别，从而获得最佳电源效益。电源框架设计文档和感知电源的驱动程序和组件设计文档将介绍此设计的详细信息。

请务必定义哪些硬件/软件中断能够唤醒设备。Power Framework 将调用电源元素所有者的适当接口来对其唤醒触发器进行编程。它可以选择请求内核设置唤醒源寄存器（如果适用且需要）。这些设计详情将在“感知功耗的内核”设计文档中介绍。

如果驱动程序/组件未能更改功耗级别，功耗框架可以选择中止操作或继续执行。

功耗框架应发起请求以暂停单调时间，将 CPU 切换到离线状态或低功耗状态，尽可能关闭时钟和电源，并执行其他与架构相关的操作（如果有）。这可以是直接向内核发出的系统调用，也可以通过驱动程序、组件或 HAL 进行路由，后续的设计文档中将对此进行讨论。

下图显示了收到挂起调用时的概要流程图。

从“暂停-空闲”流程恢复：

当启动 CPU 收到唤醒中断时，系统会从“挂起到空闲”状态恢复。只有在中断控制器或某些情况下 PMIC 中编程的可唤醒中断，或者在某些情况下在每个设备本地编程的可唤醒中断，才会由硬件传递给 CPU。并非所有中断都会触发恢复。触发恢复的会由电源框架决定并在将系统转换为“挂起到空闲”状态之前进行编程的中断。

由于启动 CPU 未离线，因此中断将传送到启动 CPU，后者将调用正确的中断服务例程。当系统调用函数返回时，Power Framework 会直接从内核接收其挂起调用的状态，或者通过驱动程序进行路由。该驱动程序或电源框架必须按相反的顺序执行操作，才能启动整个系统，具体步骤包括启用时钟和电源域、将启动 CPU 置于完全正常运行状态、启动辅助 CPU、退出内存自刷新以及其他与架构相关的操作（如果有）。Power Framework 将负责有序地使用相应的驱动程序和组件恢复所有设备。

以下是从“暂停”到“空闲”流程的概要恢复示例。

模块职责

Power Framework 组件：

Power Framework 组件将负责协调整个暂停和恢复流程。Power Framework 需要执行以下操作：

1. 使用组件框架和驱动程序框架中的服务维护电源拓扑。

2. 维护组件（包括驱动程序）之间的依赖关系。

3. 使用内核或适当驱动程序中的服务接收 CPU 的功能和当前状态。

4. 从内核或适当的驱动程序调用服务，以便

   a. 将 CPU 上线/离线

   b. 设置唤醒源中断寄存器（如果有且需要）

   c. 暂停单调时间

   d. 特定于架构的更改和编程

   上述所有步骤可以是单独的服务调用，也可以是通过单个服务调用来完成。此设计决策和详细信息将记录在功耗框架和节能内核设计文档的适当设计文档中。

5. 用于从驱动程序和组件接收电源元素及其属性（例如电源电平、电源依赖项和唤醒延迟时间）的接口。

6. 用于有序地为驱动程序和组件设置适当电源级别的接口。

7. 公开电源拓扑的当前状态、每个驱动程序/组件的状态、用于调试和遥测的唤醒触发器等指标。

驱动程序

管理功耗关键资源的每个 Fuchsia 驱动程序都需要实现以下内容，以大幅节省电量。

1. 向 Power Framework 注册渠道

   a. 提供有关受支持的电源元素、其功耗级别、依赖项和唤醒延迟时间的信息。

   b. 实现用于更改功耗级别的接口

   c. 始终提供有关其电源状态的信息（例如，是否在内部触发）。

   d. 公开当前状态和内部配置等指标，以便进行调试和遥测。

内核

概括地说，内核可以将以下各项职责分别作为单独的系统调用或单个系统调用来实现。

1. 确保在系统进入“挂起到空闲”状态时暂停单调时间。当系统处于挂起模式时，时间不应推进。这样一来，在恢复时，线程就可以始终了解系统处于活动状态的相对时间。这将确保系统暂停的时间不会影响程序的正确性。在系统处于暂停状态时，必须确保时间推进行为保持一致。

2. 在更改 CPU 功耗级别之前，请编程唤醒源（如果适用且需要）。这将因架构而异，内核需要根据开发板类型设置适当的寄存器。

3. 将 CPU 离线或恢复为在线状态。

4. 导出 CPU 指标。此值可以在恢复完成时返回，也可以是电源框架或调试程序/功耗测量工具调用的单独系统调用，用于获取每个 CPU 的状态。

由用户空间调用的挂起到空闲状态独立于系统的调度行为。不过，调度程序必须了解这一点并采取适当的措施。“感知功耗的内核”设计文档中将介绍其详细设计。

新互动功能的概要设计

向 Power Framework 注册为唤醒功能的驱动程序

设备驱动程序可以根据驱动程序类型和架构，从板级驱动程序或其他来源了解其中断是否具有唤醒功能。例如，从音频、触控和合页设备生成的中断可以定义为可唤醒。在当前设计中，相应的设备驱动程序会在挂起函数中调用 SetWakeDevice() 以注册为唤醒源。（示例：ACPI 机盖驱动程序）。这会在内部调用 ACPI 驱动程序的 SetWakeDevice() 调用。这与架构相关，且不可扩缩。

电源框架是决定所有电源相关设置的集中位置，它会决定什么可以唤醒系统从其正在转换到的电源级别唤醒。因此，具有唤醒功能的中断驱动程序应使用预定义的共享通道与电源框架共享信息。电源框架可以使用内核系统调用设置唤醒触发器，也可以与驱动程序通信以进行相同的设置。此设计决策将包含在功耗框架设计、感知功耗的内核设计和感知功耗的驱动程序和组件设计文档中。

通过静态配置为开发板预配电源配置

每个开发板都可以定义有助于做出有意义的电源政策决策的配置和属性。一些示例包括子设备/外围设备如何相互依赖、要支持的不同系统功耗级别，以及可以从低功耗级别唤醒系统的子设备。例如，某些子设备可以从“挂起到空闲”状态唤醒系统，但可能无法从“挂起到 RAM”状态唤醒系统。因此，电源框架必须知道哪些子设备可以从系统正在转换到的当前功耗级别唤醒系统。

此板级配置可以是电源框架在启动后读取的一次性配置（例如中央热故障点配置），也可以是板级驱动程序提供给其他设备驱动程序的信息。然后，驱动程序会在初始化/注册期间处理信息，并将最终配置馈送给 Power Framework。

创建电源拓扑

电源框架应维护电源拓扑，以便高效地做出电源级转换决策。Power Framework 会与组件管理器和驱动程序管理器或驱动程序和组件本身设置适当的渠道，以收集以下信息：

1. 电源元素

2. 支持的相应功率等级

3. 对其他电源元素的依赖项

4. 转换到各个级别的延迟时间

5. 唤醒功能

6. 自行发起的电源电量级别更改的状态

在驱动程序初始化期间，驱动程序和组件应通过提供的适当渠道与电源框架进行通信。

此外，驱动程序和组件还可以扩展为使用此通道进行运行时功耗管理。例如，如果驱动程序或组件了解其电源元素未被使用，则可以使用该通道请求更改电源级别。电源框架可以根据系统状态、依赖项和电源政策忽略或执行请求。如果它想执行该请求，可以使用该通道并请求电源元件转换到特定的电源级别。

定义和调用每个驱动程序/组件的功率级别更改

功耗框架将从驱动程序报告的支持的功耗级别中选择，决定哪些子设备应转换到较低的功耗级别。电源框架将根据代表拓扑外部政策的某些元素的电源级别以及一组用于管理电源依赖项的严格规则来做出此决定。功耗框架将通过适当的已建立通道发送消息，以便传达子设备必须转换到的功耗级别。驱动程序/组件必须在尝试或完成转换后通过同一渠道报告状态。

实现

挂起/恢复流程是 Fuchsia 众多电源管理流程中的第一个，是一项跨越 Fuchsia 多个构建块的功能。此 RFC 是一个整体设计。我们还会发布其他 RFC 或设计文档，其中将介绍每个模块的实现详情。每个模块都必然包含许多设计方面，需要进行多次 Gerrit 更改才能完成整个实现。

测试

此功能跨越 Fuchsia 的多个构建块。对 Fuchsia 的每个部分所做的所有更改都应进行单元测试。用于测试各个模块之间的互动和流程的集成测试应可在 CI/CQ 中运行，以确保其他功能不会破坏此复杂流程，反之亦然。驱动程序测试 realm 可用于隔离地测试驱动程序。Lacewing（如果已准备就绪）可用于创建和运行基于主机的测试。创建的所有新接口都应作为合作伙伴 SDK 的一部分提供，并且应进行 CTF 测试以进行检查。

需要提供更多文件

为了使设计完整并准备好实现，需要生成以下设计文档。

• Power Framework 设计文档
• “注重功耗的内核设计”文档
• “感知电源的驱动程序和组件”文档
• 每个域（例如音频/图形/连接）的电源管理（可选）

缺点、替代方案和未知情况

此提案需要多个实现阶段，其中内核、驱动程序、电源框架、驱动程序框架和组件框架等所有模块都将在每个阶段交付。为电源管理流程设计基准至关重要，因为这有助于纳入各种电源管理功能，使 Fuchsia 成为电池供电产品的理想操作系统。实施此方案的费用将跨多个季度。

还有其他方法可以让暂停/恢复功能正常运行。它们是：

• 使用现有的挂起流程挂起驱动程序和组件

  此策略无法提供完整的解决方案，也无法提供最佳的电池续航时间。此解决方案无法考虑驱动程序/组件具有的各种电源依赖项、基于依赖电源元素对子设备进行智能分组，以及基于子设备的电源域进行处理。由于缺少编程运行时唤醒源更改和将子设备信息公开给用户空间等功能，因此此设计将不完整。

• 遵循与 Linux 中相同的暂停/继续设计

  这种策略只能确保 Fuchsia 与 Linux 等效。Fuchsia 必须在 Linux 是单体内核且不接受政策决策等限制下运行。这种策略不允许我们利用 Fuchsia 带来的优势。Linux 电源管理在很大程度上取决于内核执行的特定回调的顺序。相比之下，Fuchsia 的大部分内容是在多个进程的用户空间中实现的，因此我们的电源管理支持必须具有更分散的特性。

虽然这些策略可能可以快速实现，但其列出的缺点是不可接受的。

目前提出的设计是全新的，在 Fuchsia 中进行了大量的添加和更改。这种策略虽然需要花费时间和精力，但可以确保我们能够以安全且可伸缩的方式在 Fuchsia 中实现电源管理。这可确保我们不会将功耗管理流程改进到受限的操作系统中。

设计中的未知问题将在下一级设计文档中展开，其中还会记录缓解措施。

术语词汇表

• 电源元素：电源元素是一种实体，表示硬件子设备（包括电源轨和时钟）的电源方面，或这些硬件元素组合为更高级别的抽象（例如音频流、超声波、相机子系统）。
  

• 功率级别：电源元素可能占据不同的功率级别。功耗等级是遵循以下约束条件的一组状态：它们由非负整数编号；等级 0 没有功耗等级依赖项，在大多数设备中，它可以是“关闭”状态；它们按功耗递增顺序排列。（有许多方法可以测量功耗；对于当前的意图和用途，只需根据上下文定义“典型”功耗即可。）在最简单的非琐碎情况下，元素有两个可能的级别，0 表示关闭，1 表示开启。ACPI D 状态也可以映射到功耗等级，但其顺序会相反：D3cold=0、D3hot=1、D2=2、D1=3、D0=4。
  

• 唤醒触发器：当系统处于低功耗模式（挂起）且 CPU 处于离线状态时，现实世界中导致系统触发中断并从低功耗级别唤醒系统的交互称为“唤醒触发器”。
  

• 子设备：SoC 的一部分，或者附加了驱动程序的外围设备或系统总线。
  

• 系统功耗级别/休眠状态：定义明确的系统级别状态，具有已知的唤醒延迟时间和大致功耗。这与 ACPI S-States 非常类似。
  

• 唤醒延迟时间：子设备或整个系统从较低功耗状态转换为完全正常运行状态所需的时间。
  

• 恢复时间：系统从低功耗级别恢复到完全正常状态所需的最长时间。
  

• OSPM：操作系统主导的配置和功耗管理
  

• ACPI S0 状态 - 完全活跃或完全开启状态，功耗较高。
  

• ACPI S1 状态 - S1 状态定义为唤醒延迟时间较短的睡眠状态。 在此状态下，除 CPU 缓存之外，所有系统上下文都会保留。
  

• 单调时间 - 单调时间是指从系统开机以来经过的时间，由内核维护。
  

在先技术

• 休眠状态 - ACPI 规范
• 关于 CPU 功耗管理、C 状态和 P 状态的最低限度完整教程
• 设备低功耗状态 - Windows 驱动程序
• D0ix 状态
• 支持功能性电源状态
• 系统休眠状态 - Linux 内核文档
• Linux 中的“挂起到空闲”历史记录

更多阅读材料：

• “Fuchsia 电源拓扑概览”演示文稿
• go/fuchsia-power-topology