第 1 章說過，電源管理是 ACPI 存在的理由；前幾章的 Method 與 Notify 也一直繞著電源事件打轉。本章正式把地圖攤開：G、S、D、C、P 五個字母家族各管什麼、彼此如何嵌套；一台筆電從闔上蓋子到再次喚醒， OS 與韌體之間完整的握手順序是什麼。這張地圖是 Module 7 後兩章、乃至日後所有電源除錯工作的座標系。

不用急著背數字。這一章的每個狀態都會回答同三個問題： 斷了哪些電、保住了什麼 context、醒來要多久 ——抓住這三軸，所有表格都能自己推出來。

電源狀態的全景地圖

ACPI 把「省電」這件事切成五個正交的家族，各自作用在不同的層級：

五個家族的嵌套關係，用一棵樹看最清楚：

兩個重點讀法。第一，D／C／P 都是 S0 世界裡的事： 系統醒著時，個別裝置可以睡（D3）、CPU 可以打盹（C6）、 頻率可以下探（Pn），這正是現代「待機時間」的主要來源。 第二，S 與 G 的對應是固定的：G1 涵蓋 S1 到 S4， G2 就是 S5——講 G-state 給人聽，講 S-state 給程式看。

S-states：S0 到 S5

S-states 定義整機的睡眠深度。判準就是導言說的三軸—— 斷了哪些電、保住什麼、醒來多久：

工程上真正活躍的只有四個：S0、S3、S4、S5。 S3 斷掉 CPU 與大部分晶片組的電，只留 RAM 自我更新與少數喚醒電路， 所以喚醒快但怕斷電；S4 把 RAM 內容寫進磁碟後全斷， 喚醒慢但拔電池也不怕；S5 連 context 都不留，下次是全新開機。 註：S4 與 S5 硬體狀態幾乎相同，差別在「磁碟裡有沒有一份待恢復的 記憶體映像」——這解釋了為什麼兩者的喚醒電路與 數值常常長得很像。

D-states：D0 到 D3cold

D-states 是「單一裝置」的電源深度，與整機狀態獨立： S0 下你的相機可以在 D3，S3 下你的網卡可能還醒著等 Wake-on-LAN。

系統睡眠的完整流程

現在把 S3 的入睡與喚醒流程走一遍。這條流程橫跨 OS、AML 與硬體， 每一站都有固定的角色；三個根層級的 Method——、 、——是韌體參與的三個掛勾點：

三個掛勾點的時機差異是考點也是雷區：（Transition To State）在driver 還沒動作前最早被叫，適合「趁裝置都醒著」 先知會 EC；（Prepare To Sleep）在 driver 都收工、 OS 即將儲存 CPU context 前執行，做最後的喚醒源設定； 最後 OS 從 Package 取出晶片組定義的 SLP_TYP 值， 連同 SLP_EN 位元一起寫進 FADT 描述的 PM1 Control 暫存器 ——這一寫下去，硬體立刻拉閘，程式碼不會有「下一行」。

喚醒是一條對稱的回程：

值得注意：S4 與 S5 也走同一套——關機前 OS 一樣會呼叫 ，所以「關機卡住」有時也是 ASL 的鍋； 而喚醒路徑上 執行時 driver 都還沒恢復， 在裡面碰還沒上電的裝置就是自找麻煩。

_Sx 物件與 _PTS／_WAK 實作

OS 怎麼知道這台機器支援哪些 S-state、SLP_TYP 該填多少？ 答案是根層級的 Package：宣告了哪個， OS 才提供哪個。DSDT 沒有 ，睡眠選單就不會有睡眠。 每個 Package 的前兩個元素是寫進 PM1a／PM1b 控制暫存器的 SLP_TYP 值，數值由晶片組 datasheet 定義，純屬平台常數：

逐行拆解：

• 四個 Package 宣告本平台支援 S0、S3、S4、S5。 以 為例，0x05 就是這顆晶片組「進 S3」的 SLP_TYP 編碼——換一顆晶片組就是另一組數字， 抄錯的下場見下面的警告框。

• 收到目標 S-state（）， 示範用 port 0x80 記 log——寫 POST code 除錯埠是 bring-up 階段追蹤睡眠流程的傳統手藝， 邏輯分析儀或除錯卡上看得一清二楚。

• 規格要求回傳兩個整數的 Package： 第一個是狀態碼（0 表示正常），第二個保留。 忘記 Return 是新手最常犯的 錯誤。

• 收到的參數同 ；喚醒收尾時 還會以 再被叫一次， 需要區分方向時檢查 是否為零。

在 Linux 上驗證平台宣告與實際行為：

顯示 這個入口實際走哪條路： 就是傳統 S3， 則是前面補充框說的 S0ix 路線——同一台機器可能兩者都支援，以中括號標示目前選擇。

Power Resources

第 15 章的 D-states 定義了裝置「可以睡多深」，但誰去真的拉 GPIO、 關穩壓器？答案是 ：ACPI 把每一條電源軌 抽象成一個「可開、可關、可查詢」的物件，並讓裝置宣告 「我在 D0 需要哪幾條軌」。OS 據此用 決定何時真正開關——兩顆裝置共用一條軌時，最後一個離開的人才關燈。 這是筆電裡攝影機、感測器、SSD 等周邊省電的實作核心， 也是 D3cold 能不能正確醒來的關鍵。

本章從 PowerResource 的宣告語法開始，走過 ／／ 三件套、reference counting 的運作、裝置端的 到 掛勾，最後以「GPIO 控制的相機電源軌」 完整範例收尾。

PowerResource 物件：宣告與參數

PowerResource 的宣告長這樣（本體裡面放的是 Method， 所以它其實是一種「帶電源語意的迷你 Device」）：

三個參數的意義：

SystemLevel 把資源和 S-states 綁在一起：一條 SystemLevel 為 0 的軌，系統要進 S1 以下就必須先關掉它；宣告成 3， 則它可以陪系統睡到 S3。ResourceOrder 解決相依問題—— OSPM 開電時從小號碼開到大號碼，關電時反向。 時脈源、上游穩壓器給小號碼，吃電的下游給大號碼， 「先有電、再有時脈、再開裝置」的順序就有了保障。

三件套：_ON、_OFF、_STA

每個 PowerResource 必須提供三個零參數的 Method，規約如下：

• ：把資源打開。返回時資源必須已可用 ——電壓要穩、時脈要鎖定，必要的 ramp-up 延遲 （／）要做在這裡面。

• ：把資源關閉。同樣要等關閉序列完成才返回。

• ：回報目前狀態，只能回 0（關）或 1（開）。 OS 開機時靠它同步初始狀態，避免多此一舉的開關。

OSPM 的 reference counting：何時真的關電

裝置宣告需求（下一節的 ），OSPM 替每條資源記帳：

• 有裝置進入「需要這條資源」的 D-state：計數加一； 0 變 1 的瞬間呼叫 。

• 裝置離開該 D-state：計數減一；歸零的瞬間 呼叫 。

• 計數在中間變動（1 變 2、2 變 1）：什麼都不呼叫。

裝置端的掛勾：_PR0 到 _PR3

裝置用四個 Package 物件申報「各個 D-state 需要哪些資源」：

那行請畫線：D3hot 與 D3cold 的差別， 在 ASL 層面就是「 列的資源開著還是關了」。 OS 想把裝置送進 D3cold，就把 資源的計數也釋放掉； 資源歸零斷電，裝置從匯流排上消失——第 15 章那條除錯分水嶺， 機關全在這個 Package 裡。

_PSx 與 PowerResource 的分工

裝置端還有一組 到 Method（第 8 章出現過）， 和 PowerResource 是分工而非競爭的關係：

• PowerResource：管「可能共用」的平台資源 ——電源軌、時脈、reset 線。誰用都一樣，所以抽出來共管。

• ：管「這顆裝置自己」的進出手續 ——儲存暫存器、通知 EC、設定內部省電模式。

• 順序是規格定死的：進 D0 時先把資源開好 （ 全 ON）再叫 ； 進 D3 時先叫 再放掉資源。 口訣：有電才辦事，辦完事才斷電。

喚醒能力：_PRW、_DSW 與 _PSW

有些裝置睡了還要能叫醒系統（網卡的 Wake-on-LAN、 USB 鍵盤喚醒）。裝置用 申報喚醒能力： Package 的第一個元素是喚醒用的 GPE 編號（第 14 章的那些 GPE）， 第二個是「還能喚醒系統」的最深 S-state， 之後可以再列喚醒期間必須維持的 PowerResource：

搭配的動詞是 （Device Sleep Wake）：OS 在裝置入睡前 呼叫它，告知「要不要武裝喚醒、系統要去哪、你會睡多深」， AML 據此設定硬體的喚醒鎖存。老式的 （一個參數， 只管開關）已被 取代，但舊表裡仍常見—— 兩者並存時 OS 用 。喚醒真的發生時， 韌體或 handler 會對裝置 Notify 0x02（第 14 章的 Device Wake）， 告訴 OS 是誰按的鈴。

完整範例：GPIO 電源軌與兩顆相機

把整章組裝起來：一條由 memory-mapped GPIO 控制的 3.3V 軌 ，供兩顆相機感測器共用。這是平板、筆電上 如假包換的真實場景：

逐行拆解：

• GPIO 暫存器用 Module 5 的 OperationRegion＋Field 描述， 恰好 1 位元寬，讓 直接 就滿足「只回 0 或 1」的規約 ——順手的欄位切法能省掉一堆遮罩程式碼。

• 拉高 GPIO 後 等電壓站穩， 對應穩壓器 datasheet 的 ramp-up 時間； 通常不必等。

• 兩顆相機的 都列 ： 這一行就是 reference counting 的報名表。

• 另有 ／ 做感測器 自己的手續——注意它們與 ／ 的相對順序由 OSPM 保證，AML 不必自己協調。

兩顆相機先後使用時，OSPM 的記帳過程如下：

在 Linux 上可以直接觀察裝置目前的 D-state， 驗證這套機制真的在動：

CPU Power Management

就算整台系統穩穩待在 S0，電源管理也一刻沒停：CPU 每一毫秒 都在「跑多快」與「睡多深」之間游走——前者是 （Performance），後者是 （Idle）。 韌體用一組 ACPI 物件把「這顆 CPU 有哪些檔位、怎麼切換」 告訴 OS；OS 的 governor 再依負載即時決策。

本章依序拆解 效能表、 閒置表、 多核協調；再看現代平台（HWP／） 的衝擊；最後用 ThermalZone 接上溫度保護閉環—— 熱管理正是 P-state 限速最大的客戶。

兩條軸線：跑多快與睡多深

先把三個字母釘在座標上：

P 與 C 的關係一句話講完：P-states 只在 C0 有意義 ——CPU 得先醒著才談跑多快。T-states 用「跳過時脈週期」 硬降溫，效率遠差於降 P-state，帶過即可。

Processor 物件：兩代寫法

CPU 在 Namespace 裡也是裝置，但歷史留下兩種宣告。 舊式用專屬的 關鍵字，參數依序是名稱、 ProcID（對應 MADT 的編號）、P_BLK 埠位址與長度； ACPI 6.4 起這個關鍵字正式棄用，新式寫法就是普通的 加上 為 ：

不論哪種殼，、 這些電源物件都放在 它的 scope 底下。（或舊式的 ProcID）是 OS 把物件 對應到實體核心的鑰匙；每顆邏輯 CPU 都要有自己的一份宣告， 所以這類表格幾乎都由 BIOS 開機時動態生成 SSDT（Module 8 實戰）。

P-states：_PSS、_PCT 與 _PPC

三件套分工： 列出檔位選單、 指出 換檔暫存器、 動態限制可用上限。 是 「Package 的 Package」，每個內層六個欄位描述一個 P-state：

完整範例——一顆有三個檔位的 CPU，換檔走原生 MSR：

逐行拆解：

• 的兩個 Register 分別是 PERF_CTL 與 PERF_STATUS。 意為「功能固定硬體」： OS 認得這家 CPU 的原生機制（x86 上是 MSR），不必給位址。

• 檔位由快到慢排列（規格要求 P0 在前）。 Control 值是「寫進暫存器的位元樣式」，來自 CPU datasheet；Status 用來輪詢確認換檔完成。

• 回傳「目前允許的最高檔位索引」： 0 表示全部開放，1 表示 P0 禁用，以此類推。

的威力在「動態」。典型劇本是拔掉變壓器改用電池： EC 的 query 方法（例如 ）把 改成 1， 再對 CPU 物件發 Notify 0x80（第 14 章的 Processor 專用碼）， OS 便重讀 、即刻禁用 P0——不改表、不重開機， 限速就生效了。過熱降頻（thermal throttling）走的也是同一條路。

C-states：_CST 與它的歷史

C-state 的宣告走 ：外層第一個元素是狀態個數， 之後每個內層 Package 四個欄位描述一個 C-state：

讀法：C1 用 ——x86 上就是 HLT／MWAIT 原生指令；C2／C3 用 ，OS 讀一下指定的 I/O 埠， 晶片組就把 CPU 送入對應深度（範例列 C1 與 C3，C2 同理）。 Type 告訴 OS 語意差異（C3 起快取不再 snoop）， Latency 讓 governor 權衡值不值得睡這麼深。

一點歷史： 之前，C-state 寫死在 FADT 的 P_BLK 裡——固定的 P_LVL2／P_LVL3 埠、最多三個狀態、 延遲是死數字。 把這一切搬進 Namespace： 數量不限、暫存器任意，還可以動態換——韌體發 Notify 0x81，OS 就重讀（接電源開放深睡、用電池收淺）。 範例的 0x415 正是傳統 P_LVL3 的位址，兩代一脈相承。

多核協調：_PSD、_CSD 與 _TSD

兩顆核心共用電壓平面時，一顆想降頻、另一顆還在全速， 誰說了算？（P-state Dependency）就是申報書： 告訴 OS 哪些 CPU 同屬一個相依域、用哪種協調方式。 Package 五欄位依序是 NumEntries（固定 5）、Revision（0）、 Domain、CoordType、NumProcessors：

（C-state）與 （T-state）格式如出一轍。 實務經驗： 寫錯域或協調型別，常見症狀是 「頻率卡死最低檔」或「一顆核心降頻全機陪跑」——禍首在韌體表。

現代平台的現實：HWP 與 _CPC

讀到這裡你可能會問：我的筆電真的照 換檔嗎？ 誠實的答案是——大概不是。

自己的平台走哪條路，在 Linux 上一查便知： 目錄下的 若顯示 就是 HWP 路線，顯示 表示 OS 正在用你的 ；而 的 狀態名稱若帶 字尾（如 ）， 代表 被採用了。

Thermal：溫度閉環

CPU 電源管理的最後一塊拼圖是熱。ACPI 用 物件描述一個溫度管理區，把感測、門檻與對策接成閉環。 核心物件一覽：

（表外還有 ——進 S4 的門檻，與 ——輪詢週期，實務較少調整。）溫度單位是本節的頭號陷阱： 0.1 K（十分之一凱氏度）。換算式： 數值 = （攝氏 + 273.15）\(\times\) 10，所以 3032 即 30.05 \(^{\circ}\)C，95 \(^{\circ}\)C 的 trip point 要寫 3682。 完整範例——含被動與主動散熱的熱區，加上配套風扇：

逐行拆解：

• 風扇是「披著 Device 外皮的 PowerResource 客戶」： （標準 為 PNP0C0B）掛著 ；OS 要開風扇就把它拉到 D0， reference counting 順勢呼叫 ——上一章的機制無縫重用。

• ＋：過 95 \(^{\circ}\)C 就對 清單裡的 CPU 被動降頻，／／ 是回授迴圈的係數與週期。

• ＋：60 \(^{\circ}\)C 開風扇； 多級風扇再加 ／，數字越小越熱。 則是 105 \(^{\circ}\)C 的保命關機線。

• 通知沿用第 14 章：EC 跨門檻時 對熱區 Notify 0x80，OS 重讀 ；改 trip point 則 Notify 0x81。

事件驅動的完整閉環如下：