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

摘要

此 RFC 提议增加对一个系统功率等级的支持，即挂起到空闲， 并支持从此状态恢复。本文档介绍了 适用于 Fuchsia 的“挂起到空闲”流程的高级要求和设计。 这是定义流程和整体设计的第一级 RFC。 我们将提供更多介绍实现的 RFC 或设计文档 每个单元的详细信息

电源管理的关键是在以下情况中降低系统功耗水平： 即未在使用中，使其恢复正常功能。通过 系统级别可与 ACPI S 状态进行比较。不同类型的系统 对电源和唤醒延迟时间有不同的要求，这会指示 “系统功率等级”电源管理系统 通过关闭或拿掉设备的某些部分， 称为“运行时电源管理”

定义一组标准系统功率等级并仅实施这些等级 定义的级别无助于实现最佳力量目标 好处和尊重系统恢复时间延迟。有些操作系统 尝试对运行时电源管理进行了改造，但尚未实现 最大优势。

为了解决这个问题，Fuchsia 将整合精细的电源管理机制 使用集中式电源框架电源框架是 本文档介绍了负责 制定和落实政策决策。系统的每个子设备 （SoC/外围设备/总线等上的部件）可自由定义任意数量的功率 达到相应的唤醒延迟时间，然后发布相同的 添加到 Power Framework。赋能框架将会发挥重要作用 做出明智的政策决策，并通过实施这些决策来 将系统降至低功率水平。Power Framework 将根据 从用户空间系统组件接收到的信息（例如，对 系统降低功率水平并保证恢复时间）、板级配置 信息（支持的系统功率等级、恢复时间和唤醒功能） 以及了解系统的当前功率等级（例如 每个子设备的级别、唤醒延迟时间、电源资源 依赖项及其 I/O 队列）。

示例：

1. Power Framework 接收来自用户空间中系统组件的请求 将系统降至较低的功率电平，并确保可以保证恢复 500 毫秒Power Framework 可以识别所有子设备 以及部分或全部唤醒延迟时间。根据这些信息， Power Framework 可能会决定仅使辅助 CPU 离线 扬声器（而非麦克风）处于离线状态，Wi-Fi 切换到某种低功耗模式； 并将显示过渡到较慢的刷新频率。我们采取处置措施的原因是 它们可以在 500 毫秒内恢复完全正常运行。它不能保留其余的 并降低其功率，因为它们可能需要 始终开启，或者其唤醒延迟时间超过 500 毫秒。

2. Power Framework 接收来自用户空间中系统组件的请求 在没有活跃用户的情况下将系统降低到较低的级别 互动Power Framework 没有恢复时间要求， 退出降低系统所施加的较低功率等级。Power Framework 可以 决定让系统进入“挂起到空闲”，然后再过渡到 随着时间的推移，“挂起到 RAM”（如果可能）。这些就是一些明确定义的紫红色 Power Framework 可以识别和执行操作的系统功率级别。

设计初衷

随着 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

社交化：

此设计与 Extended Power 团队（ Fuchsia 的各种模块，如内核、驱动程序、驱动程序框架、组件 框架和 Power Framework 属于 Power 团队）。

要求

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

1. Fuchsia 应从用户空间系统组件中获取提示，并使其 自行选择（基于系统的功能和状态） “挂起到空闲”。

2. 如果用户空间有恢复延迟时间要求，Fucsia 应 都一样如果未提供恢复延迟时间，Fucsia 应输入 挂起到空闲，尽可能缩短恢复延迟时间。

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 的操作系统充分发挥其节能和扩展扩展的潜力 电池寿命。例如，Android 电源管理功能设计为封装容器， Linux 电源管理。它创建了多项电源政策和功能，例如 “提前挂起框架”“唤醒锁定机制”以获得电能效益。但 仍然需要解决延长电池寿命和降低电池寿命等问题。 系统恢复时间。

另一方面，Windows 会从驱动程序中查询唤醒延迟时间，以便 可选择由驱动程序提供的电源状态。这有助于 让 Windows 严格执行运行时电源管理。Windows 驱动程序 需要开源，因此供应商可以创建驱动程序嵌入 专有信息但是，Windows 没有收到任何开发板， 限制自定义运行时电源政策决策的特定配置 还可能导致多个驱动程序版本与专有开发板 每个版本中嵌入的特定配置。

Fuchsia 将结合从这两种操作系统中学到的知识，并确保 有助于解决已知设计问题芯片有很多限制， Fuchsia 需要纳入的差异化优势 决策。

a) 每个芯片都有自己的电源轨管理设计、时钟树 管理、CPU 状态管理和 RTC 时钟管理。紫红色应该 拥有基础架构来提供信息以采取适当策略 决策。

b) Fuchsia 应为驾驶员提供基础架构，供驾驶员定义不同的 并允许它们转换 具有固定的功率电平，如 ACPI D 状态（D0、D0i1/2/3、D1、D2 和 D3）。

c) Fuchsia 应为司机提供报告电力的基础设施 配置（如唤醒延迟时间和对其他驱动程序的依赖性）。 Power Framework 需要访问此信息才能主动 电源管理这将有助于比其他正在尝试的操作系统 来改造这些信息，以做出与电源相关的系统级决策。

概要设计

启动/设置：

Power Framework 是第一个获得低功耗的 Fuchsia 模块 请求模式请求。要执行 则 Power Framework 应配有

1. 整个系统的电源拓扑

   电源框架将需要创建或接收电源拓扑图 并且拥有相同的权限这样，Power Framework 就能将子设备 降低能量水平构建电源拓扑的最终设计 我们将在 Power Framework 设计文档中对此进行讨论。以下 信息可能有助于创建和维护电源拓扑 图表。

   a) 组件依赖项 DAG：

   对于 DFv2，所有驱动程序都是组件，组件管理器拥有 "能力图"驱动程序和其他组件的组件。此依赖关系图 可以很好地提供给电源框架，用于构建电源拓扑 图表。驱动程序管理器和组件管理器在以下方面的不同方面： 进行交换的系统视图。组件管理器最终拥有 组件依赖关系图作为单一可信来源。Power Framework 应该能够以某种方式查询或访问这些信息。然而，此图表 不足以遵循 Power Framework。

   b) 电源元件依赖关系信息：

   电源拓扑必须捕获 并保持对同一子网的动态感知。在任意给定时间 必须确保满足给定设备的电源依赖关系。 目前，组件和驱动程序拓扑都无法执行此操作。

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

   驱动程序中变更的运行时信息存在与权力水平 应传达给 Power Framework。例如，即插即用 引入新驱动程序并终止一些驱动程序实例。可能有一些 子设备运行，相应的驱动程序可能会停止 存在。可以实现一些驱动程序来智能地关闭 其设备对运行时电源管理做出了贡献。

   所有功率电平变化都应传达给 Power Framework。 部分信息可能是组件管理器提供的运行时信息 其中一些可能是驾驶员管理器直接报告的信息， 。

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

   除了上述所有信息外，Power Framework 还具有 访问 CPU 状态、时钟树、内存和电源轨等信息 有助于做出正确的决定，以便在 安全模式对应的驱动程序或内核将公开 Power Framework 可查询当前电量以及对 在挂起和恢复期间执行一组 activity。

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

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

6. 在转换到较低功率水平之前确定唤醒功能。

   Power Framework 可以列出能够从任意设备 通过各种不同的配置实现不同的系统低功耗水平 目标。知道/知道自己可以唤醒系统的低功耗系统的驱动程序 可通过电源线将中断注册为支持唤醒 框架。Power Framework 会将这些信息与开发板一起使用 产品配置和用户空间配置 哪些子设备能够唤醒并与 内核版本。

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

“挂起到空闲”输入流程：

Power Framework 将负责将整个系统在 通过与 Fuchsia 模块通信，使任意给定系统功率电平断开 如组件管理器、驱动程序管理器和 Zircon。如果模式/状态/电源 请求级别，那么 Power Framework 可以 选择拒绝该请求。每个模式/状态/能力等级条目都需要 按特定顺序执行一组不同的操作。

这里讨论的特定模式是一种低功耗模式， “挂起到空闲”。该模式是一种低唤醒延迟时间休眠状态。力量 框架需要维护组件和系统的状态机 进行整体测试，原因如下：

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

2. 当系统已处于给定模式且 Power Framework 收到 请求使系统进入另一种模式；Power Framework 需要 了解状态机及其转换，以便系统进入新的 模式。

3. 某些转换可能不会成功，并且系统模式可能不会更改。 此类情况应由 Power Framework 处理。力量框架 在每次模式转换后都应了解产生的模式/功率电平。

当 Fuchsia 选择进入“挂起到空闲模式”以节省电量/电量时， Power Framework 将包含电源 Power Framework 将决定哪些组件需要转换 并调用接口转换它们。这需要 注册和实现接口的所有组件和驱动程序 改变由框架定义的能力级别，以获得最佳力量 优势。该设计的详细信息在 Power Framework 中进行了介绍 设计文档以及 Power-Aware 驱动程序和组件设计文档。

请务必定义哪些硬件/软件中断能够唤醒。 Power Framework 将调用 Power Element 所有者的相应的界面 来编写它们的唤醒触发器它可以选择性地请求内核 设置唤醒源寄存器（如果适用和必需）。这些设计 如 Power-Aware 内核设计文档中所述。

如果驱动程序/组件未能更改功率等级， Power Framework 可以选择中止操作或执行后续操作。

Power Framework 应发起暂停单调时间的请求， 使 CPU 离线或处于低功耗状态，关闭时钟并 以及其他依赖于架构的操作（如果有的话）。 这可以是对内核的直接系统调用，也可以是通过驱动程序进行路由 或者是组件或 HAL，我们将在后续的设计文档中对此进行讨论。

以下是收到 Suspend 调用时的概要流程图。

从“挂起到空闲”流程恢复：

当启动 CPU 收到 中断唤醒。只有 中断控制器或在某些情况下影响 PMIC，或在某些情况下，通过本地 每台设备由硬件分发到 CPU并非所有打扰内容 会触发简历。触发恢复的中断包括 由 Power Framework 决定，并在系统转换之前进行编程 进入“挂起到空闲”

由于启动 CPU 未离线，因此中断将被传递到 启动 CPU，它将调用正确的中断服务例程。力量 框架会直接从 作为系统调用函数返回内核或通过驱动程序路由内核。无论是 驱动程序或 Power Framework 必须按照相反的顺序执行操作， 从启用时钟和电源域开始，启动整个系统， 使启动 CPU 达到完全功能状态，启动辅助 CPU， 自刷新和其他依赖于架构的操作退出内存， （如果有）。Power Framework 将负责恢复所有设备 相应的驱动程序和组件。

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

模块责任

Power Framework 组件：

Power Framework 组件负责编排整个 暂停和恢复流程。电源框架需要

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

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

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

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

   a. 使 CPU 在线/离线

   b. 设置唤醒源中断寄存器（如果有和必要时）

   c. 暂停单调时间

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

   上述所有步骤既可以是单独的服务调用，也可以是单个服务调用 服务调用来完成所有这些操作。这一设计决策和细节 记录在 Power Framework 和 Power 的相应设计文档中 Aware 内核设计文档。

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

6. 用于为驱动程序和组件设置适当功率等级的接口 有序。

7. 为了公开电源拓扑的当前状态、状态 用于调试和遥测的唤醒触发器。

驱动程序

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

1. 使用 Power Framework 注册频道

   a. 提供有关支持的电源元素及其功率的信息 依赖项和唤醒延迟时间

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

   c. 随时提供有关设备电源状态的信息（例如， 内部触发）。

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

内核

概括来讲，内核可以实现以下各项： 作为单独的系统调用或单个系统调用。

1. 确保在系统进入“挂起到空闲”时暂停单调时间。 当系统处于挂起模式时，时间不应提前。恢复时 这将确保线程能够始终如一地了解 系统处于活动状态的时长。这样可确保 不会影响程序的正确性。时间是 保持一致的行为来推迟时间至关重要 。

2. 在 CPU 之前对唤醒源进行编程（如果适用和必需） 更改功率等级。这取决于架构和内核 则需要根据板类型设置适当的寄存器。

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

4. 导出 CPU 指标。当简历完成或 这可能是由 Power Framework 调用的单独系统调用， 调试程序/功耗测量工具，可用于获取每个 CPU 的状态。

用户空间调用的“挂起到空闲”独立于调度 系统行为。但是，调度程序必须了解 并采取适当措施。稍后，我们还将讨论 在“Power Aware Kernel”设计文档。

新互动的概要设计

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

设备驱动程序可以了解其中断是否可以从板级唤醒 或来自其他来源，具体取决于驱动程序类型和 架构。例如，由音频、轻触和机盖生成的中断 设备可以定义为支持唤醒。在当前的设计中， 相应的设备驱动程序会在挂起过程中调用 SetWakeDevice() 函数注册为唤醒源。（示例：ACPI 盖子驱动程序 ）。这样会在内部调用 ACPI 驱动程序的 SetWakeDevice() 调用。这是特定于架构的方案，不可扩缩。

电源框架是决定所有电源相关事项的集中位置 设置，决定了哪些内容可以唤醒系统 将整个系统转换到什么状态因此， 支持唤醒的中断应与 Power Framework 共享信息 预定义和共享渠道Power Framework 可以设置 使用内核系统调用唤醒触发器，或与驱动程序通信以设置 都一样此设计决策将成为电源框架的一部分 设计、功耗感知内核设计和功耗感知驱动程序 和组件设计文档。

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

每个开发板都可以定义有助于 做出有意义的电源政策决策。其中一些示例就是 子设备/外围设备相互依赖，因此不同的系统功率 支持的级别以及可将系统从低功耗唤醒的子设备 级别。例如，某些获准从以下设备中唤醒系统的子设备： 系统可能不允许“挂起到空闲”将系统从“挂起到 RAM”唤醒。 因此，Power Framework 非常重要 子设备可以唤醒系统，使其从目前的电量水平 将系统转换到什么状态

此板配置可以是电源 (Power) 电源读取的一次性配置 启动后的框架（例如：中央热跳点） 配置） 也可能是板驱动程序提供给其他设备的信息 。然后，司机会处理信息， 配置。

创建电源拓扑

电源框架应保持电源拓扑，以实现高效电源 转换决策。电源框架应具有适当的渠道 使用组件管理器和驱动程序管理器进行设置，或者使用驱动程序和 组件本身来收集

1. 力量元素

2. 支持对应的功率等级

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

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

5. 唤醒功能

6. 自行发起的功率等级变更状态

在驱动程序初始化期间，驱动程序和组件应该能够 通过所提供的适当渠道使用 Power Framework。

此外，驱动程序和组件可以进行扩展，以将此渠道用于 以及运行时电源管理。例如，如果驱动程序或组件 如果知道其功率元素未在使用，则可以使用通道 请求更改电量。Power Framework 可以忽略或遵循 根据系统状态、依赖关系和电源策略确定请求。如果 要接受请求，它可以使用该频道并请求获得 元素转换到特定的功率级别。

定义和调用每个驱动程序/组件的电量变化

电源框架将决定应将哪些子设备转换为较低级别的设备 功率等级，从驱动程序报告的受支持等级中进行选择。 Power Framework 会根据 表示来自拓扑外部的策略的元素， 管理电源依赖关系的规则。能源框架用于传达 子设备必须转换的功率级别，也就是通过 适当的现有频道驱动程序/组件必须报告 尝试转换后，以状态返回到原来的频道上，或 完成。

实现

挂起/恢复流程是 Fuchsia 的众多电源管理流程中的第一个流程 并且是一项涵盖 Fuchsia 的多个基础组件的功能。 此 RFC 属于整体设计。我们还会提供其他 RFC 或设计文档 其中涵盖了每个模块的实现详情每个模块 因为需要对许多设计方面进行多次 Gerrit 更改， 完成整个实现。

测试

此功能涵盖 Fuchsia 的多个基础组件。所有更改 对 Fuchsia 的每个部分进行的测试都应进行单元测试。集成测试 测试各模块的交互和流程应可用并运行 以确保其他功能不会破坏这种复杂的流程， 反之亦然。驱动程序测试领域可用于单独测试驱动程序。 Lacewing（如果准备就绪后）可用于基于主机 测试。任何创建的新接口都应作为合作伙伴的一部分提供 SDK 并应实施 CTF 测试，以确保对其进行检查。

需要其他文档

您需要制作以下设计文档，才能 且已做好实施准备。

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

缺点、替代方案和未知问题

此方案需要通过许多模块来实现 例如内核、驱动程序、电源框架、驱动程序框架和组件框架 各个阶段的广告投放情况电源管理流程基准的设计是 整合各种电源管理功能使 Fuchsia 成为 电池供电产品所需的操作系统。部署此 API 所需的费用 建议将跨季度进行

您还可以通过其他策略让挂起/恢复正常运行。它们是：

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

  此策略无法提供完整的解决方案，也无法提供最佳 电池寿命。此解决方案无法考虑 驱动程序/组件具有的各种电源依赖项， 基于依赖电源元件和处理的子设备聚类 根据子设备的电源网域来调整其容量。这个设计是 由于缺少编程运行时唤醒等功能，因此未完成 源代码更改以及将子设备信息提供给用户空间。

• 遵循在 Linux 中采用挂起/恢复的设计

  此策略只能确保 Fuchsia 等同于 Linux。紫红色 必须受限地运行 例如 Linux 是单体式应用 而不是有趣的政策决策。此策略将不允许 我们可以利用 Fuchsia 带来的益处。Linux 电源 这在很大程度上取决于对 由内核执行相比之下，大部分 Fuchsia 都是 因此，我们的电源管理支持必须 的分布情况。

虽然这些策略实施起来可能很快，但它们的缺点如下 。

当前提议的设计是全新的， 增加了不少内容， 在 Fuchsia 上发生的变化。这种策略需要耗费时间和精力， 确保我们以安全且可伸缩的方式实现 紫红色。这样可以确保我们没有要改造的电源管理流程 植入到操作系统中，但存在局限性

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

术语词汇表

• 权力元素：权力元素是代表以下各方面的权力的实体 硬件子设备（包括电源轨和时钟）或组成 将这些硬件元素转换为更高级别的抽象，例如音频流、 也就是相机子系统。
  

• 功率级别：功率元素可能占用不同的功率级别。能力等级 是遵循以下限制条件的一系列状态：它们会编入索引， 非负整数；级别 0 没有功率级别依赖项”大多数情况下 设备也可能会“关闭”state;它们按功率递增进行排序 。（有很多方法可以测量功率；对于当前意图和 “典型”一词的功耗 suffices.)在最简单的非平凡案例中，一个元素可能有两个可能 ，其中 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 中的挂起到空闲历史记录

深入阅读：

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