本頁面由 Cloud Translation API 翻譯而成。

RFC-0230：Fuchsia 中的「Pause-To-Idle」

RFC-0230：在 Fuchsia 中使用 Suspend-To-Idle
狀態	已接受
區域	電源
說明	介紹 Fuchsia 如何處理系統電源狀態變更，並詳述使用 Suspend-To-Idle 用途的設計
問題	127897
Gerrit 變更	865570
作者	harshanv@google.com
審查人員	andresoportus@google.com cja@google.com claridge@google.com cpu@google.com jamesr@google.com jmatt@google.com maniscalco@google.com quiche@google.com surajmalhotra@google.com
提交日期 (年-月-日)	2023-06-02
審查日期 (年-月-日)	2023 年 10 月 24 日

編輯此 RFC

編輯 RFC 中繼資料

摘要

這份 RFC 建議新增對一個系統電源等級的支援，即「暫停至閒置」(Suspend-to-Idle)，並支援從這個狀態恢復。本文將介紹 Fuchsia 的暫停至閒置工作流程的高層級需求和設計。這是第一級 RFC，定義整體程序和設計。我們將提供更多 RFC 或設計文件，說明各模組的實作細節。

電源管理的關鍵在於，在系統處於閒置狀態時將其轉為較低的電源等級，並在需要時恢復完整運作。系統層級可與 ACPI S 狀態進行比較。不同類型的系統對電源和喚醒延遲的要求不同，這會決定系統可轉換至的「系統電源等級」。在系統完全開啟 (或處於活動狀態) 時，透過關閉或將系統部分設為較低電源等級，對系統進行電源管理，稱為執行階段電源管理。

定義一組標準系統電源等級，並只實作這些已定義的等級，無法達成盡可能獲得最佳電源效益，並遵守系統復原時間延遲的目標。部分作業系統也曾嘗試改良即時執行電源管理功能，但尚未發揮電源效益。

為解決這個問題，Fuchsia 將使用其集中式電源架構，整合精細的電源管理功能。本文件中使用的「電源架構」一詞，是指負責做出政策決策並實施這些決策的所有電源管理元件。系統的每個子裝置 (SoC/周邊/匯流排/等) 都可以自由定義可進入的電源等級數量，並附上相應的喚醒延遲時間，然後將這些資訊發布至電源架構。電源架構會扮演重要角色，做出明智的政策決策並加以實施，將系統或系統的部分設為低電量。電源架構會根據從使用者空間系統元件收到的資訊 (例如要求將系統設為較低的電源等級，並保證恢復時間)、電路板設定資訊 (系統支援的電源等級、恢復時間和各個等級的喚醒功能) 以及瞭解系統目前的電源等級 (例如各個子裝置的等級、喚醒延遲時間、電源資源依附元件和 I/O 佇列) 採取行動。

例如：

Power Framework 會接收使用者空間中的系統元件要求，將系統切換至較低的電源等級，並確保可在 500 毫秒內恢復。Power Framework 會瞭解所有子裝置的層級，以及部分或所有喚醒延遲時間。根據這些資訊，電源架構可能會決定只將次要 CPU 離線，將音訊喇叭 (非麥克風) 離線，將 Wi-Fi 切換至其中一個低耗電模式，並將螢幕切換為較低的更新率。之所以採取這些動作，是因為這些動作可以在 500 毫秒內恢復正常運作。由於其他子裝置可能需要保持開啟狀態，或喚醒延遲時間超過 500 毫秒，因此無法將其電源降低。
由於沒有使用者積極互動，Power Framework 會收到來自使用者空間系統元件的請求，將系統設為較低的電源等級。Power Framework 沒有繼續執行時間需求，無法退出系統進入的較低電源等級。電源架構可能會決定將系統設為「暫停至閒置」模式，然後在一段時間後改為「暫停至 RAM」模式 (如果可行)。這些是 Power Framework 會瞭解並採取行動的幾個明確的 Fuchsia 系統電源等級。

提振精神

隨著 Fuchsia 擴展至支援不同類型的電池供電產品，電源管理是必須支援的重要功能。本文件將特別說明 Fuchsia 將系統切換為「暫停待命」狀態，然後再切換回完全運作狀態的所有層面。採用的設計原則如下：

驅動程式和元件可透過實作明確定義的通訊協定和介面，成為「省電」的元件。本 RFC 並未定義確切的介面。我們會在詳細設計文件中討論這些問題。
驅動程式和元件不會受到系統層級變更的影響。
這項設計會整合基礎架構，以便實作任何類型的未來電源政策強制執行 (例如其他系統電源等級轉換、執行階段電源管理)，而無須變更驅動程式庫程式碼。

這需要 Fuchsia 的各個層級參與此 RFC 中所述的明確定義功能。這份 RFC 未納入所有指標，無法協助評估系統在不同系統電源等級下的效能和效能。

需求條件

當系統想要節省電力並使用可用的低電力系統層級時，Fuchsia 應實作轉換至較低電力系統層級的功能 (視架構而定，可能是 ACPI S 狀態或任何專屬方式)，並遵循使用者空間系統元件的電源管理要求。此 RFC 針對「暫停至閒置」系統電源等級。休眠待命和復原的必要條件如下：

Fuchsia 應從使用者空間系統元件取得提示，並根據系統的能力和狀態做出選擇，進入「暫停至閒置」狀態。
如果使用者空間提供暫停延遲要求，Fuchsia 應遵循相同的規定。如果未提供繼續時間，Fuchsia 應以盡可能縮短的繼續時間進入 Suspend-To-Idle 狀態。
Fuchsia 應提供一種方法，讓您取得特定主機板的設定，定義可從「暫停待命」模式將系統恢復為完全運作模式的子裝置中斷。
相較於其他作業系統，Suspend-to-Idle 功能的耗電量應相近或更低。
Fuchsia 應公開 CPU、記憶體和子裝置的健康狀態和指標，以便使用者空間元件進行偵錯、電力測量和政策決策。
Fuchsia 應提供一種方式，可依據適當定義的電源依附元件需求，在元件之間排序作業。
Fuchsia 應在遵循電源層級變更的子裝置，以及拒絕/忽略要求的子裝置上，公開遙測資料。當變更要求遭到拒絕時，子裝置可視需要傳達原因並記錄，以便用於偵錯和微調耗電量。
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.

不同的作業系統會以各自的方式實作 Suspend-to-Idle，並根據 ACPI 規格定義進行調整。本文件將概略說明「暫停待命」的設計，並討論 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 核心之外。以 Linux 為基礎的作業系統 (例如 Android 和 Ubuntu) 會根據 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 應為驅動程式提供基礎架構，以便回報喚醒延遲時間和對其他驅動程式的依附元件等電源設定。電源架構需要存取這項資訊，才能進行積極的電源管理。這將有助於在其他作業系統嘗試改裝這項資訊，以便做出與電源相關的系統層級決策時，取得優勢。

整體設計

啟動/設定：

Power Framework 將是第一個從使用者空間中的系統元件接收低耗電模式要求的 Fuchsia 模組。如要執行指令，Power Framework 應配備

整個系統的電源拓撲

Power Framework 需要建立或接收電源拓撲圖表，並擁有該圖表。這可讓 Power Framework 將子裝置置於較低的電量等級。建構電源拓撲圖的最終設計會在 Power Framework 設計文件中討論。下列資訊可能有助於建立及維護電源拓撲圖表。

a) 元件依附 DAG：

在 DFv2 中，所有驅動程式都是元件，元件管理員則擁有驅動程式和其他元件的「能力圖表」。這個依附元件圖表可能是 Power Framework 的良好輸入內容，可用於建構電源拓樸圖表。驅動程式管理器和元件管理員交換的系統檢視畫面有不同的層面。元件管理員最後會擁有元件依附元件圖表，做為單一可靠資料來源。Power Framework 應提供查詢或存取這類資訊的方法。不過，這張圖表並不足以滿足 Power Framework 的需求。

b) 電源元素依附元件資訊：

電源結構必須擷取不同子裝置的電源等級之間的關係，並維持對這些等級的動態認知。在任何時間點，都必須確保特定裝置的電源依附元件已滿足。目前，元件和驅動程式庫拓撲都無法執行這項操作。
驅動程式和元件的目前狀態

應將驅動程式存在和電源等級變更的執行階段資訊傳送至 Power Framework。舉例來說，即插即用功能可以引入新的驅動程式，並終止部分驅動程式庫執行個體。有些子裝置可能無法運作，對應的驅動程式庫也可能會停止運作。部分驅動程式可實作，以便在執行階段進行電源管理時，聰明地關閉裝置的部分元件。

所有電源等級變更都應傳送至電源架構。其中有些資訊可能是元件管理員或驅動程式管理器提供的執行階段資訊，有些則是驅動程式直接回報的資訊。
系統狀態，例如 CPU、記憶體、時鐘和電源狀態。(選填)？

除了上述所有資訊之外，電源架構可存取 CPU、時脈樹狀結構、記憶體和電源軌狀態等資訊，協助做出正確的決定，以安全無虞的方式暫停系統。對應的驅動程式或核心會公開介面，讓電源架構查詢目前的電源等級，以及在暫停和繼續執行期間執行一組活動的系統呼叫。
接收靜態板卡專屬設定和產品專屬設定。
接收用於暫停至閒置和繼續執行的使用者設定，例如喚醒功能和繼續執行延遲時間。
在轉換為較低的電源等級前，請先判斷喚醒功能。

電源架構可透過可存取的各種設定，建立可從不同系統低耗電量層級喚醒的子裝置清單。知道/瞭解可從低電量喚醒系統的驅動程式，可註冊中斷事件，以便透過 Power Framework 喚醒系統。Power Framework 會使用這項資訊，搭配板卡設定、產品設定和使用者空間設定，決定哪些子裝置可喚醒，並與核心進行相同的通訊。

以下是初始/啟動作業的高階流程。

說明文字：啟動/初始化流程圖

從暫停狀態進入待命狀態的流程：

電源架構會負責透過與元件管理員、驅動程式管理器等 Fuchsia 模組和 Zircon 進行通訊，在任何給定的系統電源等級中轉換整個系統。如果系統不支援使用者空間要求的模式/狀態/電源等級，電源架構可以選擇拒絕要求。每個模式/狀態/電量等級項目都需要以特定順序執行不同的一組動作。

這裡所討論的特定模式是低耗電模式之一，即「暫停待命」模式。此模式是低喚醒延遲的睡眠狀態。以下是 Power Framework 需要維護元件和系統整體狀態機器的原因。

系統會在 Power Framework 內部處理決定要進入或離開某種模式，或是拒絕模式轉換的決定。
當系統已處於特定模式，且 Power Framework 收到將系統切換至其他模式的要求時，Power Framework 需要知道狀態機器及其轉換，才能將系統切換至新模式。
部分轉換作業可能無法成功，系統模式也可能不會變更。這類情況應由 Power Framework 處理。電源架構應在每次模式轉換後，瞭解產生的模式/電源等級。

當 Fuchsia 選擇進入「暫停至閒置」模式以節省電力/電池時，Power Framework 會取得系統的最新電源拓撲檢視畫面。Power Framework 會決定哪些元件需要轉換為低電量等級，並叫用介面來轉換這些元件。這需要所有元件和驅動程式註冊及實作介面，以便變更架構定義的電源等級，進而發揮最佳電源效益。這項設計的詳細資訊將在 Power Framework 設計文件和 Power-Aware 驅動程式和元件設計文件中說明。

請務必定義哪些硬體/軟體中斷可喚醒裝置。Power Framework 會叫用 Power Element 擁有者的適當介面，以便設定喚醒觸發條件。它可以選擇要求核心設定喚醒來源註冊表 (如適用且必要時)。這些設計細節將在「Power-Aware Kernel」設計文件中說明。

如果驅動程式庫/元件無法變更電源等級，Power Framework 可以選擇中止作業或繼續執行。

Power Framework 應發起要求，暫停單調時間、將 CPU 離線或置於低耗電狀態，盡可能關閉時鐘和電源，以及其他與架構相關的動作 (如有)。這可能是直接對核心的系統呼叫，或是經由驅動程式庫、元件或 HAL 轉送，這會在後續設計文件中討論。

以下是收到 Suspend 呼叫時的高階流程圖。

替代文字：Suspend-to-Idle 流程圖

從 Suspend-to-Idle 流程繼續執行：

當啟動 CPU 收到喚醒中斷時，系統就會從暫停至閒置狀態中恢復。硬體只會將在中斷控制器或在某些情況下在 PMIC 中編程，或在某些情況下在每部裝置的本機中編程的可喚醒中斷傳送至 CPU。並非所有中斷都會觸發繼續執行。觸發 resume 的中斷會是 Power Framework 決定並在將系統切換為 Suspend-to-Idle 前編程的中斷。

由於啟動 CPU 未離線，中斷會傳送至啟動 CPU，而後者會叫用正確的中斷服務例程。當系統呼叫函式傳回時，Power Framework 會直接從核心接收暫停呼叫的狀態，或透過驅動程式庫進行路由。無論是驅動程式庫或電源架構，都必須以相反的順序採取動作，才能讓整個系統啟動，從啟用時鐘和電源網域開始，將啟動 CPU 設為完全運作狀態，啟動次要 CPU，退出記憶體自刷新和其他架構相關動作 (如有)。Power Framework 會負責以有條理的方式，使用對應的驅動程式和元件恢復所有裝置。

以下是從暫停至閒置流程的高階繼續執行範例。

替代文字：履歷表流程圖

模組職責

Power Framework 元件：

Power Framework 元件會負責協調整個暫停和繼續執行的流程。Power Framework 需要：

使用元件架構和驅動程式架構中的服務，維護電源拓撲圖。
維護元件 (包括驅動程式) 之間的依附關係。
使用核心或適當的驅動程式庫提供的服務，接收 CPU 的功能和目前狀態。
從核心或適當的驅動程式呼叫服務，以便

a. 將 CPU 連上/離線

b. 如有需要，請設定喚醒來源中斷註冊

c. 如何暫停單調時間

d. 架構專屬變更和程式設計

上述所有步驟可以是個別的服務呼叫，也可以是單一服務呼叫，用於執行所有步驟。這項設計決策和詳細資料將記錄在 Power Framework 和 Power Aware Kernel 設計文件的適當設計文件中。
接收電源元素及其屬性的介面，例如電源等級、電源依附元件和喚醒延遲時間，這些資訊來自驅動程式和元件。
介面，可有條理地為驅動程式和元件設定適當的電源等級。
如要公開指標，例如電源結構目前的狀態、每個驅動程式庫/元件的狀態、偵錯和遙測的喚醒觸發事件。

驅動程式

每個管理電源重要資源的 Fuchsia 驅動程式庫都需要實作以下內容，才能積極節省電力。

使用 Power Framework 註冊管道

a. 提供支援的電源元件、電源等級、依附元件和喚醒延遲時間的相關資訊。

b. 實作可變更電源等級的介面

c. 隨時提供裝置的電源狀態資訊 (例如是否由內部觸發)。

d. 針對偵錯和遙測目的，公開目前狀態和內部設定等指標。

核心

在高層級別中，核心可以將下列各項責任實作為個別的系統呼叫或單一系統呼叫。

請確認系統進入 Suspend-to-Idle 時，單調時間會暫停。系統處於暫停模式時，時間不應推進。在繼續執行時，這麼做可確保執行緒能持續瞭解系統活動的相對時間長度。這樣可確保系統暫停的時間不會影響程式的正確性。在系統處於暫停狀態時，必須確保進度時間一致。
在 CPU 電源等級變更前，請先設定喚醒來源 (如適用且必要時)。這會依架構而異，核心必須根據主機板類型設定適當的登錄器。
將 CPU 離線或重新上線。
匯出 CPU 指標。這可能會在繼續執行完成時傳回，也可能是 Power Framework 或偵錯工具/電源量測工具為取得各個 CPU 的狀態而叫用的個別系統呼叫。

由使用者空間叫用的 Suspend-to-Idle 與系統的排程行為無關。不過，排程器必須瞭解並採取適當行動。我們會在「電源感知核心」設計文件中討論詳細設計。

新互動功能的整體設計

驅動程式以 Power Framework 註冊為喚醒功能

裝置驅動程式可以根據驅動程式庫類型和架構，瞭解中斷是否可從板卡驅動程式庫或其他來源喚醒。舉例來說，音訊、觸控和蓋子裝置所產生的中斷可定義為可喚醒裝置。在目前的設計中，對應的裝置驅動程式會在暫停函式中呼叫 SetWakeDevice()，以便將其註冊為喚醒來源。(範例：ACPI 蓋子驅動程式)。這會在內部叫用 ACPI 驅動程式庫 SetWakeDevice() 呼叫。這項功能與架構相關，無法擴充。

電源架構是決定所有電源相關設定的集中位置，會決定可從整個系統轉換至的電源等級喚醒系統。因此，具有喚醒功能中斷的驅動程式應使用預先定義的共用管道，將資訊分享給電源架構。Power Framework 可以使用核心系統呼叫來設定喚醒觸發事件，或與驅動程式庫通訊來設定相同的事件。這項設計決策將納入「電源架構設計」、「省電核心設計」和「省電驅動程式和元件設計」文件。

透過靜態設定為電路板配置電源

每個主機板都可以定義設定和屬性，以便做出有意義的電源政策決策。其中一些例子包括子裝置/周邊裝置如何彼此相依，系統支援的不同電量等級，以及可從低電量等級喚醒系統的子裝置。舉例來說，部分子裝置允許從「Suspend-to-Idle」喚醒系統，但可能無法從「Suspend-to-RAM」喚醒系統。因此，電源架構必須知道哪些子裝置可從目前的電源等級喚醒系統，並將系統轉換至該等級。

此電路板設定可能是啟動後由 Power Framework 讀取的一次性設定 (例如：中央熱點觸發點設定)，也可能是電路板驅動程式庫提供給其他裝置驅動程式的資訊。驅動程式會在初始化/註冊期間處理資訊，並將最終設定提供給 Power Framework。

建立電源拓撲

電源架構應維持電源拓撲，以便做出有效率的電源層級轉換決策。Power 架構會透過元件管理工具和驅動程式管理器，或透過驅動程式和元件本身，設定適當的管道來收集資訊，例如

電源元素
支援的對應電源等級
依賴其他電源元件
轉換至各層級的延遲時間
喚醒能力
自行啟動的電源等級變更狀態

在驅動程式庫初始化期間，驅動程式和元件應透過提供的適當管道與電源架構進行通訊。

此外，驅動程式和元件也可以擴充至使用這個管道，用於執行階段電源管理。舉例來說，如果驅動程式庫或元件瞭解其電源元素未使用，便可使用管道要求變更電源等級。電源架構可根據系統狀態、依附元件和電源政策，忽略或接受要求。如果想遵循要求，可以使用管道，並要求電源元件轉換至特定電源等級。

定義及叫用每個驅動程式庫/元件的電源等級變更

電源架構會決定哪些子裝置應轉換至較低的電源等級，並從驅動程式庫回報的支援等級中進行選擇。Power Framework 會根據代表拓撲外政策的特定元素的電源等級，以及一組用於管理電源依附元件的規則，做出這項決定。Power Framework 會透過適當的已建立管道傳送訊息，以便傳達子裝置必須轉換的電源等級。驅動程式/元件必須在嘗試或完成轉換後，透過相同管道回報狀態。

實作

暫停/繼續執行流程是 Fuchsia 眾多電源管理流程中的第一個，也是跨越 Fuchsia 多個建構區塊的功能。這份 RFC 是整體設計。我們會提供更多 RFC 或設計文件，涵蓋各模組的實作詳細資料。每個模組都會綁定許多設計面向，需要透過多項 Gerrit 變更才能完成整個實作作業。

測試

這項功能涵蓋 Fuchsia 的多個構建區塊。對 Fuchsia 的各個部分所做的所有變更都應進行單元測試。用於測試各模組間互動和流程的整合測試應可使用，並在 CI/CQ 中執行，以確保其他功能不會中斷這項複雜的流程，反之亦然。驅動程式測試領域可用於隔離驅動程式。您可以使用 Lacewing (如果已就緒且可使用) 建立及執行主機測試。任何新建立的介面都應可在合作夥伴 SDK 中使用，並應具備 CTF 測試，以便持續檢查。

需要進一步的文件

您必須產生下列設計文件，才能完成設計並準備實作。

Power Framework 設計文件
節能核心設計文件
節電驅動程式和元件文件
每個網域的電源管理，例如音訊/圖像/連線 (選用)

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

這項提案需要許多實作階段，並在每個階段提供所有模組，例如核心、驅動程式、電源架構、驅動程式架構和元件架構。設計電源管理流程的基準，對於整合各種電源管理功能，讓 Fuchsia 成為電池供電產品的理想作業系統，至關重要。這項提案的實施費用將跨季度。

還有其他策略可讓您暫停/繼續工作。如下所示：

使用現有的暫停流程暫停驅動程式和元件

這項策略無法提供完整的解決方案，也無法提供最佳電池續航力。這個解決方案無法考量驅動程式/元件具有的各種電源依附性、根據依附電源元件對子裝置進行智慧叢集，以及根據子裝置的電源網域進行處理。由於缺少編寫執行階段喚醒來源變更和向使用者空間公開子裝置資訊等功能，因此這項設計會不完整。
遵循 Linux 中的暫停/重新啟用設計

這項策略只會確保 Fuchsia 與 Linux 相等。Fuchsia 必須在 Linux 為單一核心且不支援政策決策等限制下運作。這項策略無法讓我們充分利用 Fuchsia 帶來的優勢。Linux 電源管理功能主要在於為核心執行的特定回呼排序。相較之下，Fuchsia 的大部分內容是在許多程序的使用者空間中實作，因此我們的電源管理支援功能必須以自然方式分散。

雖然這些策略可能很快就能實施，但其缺點令人無法接受。

目前提出的設計完全是全新的，在 Fuchsia 中加入了許多內容並進行許多變更。這項策略需要花費時間和精力，但可確保我們有安全且可擴充的方式，在 Fuchsia 中啟用電源管理功能。這可確保我們不會將電源管理流程改裝到有限制的作業系統。

設計中的未知項目會在下一個設計文件層級中展開，並在其中記錄因應措施。

詞彙解釋

電源元素：電源元素是實體，用於表示硬體子裝置 (包括電源軌和時脈) 的電源方面，或將這些硬體元素組合成更高層級的抽象概念，例如音訊串流、超音波、相機子系統。
電力等級：電力元素可能會占用不同的電力等級。電源等級是遵循下列限制的狀態序列：以非負整數做為索引；第 0 級沒有電源等級依附性，在大多數裝置中可能為「關閉」狀態；依據耗電量遞增排序。(測量電力的做法有很多種；就目前的意圖和用途而言，只要定義「一般」的用電量即可)。在最簡單的非簡單情況下，元素會有兩個可能的層級，0 代表關閉，1 代表開啟。ACPI D 狀態也可以對應至電源等級，但順序會顛倒：D3cold=0、D3hot=1、D2=2、D1=3、D0=4。
喚醒觸發條件：當系統處於低耗電模式 (暫停) 且 CPU 處於離線狀態時，實體互動會導致系統觸發中斷，從低耗電量喚醒系統，這稱為「喚醒觸發條件」。
子裝置：SoC 的一部分，或附有驅動程式庫的周邊裝置或系統匯流排。
系統電源層級/休眠狀態：明確定義的系統層級狀態，具有已知的喚醒延遲時間和大約耗電量。這與 ACPI S-States 非常相似。
喚醒延遲：子裝置或系統整體從較低電量狀態轉換為完全運作狀態所需的時間。
恢復時間：系統從低電量狀態恢復到完全運作狀態所需的時間上限。
OSPM：作業系統導向設定和電源管理
ACPI S0 狀態 - 完全運作或完全開啟狀態，耗電量高。
ACPI S1 狀態：S1 狀態的定義為低喚醒延遲的睡眠狀態。在這個狀態下，除了 CPU 快取，所有系統內容都會保留。
單調時間 - 單調時間是系統開機後經過的時間，並由核心維護。