Compartir a través de

Introducción al Marco de administración de energía dirigida

  • Artículo

A partir de Windows 10, la versión 1903, versión 3 del marco de administración de energía en tiempo de ejecución (PoFx) proporciona un modelo de energía dirigido opcional, Directed PoFx (DFx).

Con DFx, el sistema operativo dirige las pilas de dispositivos para entrar en sus estados de inactividad de baja potencia adecuados cuando el sistema pasa a inactivo y no hay ninguna actividad de software activada por el activador y, por lo tanto, permite al sistema entrar en baja potencia de forma más confiable.

El objetivo es hacer que los sistemas sean más eficientes desde el punto de vista energético y reducir el consumo de energía de los dispositivos Windows en todos los factores de forma.

Actualmente, DFx solo se admite con dispositivos con restricciones de estado D. DFx omite cualquier subárbol de dispositivo con una restricción de estado F.

DFx no apaga los dispositivos de paginación o depuración.

Requisitos para los controladores WDF (no minipuertos)

Un controlador WDF que sea propietario de la directiva de energía debe implementar una directiva S0-Idle adecuada especificando SystemManagedIdleTimeout o SystemManagedIdleTimeoutWithHint en la estructura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS . Esto permitirá que el dispositivo se apague cuando esté inactivo. Como medida de resistencia agregada, el controlador puede participar en DFx agregando la siguiente clave del Registro a la sección de la directiva AddReg de INF en la sección DDInstall.HW:

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

Un controlador WDF que tiene como destino la versión 31 y posteriores habilitará DFx de forma predeterminada. Si no se desea, el controlador puede no participar en DFx estableciendo la clave del Registro en 0:

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

Un controlador WDF que tiene como destino la versión 33 y posteriores puede optar por no participar en DFx estableciendo el miembro DirectedPoFxEnabled de la estructura WDF_POWER_FRAMEWORK_SETTINGS en WdfFalse.

Sugerencia

Para inicializar su estructura WDF_POWER_FRAMEWORK_SETTINGS, el controlador debe llamar a WDF_POWER_FRAMEWORK_SETTINGS_INIT.

Puesto que solicitar el tiempo de espera de inactividad administrado por el sistema hace que WDF se registre con PoFx en nombre del controlador, el controlador no necesita registrarse con PoFx en este escenario.

Si el controlador especifica DriverManagedIdleTimeout, considere la posibilidad de cambiar al tiempo de espera de inactividad administrado por el sistema. Si no es factible, use las directrices de la sección WDM siguiente para participar en DFx.

Si el controlador WDF no usa la administración de energía en tiempo de ejecución, agregue compatibilidad con él y use el tiempo de espera de inactividad administrado por el sistema. Para ello, proporcione una estructura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS como entrada en WdfDeviceAssignS0IdleSettings.

Requisitos para los controladores WDM (no minipuertos)

Si el controlador no usa la compatibilidad con inactividad administrada por el sistema proporcionada por WDF (el controlador es un controlador WDF mediante inactividad administrada por controlador o un controlador WDM), todavía puede obtener compatibilidad con DFx registrándose con PoFx. En este escenario, el controlador se registra en PoFx mediante la implementación de:

Proporcione punteros a estas devoluciones de llamada en una estructura PO_FX_DEVICE_V3 que se escriba en la función PoFxRegisterDevice .

Para obtener compatibilidad con DFx, un controlador debe:

  • Proporcionar las devoluciones de llamada PO_FX_DIRECTED_POWER* al registrarse en PoFx
  • Llame a PoFxReportDevicePoweredOn desde su función de devolución de llamada PO_FX_DIRECTED_POWER_UP_CALLBACK cuando vuelva de inactivo. Si se trata de un controlador WDF, puede establecer una marca y, a continuación, en EvtDeviceD0Entry, compruebe la marca y llame a PoFxReportDevicePoweredOn.
  • Llame a PoFxReportDevicePoweredOn tras la reanudación de la transición Sx. Si se trata de un controlador WDF, debe preprocesar IRP_MN_SET_POWER. La devolución de llamada de preprocesamiento solo debe continuar si Parameters.Power.Type == SystemPowerState. Puesto que el dispositivo puede permanecer en estado Dx para la totalidad del ciclo de suspensión y reanudación, el enfoque anterior de comprobar una marca en EvtDeviceD0Entry no funcionará. En su lugar, la función de devolución de llamada de eventos EvtDeviceWdmIrpPreprocess debe llamar a IoSetCompletionRoutine para establecer una rutina IoCompletion y desde la rutina de finalización llamar a PoFxReportDevicePoweredOn.

Ejemplo

En el ejemplo siguiente se muestra la opción de registro automático descrita anteriormente:

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;
}

Si el controlador especificó PO_FX_VERSION_V1 anteriormente, tenga en cuenta que las estructuras PO_FX_DEVICE_V3 usan PO_FX_COMPONENT_V2 para la estructura de matriz de componentes.

Requisitos para controladores de minipuerto

En las clases de dispositivo que siguen un modelo de controlador de puerto/minipuerto, los controladores de puerto suministrados por el sistema suelen gestionar la propiedad de la directiva de energía. No se espera que la mayoría de los minipuertos requieran cambios de código para participar en DFx, ya que se espera que el controlador de puerto correspondiente controle la compatibilidad con DFx.

Guía para minipuertos de terceros de KS.sys

A partir de Windows 10, versión 2004 (también conocida como 20H1 o compilación 19041), KS.sys no participa en los requisitos de DFx y HLK relacionados de forma predeterminada. Los minipuertos de terceros de KS.sys pueden participar en DFx y HLK relacionados registrándose con PoFx y agregando la clave del Registro KsDFxSupportEnable al INF.

Un controlador puede registrarse con PoFx mediante la implementación mencionada en esta sección. Además, se debe agregar la siguiente línea en la sección de la directiva AddReg.

HKR, , KSDFxSupportEnable, 0x00010001, 1

La sección AddReg se puede invocar mediante la sección [DDInstall.HW] del dispositivo o el controlador [service-install-section]. Agregarlo en la sección [DDInstall.HW] solo cambia ese dispositivo en particular. Esto resulta útil si se usa el mismo controlador para diferentes combinaciones VID/PID, pero DFx solo debe habilitarse para un dispositivo específico.

Al agregar la sección AddReg en la [service-install-section], DFx participará para todos los dispositivos que usen ese controlador.

Prueba

Microsoft proporciona tres pruebas para DFx: una prueba de un solo dispositivo en el Kit de controladores de Windows destinado a probar dispositivos especificados por el usuario, una prueba HLK de nivel de dispositivo y una prueba HLK de nivel de sistema diseñada para probar todos los dispositivos de un sistema.

La prueba de un solo dispositivo está disponible como parte de la herramienta PwrTest que se incluye con WDK. Para acceder a ella, ejecute la herramienta con el modificador /directedfx. Para obtener más información, consulte Escenario de PwrTest DirectedFx.

Para obtener información sobre las pruebas de HLK, consulte las páginas siguientes:

Se recomienda probar DFx después de una transición de S4 para detectar los casos en los que un controlador no llame correctamente a PoFxReportDevicePoweredOn después de reanudar desde S4.

Transiciones de estado S y DFx

  • El estado D de destino para las transiciones DFx debe coincidir con el de Runtime D3 (RTD3), que puede ser diferente del estado D de destino para las transiciones de S3/S4. Considere un escenario en el que un dispositivo entra en D2 para RTD3, pero entra en D3 para S3/S4. En este caso, el estado D de destino para DFx debe ser D2.
  • Del mismo modo, el comportamiento "arm-for-wake" para DFx debe coincidir con el de RTD3, que puede diferir del usado en las transiciones de S3/S4. Por ejemplo, un dispositivo puede entrar en D2/"wake-armed" para RTD3, pero entrar en D3/"no-wake-armed" para S3/S4. En este escenario, las transiciones de DFx también deben entrar en D2/"wake-armed".

DFx y Runtime D3 (RTD3)

  • Con RTD3, un dispositivo entra normalmente en un estado D de potencia inferior cuando se queda inactivo. Si llega el nuevo trabajo, el dispositivo se reactiva inmediatamente a D0. Con DFx, el dispositivo debe permanecer en su estado D de destino (y suspender nuevos trabajos en sus colas) hasta que PoFx le indique que se encienda de nuevo.

Consulte también