| RFC-0112：x86 上的 ACPI 支援 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 改善 x86 的 ACPI 支援。 |
| 問題 | |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-06-11 |
| 審查日期 (年-月-日) | 2021-07-21 |
摘要
大多數 x86 都使用進階設定和電源介面 (ACPI) 提供裝置拓撲、設定和 提供電源管理功能Fuchsia 的 ACPI 支援 目前尚有限：不支援以下列舉的 ACPI 裝置： 其他匯流排驅動程式 (例如 PCI)，且不支援存取 x86 以外的裝置專屬設定或電源管理方法 也同樣重要
這個 RFC 導入了發布機制，用於發布由 安裝 ACPI 裝置和公車 (即 I2C、SPI、PCI) 裝置。裝置也支援 提供多種 ACPI 功能 (接收事件、存取 和呼叫方法)。
提振精神
目前所有支援 ACPI 的裝置 (即不在 PCI 匯流排上) 的裝置均已支援 單一 if/else 陳述式中列舉。需要的裝置 存取其他 ACPI 資料 (例如來自 _DSD 的資料) 屬於 x86 的一部分 主機板驅動程式庫、對資料進行硬式編碼，或使用裝置專屬 「入侵」，提供裝置所需的資料 所發出的呼叫頻率
請注意，x86 主機板驅動程式是惡意行為：並非所有 x86 平台一定都適用 使用 ACPI。例如「電腦板驅動程式」是 IBM 的董事會驅動程式庫。 電腦平台。為求簡化，我們繼續將驅動程式庫稱為 x86 主機板驅動程式。雖然這個 RFC 會嘗試 將日後適用於 x86 和 ARM 的 ACPI 方法 RFC 的主要重點在於 x86 主機板驅動程式庫，以及未來的 ARM ACPI 都可能需要獨立的主機板驅動程式庫
這種工作方式無法擴大規模。由於我們想支援更多裝置 我們會遇到硬式編碼值彼此衝突的情況 那麼 x86 主機板驅動程式庫程式的數量會大幅上升這個 RFC 將會 我們能夠加入更多 x86 平台和電源管理支援，而不必手動管理 會有更多技術債。
設計
x86 上的每個現有裝置都會獲得一個對應的 ACPI 裝置，因此 前提是裝置在 ACPI 表格中有資料)。每個 ACPI 裝置都會 由 x86 主機板驅動程式庫發布，且可存取裝置的 ACPI 設定和方法x86 主機板驅動程式庫也會發布複合元件 也就是「真實」遊戲的子項以及 ACPI 裝置與其 而是直接繫結至「實際」而想要使用其中一種驅動程式庫裝置 這些裝置就會繫結至複合裝置。主機板驅動程式庫也會 探索靜態列舉匯流排 (即 I2C、SPI) 上的裝置，然後發布 中繼資料，用於告知匯流排驅動程式擁有的孩童裝置數量。
少數裝置也會獲得較危險的 ACPI 存取權 例如獲取 ACPI 通用鎖定實際上，只有少數裝置 需要存取這項功能，因此只會向一組 x86 主機板驅動程式庫已加入許可清單的裝置。
以下是裝置樹狀結構中單一分支版本可能的呈現範例： 適用於透過 SPI 匯流排連線的 TPM 裝置。
實作
探索裝置關係並在系統上發布 ACPI 裝置。
發現 ACPI 裝置時，我們必須判斷特定裝置是否為匯流排 以及它的公車種類這些資訊很重要 因為可讓我們判斷下一個步驟中要如何新增複合裝置 ，是否應與 ACPI 和真實的對應項目建立繫結ACPI 沒有簡單明瞭 要求從裝置確認這兩項屬性，或無法保證 公車上的裝置會是公車的孩童因此您需要拆分 裝置的探索和發布程序分為三個階段：
- 利用樹狀圖尋找裝置，設定裝置 ACPI 的對應關係 處理其內部表示法，其中含有 例如父項裝置、帳號代碼和 以及公車類型
- 檢查每部裝置的 _CRS (「目前資源」)，確認是否有 I2C/SPI 等資源如果答案為是，請取得匯流排裝置的控制代碼 (在資源中指定)，在步驟 1 的對應中查詢這個處理常式， 並介紹新的孩童裝置和公車類型
- 按照步驟 1 找到的裝置順序發布所有裝置，包括 與裝置公車相關的資訊 (例如 PCI) bus:device.function) 也能為每個公車裝置建立公車 ID。這是 因為我們需要區分不同產品 (例如兩部 I2C 裝置 同一地址在不同公車上
發布複合的「ACPI + Real」裝置。
為存取裝置現有並連接公車提供的資源 您需要建立複合裝置 包含「真實」匯流排驅動程式，以及 ACPI 裝置 所發布的版本
利用上一階段導入作業收集到的資訊， 根據裝置使用的匯流排，鍵盤驅動程式庫可執行以下其中一項操作：
- 針對執行階段列舉的公車 (例如 PCI、USB)：提供
針對 ACPI 經通訊協定專屬通訊協定 (ACPI) 已知裝置的相關資訊
機制 (以 PCI 為例，這會是「bus:device.functions」清單
作為 Pciroot 的
GetPciPlatformInfo()呼叫的一部分傳回)。匯流排驅動程式 就必須負責發布繫結至 「ACPI」裝置和「真實」。 - 針對執行階段未列舉的公車 (例如 I2C、SPI)：ACPI：ACPI 驅動程式庫會發布複合裝置，並使用現有機制 (例如 DEVICE_METADATA_I2C_CHANNELS)，向兒童的匯流排驅動程式提供資訊。於 在此情況下，匯流排驅動程式只會發布繫結至 複合片段x86 主機板驅動程式庫會發布複合裝置。
之所以將責任分離 執行階段列舉匯流排 (例如 PCI)，裝置驅動程式會使用 給匯流排驅動程式提供的繫結服務 (例如供應商和裝置 ID)。發布中 就讓 x86 主機板驅動程式庫程式的這些複合材料 以便向匯流排驅動程式收集這項資訊
同樣地，I2C 和 SPI 等其他公車也無法提供裝置相關資訊 建立繫結他們通常只知道足夠的資訊 定址 (例如 I2C 位址、SPI 晶片選擇編號)，但而不是 是與裝置相連而是將這項資訊顯示在 將 ACPI 表格儲存為硬體或相容 ID發布這些複合資料的來源 但匯流排驅動程式才能很有用 因此需要告訴匯流排驅動程式 例如 HID 和 CID)。
繫結程式範例
如果是第一個案件，x86 主機板驅動程式庫會告知公車需要哪些裝置 然後匯流排驅動程式程式會發布 片段。例如，PCI 匯流排驅動程式可能會發布複合裝置 提供兩個片段第一個會繫結至 PCI 匯流排上的裝置 繫結類似如下的程式：
BIND_PROTOCOL == PCI
BIND_PCI_TOPO == 0x5a
第二種會繫結至 ACPI 匯流排發布的同等裝置：
BIND_PROTOCOL == ACPI
BIND_ACPI_BUS_TYPE == PCI
BIND_PCI_TOPO == 0x5a
如果是第二種情況，x86 主機板驅動程式庫會使用已知的資訊 分別建立兩個片段例如 I2C 複合裝置會繫結至其 I2C 父項，具有類似如下的繫結程式：
BIND_PROTOCOL == I2C
BIND_I2C_ADDRESS == 0xaa
BIND_I2C_BUS_ID == 0
相應的 ACPI 繫結程式則如下所示：
BIND_PROTOCOL == ACPI
BIND_ACPI_BUS_TYPE == I2C
BIND_I2C_ADDRESS == 0xaa
BIND_I2C_BUS_ID == 0
透過 FIDL 公開 ACPI 事件、設定和方法
x86 主機板驅動程式庫會使用 ACPICA 程式庫與 ACPI 互動。我們會 以 FIDL 介面的形式向每部裝置公開一部分 ACPICA 程式庫 (我們可能會 這涵蓋了 本文件撰寫時樹狀結構內的驅動因素：
AcpiEvaluateObject- 可讓裝置任意存取評估功能 控制裝置狀態或取得設定 可能不準確或不適當我們會限制裝置本身評估方法，並 所有子項。- 事件處理常式 - ACPI 支援三種事件類型：固定事件、一般 用途事件與裝置物件通知。這三種 類似：裝置可以啟用/停用事件，以及安裝事件處理常式 系統會在收到事件時呼叫這個參數我們會公開 透過 FIDL 呼叫 install method 呼叫會以隱含形式， 在安裝到安裝的管道端關閉裝置端的情況下，
- 位址空間處理常式 - 與事件處理常式非常類似，且會處理 建立廣告代碼
我們即將限制一項危險的機制，
只有許可清單中的裝置公開 FIDL 通訊協定
AcpiAcquireGlobalLock。目前僅供 acpi-ec 驅動程式庫使用，
而且在強化轉換以外的情況下並未廣泛使用我們會加入許可清單
以 HID 為基礎，僅從 ACPI EC HID 開始
遷移驅動程式
在這個階段，您可以開始遷移驅動程式以使用 ACPI。適用對象 目前安裝在 x86 主機板驅動程式庫的驅動程式，這需要改寫才能使用 新的 ACPI-over-FIDL 通訊協定如果是 x86 主機板驅動程式庫以外的驅動程式 例如 Intel I2C 驅動程式庫或 I2C HID 驅動程式庫，這應該會相對簡單 將現有的硬式編碼設定值替換為決定的新值 。
成效
效能影響只會很少。大部分的新的負擔 來源為目前 x86 主機板駕駛，而他們會自行移動 且強制要求處理序間通訊 (IPC) 與 ACPI 互動。
安全性考量
- ACPI 方法沒有任何用途，即使設定範圍包含 剛才提到的 ACPI 方法可以執行任何所需操作 (例如關機) 和任何能夠 因此這個方法可執行各種操作因此，我們需要 並信任任何使用 ACPI 的驅動程式 (以及 ACPI 表格本身)。這並非 來變更，也就是所有 ACPI 驅動程式都站在桌上驅動程式庫上 另請注意，所有董事會驅動程式都具備同等特殊權限，且董事會都一樣重要 可使用外部提供的驅動程式庫 (即非撰寫或內建驅動程式) fuchsia.git).強化稽核能力和控管能力，可能會導致
隱私權注意事項
無。
測試
我們非常仰賴單元測試來測試主面板驅動程式的實作。 因為 ACPI 會假設存取整個系統。這些單元測試會驗證 功能正常運作 (例如公車類型推測、裝置探索、 等)。我們也將納入測試，確保所有 FIDL 方法 所導入的應用程式
裝置驅動程式將能公平模擬新的 ACPI FIDL 通訊協定 方便我們編寫裝置端的單元和整合測試 先前無法測試 (或難以測試) 的驅動程式。
說明文件
FIDL ACPI 通訊協定內含使用方式和 需要撰寫一些說明文件 「ACPI+真實」這個複合模型適用於 ACPI 系統的裝置，以及驅動程式應如何因應 會在該情境中處理繫結
缺點、替代方案和未知
不支援任意公車類型
如要支援透過 ACPI 公開的 x86 系統新客運類型，就需要 對 x86 主機板驅動程式庫所做的修改請注意， ACPI 的導入方式：不支援「一般」或「不明」公車。 預期維護作業的負擔相對較小且容易 因為能從開發板外存取 ACPI 表格而獲得抵銷 驅動程式庫。