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

摘要

這項 RFC 建議新增一個系統電源層級「暫停至閒置」，並支援從這個狀態恢復。本文將介紹 Fuchsia 的暫停至閒置流程，並說明高階需求和設計。這是第一級 RFC，定義了整個程序和設計。此外，我們也會發布更多 RFC 或設計文件，說明各個模組的實作細節。

電源管理的重點在於，當系統未處於使用中狀態時，將其降至較低的電源層級，並在需要時恢復完整功能。系統層級可與 ACPI S 狀態比較。不同類型的系統對電力和喚醒延遲有不同的要求，這會決定系統可轉換的「系統電源等級」。在系統完全開啟 (或處於活動狀態) 時，關閉或將系統部分元件調降至較低的電源層級，藉此管理系統電源，稱為執行階段電源管理。

定義一組標準系統電源等級，並只實作這些定義的等級，無法達到盡可能獲得最佳電源效益，以及遵守系統恢復時間延遲的目標。部分作業系統也嘗試改用執行階段電源管理，但尚未完全發揮省電效益。

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

例如：

1. Power Framework 會收到來自使用者空間中系統元件的要求，將系統調降至較低的電源層級，並確保恢復時間為 500 毫秒。電源架構會瞭解所有子裝置的層級，以及部分或全部的喚醒延遲。根據這項資訊，電源架構可能會決定只讓次要 CPU 離線、讓音訊喇叭 (而非麥克風) 離線、讓 Wi-Fi 進入其中一種省電模式，以及將螢幕轉換為較慢的刷新率。採取這些動作的原因是，這些動作可以在 500 毫秒內還原，恢復完整功能。因為其餘子裝置可能需要全天候運作，或喚醒延遲時間超過 500 毫秒，因此無法將其餘子裝置調降至較低的電量。

2. 由於沒有使用者互動，Power Framework 會收到使用者空間中系統元件的要求，將系統降至較低的功率等級。電力架構沒有恢復時間規定，因此可退出系統進入的較低電力級別。電源架構可能會決定讓系統進入「暫停到閒置」狀態，然後盡可能轉換為「暫停到 RAM」狀態。這些是定義完善的 Fuchsia 系統電量等級，電力架構會瞭解並據此採取行動。

提振精神

隨著 Fuchsia 支援的產品類型越來越多，且這些產品都是以電池供電，電源管理就成為不可或缺的功能。本文將著重說明 Fuchsia 讓系統進入暫停至閒置狀態，然後返回完全啟用狀態的所有層面。我們採用的設計原則如下：

1. 實作定義完善的通訊協定和介面，即可讓驅動程式和元件「瞭解電源狀態」。這份 RFC 並未定義確切的介面。詳細設計文件會說明這些內容。

2. 驅動程式和元件不會受到系統層級變更影響。

3. 設計會納入基礎架構，以便實作任何類型的未來電源政策強制執行 (例如其他系統電源層級轉換、執行階段電源管理)，而不必變更驅動程式庫程式碼。

這需要各種層級的 Fuchsia 參與，並提供本 RFC 中涵蓋的明確定義功能。這項 RFC 並未納入所有必要指標，無法協助您評估系統在各種電源等級下的電力和效能。

利害關係人

主持人：James Robinson jamesr@google.com

審查者：

• Carlos Pizano cpu@chromium.org
• Christopher Anderson cja@google.com
• Justin Mattson jmatt@google.com
• Kyle Gong kgong@google.com
• Mukesh Agrawal quiche@google.com
• Nick Maniscalco maniscalco@google.com
• Onath Dillinger claridge@google.com
• Suraj Malhotra surajmalhotra@google.com

已諮詢：

• Christopher Anderson cja@google.com
• Justin Mattson jmatt@google.com
• Nick Maniscalco maniscalco@google.com
• Onath Dillinger claridge@google.com
• Suraj Malhotra surajmalhotra@google.com

公共平台：

我們與擴大電源團隊討論了這項設計 (Fuchsia 各個模組的負責人，例如核心、驅動程式、驅動程式庫架構、元件架構和電源架構，都屬於電源團隊)。

需求條件

當系統想節省電力並使用可用的低電量等級時，Fuchsia 應實作轉換至較低電量系統等級 (視架構而定，可能是 ACPI S 狀態或任何專有方式)，並遵守使用者空間系統元件的電源管理要求。本 RFC 的目標是「暫停至閒置」系統電源層級。暫停至閒置和恢復的基本需求如下：

1. Fuchsia 應從使用者空間系統元件取得提示，並根據系統能力和狀態自行選擇進入暫停至閒置狀態。

2. 如果使用者空間提供恢復延遲時間規定，Fuchsia 應遵守相同規定。如果未提供恢復延遲時間，Fuchsia 應以盡可能最低的恢復延遲時間進入「暫停至閒置」狀態。

3. Fuchsia 應提供取得主機板專屬設定的方法，以定義允許系統從暫停到閒置狀態返回完全啟用模式的子裝置中斷。

4. 與其他作業系統相比，暫停至閒置功能應具有同等或更佳的耗電量。

5. Fuchsia 應公開 CPU、記憶體和子裝置的健康狀態和指標，供使用者空間元件用於偵錯、電力測量和制定政策決策。

6. Fuchsia 應提供方法，根據適當定義的電源依附元件，排序各元件的作業。

7. Fuchsia 應公開子裝置的遙測資料，包括接受電量等級變更的子裝置，以及拒絕/忽略要求的子裝置。如果變更要求遭到拒絕，子裝置可選擇傳送並記錄原因，以利進行偵錯及微調耗電量。

8. 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 會實作「暫停至閒置」功能，如下所示，這項功能優於其他未完全實作下表的作業系統。

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

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 核心之外。Android 和 Ubuntu 等以 Linux 為基礎的作業系統，都是以 Linux 核心提供的電源管理功能為基礎建構電源管理機制。只能根據查詢到的最低限度資訊，以及提供給使用者空間的資訊採取行動。由於缺乏喚醒延遲和耗電量等詳細資料，Linux 型作業系統無法充分發揮省電和延長電池續航力的潛力。舉例來說，Android 電源管理功能是 Linux 電源管理的包裝函式。並建立多項電源政策和功能，例如「早期暫停架構」和「Wake Lock 機制」，以獲得電源效益。但仍面臨延長電池續航力和縮短系統恢復時間等問題。

另一方面，Windows 會從驅動程式查詢功能性電源狀態的喚醒延遲時間，而驅動程式可選擇性提供這項資訊。這有助於 Windows 執行積極的執行階段電源管理。Windows 驅動程式不必開放原始碼，因此供應商可以建立驅動程式，並嵌入專屬資訊。但 Windows 不會收到任何主機板專屬設定，因此無法自訂執行階段電源管理決策，也可能導致多個驅動程式庫版本存在，且每個版本都內嵌專屬主機板設定。

Fuchsia 不僅會納入這兩個作業系統的經驗，也會確保解決已知的設計問題。Fuchsia 必須納入許多晶片限制和差異，才能做出正確決策。

a) 每種晶片都有自己的電源軌管理、時脈樹狀結構管理、CPU 狀態管理和 RTC 時脈管理設計。Fuchsia 應具備基礎架構，可提供資訊以利制定適當的政策決策。

b) Fuchsia 應提供驅動程式基礎架構，定義不同耗電量等級，並允許驅動程式在這些等級之間轉換，而非像 ACPI D 狀態 (D0、D0i1/2/3、D1、D2 和 D3) 一樣具有固定耗電量等級。

c) Fuchsia 應提供基礎架構，供驅動程式回報電源設定，例如喚醒延遲和對其他驅動程式的依附元件。電源架構需要存取這項資訊，才能積極管理電源。這有助於超越其他作業系統，因為這些作業系統會嘗試改造這項資訊，以做出與電源相關的系統層級決策。

高階設計

啟動/設定：

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

1. 整個系統的電源拓撲

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

   a) 元件依附元件 DAG：

   在 DFv2 中，所有驅動程式都是元件，元件管理服務具有驅動程式和其他元件的「能力圖」。這個依附元件圖表可做為 Power Framework 的良好輸入內容，建構電源拓撲圖表。驅動程式管理器和元件管理服務會交換系統檢視畫面中不同的層面。元件管理工具最終會將元件依附元件圖表視為單一可靠資料來源。Power Framework 應提供查詢或存取這項資訊的方式。但這個圖表不足以滿足 Power Framework 的需求。

   b) Power 元素依附元件資訊：

   電源拓撲必須擷取不同子裝置的電源電壓關係，並動態掌握這類關係。在任何時間點，都必須確保特定裝置的電源依附元件已備妥。目前元件和驅動程式庫拓撲都無法執行這項操作。

2. 驅動程式和元件的目前狀態

   驅動程式存在狀態和電量變化的執行階段資訊，應傳達給 Power Framework。舉例來說，隨插即用功能可能會導入新的驅動程式，並終止某些驅動程式庫執行個體。可能有些子裝置無法運作，對應的驅動程式庫也可能停止運作。部分驅動程式可實作智慧型功能，關閉裝置中造成執行階段電源管理問題的部分。

   所有電量變化都應通知 Power Framework。 部分資訊可能由元件管理服務或驅動程式管理器提供，部分資訊則可能由驅動程式庫直接回報。

3. 系統狀態，例如 CPU、記憶體、時脈和電源狀態。(選填)？

   除了上述所有資訊外，Power Framework 也能存取 CPU 狀態、時脈樹狀結構、記憶體和電源軌等資訊，有助於以安全無虞的方式做出暫停系統的正確決策。對應的驅動程式或核心會公開 Power Framework 的介面，以便查詢目前的電量，以及在暫停和恢復期間執行一組活動的系統呼叫。

4. 接收靜態主機板專屬設定和產品專屬設定。

5. 接收暫停至閒置和繼續作業的使用者設定，例如喚醒功能和繼續作業延遲時間。

6. 先判斷喚醒功能，再轉換至較低的電量等級。

   Power Framework 可透過存取的各種設定，列出可從不同系統低功耗層級喚醒的子裝置。如果驅動程式知道/瞭解可以從低電量狀態喚醒系統，就能向 Power Framework 註冊中斷，使其具備喚醒功能。電源架構會使用這項資訊，以及主機板設定、產品設定和使用者空間設定，判斷哪些子裝置可喚醒，並將相同資訊傳達給核心。

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

暫停至閒置狀態的進入流程：

Power Framework 會負責與元件管理服務、驅動程式管理器和 Zircon 等 Fuchsia 模組通訊，將整個系統轉換為任何指定的系統電源層級，或從該層級轉換出來。如果使用者空間要求的模式/狀態/電量不支援，電源架構可以選擇拒絕要求。每個模式/狀態/功率等級項目都需要以特定順序執行不同的動作。

本文討論的特定模式是低耗電模式之一，也就是「暫停至閒置」。這個模式的喚醒延遲時間較短，Power Framework 需要維護元件和整個系統的狀態機器，原因如下。

1. 模式轉換的決定，或拒絕模式轉換的決定，都由 Power Framework 內部處理。

2. 如果系統已處於特定模式，且 Power Framework 收到要求，要讓系統進入其他模式，Power Framework 就需要瞭解狀態機器及其轉換，才能讓系統進入新模式。

3. 部分轉換作業可能無法成功，系統模式可能不會變更。 這類情況應由 Power Framework 處理。電源架構應瞭解每次模式轉換後的模式/電源層級。

當 Fuchsia 選擇進入「暫停到閒置」模式來節省電力/電量時，電源架構會取得系統的最新檢視畫面，其中包含電源拓撲。電源架構會決定哪些元件需要轉換至低電量狀態，並叫用介面來轉換這些元件。這需要所有元件和驅動程式註冊並實作介面，才能變更架構定義的電源層級，進而獲得最佳電源效益。這項設計的詳細資料會收錄在「電源架構設計文件」和「電源感知驅動程式與元件設計文件」中。

請務必定義哪些硬體/軟體中斷可喚醒裝置。電源架構會叫用電源元素擁有者的適當介面，以程式設計喚醒觸發條件。視情況要求核心設定喚醒來源暫存器 (如適用且必要)。這些設計細節將在 Power-Aware Kernel 設計文件中說明。

如果驅動程式庫/元件無法變更電源層級，電源架構可能會選擇中止或完成作業。

電源框架應啟動要求，暫停單調時間、將 CPU 離線或設為低電量狀態、盡可能關閉時脈和電源，以及其他架構相關動作 (如有)。這可能是對核心的直接系統呼叫，也可能是透過驅動程式庫、元件或 HAL 傳送，我們會在後續設計文件中討論這點。

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

從暫停至閒置流程繼續：

當啟動 CPU 收到喚醒中斷時，系統會從「暫停到閒置」狀態繼續運作。只有在中斷控制器、PMIC 或每個裝置的本機中，以程式設計的喚醒中斷，才會由硬體傳送至 CPU。並非所有中斷都會觸發繼續作業。觸發恢復作業的中斷會由 Power Framework 決定，並在系統轉換為 Suspend-to-Idle 之前完成程式設計。

由於開機 CPU 不會離線，中斷會傳送至開機 CPU，後者會叫用正確的中斷服務常式。Power Framework 會直接從核心接收暫停呼叫的狀態 (以系統呼叫函式傳回的形式)，或透過驅動程式庫傳送狀態。該驅動程式庫或 Power Framework 必須以相反順序採取動作，才能啟動整個系統，包括啟用時脈和電源網域、將啟動 CPU 設為完全正常運作狀態、啟動次要 CPU、讓記憶體退出自我重新整理狀態，以及其他架構相關動作 (如有)。電源架構會負責使用對應的驅動程式和元件，依序恢復所有裝置。

以下是從暫停到閒置流程的高階恢復範例。

模組責任

電源架構元件：

Power Framework 元件會負責調度管理整個暫停和繼續流程。Power Framework 必須

1. 使用元件架構和驅動程式架構的服務，維護電源拓撲。

2. 維護元件 (包括驅動程式) 之間的依附關係。

3. 使用核心或適當驅動程式庫的服務，接收 CPU 的功能和目前狀態。

4. 從核心或適當的驅動程式呼叫服務，以便

   a. 讓 CPU 上線/離線

   b. 設定喚醒來源中斷暫存器 (如有需要)

   c. 如要暫停單調時間

   d. 架構特定變更和程式設計

   上述所有步驟可以是個別的服務呼叫，也可以是單一服務呼叫，一次完成所有步驟。這項設計決策和詳細資料將記錄在 Power Framework 和 Power Aware Kernel 的適當設計文件中。

5. 介面，可從驅動程式和元件接收電源元素及其屬性，例如電源層級、電源依附元件和喚醒延遲時間。

6. 介面：有條不紊地為驅動程式和元件設定適當的功率。

7. 公開電源拓撲的目前狀態、每個驅動程式庫/元件的狀態、偵錯和遙測的喚醒觸發程序等指標。

驅動程式

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

1. 使用 Power Framework 註冊管道

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

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

   c. 隨時提供電源狀態相關資訊 (例如是否在內部觸發)。

   d. 公開指標，例如目前狀態和內部設定，以利進行偵錯和遙測。

核心

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

1. 確認系統進入 Suspend-to-Idle 時，單調時間已暫停。 系統處於暫停模式時，時間不應前進。恢復後，這項作業可確保執行緒持續瞭解系統處於活動狀態的相對時間長度。這樣可確保系統暫停期間不會影響節目正確性。系統處於暫停狀態時，時間前進的行為必須一致。

2. 在變更 CPU 電源層級前，請先設定喚醒來源 (如適用且必要)。這會是架構專屬的，核心需要根據主機板類型設定適當的暫存器。

3. 將 CPU 離線或重新連線。

4. 匯出 CPU 指標。這可能在恢復作業完成時傳回，也可能是由 Power Framework 或偵錯工具/耗電量測工具叫用的個別系統呼叫，用來取得每個 CPU 的狀態。

使用者空間叫用的暫停至閒置狀態與系統的排程行為無關。不過，排程器必須瞭解並採取適當行動。相關詳細設計將在「Power Aware Kernel」設計文件中討論。

新互動的高階設計

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

裝置驅動程式可以從主機板驅動程式庫或其他來源瞭解其中斷是否具備喚醒功能，具體取決於驅動程式庫類型和架構。舉例來說，音訊、觸控和螢幕蓋裝置產生的中斷可以定義為可喚醒。在目前的設計中，對應的裝置驅動程式會呼叫 SetWakeDevice()，做為暫停函式的一部分，以註冊為喚醒來源。(例如：ACPI Lid Driver)。這會在內部叫用 ACPI 驅動程式庫 SetWakeDevice() 呼叫。這項做法僅適用於特定架構，無法擴充。

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

透過靜態設定為開發板佈建電源設定

每個主機板都可以定義有助於做出有意義電源政策決策的設定和屬性。例如子裝置/周邊裝置之間的相依性、支援的不同系統電源層級，以及可從低電源層級喚醒系統的子裝置。舉例來說，部分允許系統從暫停到閒置狀態喚醒的子裝置，可能不允許系統從暫停到 RAM 狀態喚醒。因此，電力架構必須瞭解哪些子裝置可從系統目前轉換的電力等級喚醒系統。

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

建立電源拓撲

電源架構應維護電源拓樸，以做出有效率的電源層級轉換決策。電源架構會透過適當的管道，設定元件管理服務和驅動程式管理器，或設定驅動程式庫和元件本身，以收集下列資訊：

1. 電源元素

2. 支援的相應功率等級

3. 依附於其他電源元素

4. 轉換至各層級的延遲時間

5. 喚醒能力

6. 自行發起的電量變更狀態

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

此外，驅動程式和元件可以擴充，將這個管道用於執行階段電源管理。舉例來說，如果驅動程式庫或元件瞭解自己的電源元素未在使用中，就可以透過管道要求變更電源層級。電力架構可以根據系統狀態、依附元件和電力政策，選擇忽略或接受要求。如果想接受要求，可以透過管道要求電源元素轉換至特定電源等級。

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

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

實作

暫停/繼續流程是 Fuchsia 眾多電源管理流程的第一個，也是涵蓋 Fuchsia 多個建構區塊的功能。這項 RFC 是整體設計，此外，還有其他 RFC 或設計文件，涵蓋各個模組的實作詳細資料。每個模組都綁定許多設計層面，需要多次 Gerrit 變更才能完成整個實作。

測試

這項功能涵蓋 Fuchsia 的多個建構區塊。對 Fuchsia 各個部分所做的變更，都應經過單元測試。測試模組間互動和流程的整合測試應可供使用，並在 CI/CQ 中執行，確保其他功能不會中斷這個複雜流程，反之亦然。驅動程式測試領域可用於單獨測試驅動程式。Lacewing (如果準備就緒) 可用於建立及執行以主機為準的測試。建立的任何新介面都應做為 Partner SDK 的一部分，且應通過 CTF 測試，確保介面正常運作。

需要其他文件

您需要製作下列設計文件，才能完成設計並準備好實作。

• 電源架構設計文件
• 省電核心設計文件
• 電源感知驅動程式和元件文件
• 各網域的電源管理，例如音訊/圖像/連線 (選用)

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

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

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

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

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

• 遵循 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 狀態非常相似。
  

• 喚醒延遲：子裝置或整個系統從低電量狀態轉換為全功能狀態所需的時間。
  

• 恢復時間：系統從低電量狀態恢復到完全正常運作狀態所需的最長時間。
  

• OSPM：作業系統導向的設定和電源管理
  

• ACPI S0 狀態 - 完全啟動或完全開啟狀態，耗電量高。
  

• ACPI S1 狀態 - S1 狀態定義為低喚醒延遲的睡眠狀態。在這個狀態下，除了 CPU 快取外，所有系統環境都會保留。
  

• 單調時間 - 單調時間是指系統啟動後的時間測量值，由核心維護。
  

既有技術

• 睡眠狀態 - ACPI 規格
• CPU 電源管理、C 狀態和 P 狀態的完整教學課程
• 裝置低耗電狀態 - Windows 驅動程式
• D0ix 狀態
• 支援功能電源狀態
• 系統休眠狀態 - Linux Kernel 說明文件
• Linux 中的「暫停至閒置」記錄

延伸閱讀：

• Fuchsia 電源拓撲總覽簡報
• go/fuchsia-power-topology