Architecture de pile de pilotes à double rôle USB

Les contrôleurs USB double rôle sont désormais pris en charge dans Windows, en commençant par Windows 10 pour les éditions de bureau (Famille, Professionnel, Entreprise et Éducation) et Windows 10 Mobile.

Introduction

La fonctionnalité double rôle USB permet à un système d’être un périphérique USB ou un hôte USB. Vous trouverez les spécifications détaillées pour USB Dual Role dans usb-IF sur la page d’informations Go .

Le point significatif ici est que la fonctionnalité double rôle permet à un appareil mobile, tel qu’un téléphone, une phablete ou une tablette, de se désigner comme un appareil ou un hôte.

Lorsqu’un appareil mobile est en mode de fonction , il est attaché à un PC ou à un autre appareil qui fait office d’hôte pour l’appareil mobile attaché.

Lorsqu’un appareil mobile est en mode hôte , les utilisateurs peuvent y attacher leurs appareils, tels qu’une souris ou un clavier. Dans ce cas, l’appareil mobile héberge les appareils attachés.

En prenant en charge le double rôle USB dans Windows 10, nous offrons les avantages suivants :

  • Connectivité aux périphériques mobiles via USB, qui offre une bande passante de données plus importante que les protocoles sans fil comme Bluetooth.
  • Option de chargement de la batterie via USB lors de la connexion à d’autres périphériques USB et de la communication avec d’autres périphériques USB (tant que la prise en charge matérielle requise est présente).
  • Activez les clients qui posséderont probablement un appareil mobile, tel qu’un téléphone intelligent pour l’ensemble de leur travail. Cette fonctionnalité permettra d’améliorer la productivité dans un scénario d’ancrage câblé, où un appareil mobile s’ancre et héberge donc des appareils périphériques.

Le tableau suivant montre la liste des pilotes de classe d’hôte disponibles sur les références SKU de bureau et mobiles de Windows.

Pilotes de classe hôte USB Windows 10 Mobile Windows 10 pour éditions de bureau
Hubs USB (USBHUB) Yes Oui (depuis Windows 2000)
HID - Clavier/Souris (HidClass, KBDCLass, MouClass, KBDHid, MouHid) Yes Oui (depuis Windows 2000)
Stockage de masse USB (bulk & UASP) Yes Oui (depuis Windows 2000)
Pilote hôte USB générique (WinUSB) Yes Oui (depuis Windows Vista)
Entrée/sortie audio USB (USBAUDIO) Yes Oui (depuis Windows XP)
Périphériques série (USBSER) Yes Oui (depuis Windows 10)
Bluetooth (BTHUSB) Yes Oui (depuis Windows XP)
Imprimer (usbprint) No Oui (depuis Windows XP)
Analyse (USBSCAN) No Oui (depuis Windows 2000)
WebCam (USBVIDEO) No Oui (depuis Windows Vista)
Media Transfer Protocol (initiateur MTP) No Oui (depuis Windows Vista)
NDIS distant (RNDIS) No Oui (depuis Windows XP)
ADRESSE IP via USB (IPoverUSB) No Oui (Nouveau pour Windows 10)

Les pilotes de classe de la table ont été sélectionnés en fonction des données de télémétrie de classe d’appareil et des scénarios clés sélectionnés pour Windows 10. Nous prévoyons d’inclure un nombre limité de pilotes d’hôte tiers de boîte de réception pour prendre en charge les périphériques clés sur Windows 10 Mobile. Et pour Windows 10 pour les éditions de bureau, ces pilotes seront disponibles sur le site web de l’OEM ou via Windows Update (WU).

Par Windows 10 Mobile, les pilotes tiers qui ne sont pas inclus dans la boîte de réception ne seront pas disponibles sur WU. L’empreinte disque de la pile hôte USB + HID a été réduite. C’est pourquoi tous les pilotes de classe ne sont pas inclus, et très peu de pilotes tiers sont inclus dans la boîte de réception pour Windows 10 Mobile. Un OEM qui souhaite mettre à disposition des pilotes tiers peut utiliser un package de support de carte (BSP) pour les ajouter aux images du système d’exploitation pour ses appareils mobiles.

Le tableau suivant montre les pilotes de classe de fonction disponibles sur les références SKU mobiles de Windows.

Notes

Les pilotes de fonction ne sont pas disponibles sur Windows 10 pour les éditions de bureau.

Pilotes de classe de fonction USB Windows 10 Mobile Windows 10 pour éditions de bureau Notes
Media Transfer Protocol (MTP Responder) Oui Non Il n’existe aucun scénario pour le répondeur MTP sur le bureau. Les scénarios P2P entre les systèmes de bureau ont été activés via Easy-MigCable sur WinUSB.
Affichage vidéo (vidstream) Oui Non
Pilote de fonction USB générique (GenericUSBFn) Oui Non Cela sera nécessaire pour IPoverUSB et d’autres scénarios de clignotement du bureau.

Nous surveillerons les données de pièce jointe d’appareil pour nous indiquer si nous devons fournir une prise en charge supplémentaire des pilotes de classe, à mesure que la liste de popularité des classes d’appareils change au fil du temps.

Implémentation du pilote

Le pilote URS (Microsoft USB Role Switch) permet à un implémenteur de système de tirer parti de la fonctionnalité USB à double rôle de sa plateforme.

Le pilote URS est destiné à fournir des fonctionnalités à double rôle pour les plateformes qui utilisent un seul contrôleur USB qui peut fonctionner à la fois dans les rôles hôtes et périphériques sur un seul port. Le rôle périphérique est également appelé rôle de fonction. Le pilote URS gère le rôle actuel du port, ainsi que le chargement et le déchargement des piles logicielles appropriées, en fonction des événements matériels de la plateforme.

Sur un système doté d’un connecteur USB micro-AB, le pilote utilise des interruptions matérielles qui indiquent l’état de la broche d’ID sur le connecteur. Cette broche permet de détecter si le contrôleur doit assumer le rôle hôte ou le rôle de fonction dans une connexion. Pour plus d’informations, consultez la spécification USB On-The-Go. Sur les systèmes dotés d’un connecteur USB Type-C, l’implémenteur OEM est censé fournir un pilote client de connecteur à l’aide des interfaces de programmation du pilote de connecteur USB Type-C. Le pilote client communique avec l’extension de classe Gestionnaire de connecteur USB fournie par Microsoft (UcmCx) pour gérer tous les aspects du connecteur USB Type-C, tels que la détection CC, la messagerie PD et autres. Pour le changement de rôle, le pilote client communique l’état du connecteur USB Type-C au pilote URS.

Le diagramme suivant montre la pile de pilotes de logiciels USB pour un contrôleur à double rôle qui utilise le pilote URS.

Architecture de pile de pilotes de commutateur de rôle usb.

Notez que le pilote URS ne chargera jamais les piles de fonction et d’hôte affichées dans le diagramme précédent simultanément. Le pilote URS charge la pile de fonctions ou la pile hôte, en fonction du rôle du contrôleur USB.

Configuration matérielle requise

Si vous développez une plateforme qui tirera parti du pilote URS pour fournir des fonctionnalités USB à double rôle, la configuration matérielle requise suivante doit être remplie :

  • Contrôleur USB

    Ces pilotes sont fournis par Microsoft en tant que pilotes in-box.

    Contrôleur USB 3.0 Synopsys DesignWare Core. Inf de boîte de réception : UrsSynopsys.inf.

    Chipidea High-Speed contrôleur OTG USB. Inf de boîte de réception : UrsChipidea.inf.

  • Interruptions de broches d’ID

    Les interruptions de broche d’ID pour les systèmes de type C non USB peuvent être implémentées de l’une des deux manières suivantes :

    Deux interruptions déclenchées par le bord : une qui se déclenche lorsque la broche d’ID sur le connecteur est mise à la terre et une autre qui se déclenche lorsque la broche d’ID est flottante.

    Une seule interruption active-both qui est au niveau actif lorsque la broche d’ID est mis à la terre.

  • Énumération du contrôleur USB

    Le contrôleur à double rôle USB doit être énuméré par ACPI.

  • Prise en charge logicielle

    Le pilote URS attend une interface logicielle qui permet de contrôler le VBus sur le connecteur. Cette interface est spécifique au SoC. Pour plus d’informations, contactez votre fournisseur de SoC.

Ces fonctionnalités OTG USB ne sont pas prises en charge dans Windows :

  • Détection de l’adaptateur de chargeur d’accessoires (ACA).
  • Protocole SRP (Session Request Protocol).
  • Host Negotiation Protocol (HNP).
  • Attacher le protocole de détection (ADP).

Configuration du système ACPI

Pour utiliser le pilote URS, vous devez créer un fichier de définition ACPI pour votre système. En outre, vous devez prendre en compte certaines considérations liées aux pilotes.

Voici un exemple de définition ACPI pour un contrôleur à double rôle USB.

//
// 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}
        })
    }
}

Voici quelques explications pour les sections main du fichier ACPI :

  • URS0 est la définition ACPI du contrôleur à double rôle USB. Il s’agit du périphérique ACPI sur lequel le pilote URS se chargera.

  • USB0 et UFN0 sont des appareils enfants dans l’étendue d’URS0. USB0 et UFN0 représentent les deux piles enfants qui seront énumérées par le pilote URS, et les piles hôte et fonction respectivement. Notez que _ADR est le moyen par lequel ACPI met en correspondance ces définitions d’appareil avec les objets d’appareil créés par le pilote URS.

  • Si le contrôleur utilise la même interruption pour les deux rôles, la même interruption de contrôleur peut être décrite dans les deux appareils enfants. Même dans ce cas, l’interruption peut toujours être décrite comme « Exclusive ».

  • Vous pouvez ajouter ce fichier de définition ACPI si nécessaire. Par exemple, vous pouvez définir toutes les autres méthodes ou propriétés nécessaires sur l’un des appareils du fichier de définition ACPI. Ces ajouts n’interfèrent pas avec le fonctionnement du pilote URS. Toutes les ressources supplémentaires requises dans l’une des piles peuvent également être décrites dans la _CRS de l’appareil approprié.

Le pilote URS affecte des ID matériels aux piles de l’hôte et des fonctions. Ces ID matériels sont dérivés de l’ID matériel de l’appareil URS. Par exemple, si vous avez un appareil URS dont l’ID matériel est ACPI\ABCD1234, le pilote URS crée des ID matériels pour les piles de l’hôte et des fonctions comme suit :

  • Pile d’hôtes : URS\ABCD1234&HOST

  • Pile de fonctions : URS\ABCD1234&FUNCTION

Packages d’installation de pilotes INF

Les packages de pilotes tiers peuvent prendre une dépendance sur ce schéma, si nécessaire.

Si vous êtes un IHV ou un OEM et que vous envisagez de fournir votre propre package de pilotes, voici quelques éléments à prendre en compte :

  • Package de pilotes URS

    Il est prévu que l’ID matériel du contrôleur double rôle sur chaque plateforme soit ajouté à la boîte de réception INF pour URS. Toutefois, si, pour une raison quelconque, l’ID ne peut pas être ajouté, l’IHV/OEM peut fournir à un package de pilotes un INF qui a besoin/inclut l’INF de la boîte de réception et qui correspond à son ID matériel.

    Cela est nécessaire dans le cas où l’IHV/OEM nécessite la présence d’un pilote de filtre dans la pile des pilotes.

  • Package de pilote hôte.

    Un package de pilotes fourni par IHV/OEM qui nécessite/inclut la boîte de réception usbxhci.inf et correspond à l’ID matériel de l’appareil hôte est requis. La correspondance de l’ID matériel est basée sur le schéma décrit dans la section précédente.

    Cela est nécessaire dans le cas où l’IHV/OEM nécessite la présence d’un pilote de filtre dans la pile des pilotes.

    Des travaux sont en cours pour que le pilote URS attribue l’ID compatible XHCI pour l’appareil hôte.

  • Package de pilotes de fonction

    Un package de pilotes fourni par IHV/OEM qui nécessite/inclut la boîte de réception Ufxsynopsys.inf et correspond à l’ID matériel du périphérique est requis. La correspondance de l’ID matériel est basée sur le schéma décrit dans la section précédente.

    L’IHV/OEM peut également inclure un pilote de filtre dans le package de pilotes.

Voir aussi

Informations de référence sur le pilote de contrôleur à double rôle