RFC-0250：电源拓扑

摘要

系统电源管理的关键问题之一是支持转换 这个术语通常用于指代具有 包括状态、硬件和软件等，从而调整到不同的状态，同时妥善管理 这些状态之间的相互依赖。该方案指定了一个称为 可用于解决此问题的 Fuchsia 电源拓扑，而 同时针对归因和 可观测性。这项工作的重点是建立一个概念框架， 定义明确的术语；未来的 RFC 将更密切地涉及设计 与实施有关

设计初衷

状态管理问题

此提案源自支持系统挂起/恢复的需求 操作，如 RFC 230 中所述。

系统挂起的一个主要任务是确保所有硬件元素 在 CPU 停止执行之前，已置于适当的低功耗状态 操作说明。从表面上看，这似乎是一种依赖关系管理 问题一层：“活跃”硬件元素的状态取决于 因此硬件元素必须处于挂起状态 在 CPU 挂起前的状态。

不过，硬件元素可能会相互依赖；例如，设备必须 在总线断电之前暂停运行。同时，设备可能 可在系统暂停期间 例如，在低功耗状态 设备将充当唤醒源和完全关闭状态（如果未用作唤醒源）。 同时，相关的状态管理问题无法仅与系统相关 暂停。当 CPU 处于低功耗模式时，硬件元素可能会进入低功耗状态， （例如当手机处于飞行模式时）， 无线装置

这些因素有助于创建支持过渡的框架 相互依赖的状态。由于电源管理是 但此责任由 Fuchsia 的 Power 框架。我们引入了“电源拓扑”这一术语有一定程度的灵活指代 这个框架的核心依赖关系图和框架 本身。

在开发电源拓扑时，我们发现管理 硬件元素之间的状态依赖关系自然延伸到了软件元素中， 元素，这些元素可以在硬件或 自然地描述面向用户的功能的启用/停用状态。在 具体来说就是，通过明确捕获支持集群内 因此，我们建立了一种自然的机制，可以实现按需 利用率，以便仅在需要时利用依赖项， 将所使用的资源归因给需要的资源。 组件的归因也值得关注，但特征更紧密地 与使用原因相关，因此需要在 子组件级别。

我们建立的概念用于实施基于需求的状态变化， 电源拓扑以不仅对整个 但驾驶状态规则会发生变化。这将创建一个强大的工具 产品开发者和系统工程师，他们将能够查看 系统级行为，并通过拓扑本身提出功能更改建议 而非源代码

为什么要使用新拓扑？

Fuchsia 已经有两个用于描述驱动程序和 组件。然而，这两种方法都无法很好地满足 管理问题因此，我们自行开发电源拓扑， 并希望我们会定期重新审视 以阐明其各自所起的作用。

为便于参考，我们简要回顾了现有的拓扑。

组件拓扑描述了两个 组件实例和 功能路由图。它是描述组件层次结构的树状结构 实例和功能被映射到该树之上的一个 DAG。如果 组件需要从其他子树访问功能，功能是 通过其父项进行路由

驱动程序管理器还会跟踪自己的节点 拓扑作为 DAG。驾驶员 框架，节点是设备的抽象概念，而驱动程序则绑定到节点， 使用其关联资源，例如访问 MMIO 寄存器。推动因素 组件，但它们会被展平为集合。 之所以采用这种结构，是因为组件拓扑没有 表示没有绑定驱动程序的节点， 父节点（这些称为复合节点），这是树不允许使用的 组件拓扑的结构。

利益相关方

教员：

Adam Barth abarth@google.com

审核者：

• 权力：Kyle Gong kgong@google.com
• Power：Michael Brunson mbrunson@google.com
• 驱动程序框架：Justin Mattson jmatt@google.com
• 驱动程序框架：Harsha Priya NV harshanv@google.com
• Zircon Kernel：Nick Maniscalco maniscalco@google.com
• 平台驱动程序：Andres Oportus andresoportus@google.com
• 组件框架：Gary Bressler geb@google.com

已咨询：

• David Gilhooley dgilhooley@google.com
• Corey Tabaka eieio@google.com
• Filip Filmar fmil@google.com
• Guocheng Wei guochengwei@google.com
• HanBin Yoon hanbinyoon@google.com
• Eric Holland hollande@google.com
• Mukesh Agrawal quiche@google.com
• John Wittrock wittrock@google.com

社交化：

此设计最初通过 Google 内部设计进行社交化 文档（由 Power 的审核人员撰写） 框架团队、组件框架团队、驱动程序框架团队、驱动程序团队和 Zircon 团队。它 已经过进一步优化， Broker 和系统活动 州长，这两位是 即将发布的 RFC

要求

有序的依赖项管理

如之前所述， 系统电源管理是指管理不同系统的状态变化 元素。示例 此类依赖项的影响如下：

• USB 设备只有在总线接通电源后才能开启。
• 时钟只有在电压轨之后才能以给定频率运行 提供足够高的电压。
• 视频在线播放应用只有在满足以下条件时才能开始流式传输视频： 或有效网络连接

一般来说，给定系统元素 E 可能具有状态集合 S₀、S₁、S₂ 等。由 E 到 正确占据给定状态 Si，所有 S_i 依赖项。

如果某个操作保留了所有对象的依赖项，则我们将其称为“有序操作” 始终保持系统元素状态具体来说，对于每个具有 候选状态 S_i：

• 只有在该状态的所有依赖项都已设置的情况下，E 才会输入 S_i 满意。
• 如果要破坏 Si 的一个依赖项，E 必须先退出 S_i。

Power 框架必须支持有序的状态转换以便于参与测试。 系统元素。

当无法有序执行状态转换时，幂 框架应确保元素处于明确定义的状态，并且 尽可能减少执行无序更改的元素数量。

归因

系统元素可能会占据多种状态，其中一些状态较为耗电 相较之下当元素处于高功率状态时，电源框架必须 将有助于确定出现这种情况的原因。

效率

系统元素应驱动到最低功率状态 框架可以归因操作的原因。用户必须具备的框架 根据需要将元素驱动到更高功率状态的简单方法，但是 他们可能需要引入新的归因原因。

可观测性

Power Framework 必须支持观察系统元素的状态 （由框架用户认为与功耗相关）。

性能

给定能够以某种方式执行状态转换的系统元素 产品要求，那么 Power Framework 必须充分满足 支持他们这样做。这大致分为两个问题：

• 请勿限制本地广告效果。电源框架不得引入 个别系统元素的状态转换延迟时间过长。

• 支持优化非本地性能。Power Framework 应 支持优化跨多个元素的状态转换。

  • 例如，假设图形和音频子系统继续 在系统挂起操作期间并行低功耗状态。电源 框架应指明它们是并行运行的，并提供数据洞见 花费的时间更长了，因此系统挂起的延迟优化 操作可以适当关注其中一项。

适用范围

电源拓扑有助于考虑非常大的问题空间。这个 具体而言，该方案未涉及以下主题：

• Power Broker 的详细规范。此 RFC 必须建立一些基本的 Power Broker 的几个方面，以开发拓扑模型。 但是，他们会尽可能多地提供有关 Power Broker 的 。Power Broker 将 实现本文档中详细介绍的模型之外的行为，以及 我们希望为其提供在这方面所需的全部灵活性。
• 一流的错误处理技术。本文档中开发的拓扑模型 未提供处理状态转换错误的明确方法。这个 排除是对前一项内容的扩展；它不会对 并尽量避免对 Power Broker 进行错误处理， 限制条件。
• 不良行为者。不同国家和地区之间的责任划分 Broker 和元素所有者最终 需要考虑行为不佳和意外的元素所有者 方法。
• 有期限的状态转换。作为一种 系统级操作，那么自然要考虑应用时间限制， 单个状态转换。

这些问题将进一步考虑，因为应用场景提供了具体的 要求。

设计

此处介绍的设计建立了电源拓扑的基础模型， 与任何特定接口或实现无关。实用 即将推出的一些 RFC 对开发者而言也很重要 打算将其子系统与电源拓扑集成：

• Power Broker RFC 将解决管理中涉及的接口 电源拓扑以及实现这些拓扑的组件。
• 系统活动调节器 RFC 将描述电源拓扑 与系统挂起/恢复进程的集成点。
• 启用电源的驱动程序 RFC 后，将涉及与驱动程序相关的 集成。

然而，对于专用网络， 文档。此 RFC 旨在通过一个连贯的概念，进一步证实相关概念 为其他 RFC 构建奠定基础，并在此基础上 您可以开发哪些稳定文档来帮助 Power 通过集成框架用户。

电源拓扑和核心概念

推动这种设计的主要功能需求是有序性 要求。首先，我们需要 确定可能参与模型的系统元素类型、 它们可能占据的状态，以及这些状态可能表达的依赖关系 通过电源拓扑进行传输只有这样，我们才能指定这些状态将如何 进行有序控制

力量元素

电源元素是此设计中的基本有状态实体。幂 元素可能处于有限数量的状态，并且在任何给定时间 它正好占据其中一种状态有时候，思考此类问题时， 电源元素作为广义设备型号，但也可以视为 简单地用作状态的容器。

给定的硬件设备可以直接对应于单个电源元件，但 也可能使用多个功率元件进行建模，这些功率元件描述不同的 设备状态。例如，可以单独配置触摸屏幕 传感器的采样率和位置跟踪容量；传感器的驱动程序 可能会公开独立的“采样率”和“位置跟踪”以 结果。

Power 元素还可用于为更抽象的概念建模，例如 跨越多个硬件或 面向用户的软件功能的启用/停用状态。

能力等级

功率等级是指功率元素可以占据的状态。答 功率级架构由给定功率等级的集合组成， 以及稍后介绍的元数据。

Power Framework 假定架构中的级别遵守 限制条件。框架用户有责任确保在指定 功率元素的架构，这些约束条件可准确反映 建模实体的属性。这些限制如下：

1. 它们可以按照能耗增加的顺序进行排序。（您可以通过多种方式 测量功率；针对当前意图和目的， “典型”的定义所需的电量。）剩余 以这种顺序表示限制。
2. 依赖关系是累积的：对于给定元素， 任何级别 M > 的

3. 功能是累计的：对于给定元素，提供的任何功能 任何级别 M 和更高级别的 Android 应用的

   • 此要求可避免 功率元件。例如，如果某位被抚养人需要 第 N 个级别的功能，而另一个级别的功能要求 (N+1)，该元素可以通过在 (N+1)st 运行来满足这两者。

然后，功率级架构包括：

• 架构中每个功率等级的标签。
• 根据耗电量增加的电平顺序。

示例

为便于说明，我们将使用字符串标签并表示排序顺序 并采用从下到上的顺序显示垂直列表（关于能量等级 实际上会在 Power Broker RFC 中涵盖。）

以下展示了三种可能的功率级别架构：

需要特别注意的是，功率等级按照相反的约定排序，即 ACPI 电源状态。这一选择消除了 Google Cloud 中 随意的措辞根据 ACPI 惯例，“低功率状态”等表达式 两种直接冲突的解读方式，具体取决于“较低”为 计算耗电量（对应排序中的较高指数） 排序）或排序顺序的索引（对应于高权值） 使用量）。诸如“较低权力级别”之类的表达式不会受此困扰 不确定性。

并非所有的功率元素都能使用一个通用的功率级别架构， 与其他元素共享例如，您可以定义一个功率元素， 用于指定 CPU 运行的最低频率，在这种情况下， 对应于相关 CPU 支持的频率。

用途和限制

优先级架构是表示元素状态的实用起点 有多种原因：

• 它们清楚表达了常见模式，就像下面所示的那样 上方。
• 它们提供了一种方法来捕获应用之间的依赖关系， 通过汇总而非要求收集大量状态 繁琐的重复工作。
• 它们的使用方式不会产生冲突，即： 在所有情况下都符合预期，但应尽可能加以利用。

单个功效元素和功效等级架构不足以满足所有需求 Power Framework 用户感兴趣的场景。例如，不相交运算 模式（举一个简单的例子，但这不符合上下文，可以考虑使用 可以给房间供暖或制冷的热泵）则无法准确地建模为单个 力量元素。

然而，权力级别架构可用作构建块来描述更多 复杂系统。上述操作的最佳做法不在此 RFC 的讨论范围内； 我们将在后续的文档中介绍该主题。 框架用户还可以通过 紫红 >电源 组件。

可操作性和依赖项

在任何给定的时间点，根据当前系统条件，功率元素 能够在能量水平的一部分下正常运行。这些是 可操作级别。该子集始终包含不高于 或 的所有级别 等于元素 E 的最大可操作级别，以 max_operable_level(E) 表示。

功率等级依存关系用于指明 一个功率元素的功率与另一个功率元素的当前功率级相关联 元素。功率等级依存关系表示对于子元素 C 到 操作在级别 L 或更高时，它需要父元素 P 以 所需的级别 RL。更确切地说，(C, L) 依赖于 (P, RL) 意味着：

• 如果 current_level(P) <RL，则 max_operable_level(C) <的

同样，此条件可写为：

• 仅当 current_level(P) ≥ RL 时，max_operable_level(C) ≥ L。

(C, L) 的每个依赖关系都为 L 为 可操作。依赖项可以描述为“符合”“已满足”等 相关条件的状态。

另请注意，对于任何级别 K <L，(C, K) 的每个依赖项都会创建一个 是 L.特别是 （C、L）可对父元素施加要求，即使 (C、L) 本身也是如此 不直接依赖于该元素。我们用 (C、L) 必需元素的必需元素。对于此元素中的任意元素 P， 则 (C, L) 具有最低级别要求才能正常使用；我们表示 min_required_level(P;C, L)。

聚合所有必需元素，下面是一组必需的 必须满足不同条件才能运行，L 为：

• current_level(P) ≥ min_required_level(P; C, L)，即所有 P ≥ required_elements(C, L)。

当这些条件得到满足时，我们说 L 是名义上可运行的。负 即使名义上是可操作的，也可能无法操作；当地情况，例如 （可能未观察到的）硬件错误，甚至可能导致 C 无法在 L 模式下运行 当满足所有相关的功率等级依赖项时。标称 应将可操作性视为电源拓扑尝试 真正可操作性虽然这两个概念之间的差异是不可避免的， 当元素设计人员保持 将差异降到最低。

一个功率元素可能有多个功率级别依赖关系。 固定父级和子级的所有此类级别依赖项的集合构成一个 power 元素依赖项。我们可以说，如果存在 P 存在以下情况，则 C 依赖于 P 将依赖项从至少一个 C 的级别指向 P 的级别之一。

电源拓扑

作为正式实体，电源拓扑是具有功率的多边图 以节点表示，将功率级依存关系以定向边表示。周三 另外还要对此图表施加以下限制：

1. 无循环：电源拓扑是无环的。

   • 具体而言，父/子关系的行为符合预期；如果 元素 C 依赖于元素 P，则元素 P 可以不依赖于元素 C。

2. 最低级别可操作性：最低级别 任何功率元件的功率等级必须始终处于可运行状态，无论 其他元素的当前级别。此外，它可能没有功率级 依赖项

   • 该条件指的是可操作性，而不是标称可操作性， 并确保每个元素始终至少有一个可操作级别。 此方法必须由元素所有者强制执行。

   • 一个元素的最低级别可以依赖于另一个元素的 对可操作性没有影响。但这种依赖关系 与功能并不相关，如果允许它们使用，也 考虑仅通过其相互依赖的元素 最低级别。

电源拓扑可能包含冗余电源级别依赖项。例如： (C, L) 可能同时取决于 (P, RL1) 和 (P, RL2)，其中 RL₁ <RL₂，即使由 对（P、RL₂）的依赖性强于 依赖项（P、RL₁）。这类冗余内容会被视为无害 ，但他们可能会受到一些特殊考量， 实施。

示例和上下文

注意：这些示例仅作说明之用。此 RFC 没有任何影响 必须使用功率元素建模。

功率等级依赖性的最基本形式与开/关状态有关。在 我们可以表示，要使 USB 总线 USB 设备将作为：

为了有序处理上述依赖项，必须开启总线 并且必须先关机 公交车是关掉的。

电源级别依赖项的更宽泛定义可满足更复杂的 关系，例如在 DVFS 期间时钟与电压之间的耦合。 （DVFS 具有足够的时间敏感性，因此可能不是合适的候选对象） 电源拓扑集成的例子，但它可起到很好的示范。）假设 具有一个具有以下 DVFS 表的时钟，其中列出了支持的频率和 所需的电压：

下表对功率元素、等级和依赖关系进行了解释，如下所示：

（请注意，（时钟频率，1.4 GHz）对（电压，700 mV）的依赖关系 从技术层面来讲，不会包含在拓扑中，但 以便于与表格进行比较。）

用于代表软件功能或用户层面等内容的强效元素 设备的运行模式可能带有许多依赖项，以描述所有 运行所需的资源在另一个简化示例中， 调用客户的“活跃”状态可能取决于各种硬件子系统 进行视频通话所需的：

最后，多个子元素可能依赖于同一个元素。在这里，我们描绘 说明设备功率等级的延迟。客户 A 处于有效状态 级别要求低延迟时间，而客户端 B 要求延迟时间中等。设备 可以通过低延迟运行来满足儿童的活跃级别要求。

此示例展示了权力等级的一个重要属性：它们是 确保不同客户端的需求不会发生冲突。

边缘方向惯例

从上面的图表可以看出，我们采用 拓扑会朝着从子级到父级的依存关系的方向排列。它很可能是 某些讨论和直观的术语所基于的 即从父级到子级的权力流动方向。目前，我们的意图是 在所有正式开发中都使用依赖方向， 建议读者注意这个问题。

电源级别管理

为了指定如何在真实系统中使用电源拓扑，我们接下来 需要定义涉及管理拓扑的各方， 力量元素。

Power Broker

电源拓扑将由电源框架组件管理 名为 Power Broker。Power Broker 负责维护 整个电源拓扑，包括所有电源元素及其功率级架构， 功率等级依赖项和当前功率等级。它会提供接口 每个元素所有者更新其元素的在适当的 以便尽可能有序地更改关卡。

Power Broker 的存在反映了这一设计的关键主张： 进行集中管理。我们认为有必要这样做，因为：

• 尝试在本地管理拓扑会造成大量 更容易出现依赖项管理中的实现错误。
• 中央管理员可以在系统范围内进行连接， 为满足电力需求而提升的电力水平 效率要求。
• 中央管理员有权在服务中执行归因 注明出处要求。
• 中央管理员可以维护和报告详细的遥测数据， 满足可观测性要求，即使 如果单个子系统不提供插桩，则会发生该错误。
• 中央行政管理部门创造了从 元素所有者。例如， 首选，让驱动程序不要对当前电量情况做出决定 底层硬件该偏好设置可以 编码后，驾驶员将无法再租用 属性。

集中式管理是以牺牲本地化性能为代价的 因为管理员引入了一个必须知道电力资源的团队 元素及其级别。因此，您必须格外关注性能 整个 Power Broker 的设计和实现过程。然而，全球 Power Broker 将支持的角度来看，可能允许其抵消本地 降低系统级性能优化机会，从而降低成本。

元素所有者

每个电量元素都与一个元素所有者（即实例）相关联， 组件（可能是 DFv2 驱动程序）的组件。 所有者向 Power Broker 注册元素，并声明其功率级别 定义其依赖项，并在适当的时候更新其功率级别 次。

必要时，可在 元素的生命周期这很可能涉及一个组件实例 同时负责注册和配置任务的所有者 获得运行时管理的所有权。

能量元素及其相关依赖关系的生命周期时长将是 Power Broker RFC 中配置的网址。

电源元件的类型

大多数电量元素都将进行管理，这意味着它们的所有者会延迟 功率等级的选择以及 Power Broker 更改的时间。通知方式 某元素的所有者进行必要级别更改时，Power Broker 会将该所有者 所需级别。所有者进行更改，然后通知 Power Broker 元素的新当前级别。

在当前模型中，我们进行了简化假设。收到通知时 元素 E 的必要级 RL，那么 E 的所有者将始终：

• 如果 RL 可运行，则将 current_level(E) 更新为 RL。
• 如果 RL 无法运行（例如在尝试过程中发现硬件错误） 来更新 E 的当前级别），请采取一个使 (E, RL) 不再 名义上可行（例如，错误状态 元素，可用于指定 （E, RL）。

这并非对可能的错误情况进行彻底处理。相反， 它会将错误处理的开发工作委派给 Power Broker（如 排除），同时指出采用主动式错误处理方法 。

不受管理的元素称为非受管元素。它不能包含 依赖项，其所有者直接向 Power Broker 报告其当前级别 当其级别发生变化时。当前级别会影响 依赖于它的元素。

这些元素对于描述非软件状态是必要的 受控并且只能观察到，例如硬件开关的状态 或硬件的错误状态。

功率等级控制

通过受管元素，Power Broker 将负责提升电力 变化。为了限制 讨论的话题，因此我们将把注意力集中在稳定状态 行为。

Power Broker 的控制方案旨在平衡 。

从概念上讲，对用电的需求源于设备的功能 要求。这些要求通常会动态变化，具体取决于 了解用户对设备的当前期望。用户可以打开 并表明某些功率元素 需要以较高的功率水平运行。 或者，设备也可以感应到指示用户就在附近的活动，并且 很可能很快会与其交互，这表明它应该进入 响应时间很短即使应用没有提供内容， 处理方处于非活动状态（基于用户对哪些互动的预期） 会唤醒设备 - 说出启动指令、点击鼠标、点按屏幕、 为了表示电源拓扑的输入需求，我们将引入 该对象称为lease对象。

而限制可能以两种不同的方式出现。在本例中， 无法软件控制的、可能会直接限制耗电量；这是 根据非托管元素进行建模。另一部分是 系统可能需要通过一种方式来表示功率等级在什么情况下应该或不应该消耗 提高以满足租赁需求；通过云技术 依赖项执行政策。

总而言之，这些概念让我们能够指定 Power Broker 指导系统，同时保留随时间变化所需的细微差别 Power Broker RFC。

稳定状态

在任何给定的时间点，由一组特定因素决定着所管理元素的稳定状态。 也就是，在权力的推动下，权力经纪人会指导 决定因素保持不变。在此 RFC 规范中，我们介绍了 Power 稳定状态方面的经纪人控制方案。如此一来，我们就可以 介绍其中涉及的主要概念，同时尽量 必填字段。

稳态行列式

稳定状态的行列式如下：

1. 拓扑结构，即电源元素和依赖关系。

2. 租赁。

   • 租用是针对 元素具有给定功率级别的所有依赖关系 已履行。我们认为，元素级（C、L）的租借 (C, L) 本身，以及 (C, L) 所需的每个元素级。

     租赁表示有特定元素级需求 来自电源拓扑之外的来源。租赁 “能效”部分中描述的耗电原因 要求。

3. 非受管元素的当前级别。

对这些决定性的任何更改都将导致重新评估稳定度 状态。

稳定状态评估

确定稳定状态的关键因素是评估哪些租赁 已执行，这意味着租用的元素级的所有依赖项都是 满意。

Power Broker 以“一刀切”的方式处理租赁事宜。如果有 租用 (C、L)，但 Power Broker 无法或不满足 (C, L)，则将无法满足 (C, L) 的任何依赖关系，除非 因此会产生不同的可满足租约

为了决定是否完成租赁，Power Broker 需要确定是否 可以完成租期，以及是否应该完成。“可以”是 功能要求，并且通过非受管元素级别满足。 回答“应该”的问题需要一个新概念来指定 Power Broker 将主动设法满足对托管式 元素。

为此，我们针对电源引入了两种可能的执行政策。 级别依赖项：强执行方式和弱执行方式。答 依赖项只有在其所需元素受到管理时才能强实现 而对受管理元素和非受管元素的依赖项 。

执行政策也会聚合到依赖项路径。路径 如果路径中的每个依赖项都是 非常可靠；否则，该条件会被弱执行。

现在，给定一组固定的稳态行列式，我们能够指定 完成租赁合同的时间。（C、L）的租约以稳定方式完成 当且仅当 (C, L) 依赖的每个元素级（P、RL）通过 弱执行路径：

• 如果 P 不受管理，则 current_level(P) ≥ RL。
• 如果 P 是受管的，则已履行的另一个租约需要 (P, RL) 处于稳定状态，并通过强效路径依赖于它。

一旦确定了稳定状态完成租赁，则稳定状态功率 简单来说，任何托管元素 C 所要求的最高级别 已履行的租约，或者如果已完成的租约不需要 C 点中的某一个，则需指定 min_level(C) 级别。

有序

Power Broker 将通过执行 操作。尤其要注意 注意，如果所有稳态功率电平都大于或等于电流 那么就一定能达到稳定状态 井然有序

在电量水平的某些情况下，可能会出现无序变化 。为了描述这种情况，我们制定了两项终止政策 关于功率级依赖项：orderly-on-teriation 和 disorderly-on-终止。对受管元素的任何依赖项 终止时有序，而对非受管元素的任何依赖 终止机制无效

与履单政策一样，终止政策也会汇总到 依赖项如果路径中的所有依赖项均为顺序终止时，则 即终止时有序否则，就是终止时混淆。

如果 (E, L) 通过终止时有序路径依赖于 (M, RL)，则幂 代理人将尽可能确保降低 current_level(E) 在 current_level(M) 降到 RL 以下之前，必须低于 L。反之，如果 (E, L) 依赖于 (U, RL) 通过一条终止时无序的路径，本文档的 模型就未必会保证层数变化的 应将 current_level(U) 降到 RL 以下。

从非受管元素方面更具体地描述无序情况， 假设 (E, L) 依赖 (U, RL) 终止，其中 U 为 必须处于非受管状态如果 current_level(U) 降到 RL 以下，则此事件为 超出了 Power Broker 控制范围。没有机会 current_level(E) 低于 L；Power Broker 必须将其降至更低的水平 级别。由于 (U, RL) 上的传递依赖项也会被破坏， 当 U 的当前级别降低时，没有明确的级别变更顺序 调整到新的稳定状态。

依赖项类型

上面的正式描述产生了三种不同类型的依赖项， 我们为其指定名称，如下所示：

基本依赖项始终是非受管元素上的受管元素， 而断言或机会性依赖项始终是由 创建另一个托管元素

示例

不受管理的元素

此示例演示了如何在具有 硬件静音开关。这些元素如下所示：

• 静音开关：当静音开关被断开时，系统的麦克风 运行正常。当麦克风处于“互动”状态时，系统会固定其时钟， 它提供的信号毫无用处

• 输入流：表示从 音频子系统提供给应用的麦克风。处于有效状态 电量基本依赖（静音开关、断开连接）。

• 音频处理器：此元素属于处理 出于未指定目的传入的麦克风数据。

• 系统活动：此元素抽象地表示任务的广度 处理。当该元素为高时， 将处理各种任务；处于“低”状态时，系统会 更有选择性地处理任务。

步骤： <ph type="x-smartling-placeholder"></ph>

最初，租用（音频处理器、活动）会在以下时间保留所有托管元素： 提升的功率水平。

静音开关已切换，静音开关的功率电平立即 不再互动。（输入流、活跃）和 （音频处理器，活动）现已损坏。

Power Broker 立即将输入流和音频处理器 非活跃能量等级。未指定顺序，因为这两个元素的 有效功率等级已经有未满足的依赖关系。

由于音频处理器的依赖项不再使其保持活跃状态，系统活动 将转换为“无效”。

受管元素的机会性依赖项

在本示例中，有两项功能要求系统活动元素级别为“高” 才能运行高优先级功能的依赖性是断言，因此系统 如果租用（高优先级功能、 有效）。但低优先级功能的依赖性是机会性的，因此只能 一旦租用高优先级功能会导致系统活动 高。

步骤： <ph type="x-smartling-placeholder"></ph>

存在租用（低优先级功能，有效），但 Power Broker 不会 满足该条件，因为对（系统活动，高）的依赖是机会性的。

租期已进行（高优先级功能，有效）。这会改变稳定状态。

系统活动状态已提升为“高”。

按照无特定顺序，两个特征级别都将提升为“有效”，同时满足 出租。

（高优先级功能，有效）的租约被取消。在新的稳定渠道中， 状态，则（低优先级功能，有效）的租约将不再履行。

高优先级功能降为“未启用”。（注意：此 RFC 并不保证 此状态更改发生在低优先级功能级别降低之前）。

为了保持井然有序，系统活动会保持“高”，直到低优先级功能启用 降为“无效”。 此步骤突出显示了很多人都认为机会性依赖项的一个属性。 感到惊喜机会性依赖项与断言依赖项不同 它们的执行方式不同，但 Power Broker 对这两种依赖项类型一视同仁 时。

系统活动最终降至“低”。

错误状态元素

元素所有者可以使用不受管理的元素来模拟错误状态， 可禁止某些功率等级的可操作性。下图说明了 对于级别为 L₀ 的元素 E，有两个可能的错误元素， L₁、L₂、L₃。

在上述情形中，错误元素的级别会直接镜像 E。如果 current_level(Error State)=="L_i OK"，则 L_i 是 E 可以运行的最高级别。在下面的场景中， 错误元素会在 L₂ 或 L₃ 阻止 E 的运算，前提是 current_level(Error State)==错误。

此机制仅用于停用 元素架构。您也可以使用其他机制来停用关卡 至少还有一个层级保持可运行状态， 在出现用例时对其进行检查。

归因

Power Broker 将支持将当前功率等级归因到租赁 满足的是什么。如果事实证明这样做有用，Power Broker 将提供支持 明确要求特定级别的租赁与那些 适时需要使用它。

可观测性

Power Broker 将公开有关电源元素的信息，包括其功率 级别架构及其依赖项，通过 Fuchsia 成熟的诊断功能实现 设施。它将进一步保留租赁和功率水平的记录 过渡到某些合适的、可能可配置的回溯期。 这些信息总体上有助于检查拓扑的状态 同时提供未来推出的各种工具 拓扑的最新历史记录

配置

电源拓扑的许多方面都很容易通过静态捕获 配置。例如，前面介绍的 USB 示例 可将其描述为：

    [
        {
            name: "USB Bus",
            levels: ["Off", "On"],
        },
        {
            name: "USB Device",
            levels: ["Off", "On"],
            dependencies: {
                "On": ("USB Bus", "On")
            },
        }
    ]

当必须跨组件识别元素时，情况会变得更加复杂 边界。使静态配置简单明了的技巧将如下： 与组件框架团队合作进行了研究。

今后的主题

转换延迟时间支持

从长远来看，电源拓扑旨在为 理解和优化系统状态转换的延迟时间。电源 元素定义将建立一个规范位置，以对预期进行编码 本地转换延迟时间，即更改元素的 确定所有依赖项的状态。本地元素延迟时间 但随着给定系统的成熟，可以添加它们。

本地延迟的应用包括：

• 半静态分析（例如，通过在 运行时）跨越多个元素的复合操作的延迟时间。
• 运行时跟踪观察到的延迟时间并报告出发位置 预期。
• 向客户端报告延迟时间估算值，以支持 过于严格的时间要求。

其他类型的状态和依赖项

我们引入的权力级别和依赖关系类型 表示元素状态的起点。他们 提供了一种方式来捕获系统中大量状态之间的依赖关系， 而不需要进行繁琐的重复操作。他们 而且可以不受冲突使用 并不在所有情况下都符合预期，但应该用于任何

随着电源拓扑的演变，支持 其他类型的状态和依赖项。例如：

• 可以通过实现传感器的固件来支持一组不相交 每种操作模式都经过优化 但其没有遵守严格提高 功能和功耗。虽然这种传感器可以描述为 二元幂元件，我们可能会转而引入一种新型 可以同时描述所有模式的状态架构， 规则来解决竞争客户端之间的冲突。
• 某些类型的硬件（如 GPU）的功率等级可能会基于其选择 介绍多个客户端同时加载的要求。有可能 电源拓扑支持捕获此类负载的依赖项 并以通用方式累积它们。

目前，此类进展是推测性的；因此，您应重新访问它们 在初始子系统与电源拓扑的整个集成过程中必不可少。

实现

实现电源拓扑本身并在整个 Fuchsia 中使用 只是一个庞大的项目我们将围绕这几个工作， 因此需要对初始设置进行大幅优化 实现。与此同时，Fuchsia 子系统对 电源管理工作，在许多情况下，他们的开发者需要开发 适当的电源管理策略 添加到电源拓扑中。

将开发策略分为多个不同的阶段是很有帮助的， 都属于历史特征在第 1 阶段， 隔离，然后在第 2 阶段进行少量集成，以演示 关键用例，并支持对系统挂起/恢复进行端到端测试。装备完备 通过前两个阶段的学习，我们现在将在第 3 阶段奠定基础 这将支持更多集成，并带来稳定的开发周期， 如第 4 阶段及以上所述。

第 1 阶段（历史）：核心功能

• Power Broker 管理电源拓扑。
• 系统活动调节器可定义和管理 系统挂起/恢复操作。
• 驱动程序框架支持将驱动程序与 Power Framework 集成。 （Power Framework 功能将通过 标准方式，无需特殊支持。）

第 2 阶段（历史）：概念验证电源框架 集成

• 与驱动程序进行初始集成，该驱动程序可将硬件置于较低层级和 高功率状态。
• 与支持唤醒源的驱动程序进行初始集成。
• 在端到端暂停/恢复工作流中的首次使用。

第 3 阶段（目前在撰写本文时）：纵向扩容

• 请批准此 RFC；提议并批准 RFC，以便《权力》获得支持 代理程序、系统活动调节器和功耗感知驱动程序。
• 说明现有实现施加的设计限制，例如 延迟时间开销施加的有效速率限制
• 确定并设计下一组与 Power Framework 的子系统集成。
• 制定最佳做法和设计模式并编制文档。
• 确定并实施小规模改进措施，协助进行集成 （例如 API 改进、直接优化）。
• 建立测试程序和支持库，其中包含 Power Framework 特有的特定领域问题。

• 确定大规模添加功能所需的优先事项，并 改进。可能的情况包括：

  • 支持跟踪转换延迟时间。
  • 需要进行重大界面更改的性能改进 和/或后端实现工作。
  • 简化了组件框架集成。

第 4 阶段及以上：进一步集成和大规模改进

• 集成其他子系统。
• 在适当的情况下优化现有的集成。
• 继续根据新兴的需求进行小幅改进。
• 实现优先级最高的大规模改进。
• 确定需要在下一阶段解决的更大规模的改进措施（如果有）。

性能

效果提升的许多方面都是最适合在阶段 3 个 RFC，其中 Power Broker 与此最相关 提案的概念构建过程不过，在当前范围内， 考虑效果影响的一般准则。

本地与非本地效果对比

本地营销效果与非本地广告效果之间存在矛盾 要求与通过 Power Broker 通常会产生至少一些可通过 完全本地化的解决方案不过，单纯的本地化解决方案并不能充分满足 支持执行有效的非本地分析所需的系统级分析 优化。

识别延迟开销

Power Broker 的电源拓扑管理将产生一定量 延迟开销，特别是因元素所有者和 。然而，批判性地思考什么是费用， 确实会带来开销需要特别注意的是，一些子系统本身会要求 从而实现任何形式的电源管理， 并与电源拓扑集成 。

大小驱动型延迟开销

由系统级挂起和恢复等系统级暂停和恢复等 不太频繁的节点主要受子图大小的影响 影响的因素。了解子图表的影响非常重要 广度、深度和节点数。

QPS 驱动的延迟开销

目前，影响 Power Broker 的 QPS 主要是： 暂停阻塞租赁；相关功率元素将在 系统活动调节 RFC。

对于 Power Broker 必须支持的 QPS，目前还没有明确的要求。 相反，某些子系统集成可能需要阻止 因事件达到足够高的频率而被暂停， 租期会产生太多开销在这种情况下， 将多个事件的处理整合到一个 单个暂停阻塞租用。

为帮助进行此类评估，每项租赁的延迟时间开销的估算将是 非常重要。

安全注意事项

第 3 阶段 RFC 更贴近具体实施的提案可提供范围更广的 讨论。在这里，我们将概述使用 电源拓扑

电源依赖项和功能

因为电源拓扑使用依赖关系将电源元素提升至更高层级 功率等级，声明对特定功率元素的依赖性 本身就是一项特权操作。因此，为了符合 Fuchsia 的安全要求， 依赖项声明应明确在 相当精细，至少按元素划分

到目前为止，Power Broker 已采用集中式权利管理方法， 根据当前支持的功能类型严格处理权限。 我们之所以选择这种方法作为一种经过慎重考虑的决策，是为了更快地实现完整的 与并发进化相比，对电源拓扑的影响 都允许从长远来看，组件框架 能够更多地表示与电源拓扑相关的功能 Power Broker 可以自然而然地承担一些安全相关责任 以及支持更顺畅的开发者体验。

集中管理风险

使用 Power Broker 作为中央管理员会使其面临如下风险 DDoS 攻击，可能会阻止其管理系统关键状态 以及规避其权限逻辑的行为， 攻击者能够恶意操纵硬件状态。

隐私注意事项

由于详细的子系统状态将在设备上跟踪，因此请务必 确定在舰队中利用这些数据的同时如何尊重隐私问题 指标。此问题会在第 4 阶段或之后得到最有效的处理， 我们才能有力地展示 Power Broker 可能导出 大量子系统。

测试

第 1 阶段已纳入所有功能的单元测试 以及针对虚构客户端和 集成测试将 Power Broker 与 System Activity Governor 相结合。

第 2 阶段添加了端到端挂起/恢复测试，并支持 针对系统活动调节器的非封闭驱动程序测试。

第 3 阶段将建立正式支持，具体方式包括库和 文档，用于在各种用途中测试与 Power Framework 的集成 同时扩展端到端 测试。

文档

此 RFC 是权力领域概念定义的可信来源

相关文件将添加到地址中，并非详尽无遗：

• 对此处定义的概念的可读性进行了优化的说明。
• 集成指南。
• 真实的电源拓扑集成示例。
• 电源元素的建议使用模式。

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

缺点

与此提案相关的两项主要费用是：

• Power Broker 的实现。在撰写本文时，Power Broker 有 与概念相比，可以正常运行的实现 所以这个开销很小
• 分散客户集成费用。我们将研究减少 这些成本通过文档和客户端库（尤其是 FIDL） 评分准则的注意事项）以及测试支持。

替代方案

分散电源控制

作为电源拓扑的一种极端替代方案，可以考虑采用 无需集中式电源管理在这样的系统中，子系统会提供 自定义接口，通过这些接口将其驱动到不同的电源状态。

适用于任何需要子系统采用特定电源的系统级模式 一些“模式控制器”将需要负责确保 使每个子系统处于相应模式的适当电源状态。这样 实体将需要使用每个子系统特定的接口。

负责有效控制给定模式的电源状态的实体 针对该模式执行集中式电源管理，因此，此方法 真正分散。同时，需要模式控制器控制每个 子系统使用自己选择的界面创建显而易见的扩展， 问题。这些因素结合在一起，我们预期 Fuchsia 必须 至少支持某种形式的集中电源管理， 接口标准化。

值得注意的是，此提议并未对 子系统应使用电源拓扑。一些子系统开发者 最适合执行仅公开一两个选项的轻度集成 根据需要将全局子系统状态连接到电源拓扑，以进行集成 具有系统模式转换功能其他人可能发现更深入地利用 这些集成功能可对整个平台中的子系统进行全面建模， 。

操作顺序

我们提出的基于状态和依赖关系的方法的替代方案是 实现特定操作的顺序标准化，实质上泛化 驱动程序具有“挂起回调”的概念和“恢复回调”为 是创建正常运行系统所必需的。在 Linux 中 暂停/恢复，采用四项形式 可能的挂起驱动程序回调（prepare、suspend、suspend_late、 suspend_noirq）和四个表示简历（resume_noirq、resume_early、resume、 complete)。

我们选择不采用此方法的原因有多个：

• 它可能会隐藏设备在系统挂起状态下的状态 或处于已恢复状态公开这些状态的过程将 很大程度上是为了创建此处提议的拓扑。此外，这些州 可能取决于设备在工作期间的预期行为 已暂停。

• 让用户不清楚是否“暂停”和“Resume”描述 在任何给定设备或整个系统上执行的操作。

• 这表明，它很容易满足意料之外的要求， 上面的 _late/_early 和 _noirq 回调变体。

• 有序依赖项管理问题适用于任何形式的 电源状态控制，而不仅仅是对系统范围的挂起和恢复操作。

• 状态间依赖关系图仍然存在于抽象中， 采用操作序列方法，但它隐含在源代码中。

命令式断电

作为按需利用的替代方案，Power Framework 可以使用 命令式断电模型，其中电源元素默认为高功率 而必须明确命令其下层状态。这种方法可以简化 某些功能在短期内实现的功能，但更重要的是 因此很容易受到未跟踪的依赖项的引入。此外，它还可以 不能自然地支持归因。

同时，按需利用率模式可以适应命令式断电的情况 特定作用域（如果需要）。具体而言就是电源拓扑 一个使用方元素，其目的是将资源提取到所需的 默认功率级别，其中消费者机主提供更改界面 根据需要调整该级别然后，使用方元素可用于 表示在系统级视图中对命令式断电的使用。

推迟的主题

以下问题和问题将在 Power Broker RFC 中解决：

• 元素和依赖项的生命周期。
• 租期生命周期。
• 根据指南，有关电量定义的 API 版本控制问题 在兼容性提案中，待处理 更新。
• Power Broker 是否向待租租赁的持有人提供任何反馈？
• 与拓扑集成的子系统的测试准则， 特别是在使用虚假的 Power Broker 与使用真实的 Power Broker 方面 以及虚假的电源元素。
• 用于以原子方式添加/移除依赖项的 API。
• 处理冗余的依赖项。
• Power Broker 崩溃时的行为。
• 元素所有者崩溃时的行为，包括与优雅的比较 关停/启动。
• 错误处理。

先验技术和参考资料

Linux

• 设备电源管理基础知识
• Linux 中挂起到空闲支持的演变 Kernel
• sysfs 电源接口
• 设备关联

Mac OS

• 管理权力 - IOKit 基础知识

Windows

• 电源管理概述 框架
• 设备电源状态
• 电源框架 (PoFx) 驱动程序 示例