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

摘要

此 RFC 建议添加对一个系统电源级别（即 Suspend-to-Idle）的支持，以及从该状态恢复的支持。本文档介绍了 Fuchsia 的 Suspend-to-Idle 流程的高级要求和设计。这是第一级 RFC，用于定义整个流程和设计。 后续将有更多 RFC 或设计文档介绍每个模块的实现细节。

电源管理的关键在于，当系统未被积极使用时，将其降至较低的功率水平，并在需要时将其恢复到完全正常运行状态。系统级别可以与 ACPI S 状态进行比较。不同类型的系统对电源和唤醒延迟有不同的要求，这决定了系统可以转换到的“系统电源级别”。在系统完全开启（或处于活动状态）时，通过关闭或将系统部件置于较低的功率水平来管理系统电源，称为运行时电源管理。

定义一组标准系统电源级别并仅实现这些已定义的级别，并不能帮助实现尽可能获得最佳电源效益并遵守系统恢复时间延迟的目标。一些操作系统也尝试过改造运行时电源管理，但尚未实现全面的电源优势。

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

示例：

1. 电源框架从用户空间中的系统组件接收请求，以将系统置于较低的功率级别，并确保恢复时间为 500 毫秒。电源框架会了解所有子设备的级别以及部分或全部唤醒延迟时间。根据这些信息，电源框架可能会决定仅将辅助 CPU、音频扬声器（而非麦克风）、WiFi 切换到低功耗模式，并将显示屏切换到较低的刷新率。之所以采取这些措施，是因为这些操作可以在 500 毫秒内恢复到完全正常运行状态。它无法将剩余的子设备调至较低的功率水平，因为这些子设备可能需要始终处于开启状态，或者其唤醒延迟时间超过 500 毫秒。

2. 电源框架从用户空间中的系统组件接收到请求，要求将系统切换到较低的功率级别，因为没有活跃的用户互动。电源框架没有恢复时间要求，无法退出系统进入的较低功率级别。电源框架可能会决定将系统置于 Suspend-to-Idle 状态，然后随着时间的推移，尽可能过渡到 Suspend-To-RAM 状态。这些将是 Power Framework 会了解并采取行动的一些明确定义的 Fuchsia 系统能耗级别。

设计初衷

随着 Fuchsia 扩展到支持不同类型的电池供电产品，电源管理成为一项必须支持的功能。本文档专门介绍了 Fuchsia 将系统置于“挂起到空闲”状态并返回到完全活跃状态的各个方面。采用的设计原则包括

1. 通过实现明确定义的协议和接口，驱动程序和组件可以实现“电源感知”。此 RFC 中未定义确切的接口。我们将在详细设计文档中讨论这些问题。

2. 驱动程序和组件将不受系统级更改的影响。

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

这需要各种 Fuchsia 层参与，并具有此 RFC 中涵盖的明确定义的功能。此 RFC 不包含有助于在各种系统功率级别下测量系统功率和性能所需的所有指标。

利益相关方

主持人：James Robinson jamesr@google.com

审核者：

• 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

共同化：

此设计已与扩展的电源团队（Fuchsia 各个模块（如内核、驱动程序、驱动程序框架、组件框架和电源框架）的负责人是电源团队的成员）讨论过。

要求

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

1. Fuchsia 应从用户空间系统组件获取提示，并根据系统的功能和状态自行选择进入 Suspend-to-Idle 状态。

2. 如果用户空间提供恢复延迟时间要求，Fuchsia 应遵守该要求。如果未提供恢复延迟时间，Fuchsia 应以尽可能低的恢复延迟时间进入挂起到空闲状态。

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

4. 与其他操作系统相比，Suspend-to-Idle 功能应具有相当或更低的功耗。

5. Fuchsia 应按用户空间组件的要求公开 CPU、内存和子设备的健康状况和指标，以用于调试、功率测量和制定政策决策。

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

7. Fuchsia 应公开以下子设备上的遥测数据：遵循电源级别变更的子设备，以及拒绝/忽略请求的子设备。当更改请求被拒绝时，子设备应选择性地传达并记录原因，以便用于调试和微调功耗。

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

设计

Suspend-to-Idle 是一种低功耗系统级模式，许多操作系统都支持该模式。每种操作系统对这种低电量水平的定义各不相同。在 Fuchsia 中，我们选择的定义既能实现最佳的省电效果，又能满足上述要求。此功率级别定义基于但不限于 ACPI 中的标准规范定义。根据 ACPI 规范中的定义，S1 定义为唤醒延迟时间较短的睡眠状态。规范中提供了多个实现示例。Fuchsia 的 Suspend-to-Idle 旨在尽可能接近 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.

不同的操作系统以各自的方式实现 Suspend-to-Idle，并根据 ACPI 规范的定义进行即兴创作。本文档概述了 Suspend-to-Idle 的设计，并讨论了 Fuchsia 如何做得更好。简而言之，Fuchsia 会按如下方式实现 Suspend-to-Idle，这比未完全实现下表的其他操作系统更具优势。

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

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 模块。若要执行该命令，电源框架应配备

1. 整个系统的电源拓扑

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

   a) 组件依赖关系 DAG：

   在 DFv2 中，所有驱动程序都是组件，组件管理器具有驱动程序和其他组件的“功能图”。此依赖关系图可作为电源框架的良好输入，用于构建电源拓扑图。驱动程序管理器和组件管理器交换的系统视图方面有所不同。组件管理器最终将组件依赖关系图作为单一可靠来源。电源框架应提供查询或访问此信息的方法。不过，此图对于电源框架而言还不够。

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

   电源拓扑必须捕获不同子设备的电源电平之间的关系，并保持对该关系的动态感知。在任何给定时间点，它都必须确保满足给定设备的电源依赖关系。 无论是组件拓扑还是驱动程序拓扑，目前都无法实现这一点。

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

   驱动程序存在状态和功率级别发生变化时的运行时信息应传达给电源框架。例如，即插即用可能会引入新驱动程序并终止某些驱动程序实例。可能存在一些无法正常运行的子设备，并且相应的驱动程序可能已不再存在。某些驱动程序可以实现智能关闭设备中有助于运行时电源管理的部分。

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

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

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

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

5. 接收用户针对 Suspend-to-Idle 和恢复的配置，例如唤醒功能和恢复延迟时间。

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

   电源框架可以通过其可访问的各种配置，列出能够从不同系统低功耗级别唤醒的子设备。知道/学习到可以从低功率级别唤醒系统的驱动程序可以向电源框架注册其中断，使其能够唤醒系统。电源框架将使用此信息以及主板配置、产品配置和用户空间配置来决定哪些子设备能够唤醒，并与内核通信。

以下是初始化/启动的简要流程。

进入 Suspend-to-Idle 状态的流程：

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

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

1. 进入和退出模式的决策或拒绝模式转换的决策均由电源框架在内部处理。

2. 当系统已处于某种模式，而电源框架收到将系统切换到另一模式的请求时，电源框架需要了解状态机及其转换，才能将系统切换到新模式。

3. 部分转换可能无法成功完成，系统模式可能不会发生变化。 此类情况应由电源框架处理。电源框架应了解每次模式转换后产生的模式/电源级别。

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

请务必定义哪些硬件/软件中断能够唤醒设备。电源框架将调用电源元素所有者的相应接口来对唤醒触发器进行编程。它还可以选择性地请求内核设置唤醒源寄存器（如果适用且需要）。这些设计细节将在“Power-Aware Kernel”设计文档中介绍。

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

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

下图显示了收到暂停调用时的简要流程图。

从挂起到空闲状态流程恢复：

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

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

以下是从挂起到空闲流程的高级恢复示例。

模块职责

电源框架组件：

电源框架组件将负责编排整个挂起和恢复流程。电源框架需要

1. 通过组件框架和服务框架中的服务维护电源拓扑。

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

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

4. 从内核或相应驱动程序调用服务，以

   a. 使 CPU 上线/下线

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

   c. 暂停单调时间

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

   上述所有步骤都可以是单独的服务调用，也可以是单个服务调用来完成所有步骤。此设计决策和详细信息将记录在 Power 框架和 Power 感知内核设计文档的相应设计文档中。

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

6. 以有序方式为驱动程序和组件设置适当功率级别的接口。

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

驱动程序

管理对电源要求较高的资源的每个 Fuchsia 驱动程序都需要实现以下功能，以积极节省电量。

1. 向 Power Framework 注册渠道

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

   b. 实现可更改其功率级别的接口

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

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

内核

从高层来看，内核可以将以下各项职责实现为单独的系统调用或单个系统调用。

1. 确保系统进入 Suspend-to-Idle 状态时单调时间会暂停。当系统处于挂起模式时，时间不应前进。在恢复时，这将确保线程对系统处于活动状态的相对时间度量具有一致的感知。这样可确保系统暂停的时间不会影响程序的正确性。在系统处于挂起状态时，时间推进方面的一致行为至关重要。

2. 在更改 CPU 电源级别之前，对唤醒源进行编程（如果适用且需要）。这会因架构而异，并且内核需要根据主板类型设置相应的寄存器。

3. 使 CPU 离线或重新上线。

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

用户空间调用的挂起到空闲状态与系统的调度行为无关。不过，调度程序必须了解并采取适当的措施。有关详细设计，请参阅“Power Aware Kernel”设计文档。

新互动的概要设计

驱动程序注册为具有电源框架唤醒功能

设备驱动程序可以根据驱动程序的类型和架构，从主板驱动程序或其他来源了解其中断是否支持唤醒。例如，来自音频、触控和开合盖设备的中断可以定义为能够唤醒设备。在当前的设计中，相应的设备驱动程序会调用 SetWakeDevice() 作为挂起功能的一部分来注册为唤醒源。（示例：ACPI Lid Driver）。此函数会在内部调用 ACPI 驱动程序的 SetWakeDevice() 调用。这特定于架构，无法扩缩。

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

通过静态配置为板级配置提供电源

每个主板都可以定义有助于做出有意义的电源政策决策的配置和属性。例如，子设备/外围设备如何相互依赖、要支持的不同系统电源级别以及可以从低电源级别唤醒系统的子设备。例如，某些允许从 Suspend-to-Idle 状态唤醒系统的子设备可能不允许从 Suspend-to-RAM 状态唤醒系统。鉴于此，电源框架必须知道哪些子设备可以从系统正在转换到的当前电源级别唤醒系统。

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

创建电源拓扑

电源框架应维护电源拓扑，以做出高效的电源电平转换决策。电源框架将通过组件管理器和驱动程序管理器或通过驱动程序和组件本身设置适当的渠道来收集信息，例如

1. 电源元素

2. 支持的相应功率级别

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

4. 过渡到每个级别的延迟时间

5. 唤醒功能

6. 自行启动的功率级更改的状态

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

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

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

电源框架将根据驱动程序报告的支持级别，决定哪些子设备应过渡到较低的电源级别。 电源框架将根据某些元素的功率级别做出此决定，这些元素代表了拓扑之外的政策以及用于管理电源依赖关系的少量规则。电源框架将通过适当的已建立通道发送消息，告知子设备需要转换到的电源级别。驱动程序/组件必须通过同一渠道报告尝试或完成转换后的状态。

实现

挂起/恢复流程是 Fuchsia 的众多电源管理流程中的第一个，也是一项跨越 Fuchsia 多个构建块的功能。此 RFC 是一项总体设计。后续还会有更多 RFC 或设计文档来涵盖每个模块的实现细节。每个模块都必然有很多设计方面需要多次 Gerrit 更改才能完成整个实现。

测试

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

需要提供更多文件

需要生成以下设计文档，以使设计完整且可供实现。

• 电源框架设计文档
• “Power-Aware Kernel Design”（能耗感知型内核设计）文档
• “Power-Aware Drivers and Components”（能耗感知型驱动程序和组件）文档
• 每个网域（例如音频/图形/连接）的电源管理（可选）

缺点、替代方案和未知因素

此提案将需要多个实现阶段，每个阶段都会交付内核、驱动程序、电源框架、驱动程序框架和组件框架等所有模块。设计电源管理流程的基准对于纳入各种电源管理功能至关重要，这使得 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 状态非常相似。
  

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

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

• OSPM：操作系统导向的配置和电源管理
  

• ACPI S0 状态 - 完全有效或完全开启状态，功耗高。
  

• ACPI S1 状态 - S1 状态定义为低唤醒延迟休眠状态。 在此状态下，除了 CPU 缓存之外，所有系统上下文都会保留。
  

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

在先技术

• 休眠状态 - ACPI 规范
• CPU 电源管理、C 状态和 P 状态的最低完整教程
• 设备低功耗状态 - Windows 驱动程序
• D0ix 状态
• 支持的功能性电源状态
• 系统休眠状态 - Linux 内核文档
• Linux 中的 Suspend-to-Idle 历史记录

更多阅读材料：

• 关于 Fuchsia 电源拓扑概览的演示文稿
• go/fuchsia-power-topology