Поделиться через

Общие сведения о фреймворке управления направленным питанием

  • Статья

Начиная с Windows 10 версии 1903, третья версия фреймворка управления энергопотреблением во время выполнения (PoFx) предоставляет необязательную направленную модель управления питанием, Directed PoFx (DFx).

При использовании DFx операционная система направляет стеки устройств для перехода в соответствующие состояния простоя с низким энергопотреблением, когда система переходит в режим простоя и отсутствует программная активность, регулируемая активатором, что позволяет системе более надежно входить в режим низкого энергопотребления.

Цель состоит в том, чтобы сделать системы более эффективными и сократить потребление энергии для устройств Windows на разных форм-факторах.

В настоящее время DFx поддерживается только для устройств с ограничениями состояния D. DFx пропускает любое поддерево устройства с ограничением состояния F.

DFx не выключает управление страницами памяти или отладочные устройства.

Требования к драйверам WDF (не минипорт)

Драйвер WDF, который является владельцем политики питания, должен реализовать соответствующую политику S0-Idle, указав SystemManagedIdleTimeout или SystemManagedIdleTimeoutWithHint в структуре WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS. Это позволит устройству отключаться, когда оно находится в режиме ожидания. В качестве добавленной меры устойчивости питания драйвер может принять участие в DFx. Подсистема питания может направлять WDF на выключение устройства, если оно является ограничением D-состояния и еще не выключено при входе системы в режим низкого энергопотребления современного режима ожидания. Когда подсистема питания направляет WDF на отключение устройства, WDF инициирует переход в низкоэнергетическое состояние Dx. Это концептуально похоже на то, как WDF может отключать устройство в ответ на переход системы к Sx (где x > 0). Когда устройство было переведено в состояние отключения с помощью PoFx, запросы ввода-вывода с управлением питанием или вызов WdfDeviceStopIdle не восстановят устройство в состояние D0. Дополнительные сведения см. в разделе WdfDeviceStopIdle .

Драйвер может включить эту функцию, добавив следующий ключ реестра в раздел директивы AddReg INF в разделе DDInstall.HW:

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

Драйвер WDF, предназначенный для версии 31 и выше, включает DFx по умолчанию. Если это нежелательно, драйвер может отказаться от DFx, установив ключ реестра на 0.

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

Драйвер WDF, предназначенный для версии 33 и выше, может также отказаться от DFx, задав элемент DirectedPoFxEnabled структуры WDF_POWER_FRAMEWORK_SETTINGS для WdfFalse.

Подсказка

Чтобы инициализировать структуру WDF_POWER_FRAMEWORK_SETTINGS , драйвер должен вызвать WDF_POWER_FRAMEWORK_SETTINGS_INIT.

Так как запрос на время ожидания бездействия, управляемое системой, вызывает регистрацию WDF в PoFx от имени драйвера, драйверу не нужно регистрироваться в PoFx в этом сценарии.

Если драйвер указывает DriverManagedIdleTimeout, попробуйте переключиться на время ожидания простоя, управляемого системой. Если это невозможно, воспользуйтесь рекомендациями в разделе WDM ниже, чтобы принять участие в DFx.

Если драйвер WDF не использует управление питанием на уровне среды выполнения, добавьте его поддержку и используйте системно управляемое время простоя. Для этого предоставьте структуру WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS в качестве входных данных для функции WdfDeviceAssignS0IdleSettings.

Требования к драйверам WDM (не минипорта)

Если ваш драйвер не использует предоставляемую WDF поддержку бездействия, управляемую системой (драйвер либо является драйвером WDF с управлением состоянием бездействия самим драйвером, либо драйвером WDM), он все равно может получить поддержку DFx, зарегистрировавшись в PoFx. В этом сценарии драйвер регистрируется в PoFx путем реализации:

Укажите указатели на эти обратные вызовы в структуре PO_FX_DEVICE_V3 , входной в функцию PoFxRegisterDevice .

Чтобы получить поддержку DFx, драйвер должен:

  • PO_FX_DIRECTED_POWER* Предоставление обратных вызовов при регистрации для PoFx
  • Вызов PoFxReportDevicePoweredOn из функции обратного вызова PO_FX_DIRECTED_POWER_UP_CALLBACK при возврате из простоя. Если это драйвер WDF, он может задать флаг, а затем в EvtDeviceD0Entry проверить флаг и вызвать PoFxReportDevicePoweredOn.
  • Вызов PoFxReportDevicePoweredOn при возобновлении из перехода Sx. Если это драйвер WDF, необходимо предварительно обработать IRP_MN_SET_POWER. Обратный вызов предварительной обработки должен выполняться только в случае Parameters.Power.Type == SystemPowerState. Так как устройство может оставаться в состоянии Dx в течение всего цикла сна и возобновления, вышеуказанный подход проверки состояния флага в EvtDeviceD0Entry не будет работать. Вместо этого функция обратного вызова события EvtDeviceWdmIrpPreprocess должна вызывать IoSetCompletionRoutine, чтобы задать рутин IoCompletion и из рутина завершения вызвать PoFxReportDevicePoweredOn.

Пример

В следующем примере показан вариант самостоятельной регистрации, описанный выше:

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

Если вы указали драйвер PO_FX_VERSION_V1 ранее, обратите внимание, что структуры PO_FX_DEVICE_V3 используют PO_FX_COMPONENT_V2 для структуры массива компонентов.

Требования к драйверам минипорта

Для классов устройств, которые соответствуют модели драйвера порта или минипорта, системные драйверы портов обычно управляют политикой энергопотребления. Большинство мини-портов, как ожидается, не требуют каких-либо изменений кода для участия в DFx, так как соответствующий драйвер порта, как ожидается, будет обрабатывать поддержку DFx.

Руководство по минипортам сторонних производителей KS.sys

Начиная с Windows 10 версии 2004 (также известной как 20H1 или сборка 19041), KS.sys по умолчанию отказывается от DFx и связанных требований HLK. Третьи мини-порты KS.sys могут участвовать в DFx и связанном HLK, зарегистрировавшись в PoFx и добавив ключ реестра KsDFxSupportEnable в файл INF.

Драйвер может зарегистрировать себя в PoFx с помощью реализации, указанной в этом разделе. Кроме того, в разделе директивы AddReg необходимо добавить следующую строку.

HKR, , KSDFxSupportEnable, 0x00010001, 1

Раздел AddReg можно вызвать с помощью раздела [DDInstall.HW] устройства или раздела установки службы драйвера. Добавление его в раздел [DDInstall.HW] изменяет только это конкретное устройство. Это полезно, если один и тот же драйвер используется для различных сочетаний VID/PID, но DFx необходимо включить только для конкретного устройства.

Добавление секции AddReg в [service-install-section] для активации режима DFx на всех устройствах, использующих этот драйвер.

Тестирование

Корпорация Майкрософт предоставляет три теста для DFx: тест с одним устройством в комплекте драйверов Windows , предназначенный для тестирования пользовательских устройств, теста HLK на уровне устройства и теста HLK на уровне системы, предназначенного для тестирования всех устройств в системе.

Тест с одним устройством доступен в рамках средства PwrTest , который поставляется с WDK. Чтобы получить к нему доступ, запустите средство с параметром /directedfx. Дополнительные сведения см. в разделе "Сценарий PwrTest DirectedFx".

Сведения о тестах HLK см. на следующих страницах:

Тестирование DFx после перехода в состояние S4 рекомендуется для выявления случаев, когда драйвер может неправильно вызывать PoFxReportDevicePoweredOn после выхода из состояния S4.

Переходы DFx и S-state

  • Целевое состояние D для переходов DFx должно соответствовать тому, что для среды выполнения D3 (RTD3), которое может отличаться от целевого состояния D для переходов S3/S4. Рассмотрим сценарий, в котором устройство вводит D2 для RTD3, но вводит D3 для S3/S4. В этом случае целевое состояние D для DFx должно быть D2.
  • Аналогичным образом, поведение "arm-for-wake" для DFx должно быть аналогичным тому, как для RTD3, что может отличаться от используемого в переходах S3/S4. Например, устройство может перейти в режим D2 с поддержкой пробуждения для RTD3, но перейти в режим D3 без поддержки пробуждения для S3/S4. В этом сценарии переходы DFx также должны входить в состояние D2/готовности к пробуждению.

DFx и среда выполнения D3 (RTD3)

  • При использовании RTD3 устройство обычно переходит в состояние с более низким энергопотреблением, когда находится в режиме ожидания. При поступлении новой задачи устройство немедленно выходит в состояние D0. При использовании DFx устройство должно продолжать оставаться в целевом D-состоянии (и откладывать новую работу в очередях), пока PoFx не направит его на восстановление питания.

См. также