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

社交：

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

需求條件

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

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 電源管理的包裝函式。並建立多項電源政策和功能，例如「早期暫停架構」和「喚醒鎖定機制」，以獲得電源效益。但仍面臨延長電池續航力和縮短系統恢復時間等問題。

另一方面，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 Framework 會決定哪些元件需要轉換至低電量狀態，並叫用介面來轉換這些元件。這需要所有元件和驅動程式註冊並實作介面，才能變更架構定義的電源層級，進而獲得最佳電源效益。這項設計的詳細資料會收錄在「電源架構設計文件」和「電源感知驅動程式與元件設計文件」中。

請務必定義哪些硬體/軟體中斷可喚醒裝置。 電源架構會叫用電源元素擁有者的適當介面，以程式設計喚醒觸發條件。視情況要求核心設定喚醒來源暫存器 (如適用且必要)。這些設計細節將在 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. 公開指標，例如目前狀態和內部設定，以利進行偵錯和遙測。

Kernel

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

1. 請確保系統進入「暫停至閒置」狀態時，單調時間會暫停。 系統處於暫停模式時，時間不應前進。恢復後，這項作業可確保執行緒持續瞭解系統運作時間的相對測量值。這樣可確保系統暫停期間不會影響節目正確性。系統處於暫停狀態時，時間前進的行為必須一致。

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

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

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

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

新互動的高階設計

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

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

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

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

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

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

建立電源拓撲

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

1. 電源元素

2. 支援的相應功率等級

3. 依附於其他電源元素

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

5. 喚醒能力

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

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

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

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

電力架構會根據驅動程式庫回報的支援層級，決定哪些子裝置應轉換至較低的電力層級。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 核心說明文件
• Linux 中的「暫停到閒置」記錄

延伸閱讀：

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