USB-Doppelrollentreiberstapelarchitektur

  • Artikel

USB Dual Role Controller werden jetzt in Windows unterstützt, beginnend mit Windows 10 für Desktopeditionen (Home, Pro, Enterprise und Education) und Windows 10 Mobile.

Einführung

Die USB Dual Role-Funktion ermöglicht es, dass ein System entweder ein USB-Gerät oder ein USB-Host ist. Die detaillierte Spezifikation für USB Dual Role finden Sie unter USB-IF's USB on the Go Information Page.

Der wesentliche Punkt hier ist, dass das Feature mit zwei Rollen ein mobiles Gerät, z. B. ein Smartphone, ein Phablet oder ein Tablet, sich als Gerät oder Host bezeichnen kann.

Wenn sich ein mobiles Gerät im Funktionsmodus befindet, wird es an einen PC oder ein anderes Gerät angefügt, das als Host für das angeschlossene mobile Gerät fungiert.

Wenn sich ein mobiles Gerät im Hostmodus befindet, können Benutzer ihre Geräte, z. B. eine Maus oder eine Tastatur, daran anschließen. In diesem Fall hostet das mobile Gerät die angeschlossenen Geräte.

Durch die Unterstützung der USB-Doppelrolle in Windows 10 bieten wir die folgenden Vorteile:

  • Konnektivität mit mobilen Peripheriegeräten über USB, die eine größere Datenbandbreite im Vergleich zu Drahtlosen Protokollen wie Bluetooth bietet.
  • Die Möglichkeit, den Akku über USB zu laden, während sie mit anderen USB-Geräten verbunden sind und mit anderen USB-Geräten kommunizieren (solange die erforderliche Hardwareunterstützung vorhanden ist).
  • Ermöglichen Sie Kunden, die höchstwahrscheinlich ein mobiles Gerät besitzen, z. B. ein Smartphone, für ihre gesamte Arbeit. Dieses Feature ermöglicht eine höhere Produktivität in einem kabelgebundenen Andockszenario, in dem ein mobiles Gerät andockt und somit Peripheriegeräte hostet.

Die folgende Tabelle zeigt die Liste der Hostklassentreiber , die auf Desktop- und mobilen SKUs von Windows verfügbar sind.

Treiber der USB-Hostklasse Windows 10 Mobile Windows 10-Desktopeditionen
USB Hubs (USBHUB) Yes Ja (seit Windows 2000)
HID - Tastatur/Mäuse (HidClass, KBDCLass, MouClass, KBDHid, MouHid) Yes Ja (seit Windows 2000)
USB-Massenspeicher (Massenspeicher & UASP) Yes Ja (seit Windows 2000)
Generischer USB-Hosttreiber (WinUSB) Yes Ja (seit Windows Vista)
USB Audio ein/aus (USBAUDIO) Yes Ja (seit Windows XP)
Serielle Geräte (USBSER) Yes Ja (seit Windows 10)
Bluetooth (BTHUSB) Yes Ja (seit Windows XP)
Drucken (usbprint) No Ja (seit Windows XP)
Scannen (USBSCAN) No Ja (seit Windows 2000)
WebCam (USBVIDEO) No Ja (seit Windows Vista)
Media Transfer Protocol (MTP-Initiator) No Ja (seit Windows Vista)
Remote-NDIS (RNDIS) No Ja (seit Windows XP)
IP über USB (IPoverUSB) No Ja (Neu für Windows 10)

Die Klassentreiber in der Tabelle wurden basierend auf Telemetriedaten der Geräteklasse und basierend auf wichtigen Szenarien ausgewählt, die für Windows 10 ausgewählt wurden. Wir planen, eine begrenzte Anzahl von Posteingangs- und 3-Drittanbieter-Hosttreibern einzuschließen, um wichtige Geräte auf Windows 10 Mobile zu unterstützen. Für Windows 10 für Desktopeditionen sind diese Treiber entweder auf der Website des OEM oder über Windows Update (WU) verfügbar.

Für Windows 10 Mobile sind die Treiber von Drittanbietern, die nicht im Posteingang enthalten sind, auf WU nicht verfügbar. Der Datenträgerbedarf des USB-Hoststapels + HID wurde klein gehalten. Aus diesem Grund sind nicht alle Klassentreiber und nur sehr wenige Treiber von Drittanbietern in den Posteingang für Windows 10 Mobile enthalten. Ein OEM, der Drittanbietertreiber zur Verfügung stellen möchte, kann ein Board Support Package (BSP) verwenden, um sie zu Betriebssystemimages für seine mobilen Geräte hinzuzufügen.

Die folgende Tabelle zeigt die Funktionsklassentreiber , die auf mobilen SKUs von Windows verfügbar sind.

Hinweis

Funktionstreiber sind auf Windows 10 für Desktopeditionen nicht verfügbar.

Treiber der USB-Funktionsklasse Windows 10 Mobile Windows 10-Desktopeditionen Hinweise
Media Transfer Protocol (MTP-Responder) Ja Nein Es gibt keine Szenarien für den MTP-Responder auf dem Desktop. P2P-Szenarien zwischen Desktopsystemen wurden über Easy-MigCable über WinUSB aktiviert.
VideoAnzeige out (vidstream) Ja Nein
Generischer USB-Funktionstreiber (GenericUSBFn) Ja Nein Dies wird von IPoverUSB und anderen Desktopblitzszenarien benötigt.

Wir überwachen Geräteanlagedaten, um uns mitzuteilen, ob wir zusätzliche Unterstützung für Klassentreiber bereitstellen müssen, da sich die Liste der Geräteklassenpopularität im Laufe der Zeit ändert.

Treiberimplementierung

Der Microsoft USB Role Switch (URS)-Treiber ermöglicht es einem Systemimplementierer, die USB-Funktion mit zwei Rollen seiner Plattform zu nutzen.

Der URS-Treiber soll Funktionen mit zwei Rollen für Plattformen bereitstellen, die einen einzelnen USB-Controller verwenden, der sowohl in Host- als auch in Peripherierollen über einen einzelnen Port betrieben werden kann. Die Peripherierolle wird auch als Funktionsrolle bezeichnet. Der URS-Treiber verwaltet die aktuelle Rolle des Ports sowie das Laden und Entladen der entsprechenden Softwarestapel basierend auf Hardwareereignissen von der Plattform.

Auf einem System, das über einen USB-Micro-AB-Anschluss verfügt, verwendet der Treiber Hardwareunterbrechungen, die den Status des ID-Pins am Stecker angibt. Dieser Pin wird verwendet, um zu erkennen, ob der Controller die Hostrolle oder die Funktionsrolle in einer Verbindung übernehmen muss. Weitere Informationen finden Sie in der Usb On-The-Go-Spezifikation. Auf Systemen mit einem USB-Typ-C-Anschluss wird erwartet, dass der OEM-Implementierer mithilfe der Programmierschnittstellen des USB-Typ-C-Anschlusstreibers einen Clienttreiber für den Connector bereitstellt. Der Clienttreiber kommuniziert mit der von Microsoft bereitgestellten USB-Connector-Manager-Klassenerweiterung (UcmCx), um alle Aspekte des USB-Typ-C-Connectors zu verwalten, z. B. CC-Erkennung, PD-Messaging und andere. Beim Rollenwechsel kommuniziert der Clienttreiber den Zustand des USB-Typ-C-Connectors an den URS-Treiber.

Das folgende Diagramm zeigt den USB-Softwaretreiberstapel für einen Controller mit zwei Rollen, der den URS-Treiber verwendet.

Usb Role-Switch-Treiberstapelarchitektur.

Beachten Sie, dass der URS-Treiber die Funktions- und Hoststapel im vorherigen Diagramm nie gleichzeitig lädt. Je nach Rolle des USB-Controllers lädt der URS-Treiber entweder den Funktionsstapel oder den Hoststapel.

Hardwareanforderungen

Wenn Sie eine Plattform entwickeln, die den URS-Treiber nutzt, um USB-Funktionen mit zwei Rollen bereitzustellen, müssen die folgenden Hardwareanforderungen erfüllt werden:

  • USB-Controller

    Diese Treiber werden von Microsoft als In-Box-Treiber bereitgestellt.

    Synopsys DesignWare Core USB 3.0-Controller. Posteingang INF: UrsSynopsys.inf.

    Chipidea High-Speed USB OTG-Controller. Posteingang INF: UrsChipidea.inf.

  • ID-Pin-Interrupts

    Die ID-Pin-Interrupts für Nicht-USB Typ-C-Systeme können auf eine von zwei Arten implementiert werden:

    Zwei durch Edge ausgelöste Interrupts: eine, die ausgelöst wird, wenn der ID-Pin auf dem Connector geerdet ist, und eine andere, die ausgelöst wird, wenn der ID-Pin schwebt.

    Ein einzelner aktiv-beide-Interrupt, der sich auf aktiver Ebene befindet, wenn der ID-Pin geerdet wird.

  • USB-Controlleraufzählung

    Der USB-Controller mit zwei Rollen muss ACPI-enumeriert sein.

  • Softwareunterstützung

    Der URS-Treiber erwartet eine Softwareschnittstelle, die die Steuerung von VBus über den Connector ermöglicht. Diese Schnittstelle ist SoC-spezifisch. Wenden Sie sich an Ihren SoC-Anbieter, um weitere Informationen zu erhalten.

Diese USB-OTG-Features werden in Windows nicht unterstützt:

  • Zubehörladeadaptererkennung (ACA).
  • Sitzungsanforderungsprotokoll (Session Request Protocol, SRP).
  • Host negotiation Protocol (HNP).
  • Attach Detection Protocol (ADP).

ACPI-Systemkonfiguration

Um den URS-Treiber verwenden zu können, müssen Sie eine ACPI-Definitionsdatei für Ihr System erstellen. Darüber hinaus gibt es einige treiberbezogene Überlegungen, die Sie berücksichtigen müssen.

Hier finden Sie eine ACPI-Beispieldefinition für einen USB-Controller mit zwei Rollen.

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

Hier finden Sie einige Erklärungen für die Standard Abschnitte der ACPI-Datei:

  • URS0 ist die ACPI-Definition für den USB-Controller mit zwei Rollen. Dies ist das ACPI-Gerät, auf das der URS-Treiber geladen wird.

  • USB0 und UFN0 sind untergeordnete Geräte im Bereich von URS0. USB0 und UFN0 stellen die beiden untergeordneten Stapel dar, die vom URS-Treiber bzw. dem Host- bzw. Funktionsstapel aufgelistet werden. Beachten Sie, dass _ADR das Mittel ist, mit dem ACPI diese Gerätedefinitionen mit den Vom URS-Treiber erstellten Geräteobjekten abgleicht.

  • Wenn der Controller für beide Rollen denselben Interrupt verwendet, kann derselbe Controller-Interrupt auf beiden untergeordneten Geräten beschrieben werden. Auch in diesem Fall kann der Interrupt immer noch als "Exklusiv" bezeichnet werden.

  • Sie können diese ACPI-Definitionsdatei nach Bedarf hinzufügen. Sie können beispielsweise alle anderen erforderlichen Methoden oder Eigenschaften auf einem der Geräte in der ACPI-Definitionsdatei festlegen. Solche Ergänzungen beeinträchtigen den Betrieb des URS-Treibers nicht. Alle zusätzlichen Ressourcen, die in einem der Stapel erforderlich sind, können auch in der _CRS des entsprechenden Geräts beschrieben werden.

Der URS-Treiber weist dem Host- und Funktionsstapel Hardware-IDs zu. Diese Hardware-IDs werden von der Hardware-ID des URS-Geräts abgeleitet. Wenn Sie beispielsweise über ein URS-Gerät verfügen, dessen Hardware-ID ACPI\ABCD1234 lautet, erstellt der URS-Treiber Hardware-IDs für den Host- und Funktionsstapel wie folgt:

  • Hoststapel: URS\ABCD1234&HOST

  • Funktionsstapel: URS\ABCD1234&FUNCTION

Installationspakete für INF-Treiber

Treiberpakete von Drittanbietern können bei Bedarf von diesem Schema abhängig sein.

Wenn Sie ein IHV oder OEM sind und ihr eigenes Treiberpaket bereitstellen möchten, sollten Sie folgendes beachten:

  • URS-Treiberpaket

    Es wird erwartet, dass die Hardware-ID für den Controller mit zwei Rollen auf jeder Plattform dem Posteingangs-INF für URS hinzugefügt wird. Wenn die ID jedoch aus irgendeinem Grund nicht hinzugefügt werden kann, kann der IHV/OEM ein Treiberpaket mit einem INF bereitstellen, das den Posteingangs-INF benötigt/enthält und der hardware-ID entspricht.

    Dies ist erforderlich, wenn der IHV/OEM einen Filtertreiber im Treiberstapel benötigt.

  • Hosttreiberpaket.

    Ein von IHV/OEM bereitgestelltes Treiberpaket, das den Posteingang usbxhci.inf benötigt/enthält und der Hardware-ID des Hostgeräts entspricht, ist erforderlich. Die Hardware-ID-Übereinstimmung basiert auf dem im vorherigen Abschnitt beschriebenen Schema.

    Dies ist erforderlich, wenn der IHV/OEM einen Filtertreiber im Treiberstapel benötigt.

    Es wird derzeit daran gearbeitet, dass der URS-Treiber die XHCI-kompatible ID für das Hostgerät zuweisen kann.

  • Funktionstreiberpaket

    Ein von IHV/OEM bereitgestelltes Treiberpaket, das den Posteingang Ufxsynopsys.inf benötigt/enthält und der Hardware-ID des Peripheriegeräts entspricht, ist erforderlich. Die Hardware-ID-Übereinstimmung basiert auf dem im vorherigen Abschnitt beschriebenen Schema.

    Der IHV/OEM kann auch einen Filtertreiber in das Treiberpaket aufnehmen.

Weitere Informationen

Referenz zu Controllertreibern mit zwei Rollen