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

[アーティクル]
04/01/2024

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

Windowsでのデバイスid

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

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

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

ACPIでのデバイスid

ハードウェアID(_HID)

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

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

互換性のあるID(_CID)

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

互換性 ID	説明
PNP0C40	Windowsと互換性のあるボタンの配列
PNP0C50	HID-over-I²C準拠のデバイス
PNP0C60	コンバーチブルラップトップのディスプレイセンサーデバイス
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では、_HIDと共に使用できる_SUB、_HRV、および_CLSオブジェクトを定義します。これにより、デバイスの特定のバージョン、統合、またはハードウェアリビジョンをより一意に識別する識別子を作成したり、PCI定義のデバイスクラスのメンバーシップを示したりできます。これらのオブジェクトは一般に省略可能ですが、Windowsの特定のデバイスクラスで必要になる場合があります。これらのオブジェクトの詳細については ACPI 5.0仕様のセクション6.1 「デバイス識別オブジェクト」を参照してください。

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

デバイス固有のメソッド(_DSM)

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

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

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

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

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

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

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

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

デバイスの状態の変更

ACPIで列挙されたデバイスは、さまざまな理由で無効にしたり削除したりできます。状態(_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チップに統合されており、削除することはできません。ほとんどのSoCデバイスのドライバーは、有効化と無効化の要件から除外できます。除外されていないドライバーについては、ドライバーが正常な削除をサポートしていることを示すためのドライバーインターフェイスがあります。詳細については Microsoft Connect webサイトの「SoCドライバーのPNP要件の削減」というタイトルのドキュメントを参照してください。

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

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

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

デバイスの依存関係

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

名前空間の階層。 (別のデバイスの名前空間内のデバイスとして表示される) 子デバイスであるすべてのデバイスは、親デバイスに依存しています。たとえば、USB HSICデバイスは、接続されているポート (親) とコントローラー (祖父母) に依存します。同様に、システムメモリ管理ユニット (MMU) デバイスの名前空間内に表示されるGPUデバイスは、MMUデバイスに依存します。
リソース接続。 GPIOまたはSPBコントローラーに接続されているデバイスは、これらのコントローラーに依存します。この種類の依存関係は、デバイスの_CRSに接続リソースを含めることによって記述されます。
OpRegionの依存関係。 OpRegionsを使用してi/oを実行するASL制御メソッドの場合、依存関係はコントロールメソッドの評価中にのみ決定されるため、オペレーティングシステムによって暗黙的に認識されません。この問題は、プラグアンドプレイドライバーがリージョンへのアクセスを提供するGeneralPurposeIOおよびGenericSerialBus OpRegionsに適用されます。この問題を軽減するために、ACPIはOpRegion依存関係(_DEP) オブジェクトを定義します。 _DEPは、OpRegion (HWリソース) がコントロールメソッドによって参照されている任意のデバイス名前空間で使用する必要があります。また、上記の1または2は、参照されているOpRegionの接続リソースに既に適用されています。詳細については ACPI 5.0仕様のセクション6.5.8 「_DEP (操作領域の依存関係) 」を参照してください。

デバイスドライバー間には、ソフトウェアの依存関係もあります。これらの依存関係も記述する必要があります。

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

ドライバーの読み込み順序の依存関係については、「ドライバーの読み込み順序の指定」を参照してください。
電源関係の依存関係については、次を参照してください。
- IoInvalidateDeviceRelations (電源関係の確立をトリガーするには DEVICE_RELATION_TYPE 列挙値 PowerRelations を使用して IoInvalidateDeviceRelations ルーチンを呼び出します。)
- IRP_MN_QUERY_DEVICE_RELATIONS
- WdfDeviceInitSetPnpPowerEventCallbacks
- バス上のデバイスの列挙
- 動的な列挙

次の方法で共有