Altri oggetti dello spazio dei nomi ACPI
Per alcune classi specifiche del dispositivo, esistono requisiti per altri oggetti dello spazio dei nomi Advanced Configuration e Power Interface (ACPI) da visualizzare nello spazio dei nomi. Questa sezione elenca gli oggetti aggiuntivi necessari per le piattaforme basate su SoC.
Oggetti di identificazione 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 sulla piattaforma. I dispositivi processore devono contenere gli oggetti seguenti:
- _HID: ACPI0007
- _UID: numero univoco corrispondente alla voce del processore in 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 l'opzione di output. | Obbligatorio se il sistema supporta il cambio o i livelli di luminosità LCD. |
| _DOD | Enumera tutti i dispositivi collegati alla scheda di visualizzazione. | Obbligatorio se il controller integrato supporta il commutatore di output. |
| _ROM | Ottenere i dati ROM. | Obbligatorio se l'immagine ROM viene archiviata in formato proprietario. |
| _GPD | Ottenere il dispositivo POST. | Obbligatorio se viene implementato _VPO. |
| _SPD | Impostare DISPOSITIVO POST. | Obbligatorio se viene implementato _VPO. |
| _VPO | Opzioni POST video. | Obbligatorio se il sistema supporta la modifica del dispositivo 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 luminosità. |
| _BCM | Impostare il livello di luminosità. | Obbligatorio se viene implementato _BCL. |
| _DDC | Restituisce l'EDID per questo dispositivo. | Obbligatorio se l'LCD incorporato non supporta la restituzione di EDID tramite interfaccia standard. |
| _DCS | Stato restituito del dispositivo di output. | Obbligatorio se il sistema supporta l'opzione di visualizzazione (tramite tasti di scelta rapida). |
| _DG | Eseguire query sullo stato della grafica. | Obbligatorio se il sistema supporta l'opzione di visualizzazione (tramite tasti di scelta rapida). |
| _DSS | Set di stato del dispositivo. | Obbligatorio se il sistema supporta l'opzione di visualizzazione (tramite tasti di scelta rapida). |
Controller e dispositivi host USB
I controller host USB vengono usati su piattaforme SoC per la connessione di dispositivi interni ed esterni. Windows include driver in arrivo per i 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 dell'hardware USB compatibile:
ID hardware conforme al fornitore (_HID).
Oggetto Unique ID (_UID), se è presente più di un'istanza del controller USB nello spazio dei nomi (ovvero due o più nodi con oggetti di identificazione del dispositivo identici).
ID compatibile (_CID) per il controller host USB conforme a XHCI o XHCI Standard (EHCI: PNP0D20), (XNP0D20: 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 USB Device-Specific.
Supporto di USB integrated transaction translator (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 velocità completa. L'oggetto Revisione hardware (_HRV) indica il tipo di supporto TT integrato al driver del controller host USB.
Il _HRV viene impostato in base ai criteri seguenti:
NoIntegratedTT - _HRV = 0
I controller host EHCI standard non implementano traduzione transazioni integrate 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 sapore di interfaccia include i bit LowSpeed e HiSpeed nel registro PORTSC stesso. Questi bit sono a offset di bit rispettivamente 26 e 27. Quando si determina la velocità, il driver EHCI leggerà portec ed estrae le informazioni sulla velocità da questi bit.
IntegratedTTSpeedInHostPc - _HRV = 2
Abilitare il supporto TT integrato. Questo sapore 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 estrarre 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 e disattivati quando non sono in uso. Per altre informazioni, vedere Gestione energia del dispositivo. Tutti i driver di funzione del dispositivo USB devono acconsentire esplicitamente a 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. Per questo scopo, vengono usati due oggetti, Percorso dispositivo fisico (_PLD) e Funzionalità porta USB (_UPC). Per altre informazioni, vedere gli argomenti seguenti:
Sezioni 6.1.6, "Device Identification Objects" e 9.13.1, "Controller host USB 2.0 e _UPC _PLD e _PLD", nella specifica ACPI 5.0.
Controller e dispositivi host SD
I controller host SD vengono usati nelle piattaforme SoC per l'accesso all'archiviazione e ai dispositivi I/O. Windows include un driver in arrivo 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 dell'hardware SD compatibile:
ID hardware conforme al fornitore (_HID).
Oggetto Unique ID (_UID), se è presente più di un'istanza del controller SD nello spazio dei nomi ,ovvero due o più nodi con oggetti di identificazione del dispositivo identici.
ID compatibile (_CID) per il controller host SD conforme allo standard SDA (PNP0D40).
Impostazioni risorse correnti (_CRS) assegnate al controller. Le risorse del controller sono descritte come segue:
Sono incluse risorse hardware per tutti gli slot implementati. 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 un interruzione nel controller host SD, usato per la comunicazione con il dispositivo connesso. I controller host SD possono implementare qualsiasi numero di slot, ma nelle piattaforme SoC, in genere ne esiste uno solo.
Le risorse slot sono 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 registrazione standard SD per lo slot.
Interruzione standard SD per lo slot.
Risorsa di interruzione GPIO per lo slot, per l'inserimento e la rimozione di schede di segnalazione (se l'interfaccia di rilevamento della scheda SD standard non è supportata durante tutti gli stati di alimentazione).
Risorsa di input GPIO per lo slot per leggere se una scheda è attualmente nello slot (se l'interfaccia di rilevamento della scheda SD standard non è supportata durante tutti gli stati di alimentazione). Usa lo stesso pin dell'interruzione di inserimento/rimozione.
Una seconda risorsa di input GPIO per leggere se la scheda nello slot è protetta da scrittura (se l'interfaccia di protezione da scrittura SD standard non è supportata durante tutti gli stati di alimentazione).
Le interruzioni devono essere abilitate per la riattivazione (descritte 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 figlio del controller host SD. Questo requisito consente al sistema operativo di associare il dispositivo enumerato al bus con gli attributi specifici della piattaforma forniti per il dispositivo dagli oggetti ACPI(ad esempio, non removability, stati di alimentazione del dispositivo, GPIO o SPB risorse usate e così via). Per rendere questa associazione, lo spazio dei nomi del dispositivo richiede l'oggetto Address (_ADR), che comunica l'indirizzo del dispositivo sul bus SDIO. L'oggetto _ADR restituisce un intero.
Per il bus SDIO, il valore di questo intero è definito come segue:
Parola alta - Numero slot (0 - primo slot)
Parola bassa : numero di funzione (vedere la specifica SD per le definizioni).
Uno spazio dei nomi dei dispositivi SD incorporato deve includere anche:
Oggetto Remove (_RMV) che restituisce 0 (per indicare che il dispositivo non può essere rimosso).
Un oggetto _CRS per le risorse a banda laterale il dispositivo richiede (ad esempio pin GPIO o connessioni SPB), se necessario.
Dispositivi di classe di imaging (fotocamere)
I dispositivi fotocamera possono essere enumerati dal driver grafico 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 della fotocamera incorporati nello chassis del sistema e hanno direzione fissa meccanicamente sono inclusi nello spazio dei nomi ACPI e forniscono l'oggetto Percorso dispositivo fisico (_PLD). che 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 specificare 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 seguente.
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 l'interruzione GPIO o le connessioni I/O o o), 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 su valori corretti per la superficie in cui è montata la fotocamera. Tutti gli altri campi sono facoltativi. Per i dispositivi mobili portatili, inclusi i tablet, il pannello anteriore è quello che tiene lo schermo visualizzato e la sua origine si trova nell'angolo inferiore sinistro quando lo schermo viene visualizzato nell'orientamento verticale. Usando questo riferimento, "Front" indica che la fotocamera visualizza l'utente (webcam), mentre "Indietro" indica che le visualizzazioni della fotocamera lontano dall'utente (ancora o fotocamera video). Per altre informazioni, vedere, 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. Ciò può essere determinato esaminando Windows Gestione dispositivi nella modalità "Visualizza per connessione". L'intera gerarchia, a partire dal controller host USB e dall'estensione fino al dispositivo incorporato, deve essere inclusa. La proprietà "Address" fornita in Gestione dispositivi per ogni dispositivo è l'indirizzo che il firmware deve segnalare nella _ADR del dispositivo.
La specifica ACPI 5.0 definisce gli indirizzi per i dispositivi USB come indicato di seguito:
HUB radice USB: solo figlio del controller host. Deve avere un _ADR di 0. Non sono consentiti 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, PLUS il primo numero di interfaccia della funzione. (Aggiunta aritmetica).
Per altre informazioni, vedere Identificazione della posizione delle telecamere interne.
Esempi di codice ASL
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
Nell'esempio di codice ASL seguente viene descritta 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 ed 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:
Risorsa I2CSerialBusConnection per l'accesso al dispositivo
Risorsa GpioInt per gli interruzioni
Il metodo HIDI2C _DSM per restituire l'indirizzo di registrazione del descrittore HID nel dispositivo. Per altre informazioni, vedere Metodo Device-Specific HIDI2C (_DSM).
Dispositivi pulsante
Per le piattaforme SoC, Windows supporta sia il pulsante di alimentazione del metodo di controllo definito da ACPI, sia una matrice di cinque pulsanti compatibile con Windows. Il pulsante di alimentazione, se implementato come metodo di controllo ACPI Power Button o come parte dell'array pulsante compatibile con Windows, esegue le operazioni seguenti:
Causa l'alimentazione della piattaforma se è disattivata.
Genera l'evento Power Button Override quando viene tenuto premuto. Per altre informazioni, vedere la sezione 4.8.2.2.1.3, "Power Button Override", della specifica ACPI 5.0.
Pulsante di alimentazione del metodo di controllo
La progettazione di clamshell e altri sistemi con tastiere predefinite 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 GPIO-Signaled EVENTI ACPI (sezione 5.6.5 della specifica ACPI 5.0). Per supportare il dispositivo del pulsante di alimentazione, lo spazio dei nomi:
Descrive il pin di interruzione GPIO del pulsante di alimentazione come risorsa di interruzione GPIO non condivisa (esclusiva).
Elenca la risorsa di interruzione GPIO del pulsante di alimentazione nell'oggetto _AEI del controller GPIO a cui è connesso.
Fornisce il metodo evento associato (Lxx/Exx/EVT) nel dispositivo controller GPIO. Questo metodo evento notifica al driver Pulsante del metodo di controllo nel sistema operativo che si è verificato l'evento del pulsante.
Per altre informazioni, vedere Pulsanti hardware per Windows 8 tablet e dispositivi convertibili.
Matrice di pulsanti compatibili con Windows
Per 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 relativa 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 del pulsante Della posta in arrivo di Windows, viene implementato il dispositivo ACPI della matrice di pulsanti compatibile con Windows. Il dispositivo è definito come segue:
Ognuno dei cinque pulsanti è connesso al proprio pin di interrupt dedicato sulla piattaforma.
Ogni pin di interruzione 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:
Interrompi corrispondente al pulsante "Alimentazione"
Il pulsante "Power" deve essere abilitato per la riattivazione (ExclusiveAndWake).
Interrupt corrispondente al pulsante "Windows"
Il pulsante Windows deve essere abilitato per la riattivazione (ExclusiveAndWake).
Interrupt corrispondente al pulsante "Volume up"
Il pulsante "Volume up" non deve essere abilitato per la riattivazione (deve usare Exclusive).
Interrupt corrispondente al pulsante "Volume giù"
Il pulsante "Volume giù" non deve essere abilitato per la riattivazione (deve usare Esclusivo).
Interrupt corrispondente al pulsante "Rotation Lock", se supportato
Il pulsante "Rotation Lock" non deve essere abilitato per la riattivazione (deve usare Exclusive).
Per altre informazioni, vedere Pulsanti hardware per Windows 8 tablet e dispositivi convertibili.
Per supportare l'evoluzione dell'interfaccia utente pulsante di Windows, Windows definisce un metodo Device-Specific (_DSM) per il dispositivo Array di pulsanti Windows. Per altre informazioni, vedere Metodo Device-Specific button array di Windows (_DSM).For more information, see Windows Button Array Device-Specific Method (_DSM).
Ancorare e convertire i dispositivi di rilevamento dei PC
Windows supporta dock e convertibili (combo clamshell/tablet) usando 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 applicabili 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 riprogrammazione della polarità dinamica.
Il driver del controller GPIO deve usare l'emulazione ActiveBoth fornita dall'estensione del framework GPIO (GpioClx).
Se lo stato asseribile ("Docked" o "Convert") non è impostato su un livello di logica basso, il controller GPIO _DSM metodo è necessario per eseguire l'override del comportamento predefinito dello stack di driver GPIO. Per altre informazioni, vedere la sezione Dispositivi controller GPIO nell'argomento I/O per utilizzo generico .for more information, see the GPIO controller devices section in the General-purpose I/O (GPIO).
Per altre informazioni, vedere Pulsanti hardware per Windows 8 tablet e dispositivi convertibili.
Dispositivo di rilevamento del dock
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 abilitato per la riattivazione.
Dispositivo di rilevamento pc convertibile
Un dispositivo convertibile-PC-sensing interrompe il sistema quando un PC convertibile passa dal tablet al fattore di forma 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
Una _CID di PNP0C60
Un _CRS con un interrupt ActiveBoth
L'interrupt non può essere abilitato per la riattivazione.