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

RFC-0230：Fuchsia 中的 Suspend-To-Idle
状态已接受
领域
  • 电源
说明

介绍了 Fuchsia 如何处理系统电源状态变化，通过 Suspend-To-Idle 用例详细说明了设计
问题
Gerrit 更改
  • 865570
作者
审核人
提交日期（年-月-日）2023-06-02
审核日期（年-月-日）2023-10-24

修改此 RFC

修改 RFC 元数据

总结

此 RFC 提议添加对一种系统功率等级（即“挂起到空闲”）的支持，以及对从此状态进行恢复的支持。本文档介绍了 Fuchsia “挂起到空闲”流程的总体要求和设计。 这是第一级 RFC，用于定义整个流程和整体设计。此外，我们还提供了其他 RFC 或设计文档，其中介绍了每个模块的实现详情。

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

定义一组标准系统功率水平并仅实现这些定义的水平将无助于实现获得尽可能最佳的功效以及遵循系统恢复时间延迟的目标。一些操作系统也尝试过对运行时电源管理进行改造，但目前还没有充分发挥其优势。

为了解决这个问题，Fuchsia 将使用其集中式电源框架整合精细的电源管理。电源框架是本文档中使用的一个术语，表示负责制定政策决策并予以实现的所有电源管理组件。系统的每个子设备（部分位于 SoC/外设/总线等）上，都可以自由定义它可通过相应唤醒延迟进入的任意数量的功率电平，并将其发布到电源框架中。电源框架将发挥重要作用，具体方法是做出明智的政策决策，并实施这些决策来使系统或系统的某些部分降低能耗。电源框架会根据从用户空间系统组件收到的信息（例如请求系统降低功率，同时保证恢复时间）、板配置信息（支持的系统功率水平、恢复时间和每个级别的唤醒功能）以及了解系统的当前功率水平（例如每个子设备的唤醒延迟时间、其电源资源队列及其 I/O）来执行操作。

示例：

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

  2. 由于没有有效的用户互动，Power Framework 收到来自用户空间中的系统组件的请求，以将系统降低到较低的电量。电源框架没有恢复时间要求，可退出其将系统进入的较低功率电平。电源框架可能会决定让系统进入“挂起到空闲”状态，然后尽可能过渡到“挂起到空闲”状态（如果随着时间的推移）。这些是一些定义明确的 Fuchsia 系统功率等级，电源框架将知道这些电平并据此采取行动。

设计初衷

随着 Fuchsia 不断扩展以支持不同类型的电池供电产品，电源管理是一项需要支持的重要功能。本文档具体介绍了 Fuchsia 使系统进入“挂起到空闲”状态再回到完全活动状态的所有方面。采用的设计原则包括

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

  2. 这些驱动程序和组件与系统级更改无关。

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

这就需要 Fuchsia 的各个层来参与此 RFC 中介绍的明确定义的功能。此 RFC 并未包含帮助衡量系统在不同系统功率水平下的功耗和性能所需的所有指标。

利益相关方

教员：James Robinson jamesr@google.com

审核者：

咨询人员：

社交：

此设计与扩展 Power 团队进行了讨论（Fuchsia 各种模块（例如内核、驱动程序、驱动程序框架、组件框架和 Power Framework 等）的负责人均属于 Power 团队。

要求

当系统想要节省电量并使用可用的低功率水平时，Fuchsia 应实现向较低电源系统级别的转换（根据架构，可能是 ACPI S 状态或任何专有方式），并遵从用户空间系统组件的电源管理请求。此 RFC 适用于“挂起到空闲”系统功率级别。“挂起到空闲”和“恢复返回”的基本要求如下：

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

  2. 如果用户空间规定了恢复延迟时间要求，Fuchsia 也应遵从相同要求。如果未提供恢复延迟时间，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 规范的定义。本文档简要介绍了“Suspend-to-Idle”（挂起到空闲）的设计，并讨论了 Fuchsia 如何提供更好的服务。简而言之，Fuchsia 按以下方式实现“Suspend-to-Idle”方法，比其他未完全实现下表的操作系统具有优势。

子系统 能力等级 备注
启动 CPU C0（Pn） 以功耗最低的状态运行启动 CPU
非启动 CPU 关闭或较低的 C 状态（如果有） 非启动 CPU 的最低功耗（如果我们无法将其离线）
内存 自行刷新 如果该选项可用
子设备 可能的最低功率水平（如 ACPI 中定义的 D3Hot） 根据恢复时间要求，子设备将调到最低功率。
时钟树和电源轨 尽力而为 根据开发板配置和已知的系统唤醒要求，电源框架可以关闭时钟树和电源轨的某些部分

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

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. 整个系统的电源拓扑

    Power Framework 将需要创建或接收电源拓扑图，并且需要拥有该图。这样一来，电源框架便可将子设备置于较低的功率水平。构建电源拓扑图的最终设计将在 Power Framework 设计文档中讨论。以下信息对于创建和维护电源拓扑图非常有用。

    a) 组件依赖项 DAG：

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

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

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

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

    驱动程序是否存在以及功率水平方面的变化的运行时信息应传达给电源框架。例如，即插即用可能会引入新的驱动程序并终止一些驱动程序实例。可能存在一些无法正常工作的子设备，相应的驱动程序可能不再存在。可以实现某些驱动程序，以智能关闭设备上有助于运行时电源管理的部分。

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

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

    除了上述所有信息之外，Power Framework 能够访问 CPU 状态、时钟树、内存和电源轨等信息将有助于做出正确的决策，以故障安全的方式挂起系统。对应的驱动程序或内核会公开供电源框架查询当前功率水平的接口，还会公开用于在挂起和恢复期间执行一组 activity 的系统调用。

  4. 接受静态板级专用配置和产品专用配置。

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

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

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

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

替代文本：启动/初始化序列图

挂起到空闲条目流程：

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

此处讨论的特定模式是“挂起到空闲”低功耗模式之一。此模式是一种低唤醒延迟睡眠状态。出于以下原因，电源框架需要维护组件和整个系统的状态机。

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

  2. 当系统已处于给定模式且 Power Framework 收到使系统进入其他模式的请求时；Power Framework 需要知道状态机及其转换，才能使系统进入新模式。

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

当 Fuchsia 选择进入“挂起到空闲”模式以节省电量/电量时，电源框架将获得具有电源拓扑的系统的最新视图。电源框架将决定哪些组件需要过渡到低功耗电平，并调用相应的接口来过渡它们。这需要所有组件和驱动程序注册并实现接口，以改变框架定义的功率水平，从而最大限度地发挥功效。如需详细了解此设计，请参阅 Power Framework 设计文档以及 Power-Aware 驱动程序和组件设计文档。

请务必定义哪些硬件/软件中断支持唤醒。电源框架将调用电源元件所有者的相应接口来编程其唤醒触发器。它可以选择请求内核设置唤醒源寄存器（如果适用且有需要）。电源感知内核设计文档中介绍了这些设计细节。

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

电源框架应发起暂停单调时间的请求，使 CPU 离线或将其置于低功耗状态，尽可能关闭时钟和电源以及其他依赖于架构的操作（如果有）。这可以是对内核的直接系统调用，也可以通过驱动程序、组件或 HAL 进行路由，具体细节将在后续设计文档中介绍。

下面是收到挂起调用时的概要流程图。

替代文本：挂起到空闲序列图

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

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

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

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

替代文本：继续播放顺序图

模块责任

电源框架组件：

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 的状态。

用户空间调用的 Suspend-to-Idle 与系统的调度行为无关。不过，调度程序必须知道并采取适当的措施。“电源感知内核”设计文档中详细介绍了此功能的设计。

新互动的概要设计

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

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

电源框架是决定所有与电源相关的设置的集中位置，将决定可以从整个系统转换到什么功率水平唤醒系统。有鉴于此，具有唤醒功能中断的驱动程序应使用预定义的共享通道与电源框架共享信息。电源框架可以使用内核系统调用设置唤醒触发器，也可以与驱动程序进行通信以设置唤醒触发器。这项设计决策将纳入到电源框架设计、电源感知内核设计和电源感知驱动程序和组件设计文档中。

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

每个开发板都可以定义有助于做出有意义的电源政策决策的配置和属性。部分示例包括子设备/外围设备如何相互依赖、支持的不同系统功率水平，以及可以从低功耗水平唤醒系统的子设备。例如，某些被允许从“挂起到空闲”唤醒系统的子设备可能无法从“挂起到 RAM”唤醒系统。因此，对于 Power Framework 来说，务必要了解允许哪些子设备唤醒系统，使其从系统转换到当前功率水平。

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

创建电源拓扑

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

  1. 电源元素

  2. 支持的相应功率水平

  3. 依赖于其他电源元件

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

  5. 唤醒功能

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

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

此外，驱动程序和组件可以扩展，以将此通道用于运行时电源管理。例如，如果驱动程序或组件知道其电源元件未在使用，就可以使用该通道请求更改功率等级。Power Framework 可以根据系统状态、依赖项和电源政策忽略或遵从请求。如果它想要遵从该请求，则可以使用该信道并请求功率元件转换到特定的功率等级。

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

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

实现

挂起/恢复流程是 Fuchsia 众多电源管理流程中的第一个，是一项涉及多个 Fuchsia 构建块的功能。此 RFC 是整体设计。此外，我们还提供了其他 RFC 或设计文档，其中涵盖每个模块的实现细节。每个模块都必定有许多设计方面，这些方面需要进行多项 Gerrit 更改才能完成整个实现。

测试

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

需要更多文档

您需要制作以下设计文档，才能完成设计并做好实现准备。

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

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

此方案将需要多个实现阶段，并且所有模块（例如内核、驱动程序、电源框架、驱动程序框架和组件框架）在每个阶段都会交付。设计电源管理流程基准对于整合各种电源管理功能来说至关重要，这使得 Fuchsia 成为电池供电产品的理想操作系统。实施此提案的费用将跨季度完成。

还有其他策略可以使暂停/恢复正常运行。它们是：

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

    此策略并不能提供全面的解决方案，也不能最大限度延长电池续航时间。此解决方案无法考虑驱动程序/组件的各种电源依赖关系、基于相关电源元件的子设备智能聚类以及基于其电源域对子设备的处理。由于缺少对运行时唤醒源更改进行编程以及向用户空间公开子设备信息等功能，因此该设计是不完整的。

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

    此策略只能确保 Fuchsia 等同于 Linux。Fuchsia 必须在以下限制下运行，例如 Linux 作为单体式内核，而且不具有娱乐性的政策决策。此策略使我们无法利用 Fuchsia 带来的好处。Linux 电源管理主要是对内核执行的特定回调进行排序。相比之下，Fuchsia 的大部分内容都是在用户空间的许多进程中实现的，因此我们的电源管理支持在本质上必须更加分散。

虽然这些策略实施起来可能很快，但所列缺点不可接受。

目前提出的设计是全新的，在 Fuchsia 中进行了很多添加和更改。此策略会花费时间和精力，但可以确保我们能够以安全且可伸缩的方式在紫红色上实现电源管理。这样可以确保电源管理流程没有被改进到操作系统中。

设计中的未知问题会在下一级别的设计文档中揭示出来，其中也将记录缓解措施。

术语词汇表

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

  • 功率等级：功率元件可能具有不同的功率。功率水平是遵循以下约束条件的一系列状态：它们按非负整数编入索引；级别 0 没有功率水平依赖关系，并且在大多数设备中可能是“关闭”状态；它们按照功耗增加的顺序进行排序。（有多种方法测量功耗；对于当前的 intent 和用途，“典型”功耗的特定于上下文的定义就足够了。）在最简单的情况下，一个元素有两个可能的级别，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 缓存外，所有系统上下文都会保留。

  • 单调时间 - 单调时间测量的是自系统开机并由内核维护以来所用的时间。

前文

深入阅读：