Partilhar via

Introdução à Estrutura de Gerenciamento de Energia Direcionada

  • Artigo

A partir do Windows 10, versão 1903, a versão 3 da estrutura de gerenciamento de energia em tempo de execução (PoFx) fornece um modelo de energia direcionada opcional, Directed PoFx (DFx).

Com o DFx, o sistema operativo direciona as stacks de dispositivos para entrarem nos seus estados ociosos de baixo consumo quando o sistema entra em modo ocioso e não há atividade de software intermediada por ativadores, permitindo assim que o sistema entre em baixa potência de forma mais confiável.

O objetivo é tornar os sistemas mais eficientes em termos de consumo de energia e reduzir o consumo de energia dos dispositivos Windows em todos os formatos.

Atualmente, o DFx é suportado apenas para dispositivos com restrições de estado D. DFx ignora qualquer subárvore de dispositivo com uma restrição de estado F.

O DFx não desliga dispositivos de paginação ou depuração.

Requisitos para controladores WDF (não-miniporta)

Um driver WDF que é o proprietário da política de energia deve implementar uma política de S0-Idle apropriada especificando SystemManagedIdleTimeout ou SystemManagedIdleTimeoutWithHint na estrutura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS. Isso permitirá que o dispositivo desligue quando estiver ocioso. Como medida adicional de resiliência de potência, o condutor pode optar pelo DFx. O subsistema de alimentação pode direcionar o WDF para desligar o dispositivo se for uma restrição de estado D e ainda não tiver desligado quando o sistema entrar em um estado de espera moderno de baixa potência. Quando o subsistema de alimentação direciona o WDF para desligar o dispositivo, o WDF iniciará uma transição para um estado Dx de baixa energia. Isso é conceitualmente semelhante a como WDF pode desligar o dispositivo em resposta a uma transição de energia do sistema para Sx (onde x > 0). Quando o dispositivo for instruído a desligar pela PoFx, as solicitações de E/S geridas por energia ou uma chamada para WdfDeviceStopIdle não restaurarão o dispositivo a um estado D0 ativado. Consulte WdfDeviceStopIdle para obter mais informações.

Um driver pode ativar essa opção adicionando a seguinte chave do registro na seção de diretiva AddReg do INF na seção DDInstall.HW:

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

Um driver WDF direcionado para a versão 31 e superior habilitará o DFx por padrão. Se isso não for desejado, o driver pode desativar o DFx definindo a chave do Registro como 0:

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

Um driver WDF direcionado para a versão 33 e superior pode, alternativamente, desativar o DFx definindo o membro DirectedPoFxEnabled da estrutura WDF_POWER_FRAMEWORK_SETTINGS como WdfFalse.

Sugestão

Para inicializar a sua estrutura WDF_POWER_FRAMEWORK_SETTINGS, o driver deve invocar WDF_POWER_FRAMEWORK_SETTINGS_INIT.

Como a solicitação de tempo limite ocioso gerenciado pelo sistema faz com que o WDF se registre no PoFx em nome do driver, o driver não precisa se registrar no PoFx nesse cenário.

Se o driver especificar DriverManagedIdleTimeout, considere alternar para o tempo limite ocioso gerenciado pelo sistema. Se isso não for viável, use as diretrizes na seção WDM abaixo para optar pelo DFx.

Se o driver WDF não usar o gerenciamento de energia em tempo de execução, adicione suporte para ele e use o tempo limite ocioso gerenciado pelo sistema. Para fazer isso, forneça uma estrutura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS como entrada para WdfDeviceAssignS0IdleSettings.

Requisitos para controladores WDM (não miniporta)

Se o driver não usar o suporte de estado ocioso gerido pelo sistema fornecido pelo WDF (ou seja, se o driver for um driver WDF a usar estado ocioso gerido pelo driver ou um driver WDM), ainda pode obter suporte DFx registando-se com o PoFx. Nesse cenário, o driver se registra com PoFx implementando:

Forneça ponteiros para esses callbacks na estrutura PO_FX_DEVICE_V3 que é entrada para a função PoFxRegisterDevice.

Para obter suporte DFx, um driver deve:

  • Forneça os PO_FX_DIRECTED_POWER* callbacks ao registar-se no PoFx.
  • Ligue PoFxReportDevicePoweredOn a partir da função callback PO_FX_DIRECTED_POWER_UP_CALLBACK ao retornar da ociosidade. Se este for um driver WDF, ele pode definir um sinalizador e, em seguida, em EvtDeviceD0Entry, verifique o sinalizador e chame PoFxReportDevicePoweredOn.
  • Chame PoFxReportDevicePoweredOn ao retomar da transição Sx. Se este for um driver WDF, precisará pré-processar IRP_MN_SET_POWER. O callback de pré-processamento deve apenas prosseguir se Parameters.Power.Type == SystemPowerState. Como o dispositivo pode permanecer no estado Dx durante todo o ciclo de suspensão/retomada, a abordagem acima de verificar um sinalizador em EvtDeviceD0Entry não funcionará. Em vez disso, a função de retorno de chamada de evento EvtDeviceWdmIrpPreprocess deve chamar IoSetCompletionRoutine para definir uma rotina IoCompletion e, a partir dessa rotina de conclusão, chamar PoFxReportDevicePoweredOn.

Exemplo

O exemplo a seguir mostra a opção de auto-registro descrita acima:

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 o PO_FX_VERSION_V1 foi especificado anteriormente no seu driver, observe que a estrutura da matriz de componentes usa PO_FX_DEVICE_V3PO_FX_COMPONENT_V2.

Requisitos aplicáveis aos condutores de miniportos

Para classes de dispositivos que seguem um modelo de driver de porta/miniporta, os drivers de porta fornecidos pelo sistema normalmente lidam com a gestão da política de energia. Não se espera que a maioria das miniportas exija alterações de código para aderir ao DFx, pois o driver de porta correspondente deve lidar com o suporte a DFx.

Orientação para miniportos de terceiros de KS.sys

A partir do Windows 10, versão 2004 (também conhecido como 20H1 ou build 19041), KS.sys exclui o DFx e os requisitos HLK relacionados por padrão. Miniports de terceiros do KS.sys podem aderir ao DFx e ao HLK relacionado, registando-se no PoFx e adicionando a chave de registo KsDFxSupportEnable ao INF.

Um driver pode se registrar com PoFx usando a implementação mencionada nesta seção. Além disso, a seguinte linha precisa ser adicionada na seção diretiva AddReg .

HKR, , KSDFxSupportEnable, 0x00010001, 1

A seção AddReg pode ser invocada pela seção [DDInstall.HW] do dispositivo ou pela seção [service-install-section] do driver. Adicioná-lo na seção [DDInstall.HW] altera apenas esse dispositivo específico. Isso é útil se o mesmo driver for usado para diferentes combinações de VID/PID, mas o DFx precisa ser habilitado apenas para um dispositivo específico.

Adicionar a seção AddReg na [service-install-section] ativa o DFx para todos os dispositivos que utilizam esse driver.

Testes

A Microsoft fornece três testes para DFx: um teste de dispositivo único no Kit de Driver do Windows destinado a testar dispositivos especificados pelo usuário, um teste HLK no nível do dispositivo e um teste HLK no nível do sistema destinado a testar todos os dispositivos em um sistema.

O teste de dispositivo único está disponível como parte da ferramenta PwrTest que acompanha o WDK. Para aceder a ele, execute a ferramenta com a opção /directedfx. Para obter mais informações, consulte Cenário PwrTest DirectedFx.

Para obter informações sobre testes HLK, consulte as seguintes páginas:

Recomenda-se testar DFx após uma transição S4 para detetar quaisquer casos em que um driver pode não estar chamando corretamente PoFxReportDevicePoweredOn após a retomada do S4.

Transições de estado DFx e S

  • O estado D de destino para transições DFx deve corresponder ao do Runtime D3 (RTD3), que pode ser diferente do estado D de destino para transições S3/S4. Considere um cenário em que um dispositivo entra em D2 para RTD3, mas entra em D3 para S3/S4. Nesse caso, o estado D de destino para DFx deve ser D2.
  • Da mesma forma, o comportamento de "arm-for-wake" para o DFx deve corresponder ao de RTD3, que pode diferir do usado nas transições S3/S4. Por exemplo, um dispositivo pode entrar em D2/wake-armed para RTD3, mas entrar em D3/no-wake-armed para S3/S4. Nesse cenário, as transições DFx também devem entrar em D2/wake-armed.

DFx e Runtime D3 (RTD3)

  • Com o RTD3, um dispositivo normalmente entra em um estado D de menor potência quando fica ocioso. Se um novo trabalho for recebido, o dispositivo desperta imediatamente para D0. Com o DFx, o dispositivo deve continuar a permanecer no estado D de destino (e colocar novo trabalho em espera nas suas filas) até que o PoFx o direcione para retornar ao funcionamento.

Ver também