USB デュアル ロール ドライバー スタック アーキテクチャ

USB デュアル ロール コントローラーは、Windows 10 デスクトップ エディション (Home、Pro、Enterprise、Education) および Windows 10 Mobile 以降、Windows でサポートされるようになりました。

はじめに

USB デュアル ロール機能を使用すると、システムを USB デバイスまたは USB ホストにすることができます。 USB デュアル ロールの詳細な仕様は、USB-IF の USB on the Go ページで確認できます。

ここで重要な点は、デュアル ロール機能により、電話、ファブレット、タブレットなどのモバイル デバイスが自身をデバイスまたはホストとして指定できることです。

モバイル デバイスが機能モードの場合、接続されているモバイル デバイスのホストとして機能する PC またはその他のデバイスに接続されます。

モバイル デバイスがホスト モードの場合、ユーザーはデバイス (マウスやキーボードなど) をデバイスに接続できます。 この場合、モバイル デバイスは接続されたデバイスをホストします。

Windows 10 で USB デュアル ロールのサポートを提供することにより、次の利点が得られます。

• USB 経由でモバイル周辺機器に接続すると、Bluetooth などのワイヤレス プロトコルと比較してより大きなデータ帯域幅が提供されます。
• 他の USB デバイスに接続および通信しながら、USB 経由でバッテリーを充電するオプション (必要なハードウェア サポートが存在する場合)。
• スマートフォンなどのモバイル デバイスを所有している可能性が高い顧客がすべての仕事に使用できるようにします。 この機能により、モバイル デバイスがドッキングされて周辺デバイスをホストする有線ドッキング シナリオの生産性が向上します。

次の表に、Windows のデスクトップ SKU とモバイル SKU で使用できるホスト クラス ドライバーの一覧を示します。

表内のクラス ドライバーは、デバイス クラス テレメトリと、Windows 10 用に選択された主要なシナリオに基づいて選択されました。 Windows 10 Mobile 上の主要なデバイスをサポートするために、限られた数のインボックス、サードパーティ ホスト ドライバーを含める予定です。 また、デスクトップ エディションの Windows 10 の場合、これらのドライバーは OEM の Web サイトまたは Windows Update (WU) 経由で入手できます。

Windows 10 Mobile の場合、インボックスに含まれていないサードパーティ製ドライバーは WU から入手できません。 USB ホスト スタック + HID のディスク フットプリントは小さく抑えられています。 これが、Windows 10 Mobile のインボックスにすべてのクラス ドライバーが含まれているわけではなく、ごくわずかなサードパーティ ドライバーが含まれている理由です。 サードパーティ製ドライバーを利用可能にしたい OEM は、ボード サポート パッケージ (BSP) を使用して、モバイル デバイスの OS イメージにドライバーを追加できます。

次の表は、Windows のモバイル SKU で使用できる関数クラス ドライバーを示しています。

デバイス クラスの人気リストは時間の経過とともに変化するため、追加のクラス ドライバー サポートを提供する必要があるかどうかを通知するために、デバイスの接続データを監視します。

ドライバーの実装

Microsoft USB ロール スイッチ (URS) ドライバーを使用すると、システム実装者はプラットフォームのデュアル ロール USB 機能を活用できます。

URS ドライバーは、単一のポート上でホストとペリフェラルの両方の役割で動作できる単一の USB コントローラーを使用するプラットフォームにデュアルロール機能を提供することを目的としています。 周辺機器ロールは、関数ロールとも呼ばれます。 URS ドライバーは、プラットフォームからのハードウェア イベントに基づいて、ポートの現在の役割と、適切なソフトウェア スタックのロードとアンロードを管理します。

USB マイクロ AB コネクタを備えたシステムでは、ドライバーはコネクタの ID ピンの状態を示すハードウェア割り込みを利用します。 このピンは、コントローラーが接続においてホストの役割を担う必要があるのか、それとも機能の役割を引き受ける必要があるのかを検出するために使用されます。 詳細については、USB On-The-Go の仕様に関する記事を参照してください。 USB Type-C コネクタを備えたシステムでは、OEM 実装者は USB Type-C コネクタ ドライバ プログラミング インターフェイスを使用してコネクタ クライアント ドライバーを提供することが期待されます。 クライアント ドライバーは、マイクロソフトが提供する USB コネクタ マネージャー クラス拡張機能 (UcmCx) と通信して、CC 検出、PD メッセージングなど、USB Type-C コネクタのあらゆる側面を管理します。 ロールを切り替えるために、クライアント ドライバーは USB Type-C コネクタの状態を URS ドライバーに伝えます。

次の図は、URS ドライバーを使用するデュアルロール コントローラーの USB ソフトウェア ドライバー スタックを示しています。

URS ドライバーは、上の図に示されている関数スタックとホスト スタックを同時にロードすることは決してないことに注意してください。 URS ドライバーは、USB コントローラーの役割に応じて、関数スタックまたはホスト スタックを読み込みます。

ハードウェア要件

URS ドライバーを利用するプラットフォームを開発している場合、デュアルロール USB 機能を提供するには、次のハードウェア要件を満たす必要があります。

• USB コントローラー

  これらのドライバーは、マイクロソフトによってインボックス ドライバーとして提供されます。

  Synopsys DesignWare Core USB 3.0 コントローラー。 受信トレイ INF: UrsSynopsys.inf。

  Chipidea High-Speed USB OTG コントローラー。 受信トレイ INF: UrsChipidea.inf。

• ID ピン割り込み

  非 USB Type-C システムの ID ピン割り込みは、次の 2 つの方法のいずれかで実装できます。

  2 つのエッジによってトリガーされる割り込み:1 つはコネクタの ID ピンが接地されたときに発生し、もう 1 つは ID ピンが浮動しているときに発生します。

  ID ピンが接地されている場合にアクティブ レベルにある 1 つのアクティブ/両方割り込み。

• USB コントローラーの列挙

  USB デュアルロール コントローラーは ACPI 列挙する必要があります。

• ソフトウェア サポート

  URS ドライバーは、コネクタ経由で VBus を制御できるソフトウェア インターフェイスを想定しています。 このインターフェイスは SoC 固有です。 詳細については、SoC ベンダーにお問い合わせください。

Windows では、次の USB OTG 機能はサポートされていません。

• アクセサリ 充電器アダプター検出 (ACA)。
• セッション要求プロトコル (SRP)。
• ホスト ネゴシエーション プロトコル (HNP)。
• Attach Detection Protocol (ADP)。

ACPI システム構成

URS ドライバーを使用するには、システムの ACPI 定義ファイルを作成する必要があります。 さらに、考慮する必要があるドライバー関連の考慮事項がいくつかあります。

USB デュアルロール コントローラーの ACPI 定義の例を次に示します。

//
// You may name the device whatever you want; we don't depend on it being called 'URS0'.
//
Device(URS0)
{
    //
    // Replace with your own hardware ID. Microsoft will add it to the inbox INF,
    // or you may choose to author a custom INF that uses Needs & Includes directives
    // to include sections from the inbox INF.
    //
    Name(_HID, "ABCD1234")

    Name(_CRS, ResourceTemplate() {
        //
        // The register space for the controller must be defined here.
        //
        Memory32Fixed(ReadWrite, 0xf1000000, 0xfffff)


        //
        // The ID pin interrupts, if you are using two edge-triggered interrupts.
        //
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1001}
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1002}

        //
        // Following is an example of a single active-both interrupt.
        //
        // GpioInt(Edge, ActiveBoth, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x12}
        //

        //
        // For a Type-C platform, you do not need to specify any interrupts here.
        //
    })

    //
    // This child device represents the USB host controller. This device node is in effect
    // when the controller is in host mode.
    // You may name the device whatever you want; we don't depend on it being called 'USB0'.
    //
    Device(USB0)
    {
        //
        // The host controller device node needs to have an address of '0'
        //
        Name(_ADR, 0)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt.
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x10}
        })
    }

    //
    // This child device represents the USB function controller. This device node is in effect
    // when the controller is in device/function/peripheral mode.
    // You may name the device whatever you want; we don't depend on it being called 'UFN0'.
    //
    Device(UFN0)
    {
        //
        // The function controller device node needs to have an address of '1'
        //
        Name(_ADR, 1)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt (this could be the same as the one defined in
            // the host controller).
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x11}
        })
    }
}

ACPI ファイルのメインセクションの説明を次に示します。

• URS0 は、USB デュアルロール コントローラーの ACPI 定義です。 これは、URS ドライバーが読み込まれる ACPI デバイスです。

• USB0 と UFN0 は、URS0 のスコープ内の子デバイスです。 USB0 と UFN0 は、URS ドライバーによって列挙される 2 つの子スタック、およびそれぞれホスト スタックと関数スタックを表します。 _ADR は、ACPI がこれらのデバイス定義を URS ドライバーが作成するデバイス オブジェクトと照合する手段であることに注意してください。

• コントローラーが両方のロールに同じ割り込みを使用する場合、両方の子デバイスで同じコントローラー割り込みを記述できます。 その場合でも、割り込みは「排他的」と表現できます。

• 必要に応じて、この ACPI 定義ファイルに追加できます。 たとえば、ACPI 定義ファイル内の任意のデバイスに必要なその他のメソッドまたはプロパティを設定できます。 このような追加は、URS ドライバーの操作に干渉しません。 いずれかのスタックで必要な追加リソースは、適切なデバイスの _CRS に記述することもできます。

URS ドライバーは、ホストと関数スタックにハードウェア ID を割り当てます。 これらのハードウェア ID は、URS デバイスのハードウェア ID から派生します。 たとえば、ハードウェア ID が ACPI\ABCD1234 である URS デバイスがある場合、URS ドライバーは次のようにホストおよび関数スタックのハードウェア ID を作成します。

• ホスト スタック: URS\ABCD1234&HOST

• 関数スタック: URS\ABCD1234&FUNCTION

INF ドライバーのインストール パッケージ

サードパーティのドライバー パッケージは、必要に応じてこのスキームに依存することができます。

IHV または OEM で、独自のドライバー パッケージの提供を検討している場合は、次の点を考慮する必要があります。

• URS ドライバー パッケージ

  各プラットフォームのデュアルロール コントローラーのハードウェア ID が URS の受信ボックス INF に追加されることが予想されます。 ただし、何らかの理由で ID を追加できない場合、IHV/OEM は、受信ボックス INF を必要とする/インボックス INF を含み、ハードウェア ID と一致する INF を含むドライバー パッケージを提供する場合があります。

  これは、IHV/OEM がドライバー スタックにフィルター ドライバーが存在することを要求する場合に必要です。

• ホスト ドライバー パッケージ。

  受信トレイ usbxhci.inf が必要で、ホスト デバイスのハードウェア ID と一致する IHV/OEM 提供のドライバー パッケージが必要です。 ハードウェア ID の一致は、前のセクションで説明したスキームに基づきます。

  これは、IHV/OEM がドライバー スタックにフィルター ドライバーが存在することを要求する場合に必要です。

  URS ドライバーがホスト デバイスに XHCI 互換 ID を割り当てるようにする作業が進行中です。

• 関数ドライバー パッケージ

  受信トレイ Ufxsynopsys.inf が必要で、周辺デバイスのハードウェア ID と一致する IHV/OEM 提供のドライバー パッケージが必要です。 ハードウェア ID の一致は、前のセクションで説明したスキームに基づきます。

  IHV/OEM は、ドライバー パッケージにフィルター ドライバーを含めることもできます。

参照

デュアルロール コントローラー ドライバー リファレンス