Udostępnij przez

Wprowadzenie do platformy zarządzania energią skierowaną

Począwszy od systemu Windows 10, wersja 1903, wersja 3 struktury zarządzania energią w czasie wykonywania (PoFx) udostępnia opcjonalny model zasilania kierowanego, Directed PoFx (DFx).

W ramach DFx system operacyjny kieruje stosy urządzeń, aby przechodziły w odpowiednie stany bezczynności o niskiej mocy, kiedy system przechodzi w tryb bezczynności i nie ma aktywatora-brokerowanej aktywności oprogramowania, umożliwiając systemowi bardziej niezawodne przejście w tryb niskiej mocy.

Celem jest zwiększenie energooszczędności systemów i zmniejszenie zużycia energii dla urządzeń z systemem Windows w różnych typach urządzeń.

Funkcja DFx jest obecnie obsługiwana tylko dla urządzeń z ograniczeniami stanu D. DFx pomija wszelkie poddrzewo urządzenia z ograniczeniem stanu F.

DFx nie wyłącza urządzeń stronicujących ani debugujących.

Wymagania dotyczące sterowników WDF (sterowniki inne niż miniport)

Sterownik usługi WDF, który jest właścicielem zasad zasilania, musi zaimplementować odpowiednie zasady S0-Idle, określając SystemManagedIdleTimeout lub SystemManagedIdleTimeoutWithHint w strukturze WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS. Pozwoli to na wyłączenie urządzenia w przypadku bezczynności. Jako dodatkowe zabezpieczenie przed awariami zasilania, sterownik może zdecydować się na DFx. Podsystem zasilania może skierować usługę WDF do wyłączenia urządzenia, jeśli istnieje ograniczenie wynikające ze stanu D i urządzenie nie zostało jeszcze wyłączone, gdy system przechodzi w stan niskiego zużycia energii w trybie nowoczesnego wstrzymania. Gdy podsystem zasilania nakazuje WDF wyłączenie zasilania urządzenia, usługa WDF zainicjuje przejście do stanu niskiego zużycia energii Dx. Jest to koncepcyjnie podobne do sposobu, w jaki usługa WDF może wyłączać urządzenie w odpowiedzi na przejście zasilania systemu do stanu Sx (gdzie x > 0). Gdy urządzenie zostało skierowane do wyłączenia przez PoFx, zarządzane zasilaniem żądania we/wy lub wywołanie WdfDeviceStopIdle nie przywrócą urządzenia do stanu włączenia D0. Aby uzyskać więcej informacji, zobacz WdfDeviceStopIdle.

Sterownik może dokonać wyboru, dodając następujący klucz rejestru do sekcji dyrektywy AddReg INF w sekcji DDInstall.HW:

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

Sterownik WDF przeznaczony dla wersji 31 lub nowszej domyślnie włączy funkcję DFx. Jeśli jest to niepożądane, sterownik może zrezygnować z funkcji DFx, ustawiając klucz rejestru na 0:

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

Sterownik WDF przeznaczony dla wersji 33 lub nowszej może również zrezygnować z funkcji DFx, ustawiając element członkowski struktury DirectedPoFxEnabledWDF_POWER_FRAMEWORK_SETTINGS na WdfFalse.

Wskazówka

Aby zainicjować strukturę WDF_POWER_FRAMEWORK_SETTINGS, sterownik powinien wywołać funkcję WDF_POWER_FRAMEWORK_SETTINGS_INIT.

Ponieważ żądanie limitu czasu bezczynności zarządzanej przez system powoduje, że usługa WDF rejestruje się w narzędziu PoFx w imieniu sterownika, sterownik nie musi rejestrować się w programie PoFx w tym scenariuszu.

Jeśli sterownik określa DriverManagedIdleTimeout, rozważ przełączenie do limitu czasu bezczynności zarządzanej przez system. Jeśli nie jest to możliwe, skorzystaj z wytycznych w poniższej sekcji WDM, aby wyrazić zgodę na korzystanie z narzędzia DFx.

Jeśli sterownik WDF nie używa zarządzania energią w czasie pracy, dodaj obsługę tego i użyj limitu czasu bezczynności zarządzanego przez system. W tym celu podaj strukturę WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS jako dane wejściowe WdfDeviceAssignS0IdleSettings.

Wymagania dotyczące sterowników WDM (innych niż miniport)

Jeśli sterownik nie korzysta z obsługi bezczynności zarządzanej przez system, dostarczanej przez WDF (sterownik jest sterownikiem WDF używającym bezczynności zarządzanej przez sterowniklub sterownikiem WDM), nadal może uzyskać obsługę DFx przez rejestrację w PoFx. W tym scenariuszu sterownik rejestruje się w narzędziu PoFx, implementując następujące elementy:

Podaj wskaźniki do tych wywołań zwrotnych w strukturze PO_FX_DEVICE_V3, która jest używana jako dane wejściowe do funkcji PoFxRegisterDevice.

Aby uzyskać obsługę systemu DFx, sterownik musi:

  • Podaj wywołania zwrotne PO_FX_DIRECTED_POWER* podczas rejestrowania w celu korzystania z rozwiązania PoFx
  • Wywołaj PoFxReportDevicePoweredOn z funkcji wywołania zwrotnego PO_FX_DIRECTED_POWER_UP_CALLBACK po przejściu z trybu bezczynności. Jeśli jest to sterownik WDF, może ustawić flagę, a następnie w EvtDeviceD0Entrysprawdź flagę i wywołaj PoFxReportDevicePoweredOn.
  • Wywołaj PoFxReportDevicePoweredOn po wznowieniu z przejścia Sx. Jeśli jest to sterownik WDF, musi przeprowadzić wstępne przetwarzanie IRP_MN_SET_POWER. Wywołanie zwrotne przetwarzania wstępnego powinno być kontynuowane tylko w przypadku Parameters.Power.Type == SystemPowerState. Ponieważ urządzenie może pozostawać w stanie Dx przez cały cykl uśpienia/wznowienia, powyższe podejście polegające na sprawdzaniu flagi w funkcji EvtDeviceD0Entry nie zadziała. Zamiast tego funkcja wywołania zwrotnego zdarzenia EvtDeviceWdmIrpPreprocess powinna skorzystać z IoSetCompletionRoutine, aby ustawić procedurę ukończenia IoCompletion, a z tej procedury wywołać PoFxReportDevicePoweredOn.

Przykład

W poniższym przykładzie pokazano opcję samodzielnej rejestracji opisanej powyżej:

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

Jeśli sterownik określił wcześniej PO_FX_VERSION_V1, należy pamiętać, że struktura PO_FX_DEVICE_V3 używa PO_FX_COMPONENT_V2 dla struktury tablicy składników.

Wymagania dotyczące sterowników miniportu

W przypadku klas urządzeń, które są zgodne z modelem sterowników portów/miniportów, sterowniki portów dostarczane przez system zwykle obsługują własność zasad zasilania. Oczekuje się, że większość miniportów nie wymaga żadnych zmian w kodzie, aby zdecydować się na DFx, ponieważ odpowiedni sterownik portu ma obsługiwać obsługę narzędzia DFx.

Wskazówki dotyczące miniportów KS.sys innych firm

Począwszy od systemu Windows 10, wersja 2004 (znana również jako 20H1 lub kompilacja 19041), KS.sys domyślnie rezygnuje z DFx i powiązanych wymagań HLK. Miniporty firm trzecich z kategorii KS.sys mogą zgłosić uczestnictwo w DFx i powiązanym HLK, rejestrując się w PoFx i dodając klucz rejestru KsDFxSupportEnable do pliku INF.

Sterownik może zarejestrować się w narzędziu PoFx przy użyciu implementacji wymienionej w tej sekcji. Ponadto w sekcji dyrektywy AddReg należy dodać następujący wiersz.

HKR, , KSDFxSupportEnable, 0x00010001, 1

Sekcja AddReg może być wywoływana przez sekcję [DDInstall.HW] urządzenia lub przez sekcję instalacyjną kierowcy [service-install-section]. Dodanie go do sekcji [DDInstall.HW] zmienia tylko to konkretne urządzenie. Jest to przydatne, jeśli ten sam sterownik jest używany dla różnych kombinacji VID/PID, ale DFx musi być włączony tylko dla określonego urządzenia.

Dodanie sekcji AddReg w sekcji [service-install-section] uruchamia DFx dla wszystkich urządzeń korzystających z tego sterownika.

Testowanie

Firma Microsoft udostępnia trzy testy dla DFx: test pojedynczego urządzenia w zestawie sterowników Windows przeznaczony do testowania urządzeń określonych przez użytkownika, test HLK na poziomie urządzenia oraz test HLK na poziomie systemu przeznaczony do testowania wszystkich urządzeń w systemie.

Test pojedynczego urządzenia jest dostępny w ramach narzędzia PwrTest dostarczanego z zestawem WDK. Aby uzyskać do niego dostęp, uruchom narzędzie za pomocą przełącznika /directedfx. Aby uzyskać więcej informacji, zobacz PwrTest DirectedFx Scenario.

Aby uzyskać informacje o testach HLK, zobacz następujące strony:

Testowanie DFx po przejściu ze stanu S4 jest zalecane w celu wykrycia wszelkich przypadków, w których sterownik może nie poprawnie wywoływać PoFxReportDevicePoweredOn po wznowieniu systemu ze stanu S4.

Przejścia technologiczne DFx i S-state

  • Docelowy stan D dla przejść DFx powinien być zgodny z tym dla środowiska uruchomieniowego D3 (RTD3), który może być inny niż docelowy stan D dla przejść S3/S4. Rozważmy scenariusz, w którym urządzenie wchodzi w D2 dla RTD3, ale wchodzi w D3 dla S3/S4. W tym przypadku docelowy stan DFx powinien mieć wartość D2.
  • Podobnie, działanie funkcji arm-for-wake dla DFx powinno odpowiadać temu dla RTD3, które może różnić się od używanego w przejściach S3/S4. Na przykład urządzenie może wejść w D2/wake-armed dla RTD3, ale wejść w D3/no-wake-armed dla S3/S4. W tym scenariuszu przejścia DFx powinny również wejść w D2/wake-armed.

DFx i środowisko uruchomieniowe D3 (RTD3)

  • W przypadku RTD3 urządzenie zazwyczaj przechodzi w stan o niższej mocy D, gdy staje się bezczynne. Jeśli pojawi się nowe zadanie, urządzenie natychmiast przechodzi do stanu D0. Dzięki funkcji DFx urządzenie powinno nadal pozostawać w docelowym stanie D (i oczekiwać na nową pracę w swoich kolejkach), dopóki PoFx nie poleci mu się ponownie zasilić.

Zobacz też

  • Last updated on