次の方法で共有


デバイス管理名前空間オブジェクト

ACPI 5.0 仕様では、デバイスの管理に使用できるいくつかの種類の名前空間オブジェクトが定義されています。 たとえば、デバイス識別オブジェクトには、子デバイスのハードウェア列挙をサポートしていないバス (I2C など) に接続するデバイスの識別情報が含まれます。 その他の種類の名前空間オブジェクトでは、システム リソースを指定したり、デバイスの依存関係を記述したり、無効にできるデバイスを指定したりできます。

Windows でのデバイスの識別

Windows プラグ アンド プレイは、デバイスの列挙子によって提供されるデバイス識別子に基づいて、デバイス ドライバーを検索して読み込みます。 列挙子は、デバイスから識別情報を抽出する方法を知っているバス ドライバーです。 一部のバス (PCI、SD、USB など) には、この抽出を行うハードウェア定義のメカニズムがあります。 ないバス (プロセッサ バスや単純な周辺機器バスなど) の場合、ACPI は名前空間内の識別オブジェクトを定義します。

Windows ACPI ドライバー Acpi.sysは、これらのオブジェクトで見つかった値を、ドライバーのニーズに応じて、デバイスを具体的に、または汎用的に識別できるさまざまなデバイス識別子文字列にアセンブルします。 ACPI 列挙デバイスを識別するために作成される文字列パターンの一部を次に示します。

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

デバイス マネージャーを開き、列挙されたデバイスの ハードウェア ID と 互換性のある ID のプロパティを調べることで、Windows によってデバイス用に作成されるデバイス識別子を確認できます。 これらの各文字列は、デバイス用に読み込むドライバーを識別するために INF ファイルで指定できます。 INF 照合の順序は、最も特定のハードウェア識別子 (最も優先されるドライバー) から最小の特定の識別子 (最も優先されるドライバー) までです。そのため、デバイスの特定の機能について詳しく知っているドライバーは、より具体的ではない (したがって、デバイス機能のサブセットのみをサポートする) ものを置き換えることができます。

デバイス識別子は INF 照合にのみ使用する必要があり、デバイス ドライバーによって解析または処理されることはありません。 デバイス ドライバーが読み込まれた特定のハードウェアを識別する必要がある場合は、インストール時に INF ファイルに適切なレジストリ キーを設定することをお勧めします。 その後、ドライバーは初期化中にこれらのキーにアクセスして、必要な情報を取得できます。

ACPI でのデバイスの識別

ハードウェア ID (_HID)

ACPI でデバイスを識別するための最小要件は、ハードウェア ID (_HID) オブジェクトです。 _HIDは、"ABC[D]xxxx" という形式の文字列を返します。ここで、"ABC[D]" はデバイスの製造元を識別する 3 文字または 4 文字の文字列 ("ベンダー ID") であり、 xxxx は、そのベンダーによって製造された特定のデバイス ("デバイス ID") を識別する 16 進数です。 ベンダー ID は、業界全体で一意である必要があります。 Microsoft は、これらの文字列が一意であることを確認するために割り当てます。 ベンダー ID は、 プラグ アンド プレイ ID - PNPID 要求から取得できます。

ACPI 5.0 では、_HIDおよびその他の識別オブジェクトでの PCI 割り当てベンダー ID の使用もサポートされているため、Microsoft からベンダー ID を取得する必要がない場合があります。 ハードウェア識別要件の詳細については、 ACPI 5.0 仕様のセクション 6.1.5「_HID (ハードウェア ID)」を参照してください。

互換性のある ID (_CID)

Microsoft は、Windows で提供される標準ドライバーと互換性のあるデバイスのベンダー ID "PNP" を予約しました。 Windows では、このベンダー ID で使用するデバイス ID の数を定義します。この ID を使用して、デバイスの Windows 提供のドライバーを読み込むことができます。 互換性のある ID (_CID) オブジェクトは、これらの識別子を返すために別のオブジェクトを使用します。 Windows では常に、INF 照合とドライバーの選択で互換性のある ID (_CID によって返される) よりもハードウェア ID (_HID によって返されます) が優先されます。 この設定により、ベンダーが提供するデバイス固有のドライバーが使用できない場合、Windows が提供するドライバーを既定のドライバーとして扱うことが可能になります。 次の表の互換性 ID は、SoC プラットフォームで使用するために新しく作成されます。

互換性のある ID 説明
PNP0C40 Windows 互換のボタン配列
PNP0C50 HID-over-I2C 準拠デバイス
PNP0C60 コンバーチブル ノート PC ディスプレイ センサー デバイス
PNP0C70 センサー デバイスをドッキングする
PNP0D10 標準デバッグを備えた XHCI 準拠 USB コントローラー
PNP0D15 標準デバッグなしの XHCI 準拠 USB コントローラー
PNP0D20 標準デバッグなしの EHCI 準拠 USB コントローラー
PNP0D25 標準デバッグを備えた EHCI 準拠 USB コントローラー
PNP0D40 SDA 標準準拠 SD ホスト コントローラー
PNP0D80 Windows 互換システム電源管理コントローラー

サブシステム ID (_SUB)、ハードウェアリビジョン (_HRV)、およびクラス (_CLS)

ACPI 5.0 では、デバイスの特定のバージョン、統合、ハードウェア リビジョンをより一意に識別する識別子を作成したり、PCI で定義されたデバイス クラスのメンバーシップを示したりするために、_HIDと共に使用できる_SUB、_HRV、および_CLS オブジェクトを定義します。 通常、これらのオブジェクトは省略可能ですが、Windows の特定のデバイス クラスで必要になる場合があります。 これらのオブジェクトの詳細については、 ACPI 5.0 仕様の「デバイス識別オブジェクト」セクション 6.1 を参照してください。

保守性のために、OEM システム上のデバイス ID を "4 部構成" の ID にする Windows ハードウェア認定キット (HCK) の要件があります。 4 つの部分は、ベンダー ID、デバイス ID、サブシステム ベンダー (OEM) ID、サブシステム (OEM) デバイス ID です。 そのため、OEM プラットフォームにはサブシステム ID (_SUB) オブジェクトが必要です。

Device-Specific メソッド (_DSM)

_DSMメソッドは、 ACPI 5.0 仕様のセクション 9.14.1「_DSM (デバイス固有のメソッド)」で定義されています。 このメソッドは、他のデバイス固有のメソッドと競合することなく、デバイス ドライバーによって呼び出すことができる個々のデバイス固有のデータおよび制御関数を提供します。 特定のデバイスまたはデバイス クラスの_DSMは、他の UUID と競合しないことが保証される UUID (GUID) を定義します。 UUID ごとに、_DSM メソッドがデータを提供したり、ドライバーの制御関数を実行したりするために実装できる一連の定義済み関数があります。 クラス固有のデータ形式とデータ形式は、個別のデバイス クラス固有の仕様で提供され、 ACPI Device-Specific メソッドでも説明されています。

アドレス (_ADR) と一意の ID (_UID)

デバイス識別には、次の 3 つの追加要件があります。

  • ハードウェア列挙可能な親バス (SDIO、USB HSIC など) に接続するが、プラットフォーム固有の機能またはコントロール (サイドバンド電源やウェイク割り込みなど) があるデバイスの場合、_HIDは使用されません。 代わりに、(前述のように) 親バス ドライバーによってデバイス識別子が作成されます。 ただし、この場合は、デバイスの ACPI 名前空間に Address オブジェクト (_ADR) が必要です。 このオブジェクトを使用すると、オペレーティング システムは、バス列挙デバイスを ACPI で記述された機能またはコントロールに関連付けることができます。
  • 特定の IP ブロックの複数のインスタンスが使用されているプラットフォームでは、各ブロックに同じデバイス識別オブジェクトが含まれるように、オペレーティング システムがブロックを区別できるようにするために、一意識別子 (_UID) オブジェクトが必要です。
  • 特定の名前空間スコープ内に同じ名前を持つデバイスは 2 つありません。

デバイス構成オブジェクト

名前空間で識別される各デバイスについて、デバイスによって消費されるシステム リソース (メモリ アドレス、割り込みなど) も、現在のリソース設定 (_CRS) オブジェクトによって報告される必要があります。 デバイスのリソース構成 (_SRS) を変更するための複数の可能なリソース構成 (_PRS) とコントロールのレポートはサポートされていますが、オプションです。

SoC プラットフォームの新機能は、デバイスが使用できる GPIO および単純な周辺機器バス (SPB) リソースです。 詳細については、「 汎用 I/O (GPIO)Simple Peripheral Bus (SPB)」を参照してください。

また、SoC プラットフォームの新機能は、汎用の固定 DMA 記述子です。 FixedDMA 記述子は、多数のシステム デバイスによる DMA コントローラー ハードウェアの共有をサポートしています。 特定のシステム デバイスに静的に割り当てられた DMA リソース (要求行とチャネル レジスタ) は、FixedDMA 記述子に一覧表示されます。 詳細については、 ACPI 5.0 仕様のセクション 19.5.49「FixedDMA (DMA リソース記述子マクロ)」を参照してください。

デバイスの状態の変更

ACPI 列挙デバイスは、さまざまな理由で無効にしたり削除したりできます。 Status (_STA) オブジェクトは、このような状態の変更をオペレーティング システムに伝達できるようにするために提供されます。 _STAの説明については、 ACPI 5.0 仕様のセクション 6.3.7 を参照してください。 Windows では、_STAを使用して、デバイスを列挙するか、無効として表示するか、ユーザーに表示しないかを判断します。 ファームウェアのこのコントロールは、ドッキングや USB OTG ホスト間の切り替えなど、多くのアプリケーションに役立ちます。

さらに、ACPI は、ASL がデバイスをドックから取り外されるなどのプラットフォーム内のイベントに関する通知をドライバーに提供するために使用できる通知メカニズムを備えています。 一般に、ACPI デバイスの状態が変わると、ファームウェアで "デバイス チェック" または "バス チェック" 通知を実行して、Windows がデバイスを再列挙し、その_STAを再評価する必要があります。 ACPI 通知の詳細については、ACPI 5.0 仕様のセクション 5.6.6「デバイス オブジェクト通知」を参照してください。

有効化/無効化

Windows プラグ アンド プレイの一部として、ドライバーは、ユーザーまたはシステム (ドライバーの更新など) によって動的に有効および無効にできる必要があります。

SoC 上のデバイスは SoC チップに統合されており、取り外すことはできません。 ほとんどの On-SoC デバイスのドライバーは、有効化と無効化の要件から除外できます。 除外されないドライバーの場合、ドライバーが順番に削除をサポートしていることを示すドライバー インターフェイスがあります。 詳細については、 Microsoft Connect Web サイトの「SoC ドライバーの PNP 要件の削減」というタイトルのドキュメントを参照してください。

ドライバーが順番に削除をサポートしていて、デバイス ハードウェアを無効にできる場合 (つまり、割り当てられたリソースへのアクセスを停止するようにデバイスを構成できます)、デバイスの ACPI 名前空間ノードに Disable (_DIS) オブジェクトを含めることができます。 このメソッドは、ドライバーが削除されるたびにオペレーティング システムによって評価されます。 _DISの使用には、次の追加要件があります。

  • _STAデバイスが無効になっている場合は常に、"リソースの有効化とデコード" ビットをクリアする必要があります。
  • デバイスは、リソース設定の設定 (_SRS) オブジェクトを指定して、デバイスハードウェアを再度有効にし、上記のビットを_STAに設定する必要があります。

詳細については、 ACPI 5.0 仕様のセクション 6.2.3 (_DIS)、6.2.15 (_SRS)、および 6.3.7 (_STA) を参照してください。

デバイスの依存関係

通常、特定のプラットフォーム上のデバイス間にはハードウェアの依存関係があります。 Windows では、すべてのデバイスがシステム内で動的に変化する (デバイスの電源が削除され、ドライバーが停止して起動されるなど) ように、すべてのデバイスが正しく機能するように、このような依存関係をすべて記述する必要があります。 ACPI では、デバイス間の依存関係を次の方法で説明します。

  1. 名前空間階層。 子デバイス (別のデバイスの名前空間内のデバイスとして一覧表示) であるデバイスは、親デバイスに依存します。 たとえば、USB HSIC デバイスは、接続先のポート (親) とコントローラー (祖父母) に依存します。 同様に、システム メモリ管理ユニット (MMU) デバイスの名前空間内に一覧表示される GPU デバイスは、MMU デバイスに依存します。

  2. リソース接続。 GPIO または SPB コントローラーに接続されているデバイスは、これらのコントローラーに依存します。 この種類の依存関係は、デバイスの_CRSに接続リソースを含めることによって説明されます。

  3. OpRegion の依存関係。 OpRegions を使用して I/O を実行する ASL 制御メソッドの場合、依存関係は制御メソッドの評価中にのみ決定されるため、オペレーティング システムによって暗黙的に認識されません。 この問題は、プラグ アンド プレイ ドライバーがリージョンへのアクセスを提供する GeneralPurposeIO および GenericSerialBus OpRegions に適用されます。 この問題を軽減するために、ACPI は OpRegion Dependency (_DEP) オブジェクトを定義します。 _DEPは、OpRegion (HW リソース) が制御メソッドによって参照される任意のデバイス名前空間で使用する必要があり、上記の 1 または 2 は、参照先の OpRegion の接続リソースに既に適用されることはありません。 詳細については、 ACPI 5.0 仕様のセクション 6.5.8「_DEP (操作リージョンの依存関係)」を参照してください。

デバイス ドライバー間にソフトウェアの依存関係がある場合もあります。 これらの依存関係についても説明する必要があります。

詳細については、次のリソースを参照してください。