L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Altri oggetti dello spazio dei nomi ACPI
Articolo
07/04/2025
Per alcune classi specifiche di dispositivi, ci sono requisiti affinché ulteriori oggetti dello spazio dei nomi ACPI (Advanced Configuration and Power Interface) vengano visualizzati sotto tali dispositivi nello spazio dei nomi. Questa sezione elenca gli oggetti aggiuntivi necessari per le piattaforme basate su SoC.
Oggetti di identificazione del processore
I processori devono essere enumerati nello spazio dei nomi ACPI. I processori vengono dichiarati in \_SB usando l'istruzione "Device", come con altri dispositivi nella piattaforma. I dispositivi processore devono contenere gli oggetti seguenti:
_HID: ACPI0007
_UID: Un numero univoco che corrisponde alla voce del processore nel Tavolo di Descrizione dell'Interfaccia Multiprocessore (MADT).
Oggetti specifici della visualizzazione
Per altre informazioni sugli oggetti specifici della visualizzazione, vedere Appendice B, "Estensioni video" della specifica ACPI 5.0.
Requisiti dell'oggetto Display-Specific
Metodo
Descrizione
Requisito
_DOS
Abilitare/disabilitare il cambio di output.
Obbligatorio se il sistema supporta il cambio di visualizzazione o i livelli di luminosità LCD.
_DOD
Enumerare tutti i dispositivi collegati alla scheda di visualizzazione.
Obbligatorio se il controller integrato supporta il cambio di output.
_ROM
Recupera dati ROM.
Obbligatorio se l'immagine ROM viene archiviata in formato proprietario.
_GPD
Recupera dispositivo POST.
Obbligatorio se _VPO è implementato.
_SPD
Impostare il dispositivo POST.
Obbligatorio se _VPO è implementato.
_VPO
Opzioni POST video.
Obbligatorio se il sistema supporta la modifica del dispositivo POST VGA.
_ADR
Restituisce l'ID univoco per questo dispositivo.
Obbligatorio.
_BCL
Elenco di query dei livelli di controllo della luminosità supportati.
Obbligatorio se l'LCD incorporato supporta il controllo della luminosità.
_BCM
Impostare il livello di luminosità.
Obbligatorio se _BCL è implementato.
_DDC
Restituisce l'EDID per questo dispositivo.
Obbligatorio se l'LCD incorporato non supporta la restituzione di EDID tramite l'interfaccia standard.
_DCS
Restituisce lo stato del dispositivo di output.
Obbligatorio se il sistema supporta il cambio di visualizzazione (tramite tasto di scelta rapida).
_DGS
Verificare lo stato della grafica.
Obbligatorio se il sistema supporta il cambio di visualizzazione (tramite tasto di scelta rapida).
_DSS
Stato del dispositivo impostato.
Obbligatorio se il sistema supporta il cambio di visualizzazione (tramite tasto di scelta rapida).
Controller host USB e dispositivi
I controller host USB vengono usati nelle piattaforme SoC per la connessione di dispositivi interni ed esterni. Windows include driver posta in arrivo per controller host USB standard conformi alle specifiche EHCI o XHCI.
Nelle piattaforme basate su SoC, il controller host USB può essere enumerato da ACPI. Windows usa gli oggetti dello spazio dei nomi ACPI seguenti durante l'enumerazione e la configurazione di hardware USB compatibile:
ID hardware conforme a ACPI assegnato dal fornitore (_HID).
Oggetto Unique ID (_UID), se nello spazio dei nomi sono presenti più istanze del controller USB, ovvero due o più nodi con oggetti di identificazione del dispositivo identici.
ID compatibile (_CID) per il controller host USB conforme a EHCI o XHCI Standard (EHCI: PNP0D20), (XHCI: PNP0D10).
Impostazioni risorse correnti (_CRS) assegnate al controller USB. Le risorse del controller sono descritte nella specifica dell'interfaccia hardware appropriata (EHCI o XHCI).
Metodo USB Device-Specific (_DSM)
Windows definisce un metodo Device-Specific (_DSM) per supportare la configurazione specifica della classe del dispositivo del sottosistema USB. Per altre informazioni, vedere Metodo Device-Specific USB.
Supporto integrato per Traduttore di Transazione USB (TT) (_HRV)
I controller host EHCI Standard supportano solo dispositivi USB ad alta velocità. Nelle piattaforme SoC, Windows supporta due progetti comuni di controller host conformi a EHCI che implementano un traduttore di transazioni integrato per dispositivi USB a bassa velocità e a massima velocità. L'oggetto Hardware Revision (_HRV) indica il tipo di supporto TT integrato per il driver del controller host USB.
Il _HRV viene impostato in base ai criteri seguenti:
NoIntegratedTT - _HRV = 0
I controller host EHCI standard non implementano traduttori di transazioni integrati e un valore di _HRV pari a 0 è valido solo per questi controller. Non è necessario includere l'oggetto _HRV per questi controller.
IntegratedTTSpeedInPortSc - _HRV = 1
Abilitare il supporto TT integrato. Questo tipo di interfaccia include i bit LowSpeed e HiSpeed nel registro PORTSC stesso. Questi bit sono in corrispondenza degli offset di bit 26 e 27, rispettivamente. Quando si determina la velocità, il driver EHCI leggerà il PORTSC ed estraerà le informazioni sulla velocità da questi bit.
IntegratedTTSpeedInHostPc - _HRV = 2
Abilitare il supporto TT integrato. Questo tipo di interfaccia include i bit LowSpeed e HiSpeed in un registro HOSTPC separato. Quando il driver EHCI deve determinare la velocità della porta, leggerà il registro HOSTPC corrispondente alla porta di interesse ed estrae le informazioni sulla velocità.
Supporto USB XHCI D3cold
Oltre alla sospensione selettiva, i dispositivi USB interni connessi ai controller XHCI possono essere inseriti in uno stato D3cold, ossia completamente spenti, quando non sono in uso. Per altre informazioni, vedere Gestione alimentazione del dispositivo. Tutti i driver di funzione USB devono essere configurati per D3cold.
Oggetti specifici della porta USB
Windows deve conoscere la visibilità e la capacità di connessione delle porte USB nel sistema. Questa operazione è necessaria per fornire informazioni accurate all'utente sulle porte e i dispositivi. A questo scopo vengono usati due oggetti, Physical Device Location (_PLD) e USB Port Capabilities (_UPC). Per altre informazioni, vedere quanto segue:
Sezioni 6.1.6, "Oggetti di identificazione del dispositivo" e 9.13.1, "Controller host USB 2.0 e _UPC e _PLD", nella specifica ACPI 5.0.
I controller host SD vengono usati nelle piattaforme SoC per l'accesso all'archiviazione e ai dispositivi di I/O. Windows include un driver integrato per l'hardware del controller host standard SDA. Per la compatibilità con questo driver, un dispositivo controller host SD deve essere conforme alla specifica del controller host SD dell'associazione SD.
Nelle piattaforme SoC il controller host SD può essere enumerato da ACPI. Windows usa gli oggetti dello spazio dei nomi ACPI seguenti durante l'enumerazione e la configurazione di hardware SD compatibile:
ID hardware conforme a ACPI assegnato dal fornitore (_HID).
Oggetto Unique ID (_UID), se nello spazio dei nomi sono presenti più istanze del controller SD, ovvero due o più nodi con oggetti di identificazione del dispositivo identici.
ID compatibile (_CID) per il controller host SD (PNP0D40) conforme allo standard SDA.
Impostazioni risorse correnti (_CRS) assegnate al controller. Le risorse del controller sono descritte di seguito:
Le risorse hardware per tutti gli slot implementati sono incluse. Uno slot è un punto di connessione sul bus SDIO per un dispositivo di memoria o I/O. Ogni slot è associato a un set standard di registri e a un interrupt nel controller host SD, che vengono usati per la comunicazione con il dispositivo connesso. I controller host SD possono implementare un numero qualsiasi di slot, ma nelle piattaforme SoC è in genere presente un solo slot.
Le risorse slot vengono elencate insieme, in ordine di numero di slot (le risorse dello slot 0 sono prima, le risorse dello slot 1 sono seconde e così via).
Per ogni slot, le risorse sono elencate nell'ordine seguente:
Indirizzo di base del set di registri standard SD per lo slot.
L'interruzione standard SD per lo slot.
Risorsa di interrupt GPIO per lo slot, per la segnalazione di inserimenti e rimozioni di schede (se l'interfaccia standard di rilevamento della scheda SD non è supportata durante tutti gli stati di alimentazione).
Risorsa di input GPIO per lo slot per rilevare se una scheda è attualmente presente nello slot (se l'interfaccia standard di rilevamento della scheda SD non è supportata durante tutti gli stati di alimentazione). Usa lo stesso pin per l'interrupt di inserimento/rimozione.
Una seconda risorsa di input GPIO per leggere se la scheda nello slot è protetta da scrittura (se l'interfaccia standard SD write-protect non è supportata durante tutti gli stati di alimentazione).
Gli interrupt devono essere abilitati per la riattivazione (descritti come "SharedAndWake" o "ExclusiveAndWake").
Dispositivi SD incorporati
I dispositivi connessi a SD vengono enumerati dal driver del bus SD. I dispositivi SD integrati nella piattaforma devono essere elencati anche nello spazio dei nomi ACPI come elementi figlio del controller host SD. Questo requisito consente al sistema operativo di associare il dispositivo enumerato dal bus agli attributi specifici della piattaforma forniti per il dispositivo dagli oggetti ACPI (ad esempio, non removibilità, stati di alimentazione dei dispositivi, risorse GPIO o SPB consumate e così via). Per rendere questa associazione, lo spazio dei nomi del dispositivo richiede l'oggetto Address (_ADR), che comunica l'indirizzo del dispositivo nel bus SDIO. L'oggetto _ADR restituisce un numero intero.
Per il bus SDIO, il valore di questo intero viene definito come segue:
Parola alta : numero di slot (0 - primo slot)
Parola bassa : numero di funzione (vedere specifica SD per le definizioni).
Uno spazio dei nomi del dispositivo SD integrato deve includere anche:
Oggetto Remove (_RMV) che restituisce 0 (per indicare che il dispositivo non può essere rimosso).
Oggetto _CRS per le risorse sideband richieste dal dispositivo, ad esempio pin GPIO o connessioni SPB, se necessario.
Dispositivi di classe imaging (fotocamere)
I dispositivi fotocamera possono essere enumerati dal driver di grafica o da USB. In entrambi i casi, Windows deve conoscere la posizione fisica della fotocamera in modo che sia possibile visualizzare l'interfaccia utente appropriata. A tale scopo, i dispositivi fotocamera integrati nello chassis del sistema e hanno una direzione meccanicamente fissa sono inclusi nello spazio dei nomi ACPI e forniscono l'oggetto Physical Device Location (_PLD). Questa operazione richiede:
Il dispositivo fotocamera da visualizzare come un dispositivo figlio (dispositivo annidato) del dispositivo enumeratore (il dispositivo GPU o il dispositivo USB).
Dispositivo fotocamera per fornire l'oggetto Address (_ADR) che contiene l'indirizzo della fotocamera sul bus del dispositivo padre.
Per USB, vedere Gerarchia dello spazio dei nomi ACPI e _ADR per i dispositivi USB incorporati nella sezione successiva di seguito.
Per la grafica, questo è l'identificatore specificato nel metodo _DOD fornito nel dispositivo GPU. Per altre informazioni, vedere Appendice B, "Estensioni video" della specifica ACPI 5.0.
Dispositivo fotocamera per fornire l'oggetto _PLD.
Se sono presenti risorse sideband richieste dal driver della fotocamera (ad esempio connessioni GPIO interrupt o I/O o una connessione SPB), l'oggetto _CRS viene fornito per queste risorse.
Nell'oggetto _PLD il campo Pannello (bit 67-69), il campo Coperchio (bit 66) e il campo Dock (bit 65) vengono impostati sui valori corretti per la superficie in cui è montata la fotocamera. Tutti gli altri campi sono facoltativi. Per i dispositivi mobili palmari, inclusi i tablet, il pannello anteriore è quello che contiene lo schermo e la sua origine si trova nell'angolo inferiore sinistro quando la visualizzazione è verticale. Usando questo riferimento, "Front" indica che la fotocamera visualizza l'utente (webcam), mentre "Indietro" indica che la fotocamera si allontana dall'utente (ancora o videocamera). Per altre informazioni, vedere la sezione 6.1.8 , "_PLD (posizione fisica del dispositivo)", nella specifica ACPI 5.0.
Gerarchia dello spazio dei nomi ACPI e _ADR per dispositivi USB incorporati
Quando si aggiungono dispositivi USB incorporati allo spazio dei nomi ACPI, la gerarchia dei nodi del dispositivo deve corrispondere esattamente a quella dei dispositivi enumerati dal driver USB di Windows. Questo può essere determinato esaminando Gestione dispositivi Windows nella modalità "Visualizza per connessione". L'intera gerarchia, a partire dal controller host USB ed estendendosi fino al dispositivo incorporato, deve essere inclusa. La proprietà "Address" fornita in Gestione dispositivi per ogni dispositivo è l'indirizzo che il firmware deve segnalare nel _ADR del dispositivo.
La specifica ACPI 5.0 definisce gli indirizzi per i dispositivi USB come indicato di seguito:
HUB radice USB: unico figlio del controller host. Deve avere un _ADR pari a 0. Non sono ammessi altri elementi figlio o valori di _ADR.
Porte USB: numero di porta (1-n)
I dispositivi USB connessi a una determinata porta condividono l'indirizzo di tale porta.
Se il dispositivo connesso a una porta è un dispositivo USB composito, le funzioni all'interno del dispositivo composito devono usare l'indirizzo seguente:
Funzione USB all'interno di un dispositivo USB composito: numero di porta della porta a cui è connesso il dispositivo composito, PIÙ il primo numero di interfaccia della funzione. (addizione aritmetica).
L'esempio di codice ASL seguente descrive una webcam USB connessa direttamente alla porta USB 3.
Device (EHCI) {
... // Objects required for EHCI devices
Device {RHUB) { // the Root HUB
Name (_ADR, ZERO) // Address is always 0.
Device (CAM0) { // Camera connected directly to USB
// port number 3 under the Root.
Name (_ADR, 3) // Address is the same as the port.
Method (_PLD, 0, Serialized) {...}
} // End of Camera device
} // End of Root Hub Device
} // End of EHCI device
L'esempio di codice ASL seguente descrive un dispositivo composito USB che implementa una webcam come Funzione 2.
Device (EHCI) {
... // Objects required for EHCI devices
Device {RHUB) {
Name (_ADR, ZERO)
Device (CUSB) { // Composite USB device
// connected to USB port number 3
// under the Root.
Name (_ADR, 3) // Address is the same as the port.
Device (CAM0) { // Camera function within the
// Composite USB device.
Name (_ADR, 5) // Camera function has a first
// Interface number of 2, so
// Address is 3 + 2 = 5.
Method (_PLD, 0, Serialized) {...}
} // End of Camera device
} // End of Composite USB Device
} // End of Root Hub Device
} // End of EHCI device
L'esempio di codice ASL seguente descrive una webcam connessa tramite I2C.
Device (GPU0) {
... // Other objects required for graphics devices
Name (_DOD, Package () // Identifies the children of this graphics device.
// Each integer must be unique within the GPU0 namespace.
{
0x00024321, // The ID for CAM0. It is a non-VGA
// device, cannot be detected by
// the VGA BIOS, and uses a vendor-
// specific ID format in bits 15:0
// (see the _DOD specification).
... // Other child device IDs (for
// example, display output ports)
})
Device (CAM0) {
Name (_ADR, 0x00024321) // The identifier for this device
// (Same as in _DOD above)
Name (_CRS, ResourceTemplate()
{
// I2C Resource
// GPIO interrupt resource(s), if required by
// driver
// GPIO I/O resource(s), if required by driver
...
})
Method (_PLD, 0, Serialized) {...}
} // End of CAM0 device
} // End of GPU0 device
Dispositivi HID over I2C
Windows include un driver di classe per dispositivi di interfaccia umana (HID). Questo driver consente il supporto generico per un'ampia gamma di dispositivi di input (ad esempio pannelli di tocco, tastiere, mouse e sensori). Nelle piattaforme SoC i dispositivi HID possono essere connessi alla piattaforma tramite I2C e vengono enumerati da ACPI. Per la compatibilità con il supporto della classe HID in Windows, vengono usati gli oggetti dello spazio dei nomi seguenti:
Un _HID specifico del fornitore
Un _CID di PNP0C50
Un _CRS con:
Una risorsa di connessione bus seriale I2C per accedere al dispositivo
Per le piattaforme SoC, Windows supporta sia il pulsante di alimentazione del metodo di controllo definito da ACPI che una matrice a cinque pulsanti compatibile con Windows. Il pulsante di alimentazione, se implementato come pulsante di alimentazione del metodo di controllo ACPI o come parte della matrice di pulsanti compatibile con Windows, esegue le operazioni seguenti:
Fa sì che la piattaforma venga spenta.
Genera l'evento Di sostituzione del pulsante di alimentazione quando è premuto. Per altre informazioni, vedere la sezione 4.8.2.2.1.3, "Sostituzione pulsante di alimentazione", della specifica ACPI 5.0.
Metodo di controllo del pulsante di accensione
Progetti clamshell e altri sistemi con tastiere incorporate o connesse, implementano il pulsante di alimentazione del metodo di controllo definito da ACPI (sezione 4.8.2.2.1.2 della specifica ACPI 5.0) usando eventi GPIO-Signaled ACPI (sezione 5.6.5 della specifica ACPI 5.0). Per supportare il dispositivo pulsante di alimentazione, lo spazio dei nomi:
Descrive il pin di interrupt GPIO del pulsante di alimentazione come risorsa di interrupt GPIO non condivisa (esclusiva).
Elenca la risorsa di interrupt GPIO del pulsante di alimentazione nell'oggetto _AEI del controller GPIO a cui è connesso.
Fornisce il metodo di evento associato (Lxx/Exx/EVT) nel dispositivo controller GPIO. Questo metodo di evento notifica al driver Control Method Button nel sistema operativo che si è verificato l'evento del pulsante.
Per le piattaforme touch-first (senza tastiera), ad esempio slates, Windows fornisce un driver generico per una matrice di cinque pulsanti. Ogni pulsante nella matrice ha la funzione definita (vedere gli elementi numerati nell'elenco seguente) e alcune combinazioni di pulsanti "hold-and-press" hanno un significato aggiuntivo nell'interfaccia utente. Non sono definite combinazioni di pulsanti che richiedono che il pulsante di alimentazione venga premuto. Per la compatibilità con il driver pulsante Posta in arrivo di Windows, viene implementato il dispositivo ACPI Button Array compatibile con Windows. Il dispositivo è definito come segue:
Ognuno dei cinque pulsanti è collegato al proprio pin di interrupt dedicato sulla piattaforma.
Ogni pin di interrupt viene configurato come risorsa di interrupt non condivisa (esclusiva), attivata da edge (Edge) che interrompe su entrambi i bordi (ActiveBoth).
Lo spazio dei nomi del dispositivo contiene un _HID definito dal fornitore e un _CID di PNP0C40.
Le risorse di interrupt GPIO nell'oggetto _CRS sono elencate nell'ordine seguente:
Interruzione corrispondente al pulsante "Accensione"
Il pulsante "Alimentazione" deve essere abilitato per la riattivazione (ExclusiveAndWake).
Interruzione corrispondente al pulsante "Windows"
Il pulsante Windows deve essere abilitato per la riattivazione (ExclusiveAndWake).
Interrupt corrispondente al pulsante "Volume su"
Il pulsante "Volume Su" non deve essere attivabile al risveglio (dovrebbe utilizzare Exclusive).
Interrupt corrispondente al pulsante "Volume basso"
Il pulsante "Volume giù" non deve essere abilitato per la riattivazione (deve usare Exclusive).
Interrupt corrispondente al pulsante "Blocco Rotazione", se supportato
Il pulsante "Rotation Lock" non deve essere abilitato per la riattivazione (deve utilizzare la modalità esclusiva).
Dispositivi di rilevamento per PC dock e convertibili
Windows supporta dock e dispositivi convertibili (combinazioni clamshell/tablet) tramite l'uso di due dispositivi di rilevamento nello spazio dei nomi ACPI. Questi dispositivi sono supportati dal driver pulsante Posta in arrivo di Windows. Si noti che gli stessi requisiti che si applicano al dispositivo Button Array si applicano anche a questi dispositivi:
Gli interrupt GPIO ActiveBoth devono essere connessi a un controller GPIO on-SoC (non a un controller GPIO connesso a SPB).
Il controller GPIO deve supportare interruzioni in modalità livello e la riprogrammazione della polarità dinamica.
Se lo stato dichiarato ("Ancorato" o "Convertito") non è a livello logico basso, il metodo _DSM del controller GPIO è necessario per sostituire il comportamento predefinito dello stack di driver GPIO. Per altre informazioni, vedere la sezione Dispositivi controller GPIO nell'argomento I/O per utilizzo generico (GPIO).
Un dispositivo di rilevamento del dock interrompe il sistema quando un dock è collegato o scollegato dal sistema. Questa modalità consente di modificare le informazioni per aggiornare l'esperienza di input e output dell'utente, in base alle esigenze. Lo spazio dei nomi del dispositivo richiede:
Un _HID specifico del fornitore
Un _CID di PNP0C70
Un _CRS con un'interrupt ActiveBoth
L'interrupt non può essere capace di riattivazione.
Dispositivo di rilevamento del PC convertibile
Un dispositivo che rileva i PC convertibili interrompe il sistema quando un PC convertibile passa dalla modalità tablet alla modalità clamshell. Questa modalità consente di modificare le informazioni per aggiornare l'esperienza di input e output dell'utente, in base alle esigenze. Lo spazio dei nomi del dispositivo richiede:
Un _HID specifico del fornitore
Un _CID di PNP0C60
Un _CRS con un'interruzione ActiveBoth
L'interrupt non può essere abilitato per la riattivazione.
L'implementazione della specifica hardware ACPI (Advanced Configuration and Power Interface) non è necessaria nelle piattaforme basate su SoC, ma è possibile richiedere gran parte della specifica del software ACPI.
I circuiti integrati SoC usano ampiamente semplici, a basso numero di pin e interconnessioni seriali a basso consumo per la connessione alle periferiche della piattaforma.
Per supportare un'ampia gamma di comunicazioni specifiche della classe di dispositivo tra lo stack di driver di I/O per utilizzo generico (GPIO) in Windows e il firmware della piattaforma, Microsoft definisce un metodo Device-Specific (_DSM) che può essere incluso in un controller GPIO nello spazio dei nomi ACPI.
Per supportare una maggiore funzionalità ed estensione per selezionare stack tecnologici, Windows definisce metodi Device-Specific (_DSM) per il dispositivo.
ACPI 5.0 definisce nuove funzionalità per supportare dispositivi mobili a basso consumo basato su schede SOC che implementano il modello di alimentazione di standby connesso.
Informazioni su come creare prodotti hardware di gioco standard più accessibili, ad esempio console di gioco, controller e visori VR. Tutte le modalità per progettare pacchetti hardware con componenti accessibili per migliorare l'esperienza di unboxing di una clientela più ampia.