RFC-0250：電源拓撲

摘要

系統電源管理的主要問題之一，是支援各種系統元素 (我們用這個詞簡單指稱具有狀態的項目，包括硬體和軟體) 的狀態轉換，同時適當管理這些狀態之間的相互依賴關係。這項提案指定了名為 Fuchsia Power Topology 的模型，可實作該模型來解決這個問題，同時提供歸因和可觀測性相關問題的解決方案。這項工作著重於建立概念架構，並嚴格定義術語；未來的 RFC 將更密切地處理與實作相關的設計。

提振精神

狀態管理問題

這項提案源自於 Fuchsia 中支援系統暫停/繼續作業的需求，如 RFC 230 所述。

系統暫停的主要工作是確保所有硬體元素都已進入適當的低功耗狀態，然後 CPU 才會停止執行指令。從表面上看，這似乎是深一層的依附元件管理問題：硬體元素的「作用中」狀態取決於 CPU 的作用中狀態，因此硬體元素必須先進入暫停狀態，CPU 才能暫停。

不過，硬體元素可能彼此相依，舉例來說，裝置必須先暫停，匯流排才能停用電源。同時，裝置可能有多種狀態，在不同條件下系統暫停期間，這些狀態都適合使用，例如裝置要當做喚醒來源時應使用的低耗電狀態，以及裝置不當做喚醒來源時應使用的完全關機狀態。此外，相關的狀態管理問題不只會發生在系統暫停時，CPU 處於活動狀態時，硬體元素可能會進入低功耗狀態，例如手機處於飛航模式時，需要關閉特定無線電。

因此，建立支援互依狀態轉場的架構非常重要。由於電源管理是這類轉換的必要主因，因此這項責任落在 Fuchsia 的 Power Framework。我們導入「電源拓撲」一詞，彈性地指稱這個架構核心的依附關係圖和架構本身。

在開發電源拓撲時，我們發現管理硬體元素間狀態依附元件的概念，自然延伸至軟體元素，可在硬體或自然描述使用者面向功能的啟用/停用狀態之上，提供更高層級的抽象化。具體來說，明確擷取支援面向使用者功能所需的依附元件，可建立自然機制來強制執行隨選使用，確保依附元件只在需要時使用，並將所用資源歸因於需要這些資源的功能。元件的歸因也很重要，但功能與耗電原因的關聯性更高，因此需要子元件層級的歸因。

我們建立的概念會強制執行以需求為準的狀態變化，讓電源拓撲不僅能編碼系統中各元素支援的狀態，還能編碼驅動狀態變化的規則。這項功能可為產品開發人員和系統工程師提供強大工具，讓他們能夠審查全系統行為，並透過拓撲 (而非原始碼) 提議功能變更。

為什麼要採用新拓撲？

Fuchsia 已有兩種重要拓撲，用於描述驅動程式和元件。不過，這兩種方法都無法輕易解決狀態管理問題。因此，我們自行開發電源拓撲，並預期會定期重新檢視元件和驅動程式庫圖表，釐清電源拓撲與這些圖表的關係。

為方便參考，我們將簡要回顧現有拓撲。

元件拓撲說明兩件事：元件例項之間的父項/子項關係，以及能力轉送圖。這是描述元件例項階層的樹狀結構，功能會對應到該樹狀結構頂端的 DAG。如果元件需要存取另一個子樹狀結構的能力，該能力會透過父項路徑傳送。

驅動程式管理器也會以 DAG 形式追蹤自己的節點拓撲。在驅動程式庫程式架構中，節點是裝置的抽象概念，驅動程式會繫結至節點，以使用相關聯的資源，例如存取 MMIO 暫存器。驅動程式是元件拓撲中的元件，但會扁平化為集合。這種結構的原因是，元件拓撲無法表示沒有繫結驅動程式庫的節點，且節點可能有多個父項 (稱為複合節點)，但元件拓撲的樹狀結構不允許這種情況。

利害關係人

協助人員：

Adam Barth abarth@google.com

審查者：

• 電源：Kyle Gong kgong@google.com
• 電源：Michael Brunson mbrunson@google.com
• 驅動程式架構：Justin Mattson jmatt@google.com
• 驅動程式架構：Harsha Priya NV harshanv@google.com
• Zircon 核心：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 Framework、元件架構、Driver Framework、Drivers 和 Zircon 團隊的審查人員審查。在 Power Broker 和 System Activity Governor 的類似設計程序中，這項機制已進一步改良，兩者都將成為即將發布的 RFC 主題。

需求條件

依附元件管理井然有序

如先前所述，系統電源管理的主要問題之一，就是以尊重這些狀態之間依附元件的方式，管理不同系統元素的狀態變化。這類依附元件的影響包括：

• USB 裝置必須在匯流排供電後才能開啟。
• 只有在電壓軌供應的電壓足夠高時，時脈才能以特定頻率運作。
• 影片串流應用程式必須有有效的網路連線，才能開始串流播放影片。

一般來說，特定系統元素 E 可能有一組可佔用的狀態 S₀、S₁、S₂...。如要讓 E 正確佔用特定狀態 S_i，必須滿足 S_i 的所有依附元件。

如果作業會隨時保留所有系統元素狀態的依附元件，我們就稱之為「有序」。具體來說，對於每個候選狀態為 S_i 的元素 E：

• 只有在滿足該狀態的所有依附元件後，E 才會輸入 S_i。
• 如果 S_i 的其中一個依附元件要中斷，E 必須先退出 S_i。

電源架構必須支援參與系統元素的有序狀態轉換。

如果無法依序執行狀態轉換，Power Framework 應確保元素處於明確定義的狀態，並盡量減少無序變更的元素數量。

歸因

系統元素可能會處於各種狀態，其中有些狀態的耗電量較高。當元素處於高耗電狀態時，電源架構必須能夠判斷原因。

睡眠效率

系統元素應驅動至最低電源狀態，而 Power Framework 可將運作原因歸因於該狀態。架構使用者必須有簡單明瞭的方法，視需要將元素驅動至更高功率狀態，但可能需要導入新的歸因原因才能達成。

可觀測性

電力架構必須支援觀察系統元素狀態，架構使用者認為這些狀態與耗電量相關。

效能

如果系統元素能夠以符合一組產品需求的方式執行狀態轉換，電源架構就必須充分支援這些元素。這大致可分為兩項考量：

• 不影響本機成效。Power Framework 不得為個別系統元素的狀態轉換帶來過多延遲。

• 支援非本機效能最佳化。Power Framework 應支援跨多個元素的狀態轉換最佳化。

  • 舉例來說，假設在系統暫停作業期間，圖形和音訊子系統會平行進入低功耗狀態。電源架構應指出這些動作是並行執行，並提供洞察資訊，瞭解哪個動作耗時較長，以便適當專注於其中一個動作，最佳化系統暫停作業的延遲時間。

獨家

電源拓撲會引發對非常大的問題空間的考量。這項提案「不會」具體處理下列主題：

• Power Broker 詳細規格。這項 RFC 必須建立 Power Broker 的一些基本層面，才能開發拓撲模型。不過，我們盡量將 Power Broker 的規格留給即將發布的 Power Broker RFC。Power Broker 會實作超出本文詳述模型的行為，我們希望為其提供所需的所有彈性。
• 一流的錯誤處理機制。本文開發的拓撲模型並未提供處理狀態轉換錯誤的明確方法。這項排除條件是前一個項目的延伸，不會對 Power Broker 的錯誤處理造成影響，主要目的是不施加任何限制。
• 惡意行為人。Power Broker 和元素擁有者之間的責任劃分，最終需要考慮行為不當且出乎意料的元素擁有者。
• 以期限為準的狀態轉換。為確保系統能及時採取全系統動作，自然會考慮為個別狀態轉換設定應用程式時間限制。

我們會進一步考量這些問題，因為用途會提供具體需求。

設計

本文涵蓋的設計會建立電源拓撲的基礎模型，與任何特定介面或實作無關。就實務而言，開發人員若打算將子系統與電源拓撲整合，也必須留意幾項即將發布的 RFC：

• Power Broker RFC 將說明管理電源拓撲的介面，以及實作這些介面的元件。
• 系統活動調控器 RFC 會說明電源拓撲與系統暫停/恢復程序整合點。
• Power-Enabled Drivers RFC 將說明整合的驅動程式庫特定層面。

不過，拓撲模型本身就相當複雜，因此需要專門的文件說明。這項 RFC 旨在以連貫的概念架構，認可相關概念，為其他 RFC 奠定基礎，並據此開發穩定的說明文件，協助 Power Framework 使用者進行整合。

電源拓撲和核心概念

這項設計的主要功能需求是上述整齊度規定。首先，我們需要確定哪些系統元素可能參與模型、可能佔用的狀態類型，以及這些狀態可能透過電源拓撲表達的依附元件。這樣我們才能有條不紊地指定如何控制這些狀態。

電源元素

電源元素是這項設計中的基本有狀態實體。電源元素可處於有限數量的狀態，且在任何時間點都只會處於其中一種狀態。有時可將電源元素視為一般裝置模型，但也可以簡單地視為狀態的容器。

特定硬體裝置可能直接對應單一電源元素，但也可能使用多個電源元素來模擬，以描述不同的裝置狀態。舉例來說，您或許可以分別設定觸控感應器的取樣率和位置追蹤容量；感應器的驅動程式庫可能會因此公開獨立的「取樣率」和「位置追蹤」元素。

電源元素也可用於模擬更抽象的概念，例如涵蓋多個硬體元件的子系統整體狀態，或是面向使用者的軟體功能啟用/停用狀態。

功率等級

電源等級是指電源元素可佔用的狀態。電量層級結構定義包含特定電量元素可能佔用的電量層級集合，以及稍後會說明的相關中繼資料。

Power Framework 假設結構定義中的層級遵守多項限制。架構使用者有責任確保在指定電源元素的結構定義時，這些限制會準確反映所要模擬實體的屬性。這些限制包括：

1. 你可以依耗電量遞增排序。(測量功率的方法有很多種；就目前意圖和目的而言，只要針對特定情境定義「一般」耗電量即可。)其餘限制則以這個順序表示。
2. 依附元件是累加的：對於特定元素，在 L 層級正確運作所需的任何資源，在任何 M 層級 (M > L) 也都需要。

3. 功能會累加：針對特定元素，層級 L 提供的任何功能，也會由任何層級 M > L 提供。

   • 這項規定可避免電源元件的依附元件發生衝突。舉例來說，如果一個依附元件需要第 N 層的功能，另一個依附元件需要第 (N+1) 層的功能，則元素可在第 (N+1) 層運作，同時滿足這兩項需求。

功率位準結構定義包含：

• 結構定義中每個功率等級的標籤。
• 耗電量遞增的等級順序。

範例

為方便說明，我們會使用字串標籤，並以由下往上排序的直向清單表示排序順序。(實際表示功率等級的方式詳情，請參閱 Power Broker RFC)。

以下說明三種可能的功率位準結構：

特別要注意的是，電源層級的排序方式與 ACPI 電源狀態的慣例相反。這個選擇消除了隨意用字中令人遺憾的模糊之處。根據 ACPI 慣例，「較低的電源狀態」這類運算式有兩種直接衝突的解讀方式，取決於「較低」是指耗電量 (對應於排序順序中較高的索引)，還是排序順序中的索引 (對應於較高的耗電量)。「較低的功率」等運算式不會有這種模糊不清的問題。

並非所有電源元素都能使用與其他元素共用的通用電源等級結構。舉例來說，您可以定義電源元素，指定 CPU 執行的最低頻率，此時電源等級會對應至相關 CPU 支援的頻率。

用途和限制

電量層級結構定義是表示元素狀態的實用起點，原因如下：

• 可清楚表達常見模式，例如上方所示。
• 這類函式提供一種方法，可擷取大量狀態之間的依附元件，並以匯總方式處理，不必重複執行繁瑣的作業。
• 這些屬性可無衝突地使用，雖然無法保證在所有情況下都適用，但應盡可能使用。

單一電源元素和電源等級結構定義，不足以描述 Power Framework 使用者感興趣的所有情境。舉例來說，單一裝置的不連續運作模式 (以簡單但與情境無關的例子來說，請考慮可加熱或冷卻房間的熱泵)，無法準確模擬為單一電源元素。

不過，功率位準結構定義可用於描述更複雜的系統。相關最佳做法不在本 RFC 的討論範圍內，我們將在即將發布的說明文件中說明這個主題。架構使用者也可以透過 Fuchsia > Power 元件，向 Power Framework 團隊回報錯誤。

可操作性和依附元件

在任何時間點，根據目前的系統狀況，電源元件都能在部分電源層級正常運作。這些是可運作的層級。這個子集一律包含小於或等於可運作最高層級的所有層級，以元素 E 來說，就是 max_operable_level(E)。

電量等級依附元件是一種條件，表示一個電源元件的可運作等級與另一個元件的目前電量等級之間的關係。功率等級依附元件表示，如要讓子項元素 C 以 L 級以上的功率運作，父項元素 P 必須以 RL 級的功率運作。更精確地說，(C, L) 對 (P, RL) 的依附元件是指：

• 如果 current_level(P) < RL，則 max_operable_level(C) < L。

同樣地，這個條件也可以表示為：

• 只有在 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 必須滿足下列必要條件集合，才能運作：

• 所有 P ∈ required_elements(C, L) 的 current_level(P) ≥ min_required_level(P; C, L)。

滿足這些條件時，我們稱 L 為「名義上可運作」。即使在名義上可運作，L 也可能無法運作；當地狀況 (例如可能未觀察到的硬體錯誤) 可能會導致 C 無法在 L 運作，即使所有相關的功率等級依附元件都已滿足也是如此。名義可操作性應視為電力拓撲嘗試模擬真實可操作性的方式。雖然這兩個概念之間難免會有差異，但如果元件設計人員盡量縮小這類差異，電源拓撲就能發揮最佳效能。

一個電源元素可能有多個電源層級，取決於另一個元素。 固定父項和子項的所有這類層級依附元件會形成電源元素依附元件。如果 C 的至少一個層級依附於 P 的其中一個層級，我們就會說 C 依附於 P。

電源拓撲

做為正式實體，電源拓撲是多邊圖，電源元件是節點，電源層級依附元件是導向邊緣。此外，我們還對這個圖表施加下列限制：

1. 非循環性：電源拓撲為非循環性。

   • 特別是父項/子項關係的行為符合預期；如果元素 C 依附於元素 P，則 P 可能不會依附於 C。

2. 最低等級可操作性：無論其他元素的目前等級為何，任何電源元素的最低功率等級都必須一律可操作。此外，它可能沒有電量層級依附元件。

   • 這項條件是指可操作性，而非名義上的可操作性，可確保每個元素至少有一個可操作的層級。必須由元素擁有者強制執行。

   • 允許一個元素的最低層級取決於另一個元素的最低層級，對可操作性不會有任何影響。但這類依附元件在功能上並不相關，而且允許這類依附元件也需要考慮僅透過最低層級相互依附的元素。

電源拓撲可能包含多餘的電源層級依附元件。舉例來說，(C, L) 可能同時依附於 (P, RL₁) 和 (P, RL₂)，其中 RL₁ < RL₂，即使依附於 (P, RL₂) 所施加的條件嚴格強於依附於 (P, RL₁) 所施加的條件。在本提案的模型中，這類多餘項目視為無害，但在實作時可能會受到特別考量。

範例和背景資訊

注意：這些範例僅供說明。這項 RFC 不會影響必須使用電源元素建模的項目。

最基本的電源等級依附元件形式與開/關狀態有關。以非常簡化的例子來說，我們可能會表示 USB 匯流排必須開啟，USB 裝置才能開啟，如下所示：

如要依序處理上述依附元件，必須先開啟匯流排，再開啟裝置電源；關閉匯流排前，必須先關閉裝置電源。

更廣泛的功率等級依附元件定義可容納更複雜的關係，例如 DVFS 期間的時脈和電壓耦合。(DVFS 的時間敏感度足夠，可能不適合整合電源拓撲，但可做為實用範例)。假設我們有一個時脈，其 DVFS 表格如下，列出支援的頻率和所需電壓：

這個表格會轉換為下列電源元素、層級和依附元件：

(請注意，(時脈頻率，1.4 GHz) 對 (電壓，700 mV) 的依附元件技術上不會納入拓撲，但為了方便與表格比較，因此會顯示出來)。

代表軟體功能或裝置使用者層級運作模式等項目的電源元素，可能需要許多依附元件來描述運作所需的所有資源。在另一個簡化的例子中，視訊通話用戶端的「Active」層級可能取決於進行視訊通話所需的各種硬體子系統：

最後，多個子項元素可能會依附於同一個元素。在此，我們描繪的裝置會以延遲時間描述電量。用戶端 A 的「Active」層級需要低延遲，用戶端 B 則需要中等延遲。裝置以低延遲運作時，可滿足兒童的「活躍」等級。

這個範例說明電源等級的重要屬性：電源等級的定義方式可確保不同用戶端的電源需求不會衝突。

邊緣方向慣例

如目前為止的圖表所示，我們採用慣例，電源拓撲中的邊緣會沿著依附元件的方向，從子項到父項。在某些討論中，可能無法避免使用以電力流向為基礎的直覺式術語，也就是從父項到子項。目前我們打算將依附元件的方向用於所有正式開發作業，並建議讀者注意這個問題。

管理效能等級

如要指定如何在實際系統上使用電源拓撲，接下來需要定義負責管理拓撲和個別電源元素的各方。

Power Broker

電源拓撲會由名為「Power Broker」的 Power Framework 元件管理。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 將負責推動拓撲中的大部分功率位準變化。為限制本 RFC 中討論的設計介面，我們只會關注穩定狀態行為。

Power Broker 的控制機制旨在平衡用電需求和限制用電的條件。

從概念上來說，裝置的功能需求會產生用電需求。這些需求通常會根據使用者對裝置的期望而動態變化。使用者可能會開啟應用程式來完成特定工作，這表示與該應用程式相關聯的特定電源元件需要以較高的電源層級運作。或者，裝置可能會感應到使用者在附近，且可能很快就會與裝置互動，因此建議進入低延遲回應模式。根據使用者對喚醒裝置的互動方式 (說出熱字詞、點選滑鼠、輕觸螢幕等) 的期望，即使應用程式處理器處於閒置狀態，仍會出現需求。為向電源拓撲表示需求進入，我們將導入名為「租約」的物件。

同時，限制條件可能以兩種不同方式產生。在某個案例中，無法透過軟體控制的狀態可能會直接抑制耗電量，這類狀態會以未受管理的元素為模型。在其他情況下，系統可能需要一種方式來表示何時應提高或不應提高電量，以滿足租約所表達的需求；這項需求會由依附元件履行政策擷取。

總而言之，這些概念可讓我們指定 Power Broker 引導系統達成的穩定狀態，同時將時間相關層面所需的細微差異留給 Power Broker RFC。

穩定狀態

在任何時間點，一組特定因素都會決定受管理元素的穩定狀態，也就是只要決定因素維持不變，Power Broker 就會引導這些元素達到的功率等級。在本 RFC 的範圍內，我們將以穩定狀態來說明 Power Broker 的控制機制。這麼做可讓我們介紹相關的重要概念，同時限制所需詳細資料的數量。

穩定狀態決定因素

決定穩態的因素包括：

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) 透過弱式滿足路徑依附於每個元素層級 (P, RL) 時，(C, L) 的租約會在穩定狀態下滿足：

• 如果 P 未受管理，則 current_level(P) ≥ RL。
• 如果 P 受到管理，則 (P, RL) 是另一個在穩定狀態下滿足的租約所需要，且透過強烈滿足的路徑依附於該租約。

一旦確定租約的穩定狀態履行情況，任何受管理元素 C 的穩定狀態功率等級，就只是履行租約所需的最大等級，或者如果沒有履行租約需要 C 的任何等級，則為 min_level(C)。

井然有序

Power Broker 會盡可能依作業的依附順序執行作業，引導系統達到穩定狀態。特別要注意的是，如果所有穩定狀態功率位準都大於或等於目前的功率位準，則保證可循序達到穩定狀態。

在某些情況下，功率降低時可能會發生無序變化。為說明這類情況，我們針對電源層級依附元件推出兩項終止政策：orderly-on-termination 和 disorderly-on-termination。對受管理元素的任何依附元件都會在終止時依序執行，而對未受管理元素的任何依附元件則會在終止時無序執行。

與運送政策相同，終止政策會匯總至依附元件路徑。如果路徑中的所有依附元件都依序終止，則路徑也會依序終止。否則為無序終止。

如果 (E, L) 透過有序終止路徑依附於 (M, RL)，Power Broker 會盡可能確保 current_level(E) 降至 L 以下，然後 current_level(M) 才會降至 RL 以下。反之，如果 (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 的目前層級一降低，(U、RL) 的遞移依附元件也會隨即中斷，因此系統會驅動至新的穩定狀態，無法強制執行層級變更的明確排序。

依附元件類型

上述正式說明衍生出三種不同的依附元件類型，我們將其命名如下：

基本依附元件一律是受管理元素對非受管理元素的依附元件，而斷言或機會依附元件一律是受管理元素對另一個受管理元素的依附元件。

範例

未管理的元素

這個範例說明如何在具有硬體靜音切換鍵的系統上使用未受管理元素。這些元素包括：

• 靜音切換開關：如果靜音切換開關未啟用，系統的麥克風會正常運作。如果麥克風處於「已啟用」狀態，時鐘會固定，因此提供的訊號無效。

• 輸入串流：代表音訊子系統從麥克風傳送至應用程式的輸入資料串流。其「Active」(有效) 電源層級基本依附於「Mute Switch」(靜音開關) 和「Disengaged」(已解除)。

• 音訊處理器：這個元素屬於應用程式，會處理麥克風輸入的資料，但用途不明。

• 系統活動：這個元素抽象地代表系統允許的任務處理範圍。如果這個元素是「高」，系統會處理各種工作；如果是「低」，系統會更有選擇性地處理工作。

步驟：

一開始，(音訊處理器、Active) 的租約會將所有受管理元素維持在高功率狀態。

靜音切換開關已切換，且靜音切換開關的電源層級立即變更為已停用。(輸入串流、有效) 和 (音訊處理器、有效) 的依附元件都已中斷。

Power Broker 會立即將輸入串流和音訊處理器都驅動至「閒置」電源層級。由於兩個元素「Active power levels」都已有未滿足的依附元件，因此未指定排序。

音訊處理器的依附元件不再將其設為「有效」，系統活動會轉換為「無效」。

視代管元素而定的依附元件

在本範例中，有兩項功能需要「系統活動」元素達到「高」層級才能執行。高優先順序功能的依附元件是斷言，因此如果 (高優先順序功能，有效) 的租約需要，系統活動就會升級為高優先順序。但低優先權功能的依附元件是機會主義，因此只有在高優先權功能的租約將系統活動提升至高優先權時，才能提升至「有效」。

步驟：

「低優先權功能，有效」有租約，但 Power Broker 不會滿足該租約，因為「系統活動，高」的依附元件是機會主義。

已取得租約 (高優先順序功能，有效)。這會變更穩定狀態。

系統活動已提升至高優先順序。

兩個功能層級都會提升至「有效」狀態，並滿足兩個租約。

「高優先順序功能，作用中」的租約已捨棄。在新的穩定狀態中，(低優先權功能，有效) 的租約將不再履行。

高優先順序功能降為「停用」。(注意：這項 RFC 無法保證這項狀態變更會在低優先權功能的層級降低前發生)。

為維持秩序，系統活動會保持在高優先順序，直到低優先順序功能降為非使用中為止。 這個步驟會強調機會依附元件的屬性，許多人會覺得很驚訝。機會依附元件與斷言依附元件的滿足方式不同，但 Power Broker 會同等處理這兩種依附元件類型，確保關機順序井然有序。

系統活動終於降至低度。

錯誤狀態元素

元素擁有者可以使用未受管理的元素，模擬錯誤狀態，進而抑制特定功率等級的運作能力。下圖說明元素 E 的兩個可能錯誤元素，層級分別為 L₀、L₁、L₂、L₃。

在頂端情境中，錯誤元素的層級會直接反映 E 的層級。如果 current_level(Error State)==「L_i OK」，則 L_i 是 E 可運作的最高層級。在底部情境中，如果 current_level(Error State)==Error，更簡潔的錯誤元素會抑制 E 在 L₂ 或 L₃ 的作業。

這項機制只會停用元素架構頂端的連續層級區塊。您可以使用其他機制停用高於某個層級的層級，但至少要保留一個可運作的層級。不過，我們希望在出現用途時仔細檢查。

歸因

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 會管理電源拓撲。
• 系統活動管理員會定義及管理支援系統暫停/繼續作業的元素。
• 驅動程式架構支援將驅動程式與電源架構整合。(電力架構功能會透過標準方式，傳送至非驅動程式庫元件，不需要特殊支援)。

第 2 階段 (歷史)：概念驗證 Power Framework 整合

• 初步整合驅動程式庫，將硬體置於低電源和高電源狀態。
• 初步整合支援喚醒來源的驅動程式庫。
• 首次用於端對端暫停/繼續工作流程。

第 3 階段 (撰寫本文時)：擴大規模

• 批准這項 RFC；為 Power Broker、系統活動管理員和電力感知驅動程式提議並批准 RFC。
• 找出現有實作項目造成的設計限制，例如延遲時間額外負荷造成的有效速率限制。
• 使用 Power Framework 規劃和設計下一組子系統整合。
• 開發並記錄最佳做法和設計模式。
• 找出並實施小規模改善措施，協助整合 (例如改善 API、進行簡單的最佳化)。
• 建立測試程序和支援程式庫，納入 Power Framework 的特定領域考量。

• 找出大規模新增功能和改善項目的最高優先順序。可能包括：

  • 支援追蹤轉場延遲。
  • 需要大幅變更介面和/或後端實作作業，才能提升效能。
  • 簡化元件架構整合程序。

第 4 階段以上：進一步整合及大規模改善

• 整合其他子系統。
• 視需要最佳化現有整合服務。
• 根據新興需求，持續進行小規模改良。
• 優先處理大規模改善作業。
• 找出要在下一階段處理的大規模改善項目 (如有)。

效能

許多效能相關問題最適合在第 3 階段的 RFC 中解決，而 Power Broker 與這項提案的概念建構最為密切相關。不過，在目前的範圍內，我們可以列出一些一般準則，供您思考效能影響。

本地與非本地成效

本地和非本地效能需求之間存在張力，因為與 Power Broker 協商狀態變更通常至少會產生一些成本，而純粹的本地化解決方案可以避免這些成本。不過，純粹的在地化解決方案無法充分支援系統層級的分析，因此無法有效執行非本地最佳化作業。

找出延遲時間負荷

Power Broker 管理電源拓撲時，會產生一定程度的延遲負擔，特別是元素擁有者與代理程式之間的 IPC。不過，請務必審慎思考哪些成本確實屬於間接費用。特別要注意的是，部分子系統本質上需要程序間的通訊，才能實作任何形式的電源管理，而與電源拓撲整合可能透過 Power Broker 間接完成該通訊。

大小驅動的延遲時間負荷

系統全域暫停和繼續等作業的延遲時間較長，主要會受到影響的子圖大小影響。瞭解子圖的廣度、深度和節點計數對這類額外負荷的影響，將有助於解決問題。

QPS 造成的延遲時間負荷

目前預期 QPS 傳送至 Power Broker 的主要原因，是暫停封鎖租約；相關電源元素將在系統活動管理員 RFC 中詳細說明。

Power Broker 必須支援的 QPS 尚未有明確要求。而是因為事件抵達的速率夠高，導致每個事件的租約產生過多額外負荷，因此某些子系統整合可能會需要封鎖暫停。在這種情況下，您必須採用替代設計模式，在單一暫停封鎖租約下，整合多個事件的處理作業。

為協助進行這類評估，估算每個租約的延遲時間負荷非常重要。

安全性考量

在第 3 階段的 RFC 中，應詳細考量安全性，因為提案越接近具體實作，討論範圍就越明確。以下說明使用電源拓撲時固有的安全性問題。

電源依附元件和功能

由於電源拓撲會使用依附元件將電源元素提升至較高的電源層級，因此宣告特定電源元素依附元件的能力本身就是一項具備權限的操作。因此，為符合 Fuchsia 的安全模型，依附元件宣告應在相當精細的層級 (至少是每個元素) 明確受到能力保護。

目前為止，Power Broker 採用集中式權限管理方法，根據目前支援的能力類型嚴格處理權限。我們選擇這種做法是經過審慎評估，因為相較於並行演進的元件架構，這種做法能更快全面瞭解電源拓撲的影響。從長遠來看，元件架構或許能更自然地呈現與電源拓撲相關聯的功能，減輕 Power Broker 的部分安全性相關責任，並支援更流暢的開發人員體驗。

集中管理的風險

如果將 Power Broker 做為中央管理員，可能會面臨分散式阻斷服務攻擊等風險，導致無法管理系統關鍵狀態轉換，也可能遭到規避權限邏輯，讓攻擊者惡意操縱硬體狀態。

隱私權注意事項

由於裝置會追蹤詳細的子系統狀態，因此在車隊指標中運用這項資料時，請務必考量如何尊重隱私權。我們會在第 4 階段或之後，最有效率地考量這個問題，屆時我們就能具體展示 Power Broker 可能為大量子系統匯出的資料。

測試

第 1 階段已納入所有開發功能的單元測試，以及 Power Broker 的整合測試 (搭配虛擬用戶端)，還有 Power Broker 與系統活動控管器的整合測試。

第 2 階段新增了端對端暫停/繼續測試，並支援針對系統活動調控器進行非密封式驅動程式庫測試。

第 3 階段將透過程式庫和文件，為測試與 Power Framework 的整合建立正式支援，以因應實務中遇到的各種使用案例，同時擴大端對端測試的涵蓋範圍。

說明文件

這份 RFC 是電源拓撲概念定義的可靠來源。

系統會新增說明文件，以解決下列問題 (但不限於此)：

• 以易讀方式說明這裡定義的概念。
• 整合指南。
• 整合實際電源拓撲的範例。
• 建議的電源元素使用模式。

缺點、替代方案和未知事項

缺點

這項提案的兩項主要費用如下：

• Power Broker 的實作方式。撰寫本文時，Power Broker 的實作功能運作正常，與本文介紹的概念只有些微差異，因此成本不高。
• 分散用戶端整合的成本。我們會透過說明文件、用戶端程式庫 (並注意 FIDL 評分標準的附註)，以及測試支援，研究如何降低這些成本。

替代方案

去中心化電源控制

如果不想採用電源拓撲，可以考慮不使用集中式電源管理系統。在這種系統中，子系統會提供自訂介面，可驅動子系統進入不同電源狀態。

如果系統模式需要子系統處於特定電源狀態，則必須由「模式控制器」實體負責確保每個子系統都處於該模式適用的電源狀態。該實體必須使用各個子系統專屬的介面。

負責控制特定模式電源狀態的實體，實際上是為該模式執行集中式電源管理，因此這種方法並非真正去中心化。同時，要求模式控制器使用自行選擇的介面控制每個子系統，會造成明顯的擴縮問題。綜合上述因素，我們預期 Fuchsia 必須支援某種形式的集中式電源管理，並具備一定程度的介面標準化。

值得注意的是，這項提案並未對子系統應使用電源拓撲的程度採取強硬立場。部分子系統開發人員可能會發現，執行輕量整合最合適，也就是只向電源拓撲公開一或兩個整體子系統狀態，以便與系統模式轉換整合。其他使用者可能會覺得有必要採用更深入的整合方式，在整個平台和驅動程式中徹底模擬子系統。

作業順序

我們建議以狀態和依附元件為基礎的方法，做為替代方案，將特定作業的排序標準化，基本上就是將驅動程式的「暫停回呼」和「繼續回呼」概念一般化，以建立可運作的系統。在 Linux 暫停/繼續中，這會採用四種可能的驅動程式庫回呼形式，分別用於暫停 (prepare、suspend、suspend_late、suspend_noirq) 和繼續 (resume_noirq、resume_early、resume、complete)。

我們基於下列原因，選擇不採用這種做法：

• 這可能會隱藏系統暫停或恢復狀態期間的裝置狀態；公開這類狀態的程序，大致上會轉譯為這裡建議的拓撲建立程序。此外，這類狀態可能取決於裝置在暫停期間的預期行為。

• 這會造成混淆，因為「暫停」和「繼續」可能是在描述對特定裝置或整個系統執行的動作。

• 如上述 _late/_early 和 _noirq 回呼變數所示，這項做法很容易因意料之外的需求而中斷。

• 有秩序地管理依附元件的問題適用於任何形式的電源狀態控制，而不僅限於系統範圍的暫停和恢復作業。

• 採取作業排序方法時，抽象概念中仍存在狀態間的依附元件圖，但會隱含在原始碼中。

強制關機

除了隨選使用率，Power Framework 也可以採用命令式關機模型，其中電源元素預設為高功率狀態，必須明確命令才能降低功率。這個方法可簡化短期內特定功能的實作程序，但更容易導入未追蹤的依附元件。此外，這項技術也不支援歸因。

同時，視需要，隨選使用模式可配合特定範圍的強制關機。在電源拓撲的具體細節中，只需要一個用途是將資源拉至所需預設電源層級的消費者元素，而消費者擁有者會提供介面，以便視需要變更層級。然後，消費者元素可用於明確表示系統層級檢視畫面中強制關機的使用情形。

延後的主題

Power Broker RFC 將處理下列問題和疑問：

• 元素和依附元件的生命週期。
• 租約生命週期。
• 根據相容性提案中的指引，有關電量定義的 API 版本管理問題，將於 2024 年 4 月 22 日討論後更新。
• Power Broker 是否會向待處理租約的持有人提供任何意見回饋？
• 與拓撲整合的子系統測試指南，特別是關於使用虛擬 Power Broker 與使用虛擬電源元件的真實 Power Broker。
• API，用於以原子方式新增/移除依附元件。
• 處理多餘的依附元件。
• Power Broker 異常終止時的行為。
• 元素擁有者當機時的行為，包括與正常關機/啟動的比較。
• 錯誤處理。

既有技術和參考資料

Linux

• 裝置電源管理基本概念
• Linux 核心中暫停至閒置支援功能的演進
• sysfs 電源介面
• 裝置連結

Mac 作業系統

• 管理電源 - IOKit 基礎知識

Windows

• 電源管理架構總覽
• 裝置電源狀態
• 電源架構 (PoFx) 驅動程式 範例