Requisiti del firmware per D3cold
A partire da Windows 8, i dispositivi possono entrare nello stato secondario di alimentazione D3cold anche quando il sistema rimane nello stato di alimentazione S0. Questo argomento descrive i requisiti del firmware per l'implementazione del supporto D3cold per un dispositivo incorporato. La discussione seguente ha lo scopo di aiutare gli sviluppatori di firmware a consentire ai dispositivi incorporati di entrare e uscire in modo affidabile da D3cold.
Inoltre, i requisiti dei driver di dispositivo per il supporto di D3cold sono descritti brevemente. Per altre informazioni sul supporto dei driver di dispositivo per D3cold, vedere Supporto di D3cold in un driver.
Introduzione
Gli stati di alimentazione del dispositivo sono definiti nella specifica ACPI e in varie specifiche del bus. La specifica del bus PCI ha, da quando ha introdotto il risparmio energia PCI, suddividere lo stato di alimentazione del dispositivo D3 (off) in due sotto-stati, D3hot e D3cold. Questa distinzione è stata aggiunta alla specifica ACPI in ACPI 3.0 ed estesa in ACPI 4.0. Windows ha sempre supportato entrambi gli stati secondari D3, ma Windows 7 e versioni precedenti di Windows supportano lo stato secondario D3cold solo quando l'intero computer esce dallo stato di alimentazione del sistema S0 (funzionante) per entrare in stato di sospensione o ibernazione, in genere S3 o S4. A partire da Windows 8, i driver di dispositivo possono consentire ai dispositivi di entrare nello stato D3cold anche mentre il sistema rimane in S0.
D3hot, che viene spesso chiamato "D3", è lo stato "soft-off" del dispositivo. In questo stato, il dispositivo può essere rilevato da un'analisi del bus e i comandi inviati al dispositivo possono causare l'accensione di nuovo. In D3cold tutte le fonti di alimentazione vengono rimosse, con l'eccezione possibile di una piccola quantità di potenza per guidare la logica di riattivazione del dispositivo. Ad esempio, per i dispositivi PCI Express (PCIe), l'origine di alimentazione principale del dispositivo, Vcc, viene spesso disattivata in una transizione a D3cold. La disattivazione di Vcc può ridurre il consumo di energia ed estendere il tempo di esecuzione di una piattaforma hardware mobile su una batteria. Quando un dispositivo è in D3cold, non può essere rilevato da un'analisi del bus e non può ricevere comandi. Il ripristino dell'alimentazione Vcc sposta il dispositivo in uno stato non inizializzato, che in genere equivale allo stato D0. Il software deve quindi inizializzare nuovamente il dispositivo per inserirlo nello stato di lavoro.
L'inserimento di un dispositivo in D3cold non significa necessariamente che tutte le fonti di alimentazione per il dispositivo siano state rimosse, significa solo che la fonte di alimentazione principale, Vcc, viene rimossa. La fonte di alimentazione ausiliaria, Distribuita, potrebbe anche essere rimossa se non è necessaria per la logica di riattivazione. Tuttavia, un dispositivo che potrebbe essere necessario per segnalare un evento di riattivazione al processore deve essere in grado di disegnare una potenza sufficiente per operare la logica di riattivazione. Ad esempio, una scheda di interfaccia di rete Ethernet la cui fonte di alimentazione principale viene rimossa potrebbe disegnare una potenza sufficiente dal cavo Ethernet. In alternativa, l'alimentazione standby a una scheda di interfaccia di rete Wi-Fi potrebbe essere fornita da un'origine all'esterno dell'interfaccia PCIe, nel qual caso l'interfaccia PCIe può essere completamente disattivata.
Nella discussione seguente viene descritto un set di requisiti per abilitare la transizione dello stato di alimentazione del dispositivo a D3cold. Questi requisiti rientrano nelle due categorie seguenti:
Requisiti del firmware e della piattaforma
Requisiti dei driver di dispositivo
La prima di queste due categorie è l'obiettivo principale di questa discussione. Viene presentata una breve panoramica della seconda categoria. Per altre informazioni sui requisiti dei driver di dispositivo, vedere Supporto di D3cold in un driver.
Requisiti del firmware e della piattaforma
Nella discussione seguente vengono presentati i requisiti del firmware e della piattaforma per l'abilitazione di D3cold per questi due casi:
Quando il dispositivo viene enumerato in ACPI.
Quando il dispositivo viene enumerato dal bus padre.
La maggior parte della discussione seguente è specifica per PCIe. Tuttavia, i principi generali descritti qui si applicano in gran parte anche ad altri autobus.
Astraendo alcuni dettagli, la transizione da D3cold a D0 viene attivata riapplicando l'alimentazione Vcc al dispositivo incorporato. Riapplicare l'alimentazione ripristina in modo efficace la connessione del dispositivo al bus. Windows legge gli identificatori del dispositivo per distinguere tra i due casi seguenti:
Un dispositivo è stato rimosso e sostituito da un altro dispositivo.
Lo stesso dispositivo è stato rimosso e quindi reinsertato.
Se gli identificatori corrispondono, il driver di dispositivo reinizializza il dispositivo. Se gli identificatori non corrispondono, Windows scarica il driver di dispositivo e compila un nuovo stack di driver per il nuovo dispositivo. PCIe, ad esempio, esegue una query per l'ID fornitore, l'ID dispositivo e gli ID sottosistema ,suddivisi in ID sub-dispositivo e sub-vendor in alcune versioni della specifica. Questi identificatori devono corrispondere a quelli del dispositivo collegato in precedenza dopo l'applicazione dell'alimentazione (e il periodo di attesa specificato dall'autobus scade); in caso contrario, Windows considererà che il nuovo dispositivo sia diverso da quello precedente.
Caso 1: un dispositivo incorporato viene enumerato in ACPI
Se un dispositivo incorporato non è individuabile tramite meccanismi definiti da una specifica del bus, ad esempio PCIe o USB, ma il dispositivo è connesso in modo permanente (o almeno la connessione è dedicata a un dispositivo noto), questo dispositivo può essere descritto nel firmware della piattaforma da ACPI _HID e/o oggetti _CID. Questi oggetti consentono l'enumerazione del dispositivo da parte di OSPM. ("OSPM" è un termine definito nella specifica ACPI. Significa, in modo libero, "software che non è firmware". OSPM enumera un dispositivo solo quando nessun enumeratore bus può rilevare l'ID dispositivo. Ad esempio, i dispositivi in un bus ISA vengono enumerati da OSPM. Inoltre, i dispositivi in un sistema su un chip (SoC) vengono spesso enumerati da ACPI perché sono in un'infrastruttura non enumerabile. Esempi di tali dispositivi includono controller host USB e SD.
Firmware della piattaforma (enumerato in ACPI)
OSPM usa \_SB._OSC per trasmettere le funzionalità OSPM a livello di piattaforma al firmware della piattaforma. Il firmware della piattaforma deve impostare bit 2 nel valore restituito \_SB._OSC per indicare a OSPM che il dispositivo supporta _PR3. Per altre informazioni, vedere la sezione 6.2.10.2, "Platform-Wide OSPM Capabilities", nella specifica ACPI 5.0.
Dispositivo incorporato (individuato esclusivamente tramite ACPI)
Per supportare D3cold, il firmware della piattaforma deve implementare gli oggetti risorsa di alimentazione ACPI seguenti per il dispositivo incorporato:
_PR0: questo oggetto restituisce i requisiti di alimentazione del dispositivo nello stato di alimentazione del dispositivo D0 (completamente acceso). Il valore restituito è l'elenco di risorse di alimentazione richieste dal dispositivo nello stato D0.
_PR2: questo oggetto restituisce i requisiti di alimentazione del dispositivo nello stato di alimentazione del dispositivo D2. Il valore restituito è l'elenco delle risorse di alimentazione richieste dal dispositivo nello stato D2. Si noti che per motivi cronologici, Windows prevede che _PR2 essere presente ogni volta che è presente _PR0. Se D2 viene implementato nell'hardware, _PR2 elenca le risorse di alimentazione necessarie per D2. Se D2 non è implementato, _PR2 elenca le stesse risorse di _PR0.
_PR3: questo oggetto restituisce i requisiti di alimentazione del dispositivo nello stato di alimentazione del dispositivo D3hot. Il valore restituito è l'elenco delle risorse di alimentazione richieste dal dispositivo nello stato D3hot.
Per ogni risorsa di alimentazione identificata in qualsiasi oggetto _PRx, è necessario implementare i metodi di controllo seguenti:
_OFF: impostare la risorsa di alimentazione sullo stato disattivato (spegnere la risorsa).
_ON: impostare la risorsa di alimentazione sullo stato attivo (accensione della risorsa).
_STA: questo oggetto restituisce lo stato corrente acceso o disattivato della risorsa di alimentazione (0: disattivato, 1: attivato).
Una transizione a D3cold si verifica quando ACPI esegue il metodo di controllo _OFF sulle risorse di alimentazione elencate in _PR3. Si noti che se il driver di funzione del dispositivo indica il supporto per D3cold, questo supporto non implica che tutte le transizioni a D3 comportino transizioni rapide a D3cold. È possibile che il dispositivo entri e rimanga in D3hot per un periodo prolungato e quindi torna a D0 senza mai immettere D3cold o entra D3cold in un secondo momento.
Dispositivo padre (enumerato in ACPI)
Non è necessario che un dispositivo padre sia in grado di gestire l'alimentazione. Tuttavia, se un dispositivo padre è gestito dall'alimentazione, Windows non spegne mai questo dispositivo se uno dei relativi elementi figlio (dispositivi dipendenti) non è in D3.
Esempio (enumerato in ACPI)
Il diagramma a blocchi seguente mostra un dispositivo incorporato (con etichetta EMBD) in un bus di sistema. L'alimentazione principale (Vcc) e l'alimentazione ausiliaria (Logic) per il dispositivo possono essere accesi e spenti in modo indipendente tramite la logica di alimentazione a blocchi.
Nell'esempio di codice ASL seguente vengono descritte le risorse di risparmio energia usate dal dispositivo incorporato nel diagramma precedente. Questo esempio inizia con una dichiarazione di un metodo di controllo _OSC che descrive le funzionalità del driver di dispositivo. Vengono quindi dichiarate le due risorse di alimentazione del dispositivo: i nomi delle risorse PVCC e PVAX vengono assegnati alle fonti di alimentazione principale e ausiliaria del dispositivo, Vcc e Route. Infine, vengono elencati i requisiti di risparmio energia per ogni stato di alimentazione del dispositivo supportato dal dispositivo e vengono descritte le funzionalità di riattivazione del dispositivo.
Scope (\_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVCC,0,0) // Power resource representing the main power for the device.
// Required for the device to be fully functional (D0).
{
Name(_STA,VAR1) // Return the state of the power resource.
Method(_ON,0x0) {...} // Turn on the power resource and set VAR1 to 1.
Method(_OFF,0x0) {...} // Turn off the power resource and set VAR1 to 0.
}
PowerResource(PVAX,0,0) // Power resource representing the auxiliary power for the device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
Device(EMBD) // An ACPI-enumerated device on the processor bus that supports D3Cold
{
Name(_HID, ...)
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVCC, PVAX}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package() {PVCC, PVAX}) // If D2 is implemented in the hardware,
// list the power resources needed by D2.
// If D2 is not implemented, list the same
// resources as _PR3.
// Indicate support for D3Cold.
Name(_PR3, Package() {PVCC, PVAX}) // Power resource for D3. These will be
// turned off ONLY if drivers opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the device doesn't
// need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform is
// capable of handling wake events from this device while in S0.
// The value of this object indicates the lowest D-state this device
// can be in to trigger wake events that can be handled while the
// platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way for OSPM to
// enable and disable them. The mechanism for this depends on the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with either of the above, if wake enablement
// varies depending on the target S-state and D-state.
*/
} // End of Device EMBD
} End Scope \_SB
Caso 2: un dispositivo incorporato è enumerato in bus
Se il dispositivo incorporato è conforme a una specifica comune del bus, ad esempio PCIe o USB, questo dispositivo è individuabile tramite meccanismi definiti dal bus e l'alimentazione può essere fornita parzialmente o completamente attraverso il bus. Se questo dispositivo non è alimentato da altre risorse di alimentazione sideband, l'origine di alimentazione principale del dispositivo è il collegamento che connette il dispositivo al controller del bus padre. I dispositivi enumerati dal bus possono essere identificati dall'oggetto _ADR nella definizione del dispositivo incorporato. Un oggetto _ADR viene usato per fornire a OSPM l'indirizzo di un dispositivo nel bus padre del dispositivo incorporato. Questo indirizzo viene usato per collegare la rappresentazione del bus del dispositivo (come visto dall'hardware del bus) alla rappresentazione della piattaforma del dispositivo (come illustrato dal firmware ACPI). La codifica degli indirizzi _ADR è specifica del bus. Per altre informazioni, vedere la sezione 6.1.1, "_ADR (indirizzo)", nella specifica ACPI 5.0. Quando viene usato questo meccanismo, il supporto D3cold deve essere coordinato con il driver del bus padre.
Se l'alimentazione principale per un dispositivo incorporato è il collegamento che connette il dispositivo al bus padre, il requisito chiave per inserire il dispositivo in D3cold consiste nell'accendere il collegamento. Per altre informazioni sulla transizione a D3cold, vedere il grafico dello stato in Stati di alimentazione dei dispositivi.
Firmware della piattaforma (enumerazione bus)
OSPM usa \_SB._OSC per trasmettere funzionalità OSPM a livello di piattaforma al firmware della piattaforma. Il firmware della piattaforma deve impostare bit 2 nel valore restituito \_SB._OSC per indicare a OSPM che il dispositivo supporta _PR3. Per altre informazioni, vedere la sezione 6.2.10.2, "Funzionalità OSPM a livello di piattaforma", nella specifica ACPI 5.0.
Dispositivo incorporato (enumerazione bus)
Non sono necessarie modifiche ACPI specifiche di D3cold. In questo caso, purché il driver del dispositivo e la piattaforma abbiano indicato il supporto per D3cold, il collegamento del bus che fornisce alimentazione al dispositivo incorporato può essere disattivato quando il bus padre esce da D0 e entra in uno stato di bassa potenza Dx. La transizione del dispositivo incorporato da D3hot a D3cold si verifica quando l'alimentazione viene rimossa dal collegamento. Lo stato Dx immesso dal bus padre può essere qualsiasi stato che causerà la disattivazione dell'origine dell'alimentazione del collegamento.
Dispositivo padre (enumerazione bus)
Il descrittore ACPI per il bus padre deve eseguire le operazioni seguenti:
Implementare _S0W(Dx). Questo oggetto specifica Dx come stato D-power più basso da cui il dispositivo figlio (incorporato) può riattivarsi quando il sistema si trova nello stato S0.
Definire le risorse di alimentazione per rappresentare il collegamento che connette il dispositivo figlio (incorporato) al bus padre. Inoltre, _ON, _OFF e gli oggetti _STA devono essere definiti per questa risorsa di alimentazione. L'esempio di codice ASL che segue questo elenco descrive la potenza del collegamento come due risorse, PVC1 e PVX1. Per ognuna di queste risorse, vengono definiti _ON, _OFF e oggetti _STA.
Se "Dx" (lo stato D-power più basso; vedere la prima voce di elenco) è D3cold, specificare un oggetto _PR3 che include le risorse di alimentazione che il dispositivo figlio (incorporato) richiede per D3hot (ad esempio, Vcc e Vaux). Se sono necessarie le stesse fonti di alimentazione per D0, D2 e D3hot, _PR0, _PR2 e _PR3 specificare tutte le stesse risorse di alimentazione. Queste risorse vengono disattivate solo quando il dispositivo figlio entra in D3cold.
Per motivi cronologici, Windows prevede che _PR2 essere presente ogni volta che _PR0 è presente. Se D2 viene implementato nell'hardware, _PR2 elenca le risorse di alimentazione necessarie per D2. Se D2 non è implementato, _PR2 elenca le stesse risorse di _PR0.
Implementare _PR0. L'elenco delle risorse nell'oggetto _PR0 per il bus padre deve includere le risorse che consentono di collegare il bus padre al dispositivo figlio (incorporato).
Esempio (enumerazione bus)
La configurazione hardware di esempio nel diagramma a blocchi seguente mostra due diversi modi in cui È possibile abilitare D3cold per i dispositivi PCIe. Prima di tutto, un endpoint (etichettato ENDP) è connesso a una porta radice PCIe (RP01) e riceve l'alimentazione ausiliaria dal dispositivo padre tramite un collegamento PCIe. In secondo luogo, il dispositivo HD Audio nel diagramma non ha alcun collegamento standard al relativo dispositivo padre (il controller PCI etichettato PCI0) ed è quindi modellato in modo analogo al caso dell'enumerazione ACPI.
Il dispositivo RP01 in questo diagramma ha una fonte di alimentazione principale, Vcc1 e un'origine di alimentazione ausiliaria, Vaux1. Analogamente, il dispositivo HD Audio ha una fonte di alimentazione principale, Vcc2 e una fonte di alimentazione ausiliaria, Vaux2.
Il codice ASL seguente descrive il controller del bus padre (PCI0) e le risorse di alimentazione necessarie per i dispositivi ENDP e HD Audio illustrati nel diagramma precedente.
Scope (_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVC1,0,0) // Power resource representing Vcc1 for the RP01 device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR0)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX1,0,0) // Power resource representing Vaux1 for the RP01 device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR1)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVC2,0,0) // Power resource representing Vcc2 for the HD device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX2,0,0) // Power resource representing Vaux2 for the HD device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR3)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
... // Power resources for other child devices
Device(PCI0) // The PCI root complex
{
Name(_HID, EISAID("PNP0A08")) // ACPI enumerated
Method(_OSC, 4, NotSerialized) // PCIe-specific Capabilities Check.
{
... // This must support hand-off of PCIe control to the OS.
}
... // Other (non-power) objects for this device
Device(RP01) // PCIe Root Port 1
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC1, PVX1}) // Power resources required for D0.
// Includes the Link Power for ENDP.
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC1, PVX1})
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that
// can be handled while the platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way
// for OSPM to enable and disable them. The mechanism for this depends on
// the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
Device(ENDP) // This device supports D3cold. No power-related objects
// are required.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects
} // End of Device ENDP
} // End of Device RP01
Device(HD) // A PCIe Bus0 device (HD Audio) that supports D3cold. Note that
// this case is modeled similar to the ACPI-enumerated case
// because device HD has no standard link to its parent.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC2, PVX2}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC2, PVX2})
// Indicate support for D3Cold.
Name(_PR3, Package() {PVC2, PVX2}) // Power resource for D3; These will
// be turned off ONLY if drivers
// opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that can
// be handled while the platform is in S0.
// Enable wake events (optional).
// If this device actually does generate wake events, there must be a way for
// OSPM to enable and disable them. The mechanism for this depends on the HW:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
} // End Device HD
... // Device objects for other child devices
} // End Device PCI0
} // End Scope _SB
Altre possibilità
Le tecniche illustrate nei due esempi precedenti possono essere combinate per supportare le configurazioni che usano la potenza del bus e la potenza sideband.
Requisiti del driver del dispositivo
Il proprietario dei criteri di alimentazione per un dispositivo (in genere il driver di funzione) indica al sistema operativo se abilitare la transizione del dispositivo da D3hot a D3cold. Il driver può fornire queste informazioni nel file INF che installa il dispositivo. In alternativa, il driver può chiamare la routine SetD3ColdSupport in fase di esecuzione per abilitare o disabilitare dinamicamente le transizioni del dispositivo in D3cold. Abilitando un dispositivo per immettere D3cold, un driver garantisce il comportamento seguente:
Il dispositivo può tollerare una transizione da D3hot a D3cold quando il computer deve rimanere in S0.
Il dispositivo funzionerà correttamente quando torna a D0 da D3cold.
Un dispositivo che non riesce a soddisfare un requisito potrebbe, dopo aver immesso D3cold, non essere disponibile finché il computer non viene riavviato o entra in uno stato di sospensione. Se il dispositivo deve essere in grado di segnalare un evento di riattivazione da qualsiasi stato Dx a bassa potenza immesso, la voce a D3cold non deve essere abilitata a meno che il driver non sia certo che il segnale di riattivazione del dispositivo funzionerà in D3cold.
Per altre informazioni, vedere Supporto di D3cold in un driver.