Condividi tramite

Oggetti dello spazio dei nomi di gestione dei dispositivi

  • Articolo

La specifica ACPI 5.0 definisce diversi tipi di oggetti dello spazio dei nomi che possono essere usati per gestire i dispositivi. Ad esempio, gli oggetti di identificazione del dispositivo contengono informazioni di identificazione per i dispositivi che si connettono ai bus, ad esempio I2C, che non supportano l'enumerazione hardware dei dispositivi figlio. Altri tipi di oggetti dello spazio dei nomi possono specificare le risorse di sistema, descrivere le dipendenze dei dispositivi e indicare quali dispositivi possono essere disabilitati.

Identificazione del dispositivo in Windows

Windows Plug and Play trova e carica i driver di dispositivo in base a un identificatore di dispositivo fornito dall'enumeratore del dispositivo. Gli enumeratori sono driver di bus che sanno come estrarre le informazioni di identificazione dal dispositivo. Alcuni bus (ad esempio PCI, SD e USB) dispongono di meccanismi definiti dall'hardware per eseguire questa estrazione. Per gli autobus che non sono (ad esempio il bus del processore o un bus di periferica semplice), ACPI definisce gli oggetti di identificazione nello spazio dei nomi.

Il driver ACPI di Windows, Acpi.sys, assembla i valori trovati in questi oggetti in varie stringhe di identificatore di dispositivo che possono identificare un dispositivo in modo specifico, o genericamente, a seconda delle esigenze del driver. Alcuni dei modelli di stringa creati per identificare i dispositivi con enumerazione ACPI sono:

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

È possibile visualizzare gli identificatori di dispositivo creati da Windows per il dispositivo aprendo Gestione dispositivi e controllando le proprietà ID hardware e ID compatibili del dispositivo enumerato. Ognuna di queste stringhe è disponibile per essere specificata in un file INF per identificare il driver da caricare per il dispositivo. L'ordine di corrispondenza INF è compreso tra l'identificatore hardware più specifico (il driver più preferito) e l'identificatore meno specifico (driver meno preferito), in modo che i driver che conoscano di più sulle funzionalità specifiche del dispositivo possano sostituire quelli meno specifici (e quindi supportano solo un subset delle funzionalità del dispositivo).

Gli identificatori di dispositivo devono essere usati solo per la corrispondenza INF e non devono mai essere analizzati o elaborati dal driver di dispositivo. Se il driver di dispositivo deve identificare l'hardware specifico per cui è stato caricato, il metodo consigliato consiste nell'impostare le chiavi del Registro di sistema appropriate nel file INF in fase di installazione. Il driver può quindi accedere a queste chiavi durante l'inizializzazione per ottenere le informazioni necessarie.

Identificazione del dispositivo in ACPI

ID hardware (_HID)

Il requisito minimo per identificare un dispositivo in ACPI è l'oggetto ID hardware (_HID). _HID restituisce una stringa con il formato "ABC[D]xxxx", dove "ABC[D]" è una stringa di 3 caratteri o 4 caratteri che identifica il produttore del dispositivo (l'ID fornitore) e xxxx è un numero esadecimale che identifica il dispositivo specifico prodotto dal fornitore (l'ID dispositivo). Gli ID fornitore devono essere univoci nel settore. Microsoft alloca queste stringhe per assicurarsi che siano univoche. Gli ID fornitore possono essere ottenuti da Plug and Play ID - Richiesta PNPID.

ACPI 5.0 supporta anche l'uso di ID fornitore assegnati da PCI in _HID e altri oggetti di identificazione, pertanto potrebbe non essere necessario ottenere un ID fornitore da Microsoft. Per altre informazioni sui requisiti di identificazione hardware, vedere la sezione 6.1.5 " _HID (ID hardware)" della specifica ACPI 5.0.

ID compatibile (_CID)

Microsoft ha riservato l'ID fornitore "PNP" per i dispositivi compatibili con i driver posta in arrivo forniti con Windows. Windows definisce un numero di ID dispositivo da usare con questo ID fornitore che può essere usato per caricare il driver fornito da Windows per un dispositivo. Per restituire questi identificatori viene utilizzato un oggetto separato, l'ID compatibile (_CID). Windows preferisce sempre gli ID hardware (restituiti da _HID) rispetto agli ID compatibili (restituiti da _CID) nella selezione dei driver e delle corrispondenze INF. Questa preferenza consente al driver fornito da Windows di essere considerato come driver predefinito se non è disponibile un driver specifico del dispositivo fornito dal fornitore. Gli ID compatibili nella tabella seguente vengono appena creati per l'uso con le piattaforme SoC.

ID compatibile Descrizione
PNP0C40 Matrice di pulsanti compatibile con Windows
PNP0C50 Dispositivo conforme a HID over-I2C
PNP0C60 Dispositivo sensore di visualizzazione portatile convertibile
PNP0C70 Dispositivo del sensore di ancoraggio
PNP0D10 Controller USB conforme a XHCI con debug standard
PNP0D15 Controller USB compatibile con XHCI senza debug standard
PNP0D20 Controller USB conforme a EHCI senza debug standard
PNP0D25 Controller USB conforme a EHCI con debug standard
PNP0D40 Controller host SD conforme allo standard SDA
PNP0D80 Controller di risparmio energia del sistema compatibile con Windows

ID sottosistema (_SUB), revisione hardware (_HRV) e classe (_CLS)

ACPI 5.0 definisce gli oggetti _SUB, _HRV e _CLS che possono essere usati insieme alla _HID per creare identificatori che identificano in modo più univoco una versione, un'integrazione o una revisione hardware specifiche di un dispositivo o per indicare l'appartenenza a una classe di dispositivi definita da PCI. Questi oggetti sono in genere facoltativi, ma potrebbero essere richiesti da determinate classi di dispositivi in Windows. Per altre informazioni su questi oggetti, vedere la sezione 6.1 "Device Identification Objects" della specifica ACPI 5.0.

Per la gestibilità, esiste un requisito HCK (Windows Hardware Certification Kit) che gli ID dispositivo nei sistemi OEM siano ID "in quattro parti". Le quattro parti sono l'ID fornitore, l'ID dispositivo, l'ID fornitore del sottosistema (OEM) e l'ID dispositivo sottosistema (OEM). Di conseguenza, l'oggetto SUBSYSTEM ID (_SUB) è necessario per le piattaforme OEM.

Metodo Device-Specific (_DSM)

Il metodo _DSM è definito nella sezione 9.14.1, "_DSM (metodo specifico del dispositivo)", della specifica ACPI 5.0. Questo metodo fornisce singole funzioni di controllo e dati specifici del dispositivo che possono essere chiamate da un driver di dispositivo senza conflitti con altri metodi specifici del dispositivo. Il _DSM per un determinato dispositivo o classe di dispositivo definisce un UUID (GUID) che non è garantito che si scontra con altri UUID. Per ogni UUID, è disponibile un set di funzioni definite che il metodo _DSM può implementare per fornire dati o per eseguire funzioni di controllo per il driver. I formati di dati e dati specifici della classe vengono forniti in specifiche specifiche della classe del dispositivo separate e sono descritti anche in ACPI Device-Specific Metodi.

Indirizzo (_ADR) e ID univoco (_UID)

Esistono tre requisiti aggiuntivi per l'identificazione dei dispositivi:

  • Per i dispositivi che si connettono a un bus padre enumerabile hardware (ad esempio, SDIO, USB HSIC), ma che dispongono di funzionalità o controlli specifici della piattaforma (ad esempio, alimentazione a banda laterale o interrupt di riattivazione), il _HID non viene usato. L'identificatore del dispositivo viene invece creato dal driver del bus padre (come illustrato in precedenza). In questo caso, tuttavia, l'oggetto Address (_ADR) deve trovarsi nello spazio dei nomi ACPI per il dispositivo. Questo oggetto consente al sistema operativo di associare il dispositivo enumerato tramite bus alle relative funzionalità o controlli descritti in ACPI.
  • Nelle piattaforme in cui vengono usate più istanze di un determinato blocco IP, in modo che ogni blocco abbia gli stessi oggetti di identificazione del dispositivo, l'oggetto Identificatore univoco (_UID) è necessario per consentire al sistema operativo di distinguere tra i blocchi.
  • Nessun dispositivo in uno spazio dei nomi specifico può avere lo stesso nome.

Oggetti di configurazione del dispositivo

Per ogni dispositivo identificato nello spazio dei nomi, le risorse di sistema (indirizzi di memoria, interrupt e così via) utilizzate dal dispositivo devono essere segnalate anche dall'oggetto Impostazioni risorsa corrente (_CRS). La segnalazione di più configurazioni di risorse possibili (_PRS) e controlli per la modifica della configurazione delle risorse di un dispositivo (_SRS) sono supportati ma facoltativi.

Le nuove piattaforme SoC sono GPIO e risorse spB (Peripheral Bus) semplici che un dispositivo può utilizzare. Per altre informazioni, vedere per utilizzo generico I/O (GPIO) e simple peripheral bus (SPB).

Inoltre, una novità per le piattaforme SoC è un descrittore DMA fisso per utilizzo generico. Il descrittore FixedDMA supporta la condivisione dell'hardware del controller DMA da un certo numero di dispositivi di sistema. Le risorse DMA (registri della riga di richiesta e dei canali) allocate in modo statico a un determinato dispositivo di sistema sono elencate nel descrittore FixedDMA. Per altre informazioni, vedere la sezione 19.5.49, "FixedDMA (DMA Resource Descriptor Macro)" della specifica ACPI 5.0.

Modifiche dello stato del dispositivo

I dispositivi con enumerazione ACPI possono essere disabilitati o rimossi per vari motivi. L'oggetto Status (_STA) viene fornito per consentire la comunicazione di tali modifiche di stato al sistema operativo. Per una descrizione di _STA, vedere la sezione 6.3.7 della specifica ACPI 5.0. Windows usa _STA per determinare se il dispositivo deve essere enumerato, visualizzato come disabilitato o non visibile all'utente. Questo controllo nel firmware è utile per molte applicazioni, tra cui l'ancoraggio e il cambio da host a funzione USB OTG.

INOLTRE, ACPI fornisce un meccanismo di notifica che ASL può usare per notificare ai driver di eventi nella piattaforma, ad esempio un dispositivo rimosso come parte di un dock. In generale, quando lo stato di un dispositivo ACPI cambia, il firmware deve eseguire una notifica "controllo del dispositivo" o "controllo bus" per fare in modo che Windows enumera nuovamente il dispositivo e rivaluta il relativo _STA. Per informazioni sulle notifiche ACPI, vedere la sezione 5.6.6, "Device Object Notifications", della specifica ACPI 5.0.

Abilitazione/disabilitazione

Come parte di Windows Plug and Play, i driver devono essere in grado di essere abilitati e disabilitati dinamicamente dall'utente o dal sistema (ad esempio, per l'aggiornamento di un driver).

I dispositivi On-SoC sono integrati nel chip SoC e non possono essere rimossi. I driver per la maggior parte dei dispositivi SoC possono essere esentati dai requisiti per abilitare e disabilitare. Per i driver che non sono esenti, esistono interfacce driver per indicare che il driver supporta la rimozione ordinata. Per altre informazioni, vedere il documento intitolato "Riduzione dei requisiti PNP per i driver SoC" nel sito Web di Microsoft Connect.

Se un driver supporta la rimozione ordinata e l'hardware del dispositivo può essere disabilitato , ovvero il dispositivo può essere configurato per interrompere l'accesso alle risorse assegnate, il nodo dello spazio dei nomi ACPI per il dispositivo può includere l'oggetto Disable (_DIS). Questo metodo verrà valutato dal sistema operativo ogni volta che il driver viene rimosso. L'uso di _DIS presenta i requisiti aggiuntivi seguenti:

  • _STA deve cancellare il bit "abilitato e decodificando le risorse" ogni volta che il dispositivo è disabilitato.
  • Il dispositivo deve specificare l'oggetto Imposta impostazioni risorsa (_SRS) per abilitare nuovamente l'hardware del dispositivo e impostare il bit precedente in _STA.

Per altre informazioni, vedere le sezioni 6.2.3 (_DIS), 6.2.15 (_SRS) e 6.3.7 (_STA) della specifica ACPI 5.0.

Dipendenze del dispositivo

In genere, esistono dipendenze hardware tra i dispositivi in una determinata piattaforma. Windows richiede che tutte queste dipendenze siano descritte in modo che possa garantire che tutti i dispositivi funzionino correttamente come le cose cambiano dinamicamente nel sistema (l'alimentazione del dispositivo viene rimossa, i driver vengono arrestati e avviati e così via). In ACPI le dipendenze tra i dispositivi sono descritte nei modi seguenti:

  1. Gerarchia dello spazio dei nomi. Qualsiasi dispositivo figlio (elencato come dispositivo all'interno dello spazio dei nomi di un altro dispositivo) dipende dal dispositivo padre. Ad esempio, un dispositivo USB HSIC dipende dalla porta (padre) e dal controller (nonno) a cui è connesso. Analogamente, un dispositivo GPU elencato nello spazio dei nomi di un dispositivo MMU (System Memory-Management Unit) dipende dal dispositivo MMU.

  2. Connessioni alle risorse. I dispositivi connessi ai controller GPIO o SPB dipendono da tali controller. Questo tipo di dipendenza è descritto dall'inclusione delle risorse di connessione nel _CRS del dispositivo.

  3. Dipendenze opregion. Per i metodi di controllo ASL che usano OpRegions per eseguire I/O, le dipendenze non sono note implicitamente dal sistema operativo perché vengono determinate solo durante la valutazione del metodo di controllo. Questo problema è applicabile a GeneralPurposeIO e GenericSerialBus OpRegions in cui Plug and Play driver forniscono l'accesso all'area. Per attenuare questo problema, ACPI definisce l'oggetto OpRegion Dependency (_DEP). _DEP deve essere usato in qualsiasi spazio dei nomi del dispositivo in cui viene fatto riferimento a un oggetto OpRegion (risorsa HW) da un metodo di controllo e né da 1 o 2 versioni precedenti si applica già per la risorsa di connessione di OpRegion a cui si fa riferimento. Per altre informazioni, vedere la sezione 6.5.8, "_DEP (dipendenze dell'area operativa)", della specifica ACPI 5.0.

Possono essere presenti anche dipendenze software tra i driver di dispositivo. Queste dipendenze devono essere descritte anche.

Per altre informazioni, vedere le risorse seguenti: