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

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

RFC-0230： Fuchsia 中的停權
狀態	已接受
區域	功率
說明	介紹 Fuchsia 如何利用「暫停至閒置」用途，處理系統電源狀態變更，從而提升設計
問題	(127897 年)
變更	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 狀態進行比較。不同類型的系統有不同的電源和喚醒延遲時間要求，進而引導「系統電源等級」轉換系統。在系統完全開啟 (或執行中) 的情況下關閉或設法降低系統電源等級，即可在系統完全開啟 (或啟動) 的情況下電源管理，稱作「執行階段電源管理」。

定義一組標準系統效能等級，僅實作這些定義等級將無助於達成最佳功率優勢，並遵循系統恢復時間延遲時間。部分 OS 也嘗試了改造執行階段電源管理，但尚未發揮強大的效能優勢。

為解決這個問題，Fuchsia 將運用集中式電源架構，整合精細的電源管理機制。「Power Framework」是本文中的用語，所有負責制定政策決策及實作元件的電力管理元件。系統的每個子裝置 (在 SoC/peripheral/bus 等) 上都可自由定義可使用對應的 Wake 延遲數量的電量等級，並將相同的資料發布至 Power Framework。Power Framework 將能做出明智的政策決策，並實作將系統或部分系統的處理量降至低電量等級，藉此扮演著關鍵角色。Power Framework 會根據從使用者空間系統元件提供的資訊來採取行動 (例如要求系統用保證恢復時間後降低電量)、主機板設定資訊 (支援的系統電源等級、每個層級的恢復時間和 Wake 功能)，以及瞭解系統目前的功率等級 (例如各子裝置的等級、喚醒延遲時間、電源依附元件及 I/O 佇列)。

例如：

Power Framework 會收到使用者空間中系統元件提出的要求，可將系統元件降至較低電量，並確保保證恢復時間為 500 毫秒。Power Framework 會知道子裝置的所有等級，以及部分或所有 Wake 延遲。根據資訊，Power Framework 可能決定只離線使用次要 CPU、離線音訊揚聲器 (而非麥克風)、Wi-Fi 切換至其中一個低耗電模式，以及將螢幕刷新率變慢。由於這些動作可在 500 毫秒內還原回完整功能，因此系統會採取這些措施。也無法讓子裝置的其餘部分必須一律開啟電源，或喚醒延遲時間超過 500 毫秒，因此無法降低電源等級。
Power Framework 尚未與任何使用者進行互動，因此 Power Framework 會收到來自使用者空間中系統元件的要求，以便將系統降低到電量等級。電源架構沒有恢復時間要求，無法結束系統採用的較低功率等級。Power Framework 可交由系統「暫停」至「閒置」，並視情況改用「暫停至 RAM」。這些是 Power Framework 知道並採取的一些 Fuchsia 系統電源等級。

提振精神

隨著 Fuchsia 擴展支援不同類型的電池運作，電源管理是支援的必備功能。本文件特別探討 Fuchsia 如何利用系統暫停暫停使用及恢復運作。採用的設計原則是

這些驅動程式和元件實作明確定義的通訊協定和介面可能會成為「強大感知特性」。這個 RFC 中並未定義確切的介面。之後會在詳細的設計文件中討論。
驅動程式和元件不會因系統層級變更而受到影響。
這項設計整合了基礎架構，藉此實作未來的任何電源政策強制執行作業 (例如其他系統電源層級轉換、執行階段電源管理)，而不必變更驅動程式庫程式碼。

這需要 Fuchsia 的各個層，才能參與本 RFC 所涵蓋的明確定義功能。這個 RFC 不包含用於評估不同系統電源等級的電力和效能所需的所有指標。

設計

「暫停至閒置」是許多 OS 支援的低功耗系統等級。每個作業系統會以不同方式定義這類低電量。而在 Fuchsia 中，我們選擇有一種定義能達到最佳省電效果，同時也符合上述規定。這個功率等級定義是以其中一個標準規格 (ACPI) 中的定義為基礎。根據 ACPI 規格中的定義，S1 的定義為低喚醒延遲睡眠狀態。規範中提供多個實作範例。Fuchsia 的「Suspend-to-Idle」旨在盡可能接近其中一個 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.

不同的 OS 會以自己的方式實作暫停使用 ACPI 規格的定義。本文件概述暫停對 Idle 的設計，並討論 Fuchsia 如何做出改善。簡單來說，Fusia 會依照下列方式實作暫停使用 IDle，藉此優於其他未完全實作下表的 OS。

子系統	效能等級	附註
啟動 CPU	C0 (Pn)	以最低耗電量的狀態執行啟動 CPU
非啟動 CPU	關閉或降低 C 狀態 (如果有的話)	無法中斷非開機 CPU 時，可耗用最低電量
記憶體	自行重新整理	如果有這個選項
子裝置	可能的最低電量 (例如 ACPI 中定義的 D3Hot)	系統會根據恢復時間規定，讓子裝置降到最低電量。
時鐘樹和動力軌	盡力	根據主機板設定和已知的系統喚醒要求，Power Framework 可以關閉時鐘樹狀結構和電源軌的某些部分

子裝置電源狀態轉換範例：

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 kernel 並未提供查詢驅動程式的電源狀態資訊，例如喚醒延遲時間、精細的電源轉換狀態，以及各狀態的耗電量。但無法在韌體/主機板驅動程式中，向產品設計師取得這項資訊。Linux 不會將任何政策決策納入核心層，做為設計原則，確保在 Linux 核心之外，無法開放原始碼的專屬程式碼。Linux 系統 (例如 Android 和 Ubuntu) 會根據 Linux kernel 提供的電源管理功能，建構電源管理功能。只會處理查詢並提供給使用者空間的最少資訊。缺少喚醒延遲和耗電量等細節，因此以 Linux 為基礎的 OS 能夠充分節省電力並延長電池續航力。舉例來說，Android 電源管理是設計為 Linux 電源管理的包裝函式。它建立了多項電源政策和功能，例如「早期暫停架構」、「Wake Lock 機制」，帶來強大的電源優勢。但目前仍在解決各種問題，例如延長電池續航力和縮短系統恢復時間。

另一個手部使用 Windows 查詢驅動程式，針對功能電源狀態，由驅動程式提供喚醒延遲時間。這有助於 Windows 執行積極的執行階段電源管理。Windows 驅動程式不必設為開放原始碼，因此廠商可以建立嵌入專屬資訊的驅動程式。不過，Windows 不會收到任何儀表板專屬設定 (這會限制自訂執行階段電源政策決策)，也可能造成多個驅動程式庫版本存在，且每個版本嵌入了專屬白板專屬設定。

Fuchsia 將整合這兩種 OS 的知識，並確保已知的設計問題獲得解決。Fuchsia 必須整合許多晶片限制和差異，才能做出正確的決策。

a) 每個晶片都有自己的電源軌跡管理、時鐘樹狀結構管理、CPU 狀態管理和 RTC 時鐘管理設計。Fuchsia 應具備提供資訊，以利進行適當的政策決策。

b) Fuchsia 應提供基礎架構，讓駕駛人定義不同程度的耗電量，並允許驅動程式進行轉換，而非使用 ACPI D 狀態 (D0、D0i1/2/3、D1、D2 和 D3) 等固定電源等級。

c) Fuchsia 應提供基礎架構，讓驅動程式能夠回報喚醒延遲和其他驅動程式的電源設定。Power Framework 必須存取這項資訊，才能積極執行電源管理。這有助於取得優於其他正在嘗試翻新這項資訊的作業系統，以便做出電力相關系統層級的決策的作業系統。

高階設計

啟動/設定：

Power Framework 將是第一個 Fuchsia 模組，可從使用者空間的系統元件接收低功率模式要求。如要執行指令

整個系統的電源拓撲

Power Framework 必須建立或接收功率拓撲圖，並擁有相同的權限。這可讓 Power Framework 將子裝置放到較低電量等級。建立功率拓撲圖的最終設計會於 Power Framework 設計文件中討論。下列資訊可能有助於建立及維護電源拓撲圖表。

a) 元件依附元件 DAG：

使用 DFv2 時，所有驅動程式都是元件，元件管理員也會提供驅動程式和其他元件的「能力圖表」。這個依附元件圖可做為 Power Framework 的良好輸入來源，以建構電源拓撲圖。驅動程式管理器和元件管理員對於交換系統檢視畫面的不同面向。元件管理員最終擁有元件依附元件圖表做為單一可靠資料來源。Power Framework 應有查詢或存取這項資訊的方法。但這張圖表不足以用於 Power Framework。

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

電源拓撲必須擷取不同子裝置電量之間的關係，並持續掌握相同子裝置的動態意識。無論何時，都必須確保指定裝置的電源依附元件均已完成。元件和驅動程式庫拓撲目前都無法執行此操作。
驅動程式和元件的目前狀態

驅動程式存在和電源等級變化的執行階段資訊應向 Power Framework 傳達。例如，隨插即用可能引入新的驅動程式，並終止部分驅動程式庫執行個體。有些子裝置可能無法正常運作，對應的驅動程式庫可能會停止運作。部分驅動程式可以實作，用於智慧關閉裝置的某些部分，造成執行階段電源管理。

所有功率等級變動都必須向 Power Framework 告知。其中有些可能是元件管理員或驅動程式管理器提供的執行階段資訊，其中有些可能是驅動程式直接回報的資訊。
系統狀態，例如 CPU、記憶體、時鐘和電源狀態。(選填)

除了上述所有資訊外，Power Framework 也能存取 CPU、時鐘樹、記憶體和電源軌等資訊，以協助做出以失敗安全的方式暫停系統的正確決策。對應的驅動程式或核心會公開介面，讓 Power Framework 查詢目前的功率等級，也會呼叫以在暫停和重新啟用期間執行一組活動。
接收靜態主機板專屬設定和產品專屬設定。
接收「暫停至閒置」和「繼續」的使用者設定，例如 Wake 功能和繼續延遲。
轉換至較低電量前，請先決定喚醒功能。

Power Framework 可以透過各種可存取的設定，列出可透過不同系統低功率等級喚醒的子裝置。驅動程式知道/瞭解他們可以從低電量等級喚醒系統，就可以註冊中斷點，以便利用 Power Framework 喚醒系統。Power Framework 將使用這項資訊、主機板設定、產品設定和使用者空間設定來決定哪些子裝置支援喚醒，並與核心使用相同的通訊。

初始化/啟動流程的大致流程如下。

替代文字：開始/序列圖表

停權至閒置進入流程：

Power Framework 會與元件管理員、驅動程式管理器及 Zircon 等 Fuchsia 模組通訊，藉此將整個系統轉換到任何指定系統功率等級。如果使用者空間不支援使用者空間要求的模式/狀態/電源等級，Power Framework 可以選擇拒絕要求。每種模式/狀態/電源等級項目，都需要按特定順序執行不同的動作組合。

本文討論的特定模式是「暫停至閒置」的低耗電模式之一。這個模式是低 Wake 延遲睡眠狀態。Power Framework 需要維護元件的狀態機器和系統整體狀態機器，原因如下：

轉換進入或退出模式，或是拒絕模式轉換的決定，全都由 Power Framework 內部處理。
如果系統已處於特定模式，且 Power Framework 收到將系統進入其他模式的要求；Power Framework 需要知道狀態機器及其轉換作業，才能將系統進入新模式。
某些轉換作業可能會失敗，系統模式可能不會變更。這類情況應由 Power Framework 處理。Power Framework 每次轉換模式後，都應瞭解產生的模式/電源等級。

當 Fuchsia 選擇透過暫停到閒置模式來節省電力/電池電力時，Power Framework 將擁有具有電源拓撲的系統最新檢視畫面。Power Framework 會判斷哪些元件需要轉換至低電量等級，並叫用介面進行轉換。為此，所有元件和驅動程式都必須註冊並實作介面，以變更架構定義的等級，才能獲得最佳效能優勢。有關這項設計的細節，請參閱電源架構設計文件和 Power-Aware 驅動程式和元件設計文件。

請務必定義哪些硬體/軟體中斷支援喚醒功能。Power Framework 會叫用 Power Element 擁有者的適當介面，來編寫喚醒觸發條件。如有需要，也可要求核心設定喚醒來源登錄 (如適用)。有關這些設計的詳情，請參閱權力感知核心設計說明文件。

如果驅動程式庫/元件無法變更電源等級，Power Framework 可能會選擇取消作業或繼續進行。

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

以下是接到暫停呼叫時的概要流程圖。

替代文字：停權至閒置序列圖表

從「暫停至閒置」流程繼續：

當開機 CPU 收到中斷以喚醒時，系統會從「Suspend-to-Idle」繼續執行。只有受到中斷控制器 (或在某些情況下) 的 PMIC 或在某些情況下，位於每部裝置的本機裝置才會將喚醒的中斷情形由硬體傳送至 CPU。並非所有乾擾都會觸發繼續作業。觸發恢復的中斷作業將由 Power Framework 決定，並經過程式設計後，再將系統轉換為暫停使用。

由於啟動 CPU 未進入離線狀態，因此系統會將中斷情形傳送至啟動 CPU，以便叫用正確中斷服務處理常式。Power Framework 會在系統呼叫函式傳回或透過驅動程式庫轉送時，直接從核心接收暫停呼叫的狀態。驅動程式庫或 Power Framework 必須採取反向動作，才能啟動整個系統，從啟用時鐘和電源網域開始、將啟動 CPU 轉換為完整功能狀態、啟動次要 CPU、退出自行重新整理，以及其他架構相依動作 (如果有的話)。Power Framework 將負責依序使用對應的驅動程式和元件來恢復所有裝置。

以下是暫停使用「暫停至閒置」流程的高階履歷範例。

替代文字：續傳序列圖表

單元職責

Power Framework 元件：

Power Framework 是自動化調度管理整個暫停和繼續流程的元件。「Power Framework」

透過元件架構和驅動程式架構提供的服務，維護電力拓撲。
維持元件 (包括驅動程式) 之間的相依性關係。
使用核心或適當驅動程式庫的服務取得 CPU 的功能和目前狀態。
從核心或適當驅動程式呼叫服務，

a. 為了將 CPU 付諸連線/離線

b. 設定喚醒來源中斷情形 (如有必要)

c. 暫停單調時間

d. 架構變更與程式設計

上述所有步驟都可以是不同的服務呼叫，或是單一服務呼叫來執行上述所有步驟。這項設計決策和細節會記錄在 Power Framework 和 Power Aware 核心設計文件的適當設計文件中。
接收電源元素及其屬性 (例如電源元件、電源依附元件，以及驅動程式和元件喚醒延遲時間) 的介面。
可依序為驅動程式和元件設定適當功率的介面。
如要公開電源拓撲目前狀態、每個驅動程式庫/元件的狀態等指標，以及偵錯和遙測的喚醒觸發條件。

驅動程式

每個管理電力關鍵資源的 Fuchsia 驅動程式庫都需要實作下列項目來積極節省電力。

使用 Power Framework 註冊管道

a. 請提供支援的電源元素、電源層級、依附元件和 Wake 延遲時間相關資訊。

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

c. 一律提供裝置電源狀態的相關資訊 (例如由內部觸發)。

d. 公開目前狀態和內部設定等指標，以用於偵錯和遙測用途。

核心

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

確保系統在系統進入 Suspend-to-Idle 時暫停單調時間。系統處於暫停模式時，不應提前顯示時間。重新啟用時，這麼做可確保執行緒能夠與系統啟用時間的相對測量值保持一致。這樣可以確保系統暫停的時間不會影響程式的正確性。只有在系統處於暫停狀態時，如要縮短時間，請務必擁有一致的行為。
在變更 CPU 電源等級之前，先編寫 Wake 來源 (如果適用的話)。這要指的架構，而核心需要根據主面板類型設定適當的暫存器。
讓 CPU 離線或重新連線。
匯出 CPU 指標。這可能會在重新啟用作業完成時傳回，或者這可能是由 Power Framework 或偵錯工具/電源測量工具叫用的個別系統呼叫，以取得每個 CPU 的狀態。

使用者空間叫用的「暫停至閒置」與系統的排程行為無關。但是，排程器必須瞭解並採取適當行動。我們會在「Power Aware 核心」設計文件中討論這個主題的詳細設計。

全新互動的概略設計

使用 Power Framework 註冊為 Wake 功能的驅動程式

裝置驅動程式可根據驅動程式庫程式和架構類型，瞭解自身是否可透過駕駛板驅動程式庫或其他來源喚醒。舉例來說，從音訊、觸控和蓋子裝置產生的干擾都可以定義為「支援喚醒」。在目前的設計中，相對應的裝置驅動程式會呼叫 SetWakeDevice()，做為暫停函式的一部分，註冊為 Wake 來源。(例如：ACPI 上蓋驅動程式)。這項操作會在內部叫用 ACPI 驅動程式庫 SetWakeDevice() 呼叫。這屬於特定架構，無法擴充。

電源架構是決定所有電源相關設定的集中位置，會決定系統從電源層級喚醒系統的項目，目前已轉換為整個系統。因此，採用可喚醒中斷的驅動程式應使用預先定義的管道與 Power Framework 分享相關資訊。Power Framework 可以透過核心系統呼叫設定喚醒觸發條件，或與驅動程式庫進行通訊，藉此設定相同的喚醒觸發條件。這項設計決策將成為「電源架構設計」、「電源感知核心設計」和「電源感知驅動程式及元件設計」文件的一部分。

透過靜態設定佈建白板的電源設定

每個主面板都可定義設定和屬性，協助您做出有意義的電源政策決策。其中幾個範例是子裝置/週邊裝置彼此間的關係、支援的不同系統效能等級，以及可透過低功率水平喚醒系統的子裝置。例如，某些允許從 Nest-to-Idle 喚醒系統的子裝置可能無法從暫停到 RAM 喚醒系統。因此，Power Framework 有必要知道哪些子裝置可以從目前的電源等級喚醒系統。

這個主面板設定可能是開機後 Power Framework 讀取的一次性設定 (例如中央熱測點設定)，或是由主面板驅動程式庫提供給其他裝置驅動程式的資訊。驅動程式接著會處理資訊，並在初始化/註冊期間將最終設定提供給 Power Framework。

建立「能源拓撲」

Power Framework 應維護電力拓撲，以便做出有效率的電力層級轉換決策。Power Framework 具備適當的通道設定，透過元件管理員和驅動程式管理器，或與驅動程式和元件本身一併收集，以便收集資訊，例如

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

在驅動程式庫初始化期間，驅動程式和元件應透過提供的適當管道與 Power Framework 通訊。

此外，驅動程式和元件可延伸將此管道用於執行階段電源管理。例如，如果驅動程式庫或元件瞭解其電源元素並未使用，便可使用此管道要求變更電源等級。Power Framework 可根據系統狀態、依附元件和電源政策忽略或接受要求。如果要求符合要求，就可以使用管道並要求電源元素轉換為特定功率等級。

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

Power Framework 會根據驅動程式庫回報的支援等級，決定要讓哪些子裝置轉換至較低的功率等級。Power Framework 會根據特定元素的強大程度來做出這項決策。這些元素代表來自拓撲以外的政策，以及用來管理電源依附元件的一組規則。Power Framework 會透過適當的已建立管道傳送訊息，傳達子裝置轉換所需的能力層級。嘗試轉換或完成轉換後，驅動程式/元件必須向相同的管道回報狀態。

實作

暫停/恢復流程是 Fuchsia 眾多電源管理流程的第一批電源管理流程，它橫跨 Fuchsia 的多個建構區塊。這是整體設計，還有更多 RFC 或設計文件，其中涵蓋每個模組的實作詳細資料。每個模組都繫結至許多設計層面，需要進行多項變更，才能完成整個實作。

測試

這項功能橫跨福奇尼亞的多個構成元素。針對 Fuchsia 每個部分所做的任何變更都應進行單元測試。針對測試不同模組的互動和流程，應在 CI/CQ 中提供及執行整合測試，以確保其他功能不會破壞此複雜的流程，反之亦然。驅動程式測試領域可用來單獨測試驅動程式。蕾修 (無論是否準備就緒) 可用於建立及執行主機型測試。所有新建立的介面都應該在合作夥伴 SDK 中開放使用，且應進行 CTF 測試來檢查這些介面。

需要進一步文件

您必須產生下列設計文件，確保設計已完成並實作。

Power Framework Design 文件
Power-Aware 核心設計文件
Power-Aware 驅動程式和元件文件
適用於各網域的電源管理，例如音訊/繪圖/連線能力 (選用)

缺點、替代方案和未知

本提案需要許多實作階段，所有模組如核心、驅動程式、電源架構、驅動程式架構和元件架構都可提供。設計電源管理流程基準是很重要的，包括整合各種電源管理功能，讓 Fuchsia 成為電池供電產品的理想 OS。實作這項提案的成本將範圍涵蓋每一季。

還有其他策略可暫停/重新啟用。如下所示：

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

這項策略無法提供完整的解決方案，也無法提供最佳電池續航力。這個解決方案無法考量驅動程式/元件擁有的各種電源依附元件、根據相依的電源元素將子裝置分群，並根據其電源網域處理子裝置。由於缺少程式設計執行階段 Wake 來源變更、向使用者空間公開子裝置資訊等功能，因此這項設計並不完整。
遵循 Linux 中的暫停/繼續作業設計

這項策略只能確保 Fuchsia 等同於 Linux。Fuchsia 只能在這些限制下運作，例如 Linux 是單體式核心，且不像娛樂政策決策。這項策略無法讓我們利用 Fuchsia 帶來的優勢Linux 電源管理主要是是由核心執行的特定回呼作業。相較之下，許多 Fuchsia 會在使用者空間中導入許多程序，因此我們的電源管理支援必須更加分散。

雖然這些策略可能快速實作，但不接受以下這些缺點。

目前的設計提案是全新的設計，在 Fuchsia 中完成許多新增和變更。這項策略需要時間和心力，但確保我們能以安全且可擴充的方式在 Fuchsia 進行電源管理。這可確保系統不會在受限制的情況下，將電源管理流程翻新至 OS。

設計文件的未知問題將會在下一級設計文件中展開，屆時也會記錄因應措施。

詞彙解釋

電源元素：電源元素是一個實體，代表硬體子裝置 (包括電源軌和時鐘) 的強大功能，或將這些硬體元素組合成較高層級的抽象化，例如音訊串流、超音波和相機子系統。
功率：電源元素可能會佔用不同的電量。電源等級是遵循下列限制的狀態序列：由非負整數進行索引；等級 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 快取除外。
單音時間 - 單音時間是自系統開機且由核心維護的時間測量時間。