Condividi tramite

Oggetti dello spazio dei nomi di gestione dei dispositivi

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 dei dispositivi contengono informazioni di identificazione per i dispositivi che si connettono ai bus, ad esempio I2C, che non supportano l'enumerazione hardware dei dispositivi figli. 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

Plug and Play di Windows 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 i bus che non ne dispongono (come il bus del processore o un semplice bus periferico), ACPI definisce 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 enumerati 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 ed esaminando gli ID hardware e le proprietà 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 è dall'identificatore hardware più specifico (driver più preferito) all'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. Il metodo consigliato, se il driver di dispositivo deve identificare l'hardware specifico per cui è stato caricato, è che il file INF imposti le chiavi del Registro di sistema appropriate 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 (ID fornitore) e xxxx è un numero esadecimale che identifica il dispositivo specifico prodotto dal fornitore (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 degli 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 esclusivamente l'ID del fornitore "PNP" per i dispositivi compatibili con i driver integrati 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. Un oggetto separato, l'oggetto Compatible ID (_CID), viene usato per restituire questi identificatori. 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 di considerare il driver fornito da Windows 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 HID-over-I2C
PNP0C60 Dispositivo sensore di visualizzazione portatile convertibile
PNP0C70 Dispositivo sensore di docking
PNP0D10 Controller USB conforme a XHCI con debug standard
PNP0D15 Controller USB conforme a 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 al _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 dispositivo 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 manutenibilità, c'è un requisito del Windows Hardware Certification Kit (HCK) affinché 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). Pertanto, 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 scontri 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 dati specifici della classe e i formati di dati sono forniti in specifiche separate della classe del dispositivo e sono illustrati anche in ACPI Device-Specific Metodi.

Indirizzo (_ADR) e ID univoco (_UID)

Esistono tre requisiti aggiuntivi per l'identificazione del dispositivo:

  • 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 funzionalità o ai controlli descritti dall'ACPI.
  • Nelle piattaforme in cui vengono usate più istanze di un blocco IP specifico, in modo che ogni blocco abbia gli stessi oggetti di identificazione del dispositivo, è necessario l'oggetto Identificatore univoco (_UID) 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 risorse correnti (_CRS). La segnalazione di più possibili configurazioni di risorse (_PRS) e controlli per la modifica della configurazione delle risorse di un dispositivo (_SRS) sono supportati ma facoltativi.

Le novità per le piattaforme SoC sono le risorse GPIO e SPB (bus periferico semplice) che un dispositivo può consumare. Per ulteriori informazioni, consultare GPIO (General Purpose I/O) e SPB (Simple Peripheral Bus).

Novità anche 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 enumerati 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 la connessione e la commutazione 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 di "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.

Abilitare/disabilitare

Come parte di Plug and Play di Windows, 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 l'abilitazione e la disabilitazione. Per i driver che non sono esenti, ci sono interfacce che indicano che il driver supporta la rimozione ordinata. Per altre informazioni, vedere il documento "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 "attivato e decodificando le sue risorse" ogni volta che il dispositivo è disabilitato.
  • Il dispositivo deve fornire l'oggetto "Set Resource Settings" (_SRS) per riabilitare l'hardware del dispositivo e impostare il bit sopracitato 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 man mano che 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 HSIC USB 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 operazioni di I/O, le dipendenze non sono note in modo implicito dal sistema operativo perché vengono determinate solo durante la valutazione del metodo di controllo. Questo problema è applicabile a GeneralPurposeIO e GenericSerialBus OpRegions in cui i driver Plug and Play 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 di dispositivo in cui un OpRegion (risorsa HW) viene referenziato da un metodo di controllo e in cui non si applicano già le condizioni 1 o 2 sopra indicate per la risorsa di connessione dell'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:

  • Last updated on