Architettura dello stack di driver a doppio ruolo USB
I controller con doppio ruolo USB sono ora supportati in Windows, a partire da Windows 10 per le edizioni desktop (Home, Pro, Enterprise ed 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 il doppio ruolo USB è disponibile nella pagina delle informazioni su USB-IF.
La funzionalità dual role consente a un dispositivo mobile, ad esempio un telefono 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 il dispositivo, ad esempio un mouse o una tastiera. 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 maggiore larghezza di banda dei dati 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 lavoro. Questa funzionalità consente una maggiore produttività in uno scenario di ancoraggio cablato, in cui un dispositivo mobile è ancorato e ospita quindi i dispositivi periferici.
La tabella seguente mostra l'elenco dei driver di classe host disponibili nelle edizioni desktop e per dispositivi mobili di Windows.
| Driver di classe host USB | Windows 10 Mobile | Windows 10 per le 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 (Bulk & UASP) | Sì | Sì (da Windows 2000) |
| Driver host USB generico (WinUSB) | Sì | Sì (da Windows Vista) |
| Usb Audio in/out (USBAUDIO) | Sì | Sì (da Windows XP) |
| Dispositivi seriali (USBSER) | Sì | Sì (da Windows 10) |
| Bluetooth (BTHUSB) | Sì | Sì (da Windows XP) |
| Stampa (usbprint) | No | Sì (da Windows XP) |
| Scansione (USBSCAN) | No | Sì (da Windows 2000) |
| WebCam (USBVIDEO) | No | Sì (da Windows Vista) |
| Media Transfer Protocol (iniziatore MTP) | No | Sì (da Windows Vista) |
| Remote NDIS (RNDIS) | No | Sì (da 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. Prevediamo di includere un numero limitato di driver di posta in arrivo, host di terze parti, per supportare i dispositivi chiave in Windows 10 Mobile. E per Windows 10 per le edizioni desktop, questi driver sono disponibili nel sito Web dell'OEM o tramite Windows Update (WU).
Per Windows 10 Mobile, i driver di terze parti non inclusi nella posta in arrivo non sono disponibili in Windows Update. Il footprint del disco dello stack host USB + HID è mantenuto piccolo. Ecco perché non tutti i driver di classe e alcuni driver di terze parti sono inclusi nella posta in arrivo per Windows 10 Mobile. Un OEM che vuole rendere disponibili driver di terze parti può usare un pacchetto BSP (Board Support Package) per aggiungerli alle immagini del sistema operativo per i propri dispositivi mobili.
La tabella seguente illustra i driver della classe di funzione disponibili nelle edizioni per dispositivi mobili di Windows.
Nota
I driver di funzione non sono disponibili in Windows 10 per le edizioni desktop.
| Driver di classe della funzione USB | Windows 10 Mobile | Windows 10 per le edizioni desktop | Note |
|---|---|---|---|
| Risponditore MTP (Media Transfer Protocol) | Sì | No | Non esistono scenari per il risponditore MTP sul desktop. Gli scenari P2P tra sistemi desktop sono stati abilitati tramite Easy-MigCable su WinUSB. |
| Video Display out (vidstream) | Sì | No | |
| Driver di funzione USB generico (GenericUSBFn) | Sì | No | IPoverUSB e altri scenari di flashing desktop richiedono questo driver. |
Monitoriamo i dati degli allegati del dispositivo per segnalarci se dobbiamo fornire un supporto maggiore per i driver di classe come aggiornamenti dell'elenco di popolarità della classe di dispositivo.
Implementazione del driver
Il driver URS (Microsoft USB Role Switch) consente a un implementatore di sistema di sfruttare la funzionalità USB a doppio ruolo della piattaforma.
Il driver URS è progettato per fornire funzionalità a doppio ruolo per le piattaforme che usano un singolo controller USB che può funzionare sia in ruoli host che periferici su una singola porta. Il ruolo periferica è noto anche come ruolo funzione. Il driver URS gestisce il ruolo corrente della porta. Il driver URS carica e scarica gli stack software appropriati, in base agli eventi hardware della piattaforma.
In un sistema che dispone di un connettore USB micro-AB, il driver usa interrupt hardware che indica lo stato del pin ID sul 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, l'implementatore OEM dovrebbe fornire un driver client connettore usando le interfacce di programmazione dei driver del connettore USB Type-C. Il driver client comunica con l'estensione della classe UcmCx (Usb Connector Manager) fornita da Microsoft per gestire tutti gli aspetti del connettore USB Type-C, ad esempio il rilevamento cc, la 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.
Il driver URS non carica mai gli stack di funzioni e host visualizzati contemporaneamente nel diagramma precedente. Il driver URS carica lo stack di funzioni o lo stack host, a seconda del ruolo del controller USB.
Requisiti hardware
Se si sviluppa una piattaforma che sfrutta il driver URS, per fornire funzionalità USB a doppio ruolo, è necessario soddisfare i requisiti hardware seguenti:
Controller USB
Questi driver vengono forniti da Microsoft come driver predefiniti.
Controller USB 3.0 di Synopsys DesignWare Core. Inbox INF: UrsSynopsys.inf.
Chipidea High-Speed USB OTG Controller. Inbox INF: UrsChipidea.inf.
Interruzioni dei pin ID
Uno o più interrupt di pin ID per sistemi non USB Type-C vengono implementati in uno dei due modi seguenti:
- Interruzioni attivate da due archi: una che viene attivata quando il pin ID sul connettore è a terra e un altro che viene attivato quando il pin ID è mobile.
- Un singolo interrupt attivo-entrambi a livello attivo quando il pin ID è a terra.
Enumerazione controller USB
Il controller a doppio ruolo USB deve essere enumerato con ACPI.
Supporto software
Il driver URS prevede un'interfaccia software che consente il controllo del bus di rete sul connettore. Questa interfaccia è specifica di SoC. Per altri dettagli, contattare il fornitore soC.
Queste funzionalità USB OTG non sono supportate in Windows:
- Rilevamento dell'adattatore del caricabatterie per accessori (ACA).
- Session Request Protocol (SRP).
- Protocollo HNP (Host Negotiation Protocol).
- Attach Detection Protocol (ADP).
Configurazione del sistema ACPI
Per usare il driver URS, è necessario creare un file di definizione ACPI per il sistema. Inoltre, esistono alcune considerazioni relative ai driver da 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. Il driver URS viene caricato in questo dispositivo ACPI.
USB0 e UFN0 sono dispositivi figlio all'interno dell'ambito di URS0. USB0 e UFN0 rappresentano rispettivamente i due stack figlio enumerati dal driver URS e gli stack host e funzione. _ADR è il mezzo con cui ACPI corrisponde a queste definizioni di dispositivo con gli oggetti dispositivo creati dal driver URS.
Se il controller usa lo stesso interrupt per entrambi i ruoli, lo stesso interrupt controller può essere descritto in entrambi i dispositivi figlio. Anche in questo caso, l'interrupt può comunque essere descritto come "Esclusivo".
È possibile aggiungere il file di definizione ACPI in base alle esigenze. Ad esempio, è possibile impostare qualsiasi altro metodo o proprietà necessario in uno dei dispositivi nel file di definizione ACPI. Tali aggiunte non interferiscono con il funzionamento del driver URS. Tutte le altre risorse necessarie in uno qualsiasi degli stack possono essere descritte anche nella _CRS del dispositivo appropriato.
Il driver URS assegna gli ID hardware agli stack di host e funzioni. Questi ID hardware derivano 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 di host e funzioni come indicato di seguito:
Stack host: URS\ABCD1234&HOST
Stack di funzioni: URS\ABCD1234&FUNCTION
Pacchetti di installazione dei driver INF
Se necessario, i pacchetti driver di terze parti possono dipendere da questo schema.
Se sei un IHV o un OEM e stai pensando di fornire il tuo pacchetto driver, ecco alcuni aspetti da considerare:
Pacchetto driver URS
L'ID hardware per il controller a doppio ruolo in ogni piattaforma viene aggiunto alla posta in arrivo INF per URS. Tuttavia, se per qualche motivo l'ID non può essere aggiunto, 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.
Questo pacchetto driver è necessario quando l'IHV/OEM richiede che un driver di filtro sia presente nello stack di driver.
Pacchetto driver host
Pacchetto driver fornito da IHV/OEM che richiede/Include la posta in arrivo usbxhci.inf e corrisponde all'ID hardware del dispositivo host. La corrispondenza dell'ID hardware si basa sullo schema descritto nella sezione precedente.
Questo pacchetto driver è necessario quando l'IHV/OEM richiede che un driver di filtro sia presente nello stack di driver.
È in corso il processo per assegnare al driver URS l'ID compatibile XHCI per il dispositivo host.
Pacchetto del driver di funzione
Pacchetto driver fornito da IHV/OEM che richiede/Include la posta in arrivo Ufxsynopsys.inf e corrisponde all'ID hardware del dispositivo periferico. La corrispondenza dell'ID hardware si basa sullo schema descritto nella sezione precedente.
L'IHV/OEM può includere anche un driver di filtro nel pacchetto driver.