RFC-0250：電源拓撲

摘要

系統電源管理的主要問題之一，就是在妥善管理各狀態之間的相互依賴關係的同時，支援各種系統元素 (我們用來簡單指稱具有狀態的東西，包括硬體和軟體) 轉換為不同狀態。這份提案指定了名為 Fuchsia Power Topology 的模型，可實作以解決此問題，同時提供歸因和可觀察性相關問題的解決方案。這項工作著重於建立概念架構，並嚴格定義相關術語；日後的 RFC 將著重於與實作相關的設計。

提振精神

狀態管理問題

這項提案源自於需要在 Fuchsia 中支援系統暫停/繼續執行作業，詳情請參閱 RFC 230。

系統暫停的主要任務，就是確保在 CPU 停止執行指令前，所有硬體元件都已置於適當的低耗電狀態。乍看之下，這似乎是深一層的依附元件管理問題：硬體元素的「活動」狀態取決於 CPU 的活動狀態，因此必須先將硬體元素設為暫停狀態，才能暫停 CPU。

不過，硬體元素可能會彼此依賴；舉例來說，裝置必須處於暫停狀態，才能關閉匯流排的電源。同時，裝置可能會有多個狀態，在不同情況下，這些狀態在系統休眠期間使用時會有所差異，例如，如果裝置要做為喚醒來源，則應使用低耗電狀態，如果不是，則應使用完全關閉狀態。同時，相關的狀態管理問題並非只會發生在系統暫停時。硬體元素可能會在 CPU 處於活動狀態時進入低耗電狀態，例如當手機處於飛航模式時，需要關閉特定無線電。

基於這些因素，建立可支援相互依賴狀態轉換的架構就顯得相當重要。由於電源管理是這類轉換作業的必要原因，因此這項工作會交由 Fuchsia 的電源架構負責。我們引入「電源拓樸」一詞，以便靈活地指涉這個架構核心的依附元件圖表和架構本身。

在開發電源拓撲時，我們發現用於管理硬體元素之間狀態依附性的概念，會自然延伸至軟體元素，可在硬體上提供更高層級的抽象概念，或自然描述面向使用者的功能的啟用/停用狀態。具體來說，我們會明確擷取支援面向使用者的功能所需的依附元件，藉此建立自然的依附元件使用方式，讓依附元件只在需要時才會使用，並為需要依附元件的功能提供歸因的使用資源。我們也想知道元件的歸因，但功能與電力使用情形的關聯性更強，因此需要在子元件層級進行歸因。

我們為了強制實施以需求為準的狀態變更而建立的概念，可讓電源拓樸編碼，不僅是系統中元素支援的狀態，還包括驅動狀態變更的規則。這將為產品開發人員和系統工程師建立強大的工具，讓他們能夠透過拓樸本身 (而非原始碼) 檢查系統層級行為，並提出功能變更建議。

為什麼要採用新的拓撲？

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

為方便您參考，我們將簡要介紹現有的拓撲。

元件拓樸描述兩件事：元件例項之間的父項/子項關係，以及能力轉送圖表。它是描述元件執行個體階層的樹狀結構，且功能會對應至該樹狀結構頂端的 DAG。如果元件需要存取其他子樹的能力，該能力會透過其父項進行路由。

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

相關人員

協助人員：

Adam Barth abarth@google.com

審查者：

• 電源：Kyle Gong kgong@google.com
• 電源：Michael Brunson mbrunson@google.com
• Driver Framework：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 Framework、元件架構、Driver Framework、Drivers 和 Zircon 團隊的審查人員進行交流。在電源仲介和系統活動控管器的類似設計程序中，我們進一步改良了這項功能，這兩項功能都將成為即將推出的 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 可將運作原因歸因於此。Framework 使用者必須有簡單的方法，可視需要將元素推升至更高效能的狀態，但可能需要引入新的歸因原因才能做到這點。

觀測能力

電源架構必須啟用觀察功能，以便觀察架構使用者認為與電力消耗相關的系統元素狀態。

成效

假設系統元素能夠以符合一組產品需求的方式執行狀態轉換，Power 架構必須充分支援這類操作。這大致分為兩個問題：

• 不要抑制本機效能。Power Framework 不得在個別系統元素的狀態轉換中造成過長的延遲。

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

  • 舉例來說，假設在系統暫停作業期間，圖形和音訊子系統會並行進入低耗電狀態。Power Framework 應指出它們會並行執行，並提供哪項作業耗費較多時間的洞察資料，因此系統暫停作業的延遲時間最佳化作業就能適當地著重於一項或另一項作業。

獨家

電源拓撲會讓您考慮非常大的解決方案空間。本提案特別未處理下列主題：

• Power Broker 的詳細規格。此 RFC 必須建立 Power Broker 的部分基本層面，才能開發拓樸模型。不過，它會盡可能將 Power Broker 的規格保留給即將推出的 Power Broker RFC。Power Broker 會實作這份文件中所述模型以外的行為，我們希望為其提供所需的所有彈性。
• 第一級錯誤處理。本文件中開發的拓樸模型並未提供處理狀態轉換錯誤的明確方法。這個排除項目是前一個項目的延伸項目，不會影響 Power Broker 的錯誤處理，主要目的是避免強制限制。
• 惡意行為人。Power Broker 和 元素擁有者之間的責任劃分，最終將需要考量元素擁有者是否會以不當和出乎意料的方式運作。
• Deadline 支援的狀態轉換。為了確保系統能及時執行全系統動作，自然會考慮為個別狀態轉換設定應用程式時間限制。

這些問題會在使用案例提供具體需求時進一步考量。

設計

這裡所述的設計會建立電源拓樸結構的基礎模型，不受任何特定介面或實作方式的影響。為實用目的，幾項即將推出的 RFC 也將對打算將子系統與電源拓樸整合的開發人員具有重要意義：

• Power Broker RFC 將處理管理電源拓撲結構的介面，以及實作這些介面的元件。
• 系統活動監控器 RFC 將說明電源拓樸與系統暫停/繼續執行程序的整合點。
• 這份「啟用電源的驅動程式」RFC 將說明整合作業的驅動程式庫專屬層面。

不過，拓樸模型本身已足夠複雜，需要專屬文件才能說明。這項 RFC 旨在透過一致的概念架構來核准概念，為其他 RFC 建立基礎，並在此基礎上開發穩定的說明文件，協助 Power Framework 使用者進行整合。

電源拓撲和核心概念

驅動這項設計的主要功能需求是上述的有序性要求。首先，我們需要確定哪些系統元素可參與模型、這些元素可能佔用哪些狀態，以及這些狀態可能透過電源拓撲表示哪些依附元件。只有在這種情況下，我們才能指定如何有條理地控制這些狀態。

電源元素

電源元素是此設計中的基本有狀態實體。電源元素可占用的狀態數量有限，且在任何特定時間都只會占用其中一種狀態。有時將電源元素視為一般裝置模型會很有幫助，但也可以將其視為狀態的容器。

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

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

電源等級

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

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

1. 可依耗電量遞增排序。(測量電力的做法有很多種；就目前的意圖和用途而言，只要根據特定情境定義「一般」的耗電量即可)。其餘限制則以此排序表示。
2. 依附元件是累加的：對於特定元素，任何資源都需要在 L 級別正確運作，也需要在 M 級別 (大於 L) 正確運作。

3. 功能是累加的：對於特定元素，任何由 L 級提供的功能，也由 M 級以上 (大於 L) 提供。

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

電量等級結構定義包含：

• 結構定義中各電量等級的標籤。
• 依耗電量增加的順序排列。

範例

為了說明方便，我們會使用字串標籤，並以從下到上的垂直清單表示排序順序。(Power Broker RFC 將說明實際的電量等級呈現方式)。

以下是三種可能的電源等級架構：

特別值得注意的是，電源等級的排序方式與 ACPI 電源狀態相反。這個選項可消除口語詞彙中不幸出現的模糊表達方式。在 ACPI 慣例中，「lower」一詞有兩種截然不同的解釋，取決於「lower」是用於耗電量 (對應於排序順序中的較高索引)，還是排序順序中的索引 (對應於較高耗電量)。像是「降低電力」這類的詞彙就不會出現這種模糊不清的情況。

並非所有電源元素都能使用與其他元素共用的電源等級結構定義。舉例來說，您可以定義電源元素，指定 CPU 執行的最低頻率，在這種情況下，電源等級會對應至所討論 CPU 支援的頻率。

用途和限制

電源等級架構是表示元素狀態的實用起點，原因如下：

• 這些模式清楚表達常見的模式，如上方所示。
• 這些類別提供一種方法，可在大量狀態之間擷取依附元件，以匯總方式擷取，而不需要繁瑣的重複作業。
• 這些屬性可用於不發生衝突的方式，這是無法在所有情況下預期的屬性，但應盡可能使用。

單一電源元素和電源層級架構不足以描述 Power Framework 使用者感興趣的所有情境。舉例來說，單一裝置的不同運作模式 (簡單但不符合情境的例子，請考慮可為房間加熱或降溫的熱泵) 無法準確模擬為單一電源元件。

不過，電源等級結構定義可做為建構區塊，用於描述更複雜的系統。這類最佳做法不在本 RFC 的討論範圍內，將在即將推出的說明文件中說明。Framework 使用者也可以透過 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) 表示為 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 需要中等延遲。裝置可在低延遲的情況下運作，滿足兩個孩子的 Active 等級。

這個範例說明電源等級的重要屬性：這些等級的定義是為了避免不同用戶端的需求發生衝突。

邊緣方向慣例

如同目前圖表所示，我們採用的慣例是電源拓撲中的邊會沿著從子項到父項的方向，依賴性。有些討論和直覺性的術語可能會以從父項傳遞至子項的電源流向為依據，目前，我們打算在所有正式開發作業中使用依附元件方向，並建議讀者留意這個問題。

權限層級管理

如要指定電源拓撲在實際系統中的使用方式，我們接下來需要定義管理拓撲和個別電源元素的相關人員。

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 的控制方案旨在平衡電源使用需求，並限制其使用方式。

從概念上來說，裝置的功能需求會導致用電需求。這些需求通常會根據使用者對裝置的現有期望，動態調整。使用者可能會開啟應用程式來執行特定工作，這表示與該應用程式相關聯的特定電源元件需要以較高的電源等級運作。或者，裝置可能會感應到使用者附近的活動，並判斷使用者可能很快就會與裝置互動，因此建議裝置進入低延遲回應模式。根據使用者對喚醒裝置的互動方式期待，應用程式處理器處於閒置狀態時，也會出現需求，例如說出熱字詞、按下滑鼠、輕觸螢幕等。為了表示對電源拓撲的需求，我們會引入名為 lease 的物件。

限制則可分為兩種情況。在某些情況下，無法透過軟體控制的狀態可能會直接抑制電力使用量；這類情況會由未管理的元素模擬。另一方面，系統可能需要一種方式，指出何時應或不應提高電量等級，以滿足租用權所表示的需求；依附元件執行要求政策可滿足這項需求。

總而言之，這些概念可讓我們指定 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 是否會主動處理受控元素的依附元件。

為此，我們針對電源層級依附元件引進兩種可能的履行政策：強履行和弱履行。只有在必要元素受管理的情況下，才能強制滿足依附元件，而受管理和未管理元素的依附元件可能會弱式滿足。

政策也會匯總為依附元件的路徑。如果路徑中的每個依附元件都已強制滿足，則依附元件路徑為強制滿足；否則為弱式滿足。

有了固定的穩態決定因素組合，我們就能指定租約何時履行。只有在每個元素層級 (P, RL) 都透過弱式履行的路徑依附於 (C, L) 時，才會在穩定狀態下履行 (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，再降至低於 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」電源等級會依賴 (靜音開關, 未啟用) 的基礎依附元件。

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

• 系統活動：此元素以抽象方式代表系統允許的工作處理範圍。當這個元素設為「高」時，系統會處理各種工作；設為「低」時，系統會更有選擇地處理工作。

步驟：

一開始，(Audio Processor, Active) 的租用權會將所有受管理的元素保留在較高的電源等級。

靜音開關會切換，且靜音開關的電源等級會立即變更為未連結。依附元件 (輸入串流、已啟用) 和 (音訊處理器、已啟用) 現已中斷。

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

由於 Audio Processor 的依附元件不再保持為「活動中」，因此系統活動會轉換為「非活動中」。

對受管理元素的機會依附元件

在這個範例中，兩項功能都需要系統活動元素設為高等級才能執行。高優先順序功能的依附元件是斷言式，因此如果租約 (High Priority Feature, Active) 要求，系統活動會提高至高。不過，低優先順序功能的依附元件是隨機的，因此只有在高優先順序功能的租約將系統活動提高至高時，才能將其提高至「活動中」。

步驟：

(Low Priority Feature, Active) 有租約，但 Power Broker 無法滿足該租約，因為 (System Activity, High) 的依附元件是機會主義。

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

系統活動已提高至「高」。

兩個功能層級都會依序提升為「Active」，並履行兩個租約。

(High Priority Feature, Active) 的租約已終止。在新的穩定狀態中，(Low Priority Feature, Active) 的租用權將不再履行。

高優先順序功能已降為「Inactive」。(注意：此 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")
            },
        }
    ]

如果元素必須跨元件邊界識別，就會產生額外的複雜性。我們將與元件架構團隊合作，研究如何簡化靜態設定。

未來主題

轉換延遲支援

長期來說，電源拓撲圖旨在提供一個架構，以便瞭解及改善系統狀態轉換的延遲時間。Power 元素定義會建立標準位置，以便對本機轉換延遲時間進行編碼，也就是在滿足所有依附元件後，變更元素層級所需的時間。不需要本機元素延遲時間，但可在特定系統成熟時新增。

本地延遲時間的應用方式包括：

• 針對跨多個元素的複合作業，以半靜態分析 (例如在執行階段擷取拓樸圖設定) 來分析延遲時間。
• 執行階段追蹤觀察到的延遲情形，並回報與預期的差異。
• 向用戶端回報預估延遲時間，以支援具有嚴格時間限制的作業。

其他類型的狀態和依附元件

我們已介紹的電源等級和依附元件類型，是用來表示元素狀態的實用起點，可用於各種情況。這些方法可讓您以匯總方式擷取大量狀態之間的依附元件，而不需要繁瑣的重複動作。此外，這些資源還可以不衝突的方式使用，這項屬性並非在所有情況下都適用，但應盡可能使用。

隨著電源拓撲結構的演進，支援其他類型的狀態和依附元件可能會變得實用和/或必要。例如：

• 感應器的韌體可能會實作以支援一組不相干的作業模式，每個模式都經過最佳化處理，以滿足不同的需求，但不會遵循嚴格增加功能和電力使用的規模。雖然這類感應器可能會以每個模式的一個二進位電源元素來描述，但我們可能會改為引入新類型的狀態結構定義，以便同時描述所有模式，並納入用於解決競爭用戶端之間衝突的規則。
• 某些硬體類型 (例如 GPU) 可能會根據多個用戶端的同時負載需求，選擇其電源等級。電源拓撲可能會支援擷取這類負載需求的依附元件，並以一般方式累積這些需求。

這類開發作業目前仍處於推測階段，因此在初始子系統與電源拓撲整合時，應視需要重新檢視這些作業。

實作

實作電源拓撲本身並在 Fuchsia 中使用，是一項大工程。有幾項集中作業會廣泛使用，因此需要在初始導入後進行大幅精進。同時，Fuchsia 子系統目前對電源管理的支援程度有限，在許多情況下，開發人員需要同時制定適當的電源管理策略，並將這些策略對應至電源拓撲。

建議您將開發策略分成不同階段，其中有些階段是歷史階段。在第 1 階段，我們以相對隔離的方式開發核心功能，接著在第 2 階段進行少量整合，以便展示主要用途，並進行系統暫停/繼續的端對端測試。在掌握前兩個階段的學習成果後，我們現在正透過第 3 階段奠定基礎，以便進行更多整合，並在第 4 階段及以後建立穩定的開發週期。

第 1 階段 (已完成)：核心功能

• Power Broker 會管理電源結構。
• 系統活動控管器會定義及管理支援系統暫停/繼續作業的元素。
• 驅動程式架構支援將驅動程式與電源架構整合。(Power Framework 功能會透過標準方式路由至非驅動程式庫元件，不需要特殊支援)。

第 2 階段 (已完成)：概念驗證的 Power Framework 整合

• 與可將硬體置於低功耗和高功耗狀態的驅動程式庫進行初始整合。
• 與支援喚醒來源的驅動程式庫進行初始整合。
• 首次在端對端暫停/繼續工作流程中使用。

第 3 階段 (目前處於此階段)：擴大規模

• 核准此 RFC；提出並核准 Power Broker、System Activity Governor 和 Power-Aware Driver 的 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 做為中央管理員會使其面臨風險，例如分散式阻斷服務攻擊，這可能會導致 Power Broker 無法管理系統重要狀態轉換，以及規避其權限邏輯，進而讓攻擊者有能力惡意操控硬體狀態。

隱私權注意事項

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

測試

第 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) 的形式呈現。

我們不採用這種做法的原因如下：

• 它可能會隱藏裝置在系統暫停狀態或恢復狀態時的狀態；公開這類狀態的程序主要會轉換為建立這裡提出的拓樸結構。此外，這類狀態可能會依裝置在暫停時的預期行為而定。

• 這會讓人混淆，因為「suspend」和「resume」描述的是任何特定裝置或整個系統執行的動作。

• 這類回呼容易受到意外需求的影響，如上述 _late/_early 和 _noirq 回呼變化版本所示。

• 有序依附元件管理問題適用於任何形式的電源狀態控制，而不僅限於系統層級的暫停和繼續作業。

• 採用作業順序方法時，狀態間相依性的圖表仍會存在於摘要中，但在原始碼中則是隱含的。

強制關機

除了按需使用之外，電源架構也可以使用強制關機的模型，其中電源元素預設為高電源狀態，且必須明確下達指令才能降低電源。這種做法可簡化短期內的特定功能實作，但更容易引入未追蹤的依附元件。此外，這項功能本身不支援歸因。

同時，按需使用率模型可在必要時在特定範圍內支援強制關機。在電源拓撲結構的具體情況下，您只需要一個消費者元素，其目的是將資源拉至所需的預設電源等級，而消費者的擁有者會提供介面，以便視需要變更等級。接著，您可以使用消費者元素，在系統層級檢視畫面中明確表示使用強制關機功能。

延後的主題

以下問題和疑問將在 Power Broker RFC 中解決：

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

既有技術與參考資料

Linux

• 裝置電源管理基礎知識
• Linux 核心中暫停至閒置狀態支援功能的演進
• sysfs Power Interface
• 裝置連結

Mac 作業系統

• 管理電源 - IOKit 基礎知識

Windows

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