Vorbreiten der Hardware für den modernen Standbymodus

Beim Eintritt in den modernen Standby müssen Hardwarekomponenten für den Übergang in den Low-Power-Betrieb vorbereitet werden. Nachdem Softwarekomponenten und Apps für einen niedrigen Energieverbrauch vorbereitet wurden, müssen die Hardwarekomponenten, einschließlich ihrer Softwaregerätetreiber, ähnlich auf den niedrigeren Energieverbrauch vorbereitet werden.

Im Rest dieses Artikels wird erläutert, wie die Geräte außerhalb und innerhalb des System-on-a-Chip (SoC) für den Betrieb in einem Energiesparmodus vorbereitet werden, nachdem die Hardwareplattform in den Standbymodus wechselt.

Hardware-Übergang in den Energiesparmodus

Alle Geräte außerhalb des SoC und innerhalb des SoC müssen in einen Energiesparmodus wechseln, um im Ruhezustand eine lange Akkulaufzeit zu erreichen. Nachdem eine Hardwareplattform in den Energiesparmodus wechselt, wechseln die Geräte in der Plattform in einem geordneten Prozess in den Energiesparmodus, der mit den Geräten außerhalb des SoC beginnt.

Zunächst müssen alle Geräte außerhalb des SoC oder Core-Siliziums in einen Energiesparmodus wechseln. Der Energiemodus kann ein taktgesteuerter Ruhezustand sein – beispielsweise das Versetzen eines I²C-verbundenen Touch-Controllers in einen Schlafmodus. Oder der Strommodus kann ein power-gated, 0-Watt-Zustand namens D3cold sein. Eine über USB angeschlossene Webkamera wechselt während des modernen Standbymodus häufig zu D3cold. Weitere Informationen finden Sie unter Unterstützung von D3cold für USB-Geräte.

Jede Geräteklasse und jeder Verbindungsbus hat seine eigene Terminologie und Anforderungen für den Übergang eines Geräts in den Modus mit dem niedrigsten Stromverbrauch. Es ist jedoch wichtig, dass ein Systemdesigner für jedes Gerät auf der Plattform während des modernen Standby einen Betriebsmodus mit geringem Stromverbrauch plant. Die Akkulaufzeit des Systems und die Fähigkeit, das SoC selbst in einen Energiesparmodus zu versetzen, hängen von der korrekten Energieverwaltung jedes Geräts außerhalb des SoC selbst ab.

Als nächstes werden Netzwerk- und Funkgeräte in einen Energiesparmodus für den Ruhezustand versetzt. Während des Ruhezustands werden diese Geräte häufig noch mit Strom versorgt, um die Konnektivität aufrechtzuerhalten, und sie müssen den SoC bei Bedarf aufwecken. Kommunikations- und Funkgeräte treten typischerweise in den Niedrigleistungszustand D2/D3 ein, obwohl der Eintritt in jeden Zustand geräteklassenspezifisch und busspezifisch ist.

Nachdem alle Geräte außerhalb des SoC, einschließlich Kommunikationsgeräten, heruntergefahren wurden, werden die Hostcontroller auf dem SoC ausgeschaltet. Fast jeder SoC verfügt über USB-, I²C-, GPIO-, SDIO- und UART-Hostcontroller. Jede dieser Komponenten auf dem SoC muss ausgeschaltet werden, damit das SoC in einen Energiesparmodus wechselt.

Der Prozess zum Vorbereiten der Hardware für den Energiesparmodus während des Ruhezustands kann als umgekehrte Pyramide visualisiert werden, wie im folgenden Diagramm dargestellt. Die niedrigste Leistung wird erreicht, wenn der gesamte SoC-Chip ausgeschaltet wird, aber dies kann nur geschehen, nachdem jeder Satz von Geräten darüber in der Pyramide ausgeschaltet wurde.

Herunterschalten der Geräte außerhalb des SoC

Jedes Gerät außerhalb des SoC-Chips muss für zwei Hauptziele in einen Energiesparmodus wechseln:

• Reduzieren Sie den Stromverbrauch des Geräts.
• Lassen Sie das SoC selbst herunterfahren, indem Sie dem On-SoC-Hostcontroller, mit dem das Gerät verbunden ist, erlauben, heruntergefahren zu werden.

Die Methode zum Herunterfahren jedes Geräts außerhalb des SoC variiert je nach Geräteklasse und angeschlossenem Bus.

Einige Geräte außerhalb des SoC werden in einem 0-Watt-, no-power-verbrauchten Zustand namens D3cold platziert. Gängige Geräte für D3cold sind Kameras und Sensoren. Der Treiber muss den Registerzustand des Geräts speichern und das Gerät dann in den D3-Leistungszustand überführen. Die Stromversorgung wird von der ACPI-Firmware entfernt, indem eine GPIO-Leitung umgeschaltet oder eine Stromschiene vom Power-Management-IC (PMIC) ausgeschaltet wird.

Einige Geräte außerhalb des SoC werden in einen stromsparenden Leerlaufmodus versetzt, in dem der Registerstatus beibehalten wird, oder das Gerät ist möglicherweise einfach taktgesteuert. Beispielsweise verfügen viele Touch-Controller über einen taktgesteuerten Zustand, der weniger als 1 Milliwatt Strom verbraucht. Die typischen Vorteile der Verwendung eines taktgesteuerten Zustands sind eine schnellere Einschaltzeit und niedrigere Kosten, da das Gerät nicht an eine schaltbare Stromschiene angeschlossen werden muss.

Im Allgemeinen muss jedes Gerät außerhalb des SoC in der Lage sein, in einen Energiesparmodus zu wechseln, der weniger als 1 Milliwatt Strom verbraucht. Geräte, die diesen Leistungspegel nicht mit einem internen Clock-Gated-Zustand erreichen können, sollten Power-Gating über D3cold implementieren.

Netzwerk- und Funkgeräte sind die bemerkenswerte Ausnahme von der 1-Milliwatt-Richtlinie. Netzwerk- und Funkgeräte benötigen möglicherweise mehr Strom, um eine Verbindung zum Netzwerk aufrechtzuerhalten oder drahtlose Geräte abzuhören. Einige Systemdesigner bezeichnen diese Energiezustandsübergänge als Laufzeit D3 (RTD3).

Directed Power Management für PCIe-Geräte

PCIe-Karten außerhalb des SoC müssen einen gerichteten Energie-Management-Mechanismus namens Device-S4 aktivieren, um sicherzustellen, dass sie einen Niedrigleistungsmodus eingeben können. Wenn ein Benutzer ohne Device-S4 ein Gerät an einen PCIe-Root-Port mit benutzerzugänglichen Steckplätzen auf einem Desktop-Modern-Standby-System anschließt und der Treiber für das Gerät Runtime D3 (RTD3) nicht unterstützt, kann das PCIe-Gerät das System verhindern vom Eindringen in DRIPS. Um dieses Problem zu vermeiden, müssen OEMs die Root-Ports des PCIe-Geräts auf Device-S4 umstellen. Damit Device-S4 für ein bestimmtes PCIe-Gerät aktiviert werden kann, müssen die folgenden Anforderungen erfüllt sein:

1. Der übergeordnete PCIe-Stammport für das Gerät muss als Einschränkung für DRIPS angegeben werden.
2. Der übergeordnete PCIe-Root-Port muss beim D0->D3-Übergang des Root-Ports eine grundlegende Geräterücksetzung für alle untergeordneten Geräte nach dem Root-Port anwenden und die grundlegende Geräterücksetzung für diese Kinder beim D3->D0-Übergang deaktivieren. Weitere Informationen zu PCIe Fundamental Resets finden Sie in Abschnitt 6.6.1 der PCI Express Base Specification. Die Anwendung des grundlegenden Zurücksetzens kann durch ergänzende ACPI-Mechanismen bereitgestellt werden. Weitere Informationen finden Sie in diesem Leitfaden zu PCI Energieverwaltung. Um anzuzeigen, dass die Plattform diese grundlegende Reset-Anforderung erfüllt, muss die Firmware _DSD mit Unterstützung für GUID {FDF06FAD-F744-4451-BB64-ECD792215B10} definieren. Ohne dies werden Directed DRIPS für Geräte unter diesem PCIe-Root-Port nicht ausgelöst. Weitere Informationen finden Sie in den ACPI-Gerätespezifischen Daten (_DSD) für PCIe-Stammports.
3. Energieressourcen müssen für einen bestimmten PCIe-Root-Port eindeutig sein, d.h. nicht mit anderen Root-Ports geteilt.

Bitte beachten Sie, dass PCIe-Karten, die Compatibility Support Modules (CSM) erfordern, in modernen Standby-Systemen nicht funktionieren. CSM wird im BIOS auf Modern Standby-Systemen aufgrund der UEFI Secure Boot-Anforderung nicht unterstützt. Weitere Informationen finden Sie unter der Windows-Hardwarekompatibilitätsprogrammspezifikation.

Für weitere Informationen zur Energieverwaltung für bestimmte Geräteklassen werden Systemdesigner ermutigt, die gerätespezifische Energieverwaltung für modernen Standby sowie die gerätespezifische Dokumentation zu Microsoft Collaborate zu lesen.

Herunterschalten von Netzwerkgeräten

Das Herunterfahren der Netzwerk- und Funkgeräte ist ein weiterer wichtiger Teil der Vorbereitung der Hardware für den Betrieb mit geringem Stromverbrauch im Ruhezustand. Netzwerk- und Funkgeräte unterscheiden sich von anderen Geräten außerhalb des SoC, da sie bei eingeschalteter Stromversorgung eingeschaltet bleiben müssen, um nach interessanten Ereignissen zu lauschen und das SoC zu aktivieren. Beispielsweise muss das Wi-Fi-Radio in der Lage sein, auf Pakete zu lauschen, die mit WoL-Mustern übereinstimmen, und den SoC zu aktivieren, wenn ein passendes Paket erkannt wird.

Windows versetzt Netzwerkgeräte während des Ruhezustands in den D2/D3-Zustand, wenn erwartet wird, dass sie den SoC aufwecken. Der Windows-Netzwerkstapel konfiguriert WoL-Muster und Protokollabladungen, bevor er das Gerät in den D2/D3-Zustand mit geringem Stromverbrauch versetzt. Alle Netzwerkgeräte, einschließlich Wi-Fi, mobiles Breitband (MBB) und kabelgebundenes Ethernet, müssen in der Lage sein, während des Ruhezustands in den D2/D3-Zustand überzugehen. Wenn kein Netzwerkgerät zum Reaktivieren des Systems erforderlich ist, versetzt Windows das Gerät in den D3-Zustand. Das Netzwerkgerät kann in den D3-Zustand versetzt werden, wenn der Benutzer den Flugmodus aktiviert oder das spezifische Netzwerkgerät deaktiviert hat.

Jedes Gerät verfügt über eine andere physikalische Methode, um den SoC aus seinem niedrigsten Energiemodus zu reaktivieren. Von Azure Netzwerkgeräten auf SDIO oder UART wird erwartet, dass sie eine GPIO-Leitung zum Aufwecken des SoC signalisieren. Es wird erwartet, dass Azure Netzwerkgeräte, die über USB oder HSIC verbunden sind, In-Band-USB-Wiederaufnahmesignalisierung verwenden, um den SoC zu aktivieren. Azure Netzwerkgeräte auf PCI- oder PCIe-Bussen werden erwartet, dass die In-Band-PME-Signalisierung verwendet wird, um die SoC zu aktivieren.

Außerdem wird erwartet, dass ein Funkgerät, wie beispielsweise ein Bluetooth- oder NFC-Gerät (Near Field Communications), in den D2-Zustand übergeht, wenn der Benutzer das Funkgerät für dieses Gerät eingeschaltet hat. Im D2-Zustand lauscht ein Bluetooth-Radio auf Eingabeereignisse von gekoppelten Mäusen und Tastaturen. Wenn ein Eingabeereignis erkannt wird, schaltet das Bluetooth-Radio eine mit dem SoC verbundene GPIO-Leitung um, wodurch das SoC aus seinem Energiesparmodus reaktiviert wird.

Jedes Netzwerk- oder Funkgerät hat seine eigene Implementierung des Herunterfahrens für modernen Standby. Systemdesignern wird empfohlen, die geräteklassenspezifischen Dokumente auf der Microsoft Collaborate-Website zu lesen.

Herunterfahren von On-SoC-Hostcontrollern

Nachdem alle Geräte außerhalb des SoC, einschließlich Netzwerk- und Funkgeräte, heruntergefahren wurden, müssen die Hostcontroller, an die die Geräte angeschlossen sind, heruntergefahren werden. Allgemeine Hostcontroller umfassen USB, PCI, SDIO, GPIO und I²C.

Der Treiber für jeden Host-Controller kann die Hardware erst herunterfahren, nachdem alle an den Host-Controller angeschlossenen Geräte heruntergefahren wurden. Ein gängiges Beispiel ist der USB-Hostcontroller. Der USB-Host-Controller kann erst heruntergefahren werden, nachdem alle daran angeschlossenen USB-Geräte in einen selektiven Suspend-Zustand eingetreten sind. Wenn an einen USB-Host-Controller eine USB-Maus und -Tastatur angeschlossen sind, kann der Host-Controller erst heruntergefahren werden, nachdem sowohl die Maus als auch die Tastatur ausgeschaltet wurden. Wenn entweder die Maus oder die Tastatur eingeschaltet bleibt, bleibt auch der USB-Host-Controller eingeschaltet.

Alle Hostcontroller auf dem SoC müssen für den Energiesparmodus heruntergefahren werden, damit der SoC selbst heruntergefahren werden kann. Aus diesem Grund ist es wichtig, dass jedes Gerät eine Geräteenergieverwaltung durchführt. Der SoC selbst kann nur heruntergefahren werden, wenn jeder Host-Controller heruntergefahren ist. Die Host-Controller können erst heruntergefahren werden, nachdem alle mit ihnen verbundenen Geräte ausgeschaltet wurden.

Herunterfahren von CPUs und GPUs

In Bezug auf die Energieverwaltung unterscheiden sich CPUs und GPUs auf dem SoC-Chip von anderen Geräten. CPUs und GPUs werden im Rahmen des Herunterfahrens des SoC selbst heruntergefahren und können heruntergefahren werden, wenn keine Softwareaktivität auf sie abzielt.

Die meisten Softwareaktivitäten auf dem System werden durch die Vorbereitungsphasen gestoppt, die unter Vorbereiten der Software für den modernen Standby beschrieben werden. Microsoft Store-Apps werden im Rahmen der PLM-Phase angehalten. Desktopanwendungen werden als Teil des Abschlusses der DAM-Phase angehalten. Die einzigen CPU-Aktivitäten, die verbleiben, nachdem die Plattform in die Resilienzphase eintritt, sind Leerlaufvorgänge von Windows selbst. Ebenso wenig GPU-Aktivität, da alle Apps pausiert und der Bildschirm ausgeschaltet ist.

Windows verwaltet kontinuierlich den Energiezustand der CPUs im System, selbst wenn der Bildschirm eingeschaltet ist und der Benutzer mit dem PC arbeitet. Die gleiche CPU-Leistungszustandsverwaltung platziert die CPUs im Energiesparmodus während des Ruhezustands. Wenn sich alle CPUs in einem Energiesparmodus befinden und alle Hostcontroller auf dem SoC heruntergefahren wurden, kann das SoC selbst heruntergefahren werden.

Herunterfahren des SoC

Wenn alle einzelnen Hostcontroller, CPUs und GPUs auf dem SoC heruntergefahren wurden, bestimmt Windows, ob es sicher ist, den gesamten SoC selbst herunterzufahren. Der SoC-Anbieter stellt ein Power Engine Plug-In (PEP) bereit, um Windows mitzuteilen, wann der gesamte Zustand auf dem SoC gespeichert wurde, damit der SoC bereit ist, einen Energiesparmodus einzugeben. Für Intel-basierte SoCs wird der PEP-Posteingang bereitgestellt.

Jeder SoC-Anbieter hat eine andere Implementierung eines SoC-weiten Energiesparzustands. Diese Zustände sind typischerweise entweder Clock-Gated- oder Power-Gated-Zustände, in denen Speicherinhalte in Selbstaktualisierung erhalten bleiben und das System durch einen programmierbaren Timer und eine kleine Anzahl von GPIO-Pins geweckt werden kann, die sehr wenig Strom verbrauchen. Windows bezeichnet den niedrigsten SoC-Energiezustand als Deepest Runtime Idle Platform State (DRIPS).

Der DRIPS-Zustand hat immer die folgenden Eigenschaften:

• DRIPS ist der niedrigste Stromverbrauchszustand für das SoC, in dem der Speicher in einem Selbstaktualisierungsmodus erhalten bleibt.
• DRIPS ermöglicht es dem SoC, Ereignisse von Netzwerken, Radio und Eingabegeräten zu aktivieren.
• Während des DRIPS-Zustands darf kein CPU-Code ausgeführt werden.
• Wenn sich das SoC im DRIPS-Zustand befindet, verbraucht die Plattform während des Ruhezustands so wenig Strom wie möglich (mit Ausnahme von Schwankungen im Stromverbrauch, die durch Netzwerk- und Funkgeräte verursacht werden).