Architecture de la pile des pilotes de double rôle USB

  • Article
  • 10 minutes de lecture

Les contrôleurs de double rôle USB sont désormais pris en charge dans Windows, à compter de Windows 10 pour les éditions de bureau (Accueil, Pro, Enterprise et Éducation) et Windows 10 Mobile.

Introduction

La fonctionnalité de double rôle USB permet à un système d’être un périphérique USB ou un hôte USB. Vous trouverez la spécification détaillée du double rôle USB-IF sur la page d’informations Go.

Le point important ici est que la fonctionnalité double rôle permet à un appareil mobile, tel qu’un téléphone, un phablet ou une tablette, de se désigner comme étant 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 agit comme hôte pour l’appareil mobile attaché.

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

En fournissant la prise en charge du double rôle USB dans Windows 10, nous offrons les avantages suivants :

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

Le tableau suivant montre la liste des pilotes de classe 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) Oui Oui (depuis Windows 2000)
HID - Clavier/Souris (HidClass, KBDCLass, MouClass, KBDHid, MouHid) Oui Oui (depuis Windows 2000)
Stockage de masse USB (UASP en bloc&) Oui Oui (depuis Windows 2000)
Pilote hôte USB générique (WinUSB) Oui Oui (Depuis Windows Vista)
Usb Audio in/ out (USBAUDIO) Oui Oui (depuis Windows XP)
Appareils série (USBSER) Oui Oui (depuis Windows 10)
Bluetooth (BTHUSB) Oui Oui (depuis Windows XP)
Imprimer (usbprint) Non Oui (depuis Windows XP)
Analyse (USBSCAN) Non Oui (depuis Windows 2000)
WebCam (USBVIDEO) Non Oui (Depuis Windows Vista)
Protocole de transfert multimédia (initiateur MTP) Non Oui (Depuis Windows Vista)
NDIS distant (RNDIS) Non Oui (depuis Windows XP)
IP via USB (IPoverUSB) Non 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 basés sur des scénarios clés sélectionnés pour Windows 10. Nous prévoyons d’inclure un nombre limité de pilotes hôtes tiers, pour prendre en charge les appareils 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).

Pour 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é conservée petite. C’est pourquoi tous les pilotes de classe, et très peu de pilotes tiers sont inclus dans la boîte de réception pour Windows 10 Mobile. Un OEM qui souhaite rendre les pilotes tiers disponibles peut utiliser un package de support de carte (BSP) pour les ajouter aux images du système d’exploitation pour leurs 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
Protocole de transfert multimédia (répondeur MTP) Oui Non Il n’existe aucun scénario pour le répondeur MTP sur Desktop. Les scénarios P2P entre les systèmes de bureau ont été activés via Easy-MigCable via WinUSB.
Affichage vidéo (vidstream) Oui Non
Pilote de fonction USB générique (GenericUSBFn) Oui Non Cela sera nécessaire par IPoverUSB et d’autres scénarios de flashing de bureau.

Nous allons surveiller les données de pièce jointe de l’appareil, pour nous informer si nous devons fournir une prise en charge supplémentaire du pilote de classe, car la liste de popularité de la classe d’appareil change au fil du temps.

Implémentation du pilote

Le pilote URS (Microsoft USB Role Switch) permet à un implémenteur système de tirer parti de la fonctionnalité USB double rôle de leur 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 dans des 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 avec 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 d’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 des pilotes logiciels USB pour un contrôleur à double rôle qui utilise le pilote URS.

usb role-switch driver stack architecture.

Notez que le pilote URS ne charge jamais les piles de fonction et d’hôte affichées simultanément dans le diagramme précédent. 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 Synopsys DesignWare Core USB 3.0. Inf de la boîte de réception : UrsSynopsys.inf.

    Chipidea High-Speed contrôleur USB OTG. Inbox INF: UrsChipidea.inf.

  • Interruptions de broche d’ID

    Les interruptions de broche d’ID pour les systèmes non USB Type-C 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 l’épingle d’ID sur le connecteur est ancrée, et une autre qui se déclenche lorsque la broche d’ID est flottante.

    Interruption active unique qui se trouve au niveau actif lorsque la broche d’ID est ancrée.

  • É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 s’attend à une interface logicielle qui autorise le contrôle de VBus sur le connecteur. Cette interface est spécifique à SoC. Pour plus d’informations, contactez votre fournisseur soC.

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

  • Détection de l’adaptateur chargeur accessoire (ACA).
  • Protocole SRP (Session Request Protocol).
  • Protocole de négociation d’hôte (HNP).
  • Attach Detection Protocol (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, il existe certaines considérations relatives aux pilotes que vous devez prendre en compte.

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 principales du fichier ACPI :

  • URS0 est la définition ACPI pour le contrôleur à double rôle USB. Il s’agit de l’appareil ACPI sur lequel le pilote URS se charge.

  • USB0 et UFN0 sont des périphériques enfants à l’intérieur de l’étendue de URS0. USB0 et UFN0 représentent les deux piles enfants qui seront énumérées par le pilote URS, et les piles d’hôtes et de fonctions respectivement. Notez que _ADR est le moyen par lequel ACPI correspond à 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 en fonction des besoins. 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èreront 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 d’hôtes et de 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 d’hôtes et de fonctions comme suit :

  • Pile d’hôtes : URS\ABCD1234HOST&

  • Pile de fonctions : URS\ABCD1234FUNCTION&

Packages d’installation de pilotes INF

Les packages de pilotes tiers peuvent dépendre de 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

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

    Cela est nécessaire dans le cas où l’IHV/OEM nécessite qu’un pilote de filtre soit présent 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 qui correspond à l’ID matériel de l’appareil hôte est requis. La correspondance d’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 qu’un pilote de filtre soit présent dans la pile des pilotes.

    Il existe un travail en cours pour que le pilote URS affecte 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 qui correspond à l’ID matériel du périphérique est requis. La correspondance d’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 du contrôleur de rôle double