Architettura dello stack di driver dual role USB
I controller con doppio ruolo USB sono ora supportati in Windows, a partire da Windows 10 per le edizioni desktop (Home, Pro, Enterprise e Education) e Windows 10 Mobile.
Introduzione
La funzionalità dual role USB consente a un sistema di essere un dispositivo USB o un host USB. La specifica dettagliata per USB Dual Role è disponibile nella pagina informazioni su USB-IF.
Il punto significativo è che la funzionalità del doppio ruolo consente a un dispositivo mobile, ad esempio un telefono, un phablet o un tablet, di designarsi come un dispositivo o un host.
Quando un dispositivo mobile è in modalità funzione , viene collegato a un PC o a un altro dispositivo che funge da host per il dispositivo mobile collegato.
Quando un dispositivo mobile è in modalità host , gli utenti possono collegare i dispositivi, ad esempio un mouse o una tastiera, a esso. In questo caso il dispositivo mobile ospita i dispositivi collegati.
Fornendo supporto per il doppio ruolo USB in Windows 10, offriamo i vantaggi seguenti:
- Connettività ai dispositivi periferici mobili tramite USB, che offre una larghezza di banda dei dati maggiore rispetto ai protocolli wireless come Bluetooth.
- L'opzione di ricarica della batteria tramite USB durante la connessione e la comunicazione con altri dispositivi USB (purché sia presente il supporto hardware richiesto).
- Abilitare i clienti che probabilmente possiedono un dispositivo mobile, ad esempio uno smart phone per tutto il loro lavoro. Questa funzionalità consente una maggiore produttività in uno scenario di ancoraggio cablato, in cui un dispositivo mobile ancora e quindi ospita dispositivi periferici.
Nella tabella seguente viene illustrato l'elenco dei driver di classe host disponibili negli SKU desktop e per dispositivi mobili di Windows.
| Driver di classe host USB | Windows 10 Mobile | Windows 10 per edizioni desktop |
|---|---|---|
| Hub USB (USBHUB) | Sì | Sì (da Windows 2000) |
| HID - Tastiera/Mouse (HidClass, KBDCLass, MouClass, KBDHid, MouHid) | Sì | Sì (da Windows 2000) |
| Archiviazione di massa USB (& UASP bulk) | Sì | Sì (da Windows 2000) |
| Driver host USB generico (WinUSB) | Sì | Sì (dal momento che Windows Vista) |
| Audio USB in/out (USBAUDIO) | Sì | Sì (dal momento che Windows XP) |
| Dispositivi seriali (USBSER) | Sì | Sì (dal momento che Windows 10) |
| Bluetooth (BTHUSB) | Sì | Sì (dal momento che Windows XP) |
| Stampa (usbprint) | No | Sì (dal momento che Windows XP) |
| Analisi (USBSCAN) | No | Sì (da Windows 2000) |
| WebCam (USBVIDEO) | No | Sì (dal momento che Windows Vista) |
| Protocollo di trasferimento multimediale (iniziatore MTP) | No | Sì (dal momento che Windows Vista) |
| RNDIS (Remote NDIS) | No | Sì (dal momento che Windows XP) |
| IP tramite USB (IPoverUSB) | No | Sì (Nuovo per Windows 10) |
I driver di classe nella tabella sono stati selezionati in base ai dati di telemetria della classe di dispositivo e in base agli scenari chiave selezionati per Windows 10. Si prevede di includere un numero limitato di driver host di terze parti, per supportare i dispositivi chiave in Windows 10 Mobile. E per Windows 10 per le edizioni desktop, questi driver saranno disponibili sul sito Web dell'OEM o tramite Windows Update (WU).
Per Windows 10 Mobile, i driver di terze parti che non sono inclusi nella posta in arrivo non saranno disponibili in WU. Il footprint del disco dello stack host USB + HID è stato mantenuto piccolo. Questo è il motivo per cui non tutti i driver di classe e pochissimi driver di terze parti sono inclusi nella casella di posta in arrivo per Windows 10 Mobile. Un OEM che desidera rendere disponibili i driver di terze parti può usare un pacchetto di supporto della scheda (BSP) per aggiungerli alle immagini del sistema operativo per i dispositivi mobili.
Nella tabella seguente vengono illustrati i driver della classe di funzione disponibili negli SKU mobili di Windows.
Nota
I driver di funzione non sono disponibili in Windows 10 per le edizioni desktop.
| Driver di classe funzione USB | Windows 10 Mobile | Windows 10 per edizioni desktop | Note |
|---|---|---|---|
| Protocollo di trasferimento multimediale (risponditore MTP) | Sì | No | Non esistono scenari per il risponditore MTP su Desktop. Gli scenari P2P tra sistemi Desktop sono stati abilitati tramite Easy-MigCable tramite WinUSB. |
| Visualizzazione video (vidstream) | Sì | No | |
| Driver di funzione USB generico (GenericUSBFn) | Sì | No | Questo sarà necessario per IPoverUSB e altri scenari di flashing desktop. |
Monitoreremo i dati degli allegati del dispositivo, per comunicare se è necessario fornire supporto aggiuntivo per driver di classe, poiché l'elenco di popolarità della classe di dispositivi cambia nel tempo.
Implementazione del driver
Il driver Microsoft USB Role Switch (URS) consente a un implementatore di sistema di sfruttare la funzionalità USB a doppio ruolo della piattaforma.
Il driver URS è destinato a fornire funzionalità dual-role per le piattaforme che usano un singolo controller USB che può funzionare sia in ruoli host che periferiche su una singola porta. Il ruolo periferica è noto anche come ruolo funzione. Il driver URS gestisce il ruolo corrente della porta e il caricamento e lo scarico degli stack software appropriati, in base agli eventi hardware della piattaforma.
In un sistema con connettore USB micro-AB, il driver usa interruzioni hardware che indica lo stato del pin ID nel connettore. Questo pin viene usato per rilevare se il controller deve assumere il ruolo host o il ruolo della funzione in una connessione. Per altre informazioni, vedere la specifica USB On-The-Go. Nei sistemi con un connettore USB Type-C, è previsto che l'implementatore OEM fornisca un driver client connettore usando le interfacce di programmazione del driver del connettore USB Type-C. Il driver client comunica con l'estensione della classe di Gestione connettori USB fornita da Microsoft (UcmCx) per gestire tutti gli aspetti del connettore USB Type-C, ad esempio rilevamento CC, messaggistica PD e altri. Per il cambio di ruolo, il driver client comunica lo stato del connettore USB Type-C al driver URS.
Il diagramma seguente illustra lo stack di driver software USB per un controller a doppio ruolo che usa il driver URS.
Si noti che il driver URS non caricherà mai gli stack di funzioni e host visualizzati contemporaneamente nel diagramma precedente. Il driver URS caricherà lo stack di funzioni o lo stack host, a seconda del ruolo del controller USB.
Requisiti hardware
Se si sta sviluppando una piattaforma che sfrutta il driver URS, per fornire funzionalità USB a doppio ruolo, i requisiti hardware seguenti devono essere soddisfatti:
Controller USB
Questi driver vengono forniti da Microsoft come driver in box.
Controller USB 3.0 di Synopsys DesignWare Core. Inbox INF: UrsSynopsys.inf.
Chipidea High-Speed controller USB OTG. Inbox INF: UrsChipidea.inf.
Interruzioni del pin ID
Gli interruzioni dei pin ID per sistemi non USB Type-C possono essere implementati in uno dei due modi seguenti:
Due interruzioni attivate dal bordo: una che viene attivata quando il pin ID sul connettore viene bloccato a terra e un altro che viene attivato quando il pin ID è mobile.
Un singolo interruzione attivo che è a livello attivo quando il pin ID è a terra.
Enumerazione controller USB
Il controller a doppio ruolo USB deve essere enumerazione ACPI.
Supporto software
Il driver URS prevede un'interfaccia software che consente il controllo di VBus sul connettore. Questa interfaccia è specifica del SoC. Per altre informazioni, contattare il fornitore di SoC.
Queste funzionalità USB OTG non sono supportate in Windows:
- Rilevamento dell'adattatore del caricatore accessorio (ACA).
- Protocollo SRP (Session Request Protocol).
- Protocollo di negoziazione host (HNP).
- Collegare il protocollo di rilevamento (ADP).
Configurazione del sistema ACPI
Per usare il driver URS, è necessario creare un file di definizione ACPI per il sistema. Inoltre, esistono alcune considerazioni correlate al driver che è necessario tenere in considerazione.
Ecco una definizione ACPI di esempio per un controller a doppio ruolo 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}
})
}
}
Ecco alcune spiegazioni per le sezioni principali del file ACPI:
URS0 è la definizione ACPI per il controller a doppio ruolo USB. Si tratta del dispositivo ACPI in cui verrà caricato il driver URS.
USB0 e UFN0 sono dispositivi figlio all'interno dell'ambito di URS0. USB0 e UFN0 rappresentano rispettivamente i due stack figlio che verranno enumerati dal driver URS e gli stack host e funzione. Si noti che _ADR è il mezzo in base al quale ACPI corrisponde a queste definizioni di dispositivo con gli oggetti dispositivo creati dal driver URS.
Se il controller usa lo stesso interruzione per entrambi i ruoli, lo stesso interruzione del controller può essere descritta in entrambi i dispositivi figlio. Anche in questo caso, l'interruzione può comunque essere descritta come "Esclusiva".
È possibile aggiungere il file di definizione ACPI in base alle esigenze. Ad esempio, è possibile impostare qualsiasi altro metodo o proprietà necessari in uno dei dispositivi nel file di definizione ACPI. Tali aggiunte non interferiscono con l'operazione del driver URS. Tutte le risorse aggiuntive necessarie in uno qualsiasi degli stack possono essere descritte anche nella _CRS del dispositivo appropriato.
Il driver URS assegna ID hardware agli stack host e funzione. Questi ID hardware sono derivati dall'ID hardware del dispositivo URS. Ad esempio, se si dispone di un dispositivo URS il cui ID hardware è ACPI\ABCD1234, il driver URS crea ID hardware per gli stack host e funzione come indicato di seguito:
Stack host: URS\ABCD1234&HOST
Stack di funzioni: URS\ABCD1234&FUNCTION
Pacchetti di installazione driver INF
Se necessario, i pacchetti driver di terze parti possono assumere una dipendenza da questo schema.
Se si è un IHV o un OEM e si sta pensando di fornire il proprio pacchetto driver, ecco alcune cose da considerare:
Pacchetto driver URS
Si prevede che l'ID hardware per il controller a doppio ruolo in ogni piattaforma venga aggiunto alla posta in arrivo INF per URS. Tuttavia, se per qualche motivo non è possibile aggiungere l'ID, l'IHV/OEM può fornire un pacchetto driver con un INF che richiede/Include la posta in arrivo INF e corrisponde al relativo ID hardware.
Ciò è necessario nel caso in cui l'IHV/OEM richieda che un driver di filtro sia presente nello stack di driver.
Pacchetto del driver host.
È necessario un pacchetto driver fornito da IHV/OEM che richiede/Include l'indirizzo usbxhci.inf della posta in arrivo e corrisponde all'ID hardware del dispositivo host. La corrispondenza ID hardware si basa sullo schema descritto nella sezione precedente.
Ciò è necessario nel caso in cui l'IHV/OEM richieda che un driver di filtro sia presente nello stack di driver.
Il driver URS assegna l'ID compatibile XHCI per il dispositivo host.
Pacchetto driver funzione
È necessario un pacchetto driver fornito da IHV/OEM che richiede/Include la casella di posta in arrivo Ufxsynopsys.inf e corrisponde all'ID hardware del dispositivo periferico. La corrispondenza ID hardware si basa sullo schema descritto nella sezione precedente.
L'IHV/OEM può includere anche un driver di filtro nel pacchetto driver.
Vedere anche
Informazioni di riferimento sul driver del controller a doppio ruolo
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per