Présentation de l’infrastructure de gestion de l’alimentation dirigée

  • Article

À partir de Windows 10, version 1903, la version 3 de l’infrastructure de gestion de l’alimentation pendant l’exécution (PoFx) fournit un modèle d’alimentation dirigé facultatif, Directed PoFx (DFx).

Avec DFx, le système d’exploitation dirige les piles de périphériques pour entrer dans leurs états d’inactivité à faible consommation appropriés lorsque le système passe en mode inactif et qu’il n’y a pas d’activité logicielle répartie par activateur, ce qui permet au système d’entrer dans un état à faible consommation de manière plus fiable.

L’objectif est d'améliorer l'efficacité des systèmes et de réduire la consommation d’énergie pour les périphériques Windows dans tous les facteurs de forme.

DFx est actuellement pris en charge pour les périphériques avec des contraintes d’état D uniquement. DFx ignore toute sous-arborescence de périphériques avec une contrainte d’état F.

DFx n’éteint pas les périphériques de pagination ou de débogage.

Exigences pour les pilotes WDF (non miniport)

Un pilote WDF qui est un propriétaire de stratégie d’alimentation doit implémenter une stratégie S0-Idle appropriée en spécifiant SystemManagedIdleTimeout ou SystemManagedIdleTimeoutWithHint dans la structure WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS. Cela permet au périphérique de se mettre hors tension lorsqu’il est inactif. Comme mesure de résilience supplémentaire, le pilote peut opter pour DFx en ajoutant la clé de registre suivante à la section d'instruction AddReg du fichier INF dans la section DDInstall.HW :

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

Un pilote WDF ciblant la version 31 et ultérieure active DFx par défaut. Si cette activation n'est pas souhaitée, le pilote peut désactiver DFx en définissant la clé de registre sur 0 :

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

Un pilote WDF ciblant la version 33 et ultérieure peut également refuser DFx en définissant le membre DirectedPoFxEnabled de la structure WDF_POWER_FRAMEWORK_SETTINGS sur WdfFalse.

Conseil

Pour initialiser sa structure WDF_POWER_FRAMEWORK_SETTINGS, votre pilote doit appeler WDF_POWER_FRAMEWORK_SETTINGS_INIT.

Étant donné que la demande d'un délai d'inactivité géré par le système entraîne l'enregistrement de WDF auprès de PoFx pour le compte du pilote, ce dernier n'a pas besoin de s'enregistrer auprès de PoFx dans ce scénario.

Si le pilote spécifie DriverManagedIdleTimeout, envisagez de passer au délai d’inactivité géré par le système. Si cela s'avère impossible, appliquez les instructions de la section WDM ci-dessous pour choisir DFx.

Si le pilote WDF n’utilise pas la gestion de l’alimentation du runtime, ajoutez la prise en charge et utilisez le délai d’inactivité géré par le système. Pour ce faire, fournissez une structure WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS en tant qu'entrée à WdfDeviceAssignS0IdleSettings.

Exigences pour les pilotes WDM (non miniport)

Si votre pilote n’utilise pas la prise en charge d’inactivité gérée par le système fournie par WDF (le pilote est soit un pilote WDF qui utilise l'inactivité gérée par un pilote, ou un pilote WDM), il peut toujours obtenir la prise en charge DFx en s’inscrivant auprès de PoFx. Dans ce scénario, le pilote s’inscrit auprès de PoFx en implémentant :

Fournissez des pointeurs vers ces rappels dans une structure PO_FX_DEVICE_V3 qui est l'entrée de la fonction PoFxRegisterDevice.

Pour bénéficier de la prise en charge DFx, un pilote doit :

  • Fournir les rappels PO_FX_DIRECTED_POWER* lors de l’inscription auprès de PoFx
  • Appelez PoFxReportDevicePoweredOn à partir de sa fonction de rappel PO_FX_DIRECTED_POWER_UP_CALLBACK lors du retour d’inactivité. S’il s’agit d’un pilote WDF, il peut définir un indicateur, puis dans EvtDeviceD0Entry, vérifier l'indicateur et appeler PoFxReportDevicePoweredOn.
  • Appelez PoFxReportDevicePoweredOn lors de la reprise de la transition Sx. S’il s’agit d’un pilote WDF, il doit prétraiter IRP_MN_SET_POWER. Le rappel de prétraitement doit uniquement s'exécuter si Parameters.Power.Type == SystemPowerState. Étant donné que le périphérique peut rester dans l’état Dx pendant l’intégralité du cycle de veille/reprise, l’approche ci-dessus consistant à vérifier un indicateur dans EvtDeviceD0Entry ne fonctionnera pas. Au lieu de cela, la fonction de rappel d'événement EvtDeviceWdmIrpPreprocess doit appeler IoSetCompletionRoutine pour définir une routine IoCompletion, et à partir de la routine d'achèvement appeler PoFxReportDevicePoweredOn.

Exemple

L’exemple suivant montre l’option d’auto-inscription décrite ci-dessus :

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 votre pilote a spécifié PO_FX_VERSION_V1 précédemment, notez que les structures PO_FX_DEVICE_V3 utilisent PO_FX_COMPONENT_V2 pour la structure du tableau de composants.

Exigences pour les pilotes miniports

Pour les classes de périphérique qui suivent un modèle de pilote port/miniport, les pilotes de port fournis par le système gèrent généralement la propriété de la stratégie d’alimentation. La plupart des mini-ports ne devraient pas nécessiter de modifications du code pour être compatibles avec DFx, car le pilote du port correspondant est censé gérer la prise en charge de DFx.

Conseils pour les miniports tiers de KS.sys

À partir de Windows 10, version 2004 (également appelée 20H1 ou build 19041), KS.sys refuse DFx et les exigences HLK associées par défaut. Les miniports tiers de KS.sys peuvent accepter DFx et les exigences HLK associées en s’inscrivant auprès de PoFx et en ajoutant la clé de Registre KsDFxSupportEnable au fichier INF.

Un pilote peut s’inscrire lui-même auprès de PoFx à l’aide de l’implémentation mentionnée dans cette section. En outre, la ligne suivante doit être ajoutée dans la section d'instruction AddReg.

HKR, , KSDFxSupportEnable, 0x00010001, 1

La section AddReg peut être appelée par la section [DDInstall.HW] du périphérique ou par la section [service-install-section] du pilote. En l'ajoutant dans la section [DDInstall.HW] on modifie uniquement ce périphérique spécifique. Cela s'avère utile si le même pilote est utilisé pour différentes combinaisons VID/PID, mais que DFx ne doit être activé que pour un périphérique spécifique.

L’ajout de la section AddReg dans la [section service-install-] accepte DFx pour tous les périphériques qui utilisent ce pilote.

Test

Microsoft fournit trois tests pour DFx : un test pour seul périphérique dans le Windows Driver Kit destiné à tester les périphériques spécifiés par l'utilisateur, un test HLK au niveau du périphérique et un test HLK au niveau du système destiné à tester tous les périphériques d'un même système.

Le test pour un seul périphérique est disponible avec l’outil PwrTest fourni avec WDK. Pour y accéder, exécutez l’outil avec le commutateur /directedfx. Pour plus d’informations, consultez PwrTest DirectedFx Scenario.

Pour plus d’informations sur les tests HLK, consultez les pages suivantes :

Le test DFx après une transition S4 est recommandé pour détecter les cas où un pilote pourrait ne pas appeler correctement PoFxReportDevicePoweredOn après une reprise depuis S4.

Transitions d'états DFx et S

  • L’état D cible pour les transitions DFx doit correspondre à celui du runtime D3 (RTD3), qui peut être différent de l’état D cible pour les transitions S3/S4. Considérons un scénario dans lequel un périphérique entre en D2 pour RTD3, mais entre en D3 pour S3/S4. Dans ce cas, l’état D cible pour DFx doit être D2.
  • De même, le comportement « arm-for-wake » pour DFx doit correspondre à celui de RTD3, qui peut différer de celui utilisé dans les transitions S3/S4. Par exemple, un périphérique peut entrer en D2/« wake-armed » pour RTD3, mais entrer D3/« no-wake-armed » pour S3/S4. Dans ce scénario, les transitions DFx doivent également entrer en D2/« wake-armed ».

DFx et Runtime D3 (RTD3)

  • Avec RTD3, un périphérique entre généralement dans un état D de faible consommation lorsqu’il est inactif. Si une nouvelle tâche arrive, il se réveille immédiatement vers D0. Avec DFx, l'appareil doit rester dans son état D cible (et mettre en attente les nouvelles tâches dans ses files d'attente) jusqu'à ce que le PoFx lui ordonne de se remettre sous tension.

Voir aussi