Introduzione a Directed Power Management Framework

  • Articolo

A partire da Windows 10, versione 1903, versione 3 del framework di risparmio energia in fase di esecuzione (PoFx) fornisce un modello di alimentazione diretta facoltativo, Directed PoFx (DFx).

Con DFx, il sistema operativo indirizza gli stack di dispositivi a immettere i propri stati di inattività a basso consumo appropriati quando il sistema passa a inattiva e non esiste alcuna attività software negoziata dall'attivatore, e quindi consente al sistema di immettere energia bassa in modo più affidabile.

L'obiettivo è quello di rendere i sistemi più efficienti in modo energetico e ridurre il consumo energetico per i dispositivi Windows in diversi fattori di forma.

DFx è attualmente supportato solo per i dispositivi con vincoli di stato D. DFx ignora qualsiasi sottoalbero del dispositivo con un vincolo di stato F.

DFx non spegne il paging o esegue il debug dei dispositivi.

Requisiti per i driver WDF (non miniport)

Un driver WDF proprietario di criteri di alimentazione deve implementare un criterio S0-Idle appropriato specificando SystemManagedIdleTimeout o SystemManagedIdleTimeoutWithHint nella struttura WDF_DEVICE_POWER_POLICY_IDLE_edizione Standard TTINGS. Ciò consentirà al dispositivo di spegnere quando è inattivo. Come misura di resilienza aggiunta, il driver può acconsentire esplicitamente a DFx aggiungendo la chiave del Registro di sistema seguente alla sezione della direttiva AddReg di INF all'interno della sezione DDInstall.HW:

HKR,"WDF","WdfDirectedPowerTransitionEnable",0x00010001,1

Un driver WDF destinato alla versione 31 e successive abiliterà DFx per impostazione predefinita. Se ciò non è indesiderato, il driver può rifiutare esplicitamente DFx impostando la chiave del Registro di sistema su 0:

HKR,"WDF","WdfDirectedPowerTransitionEnable",0x00010001,0

Un driver WDF destinato alla versione 33 e successive può in alternativa rifiutare esplicitamente DFx impostando il membro DirectedPoFxEnabled della struttura WDF_POWER_FRAMEWORK_edizione Standard TTINGS su WdfFalse.

Suggerimento

Per inizializzare la struttura WDF_POWER_FRAMEWORK_edizione Standard TTINGS, il driver deve chiamare WDF_POWER_FRAMEWORK_edizione Standard TTINGS_INIT.

Poiché la richiesta di timeout di inattività gestito dal sistema causa la registrazione di WDF con PoFx per conto del driver, il driver non deve eseguire la registrazione con PoFx in questo scenario.

Se il driver specifica DriverManagedIdleTimeout, è consigliabile passare al timeout di inattività gestito dal sistema. Se ciò non è fattibile, usare le linee guida nella sezione WDM seguente per acconsentire esplicitamente a DFx.

Se il driver WDF non usa il risparmio energia di runtime, aggiungere il supporto e usare il timeout di inattività gestito dal sistema. A tale scopo, specificare una struttura WDF_DEVICE_POWER_POLICY_IDLE_edizione Standard TTINGS come input per WdfDeviceAssignS0Idle Impostazioni.

Requisiti per i driver WDM (non miniport)

Se il driver non usa il supporto di inattività gestito dal sistema fornito da WDF (il driver è un driver WDF usando l'inattività gestita dal driver o un driver WDM), può comunque ottenere il supporto DFx registrandosi con PoFx. In questo scenario, il driver viene registrato con PoFx implementando:

Fornire puntatori a questi callback in una struttura PO_FX_DEVICE_V3 che è input per la funzione PoFxRegisterDevice.

Per ottenere il supporto di DFx, un driver deve:

Esempio

L'esempio seguente illustra l'opzione di registrazione automatica descritta in precedenza:

PO_FX_DEVICE_V3 MyPoFxDevice;
POHANDLE MyPoFxHandle;

RtlZeroMemory(&MyPoFxDevice, sizeof(PO_FX_DEVICE_V3));
MyPoFxDevice.Version = PO_FX_VERSION_V3;

// Initialize other PoFx callbacks and other fields like
// components and their idle states.

MyPoFxDevice.DirectedPowerUpCallback = <Driver's DFx power up callback>
MyPoFxDevice.DirectedPowerDownCallback = <Driver's DFx power down callback>

Status = PoFxRegisterDevice(
  <Driver's device object>,
  (PPO_FX_DEVICE)&MyPoFxDevice,
  &MyPoFxHandle);
  if (!NT_SUCCESS(Status)) {
  return Status;
}

Se il driver specificato PO_FX_VERSION_V1 in precedenza, tenere presente che PO_FX_DEVICE_V3 le PO_FX_COMPONENT_V2 strutture usano per la struttura della matrice di componenti.

Requisiti per i driver miniport

Per le classi di dispositivo che seguono un modello di driver porta/miniport, i driver di porta forniti dal sistema gestiscono in genere la proprietà dei criteri di alimentazione. La maggior parte dei miniport non richiede alcuna modifica del codice per acconsentire esplicitamente a DFx, perché si prevede che il driver di porta corrispondente gestisca il supporto DFx.

Linee guida per miniport di terze parti di KS.sys

A partire da Windows 10, versione 2004 (nota anche come 20H1 o build 19041), KS.sys rifiutare esplicitamente DFx e i requisiti HLK correlati per impostazione predefinita. I minport di terze parti di KS.sys possono acconsentire esplicitamente a DFx e HLK correlato registrandosi con PoFx e aggiungendo la chiave del Registro di sistema KsDFxSupportEnable a INF.

Un driver può registrarsi con PoFx usando l'implementazione indicata in questa sezione. Inoltre, la riga seguente deve essere aggiunta nella sezione direttiva AddReg.

HKR, , KSDFxSupportEnable, 0x00010001, 1

La sezione AddReg può essere richiamata dalla sezione [DDInstall.HW] del dispositivo o dalla [sezione service-install-section] del driver. L'aggiunta nella sezione [DDInstall.HW] cambia solo il dispositivo specifico. Ciò è utile se lo stesso driver viene usato per combinazioni VID/PID diverse, ma DFx deve essere abilitato solo per un dispositivo specifico.

L'aggiunta della sezione AddReg nella [service-install-section] opts-in DFx per tutti i dispositivi che usano tale driver.

Test in corso

Microsoft fornisce tre test per DFx: un test a dispositivo singolo in Windows Driver Kit destinato ai test dei dispositivi specificati dall'utente, un test HLK a livello di dispositivo e un test HLK a livello di sistema destinato a testare tutti i dispositivi in un sistema.

Il test a dispositivo singolo è disponibile come parte dello strumento PwrTest fornito con WDK. Per accedervi, eseguire lo strumento con l'opzione /directedfx . Per altre informazioni, vedere Scenario PwrTest DirectedFx.

Per informazioni sui test HLK, vedere le pagine seguenti:

È consigliabile testare DFx dopo una transizione S4 per intercettare eventuali casi in cui un driver potrebbe non chiamare correttamente PoFxReportDevicePoweredOn dopo la ripresa da S4.

Transizioni di stato DFx e S

  • Lo stato D di destinazione per le transizioni DFx deve corrispondere a quello per Runtime D3 (RTD3), che può essere diverso dallo stato D di destinazione per le transizioni S3/S4. Si consideri uno scenario in cui un dispositivo entra in D2 per RTD3, ma entra in D3 per S3/S4. In questo caso, lo stato D di destinazione per DFx deve essere D2.
  • Analogamente, il comportamento arm-for-wake per DFx deve corrispondere a quello per RTD3, che può differire da quello usato nelle transizioni S3/S4. Ad esempio, un dispositivo può immettere D2/wake-armed per RTD3, ma immettere D3/no-wake-armed per S3/S4. In questo scenario, anche le transizioni DFx devono entrare D2/wake-armed.

DFx e Runtime D3 (RTD3)

  • Con RTD3, un dispositivo in genere entra in uno stato D di alimentazione inferiore quando diventa inattiva. Se arriva un nuovo lavoro, il dispositivo si riattiva immediatamente su D0. Con DFx, il dispositivo deve continuare a rimanere nello stato D di destinazione (e pende nuovo lavoro sulle code) fino a quando PoFx lo indirizza al backup.

Vedi anche