Firmwareanforderungen für D3cold
Ab Windows 8 können Geräte auch dann in den D3cold-Energieunterzustand wechseln, wenn das System im S0-Stromzustand bleibt. In diesem Thema werden die Firmwareanforderungen für die Implementierung der D3cold-Unterstützung für ein eingebettetes Gerät beschrieben. Die folgende Diskussion soll Firmwareentwicklern helfen, es ihren eingebetteten Geräten zu ermöglichen, D3cold zuverlässig zu betreten und zu beenden.
Darüber hinaus werden die Gerätetreiberanforderungen für die Unterstützung von D3cold kurz erläutert. Weitere Informationen zur Gerätetreiberunterstützung für D3cold finden Sie unter Unterstützung von D3cold in einem Treiber.
Einführung
Geräteleistungszustände werden in der ACPI-Spezifikation und in verschiedenen Busspezifikationen definiert. Die PCI-Busspezifikation hat, seit sie das PCI-Energiemanagement eingeführt hat, den D3 -Gerätestromzustand (aus) in zwei Unterzustände unterteilt: D3hot und D3cold. Diese Unterscheidung wurde der ACPI-Spezifikation in ACPI 3.0 hinzugefügt und in ACPI 4.0 erweitert. Windows hat immer beide D3-Unterzustände unterstützt, aber Windows 7 und frühere Versionen von Windows unterstützen den D3cold-Unterzustand nur, wenn der gesamte Computer den S0 -Systemstromzustand (Arbeits-)System beendet, um in einen Ruhezustand oder Ruhezustand zu wechseln – normalerweise S3 oder S4. Ab Windows 8 können Gerätetreiber ihre Geräte in den D3cold-Zustand versetzen, auch wenn das System in S0 bleibt.
D3hot, das oft nur als "D3" bezeichnet wird, ist der "Soft-Off"-Zustand des Geräts. In diesem Zustand kann das Gerät durch einen Busscan erkannt werden, und befehle, die an das Gerät gesendet werden, können dazu führen, dass es wieder eingeschaltet wird. In D3cold werden alle Energiequellen entfernt, mit ausnahme einer geringen Energiemenge, die die Aktivierungslogik des Geräts antreibt. Bei PCI Express-Geräten (PCIe) wird beispielsweise die Standard Gerätestromquelle Vcc häufig bei einem Übergang zu D3cold deaktiviert. Das Ausschalten von Vcc kann den Energieverbrauch reduzieren und die Zeit verlängern, die eine mobile Hardwareplattform mit Akkuladung ausführen kann. Wenn sich ein Gerät in D3cold befindet, kann es nicht von einer Busüberprüfung erkannt werden und keine Befehle empfangen. Durch die Wiederherstellung der Vcc-Stromversorgung wird das Gerät in einen nicht initialisierten Zustand versetzt, der in der Regel dem D0-Zustand entspricht. Die Software muss das Gerät dann erneut initialisieren, um es in den Betriebszustand zu versetzen.
Das Einlegen eines Geräts in D3cold bedeutet nicht unbedingt, dass alle Stromquellen für das Gerät entfernt wurden. Dies bedeutet nur, dass die Standard Stromquelle, Vcc, entfernt wird. Die Hilfsstromquelle Vaux kann auch entfernt werden, wenn sie für die Aktivierungslogik nicht erforderlich ist. Ein Gerät, das möglicherweise erforderlich ist, um dem Prozessor ein Aktivierungsereignis zu signalisieren, muss jedoch in der Lage sein, genügend Strom zu ziehen, um die Aktivierungslogik zu betreiben. Beispielsweise kann eine Ethernet-Netzwerkschnittstelle Karte (NIC), deren Standard Stromquelle entfernt ist, ausreichend Strom aus dem Ethernet-Kabel ziehen. Oder die Standby-Stromversorgung einer Wi-Fi NIC kann von einer Quelle außerhalb der PCIe-Schnittstelle bereitgestellt werden. In diesem Fall kann die PCIe-Schnittstelle vollständig ausgeschaltet werden.
In der folgenden Diskussion werden eine Reihe von Anforderungen für das Aktivieren von Gerätestromzustandsübergängen auf D3cold beschrieben. Diese Anforderungen fallen in die folgenden beiden Kategorien:
Firmware- und Plattformanforderungen
Gerätetreiberanforderungen
Die erste dieser beiden Kategorien ist der Standard Schwerpunkt dieser Diskussion. Eine kurze Übersicht über die zweite Kategorie wird vorgestellt. Weitere Informationen zu Gerätetreiberanforderungen finden Sie unter Unterstützung von D3cold in einem Treiber.
Firmware- und Plattformanforderungen
In der folgenden Diskussion werden die Firmware- und Plattformanforderungen für die Aktivierung von D3cold für diese beiden Fälle vorgestellt:
Wenn das Gerät in ACPI aufgezählt wird.
Wenn das Gerät von seinem übergeordneten Bus aufgezählt wird.
Die meisten der folgenden Diskussionen sind spezifisch für PCIe. Die hier beschriebenen allgemeinen Grundsätze gelten jedoch weitgehend auch für andere Busse.
Der Übergang von D3cold zu D0 wird durch erneutes Anwenden von Vcc-Power auf das eingebettete Gerät ausgelöst. Durch erneutes Anwenden der Energie wird die Verbindung des Geräts mit dem Bus wiederhergestellt. Windows liest die Bezeichner des Geräts, um zwischen den folgenden beiden Fällen zu unterscheiden:
Ein Gerät wurde entfernt und durch ein anderes Gerät ersetzt.
Dasselbe Gerät wurde entfernt und dann erneut eingefügt.
Wenn die Bezeichner übereinstimmen, wird das Gerät vom Gerätetreiber neu initialisiert. Wenn die Bezeichner nicht übereinstimmen, entladen Windows den Gerätetreiber und erstellt einen neuen Treiberstapel für das neue Gerät. PCIe fragt z. B. die Anbieter-ID, die Geräte-ID und die Subsystem-IDs ab (die in einige Versionen der Spezifikation in Untergeräte- und Subanbieter-IDs unterteilt sind). Diese Bezeichner müssen mit denen des zuvor angeschlossenen Geräts übereinstimmen, nachdem die Stromversorgung erneut angewendet wurde (und die vom Bus angegebene Wartezeit verstreicht). Andernfalls sieht Windows das neue Gerät als anders als das vorherige Gerät an.
Fall 1: Ein eingebettetes Gerät wird in ACPI aufgelistet
Wenn ein eingebettetes Gerät nicht durch Mechanismen auffindbar ist, die durch eine Busspezifikation definiert sind, z. B. PCIe oder USB, aber das Gerät dauerhaft verbunden ist (oder zumindest die Verbindung einem bekannten Gerät zugeordnet ist), kann dieses Gerät in der Plattformfirmware von ACPI _HID und/oder _CID-Objekten beschrieben werden. Mit diesen Objekten kann das Gerät von OSPM aufgezählt werden. ("OSPM" ist ein Begriff, der in der ACPI-Spezifikation definiert ist. Es bedeutet, lose, "Software, die keine Firmware ist.") OSPM zählt ein Gerät nur auf, wenn kein Busumerator die Geräte-ID erkennen kann. Beispielsweise werden Geräte in einem ISA-Bus von OSPM aufgezählt. Darüber hinaus werden Geräte auf einem System on a Chip (SoC) häufig von ACPI aufgezählt, da sie sich auf einem nicht aufzählbaren Gewebe befinden. Beispiele für solche Geräte sind USB- und SD-Hostcontroller.
Plattformfirmware (in ACPI aufgezählt)
OSPM verwendet \_SB._OSC, um plattformweite OSPM-Funktionen an die Plattformfirmware zu übermitteln. Die Plattformfirmware muss Bit 2 im Rückgabewert \_SB._OSC festlegen, um FÜR OSPM anzugeben, dass das Gerät _PR3 unterstützt. Weitere Informationen finden Sie in Abschnitt 6.2.10.2, "Plattformweite OSPM-Funktionen" in der ACPI 5.0-Spezifikation.
Eingebettetes Gerät (nur über ACPI ermittelt)
Um D3cold zu unterstützen, sollte die Plattformfirmware die folgenden ACPI-Energieressourcenobjekte für das eingebettete Gerät implementieren:
_PR0: Dieses Objekt wertet die Leistungsanforderungen des Geräts im D0 -Gerätestromzustand (vollständig ein) aus. Der Rückgabewert ist die Liste der Energieressourcen, die das Gerät im Zustand D0 benötigt.
_PR2: Dieses Objekt wertet die Leistungsanforderungen des Geräts im D2-Gerätestromzustand aus. Der Rückgabewert ist die Liste der Energieressourcen, die das Gerät im D2-Zustand benötigt. Beachten Sie, dass Windows aus historischen Gründen erwartet, dass _PR2 immer dann vorhanden sind, wenn _PR0 vorhanden ist. Wenn D2 in der Hardware implementiert ist, listet _PR2 die für D2 benötigten Energieressourcen auf. Wenn D2 nicht implementiert ist, listet _PR2 dieselben Ressourcen auf wie _PR0.
_PR3: Dieses Objekt wertet die Energieanforderungen des Geräts im D3hot-Gerätestromzustand aus. Der Rückgabewert ist die Liste der Energieressourcen, die das Gerät im D3hot-Zustand benötigt.
Für jede Energieressource, die in einem _PRx -Objekt identifiziert wird, müssen die folgenden Steuerungsmethoden implementiert werden:
_OFF: Legen Sie die Energieressource auf den Aus-Zustand fest (schalten Sie die Ressource aus).
_ON: Legen Sie die Energieressource auf den Zustand on (Einschalten der Ressource) fest.
_STA: Dieses Objekt wird im aktuellen Ein- oder Aus-Zustand der Energieressource ausgewertet (0: aus, 1: ein).
Ein Übergang zu D3cold erfolgt, wenn ACPI die _OFF-Steuerungsmethode für die in _PR3 aufgeführten Energieressourcen ausführt. Wenn der Gerätefunktionstreiber die Unterstützung für D3cold angibt, bedeutet diese Unterstützung nicht, dass alle Übergänge zu D3 zu schnellen Übergängen zu D3cold führen. Es ist möglich, dass das Gerät für einen längeren Zeitraum in D3hot ein- und bleibt und dann entweder zu D0 zurückkehrt, ohne D3cold einzugeben, oder zu einem späteren Zeitpunkt D3cold eingibt.
Übergeordnetes Gerät (aufgelistet in ACPI)
Es ist nicht erforderlich, dass ein übergeordnetes Gerät energieverwaltet werden kann. Wenn ein übergeordnetes Gerät jedoch stromverwaltet ist, schaltet Windows dieses Gerät nie aus, wenn sich eines seiner untergeordneten Geräte (abhängige Geräte) nicht in D3 befindet.
Beispiel (in ACPI aufgezählt)
Das folgende Blockdiagramm zeigt ein eingebettetes Gerät (mit der Bezeichnung EMBD) auf einem Systembus. Die Standard Leistung (Vcc) und Hilfsleistung (Vaux) für das Gerät können unabhängig über den Block ein- und ausgeschaltet werden, der mit der Bezeichnung Power logic bezeichnet wird.
Im folgenden ASL-Codebeispiel werden die Energieressourcen beschrieben, die vom eingebetteten Gerät im vorherigen Diagramm verwendet werden. Dieses Beispiel beginnt mit einer Deklaration einer _OSC-Steuerungsmethode, die die Funktionen des Gerätetreibers beschreibt. Als Nächstes werden die beiden Energieressourcen des Geräts deklariert– die Ressourcennamen PVCC und PVAX werden den Standard- und Hilfsstromquellen des Geräts, Vcc und Vaux, zugewiesen. Schließlich werden die Energieressourcenanforderungen für jeden vom Gerät unterstützten Gerätestromzustand aufgeführt, und die Aktivierungsfunktionen des Geräts werden beschrieben.
Scope (\_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVCC,0,0) // Power resource representing the main power for the device.
// Required for the device to be fully functional (D0).
{
Name(_STA,VAR1) // Return the state of the power resource.
Method(_ON,0x0) {...} // Turn on the power resource and set VAR1 to 1.
Method(_OFF,0x0) {...} // Turn off the power resource and set VAR1 to 0.
}
PowerResource(PVAX,0,0) // Power resource representing the auxiliary power for the device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
Device(EMBD) // An ACPI-enumerated device on the processor bus that supports D3Cold
{
Name(_HID, ...)
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVCC, PVAX}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package() {PVCC, PVAX}) // If D2 is implemented in the hardware,
// list the power resources needed by D2.
// If D2 is not implemented, list the same
// resources as _PR3.
// Indicate support for D3Cold.
Name(_PR3, Package() {PVCC, PVAX}) // Power resource for D3. These will be
// turned off ONLY if drivers opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the device doesn't
// need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform is
// capable of handling wake events from this device while in S0.
// The value of this object indicates the lowest D-state this device
// can be in to trigger wake events that can be handled while the
// platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way for OSPM to
// enable and disable them. The mechanism for this depends on the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with either of the above, if wake enablement
// varies depending on the target S-state and D-state.
*/
} // End of Device EMBD
} End Scope \_SB
Fall 2: Ein eingebettetes Gerät ist busumeriert
Wenn das eingebettete Gerät einer allgemeinen Busspezifikation entspricht, z. B. PCIe oder USB, ist dieses Gerät über busdefinierte Mechanismen auffindbar, und die Stromversorgung kann teilweise oder vollständig über den Bus bereitgestellt werden. Wenn dieses Gerät nicht mit anderen Nebenband-Energieressourcen versorgt wird, ist die Standard Stromquelle des Geräts die Verbindung, die das Gerät mit dem übergeordneten Buscontroller verbindet. Bus-enumerierte Geräte können durch das _ADR-Objekt in der Definition des eingebetteten Geräts identifiziert werden. Ein _ADR-Objekt wird verwendet, um OSPM mit der Adresse eines Geräts auf dem übergeordneten Bus des eingebetteten Geräts bereitzustellen. Diese Adresse wird verwendet, um die Darstellung des Geräts (wie von der Bushardware gesehen) durch den Bus an die Darstellung des Geräts auf der Plattform zu binden (wie in ACPI-Firmware zu sehen). (Die _ADR Adresscodierung ist busspezifisch. Weitere Informationen finden Sie in Abschnitt 6.1.1, "_ADR (Adresse)" in der ACPI 5.0-Spezifikation.) Wenn dieser Mechanismus zum Einsatz kommt, muss die D3cold-Unterstützung mit dem übergeordneten Bustreiber koordiniert werden.
Wenn die Standard Stromquelle für ein eingebettetes Gerät der Link ist, der dieses Gerät mit dem übergeordneten Bus verbindet, besteht die Hauptanforderung für das Platzieren des Geräts in D3cold darin, den Link herunterzuschalten. Weitere Informationen zum Übergang zu D3cold finden Sie im Zustandsdiagramm unter Geräteleistungszustände.
Plattformfirmware (bus-enumeriert)
OSPM verwendet \_SB._OSC, um plattformweite OSPM-Funktionen an die Plattformfirmware zu übermitteln. Die Plattformfirmware muss Bit 2 im \_SB._OSC-Rückgabewert festlegen, um OSPM anzugeben, dass das Gerät _PR3 unterstützt. Weitere Informationen finden Sie im Abschnitt 6.2.10.2, "Plattformweite OSPM-Funktionen" in der ACPI 5.0-Spezifikation.
Eingebettetes Gerät (bus-enumeriert)
Es sind keine D3cold-spezifischen ACPI-Änderungen erforderlich. In diesem Fall kann, sofern der Gerätetreiber und die Plattform die Unterstützung für D3cold angegeben haben, die Busverbindung, die das eingebettete Gerät mit Strom versorgt, deaktiviert werden, wenn der übergeordnete Bus D0 verlässt und in den Low-Power-Zustand DX wechselt. Der Übergang des eingebetteten Geräts von D3hot zu D3cold erfolgt, wenn die Stromversorgung aus dem Link entfernt wird. Der Dx-Zustand, den der übergeordnete Bus eingibt, kann ein beliebiger Zustand sein, der dazu führt, dass die Verbindungsstromquelle deaktiviert wird.
Übergeordnetes Gerät (bus-enumeriert)
Der ACPI-Deskriptor für den übergeordneten Bus muss folgendes ausführen:
Implementieren Sie _S0W(Dx). Dieses Objekt gibt Dx als D-Zustand mit der niedrigsten Leistung an, aus dem das untergeordnete (eingebettete) Gerät reaktiviert werden kann, wenn sich das System im S0-Zustand befindet.
Definieren Sie Energieressourcen, um den Link darzustellen, der das untergeordnete (eingebettete) Gerät mit dem übergeordneten Bus verbindet. Darüber hinaus sollten _ON-, _OFF- und _STA-Objekte für diese Energieressource definiert werden. Das ASL-Codebeispiel, das auf diese Liste folgt, beschreibt die Verbindungsleistung als zwei Ressourcen: PVC1 und PVX1. Für jede dieser Ressourcen werden _ON, _OFF und _STA-Objekte definiert.
Wenn "Dx" (D-Zustand mit niedrigster Leistung; siehe das erste Listenelement) D3cold ist, geben Sie ein _PR3-Objekt an, das die Energieressourcen enthält, die das untergeordnete (eingebettete) Gerät für D3hot benötigt (z. B. Vcc und Vaux). Wenn für D0, D2 und D3hot die gleichen Stromquellen erforderlich sind, geben _PR0, _PR2 und _PR3 dieselben Energieressourcen an. Diese Ressourcen werden nur deaktiviert, wenn das untergeordnete Gerät in D3cold wechselt.
Aus historischen Gründen erwartet Windows, dass _PR2 immer dann vorhanden sind, wenn _PR0 vorhanden ist. Wenn D2 in der Hardware implementiert ist, listet _PR2 die für D2 erforderlichen Energieressourcen auf. Wenn D2 nicht implementiert ist, listet _PR2 die gleichen Ressourcen wie _PR0 auf.
Implementieren Sie _PR0. Die Liste der Ressourcen im _PR0 -Objekt für den übergeordneten Bus sollte die Ressourcen enthalten, die die Verbindung zwischen dem übergeordneten Bus und dem untergeordneten (eingebetteten) Gerät herstellen.
Beispiel (bus-enumeriert)
Die Beispielhardwarekonfiguration im folgenden Blockdiagramm zeigt zwei verschiedene Möglichkeiten, wie D3cold für PCIe-Geräte aktiviert werden kann. Zunächst wird ein Endpunkt (mit der Bezeichnung ENDP) mit einem PCIe-Stammport (RP01) verbunden und erhält über eine PCIe-Verbindung Hilfsstrom vom übergeordneten Gerät. Zweitens verfügt das HD-Audiogerät im Diagramm über keine Standardverbindung mit seinem übergeordneten Gerät (dem PCI-Controller mit der Bezeichnung PCI0) und wird daher ähnlich wie der ACPI-aufgezählte Fall modelliert.
Das RP01-Gerät in diesem Diagramm verfügt über eine Standard Stromquelle Vcc1 und eine Hilfsstromquelle, Vaux1. Ebenso verfügt das HD Audio-Gerät über eine Standard Stromquelle, Vcc2, und eine Hilfsstromquelle, Vaux2.
Der folgende ASL-Code beschreibt den übergeordneten Buscontroller (PCI0) und die Energieressourcen, die für die im vorherigen Diagramm dargestellten ENDP - und HD-Audiogeräte erforderlich sind.
Scope (_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVC1,0,0) // Power resource representing Vcc1 for the RP01 device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR0)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX1,0,0) // Power resource representing Vaux1 for the RP01 device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR1)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVC2,0,0) // Power resource representing Vcc2 for the HD device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX2,0,0) // Power resource representing Vaux2 for the HD device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR3)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
... // Power resources for other child devices
Device(PCI0) // The PCI root complex
{
Name(_HID, EISAID("PNP0A08")) // ACPI enumerated
Method(_OSC, 4, NotSerialized) // PCIe-specific Capabilities Check.
{
... // This must support hand-off of PCIe control to the OS.
}
... // Other (non-power) objects for this device
Device(RP01) // PCIe Root Port 1
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC1, PVX1}) // Power resources required for D0.
// Includes the Link Power for ENDP.
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC1, PVX1})
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that
// can be handled while the platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way
// for OSPM to enable and disable them. The mechanism for this depends on
// the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
Device(ENDP) // This device supports D3cold. No power-related objects
// are required.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects
} // End of Device ENDP
} // End of Device RP01
Device(HD) // A PCIe Bus0 device (HD Audio) that supports D3cold. Note that
// this case is modeled similar to the ACPI-enumerated case
// because device HD has no standard link to its parent.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC2, PVX2}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC2, PVX2})
// Indicate support for D3Cold.
Name(_PR3, Package() {PVC2, PVX2}) // Power resource for D3; These will
// be turned off ONLY if drivers
// opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that can
// be handled while the platform is in S0.
// Enable wake events (optional).
// If this device actually does generate wake events, there must be a way for
// OSPM to enable and disable them. The mechanism for this depends on the HW:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
} // End Device HD
... // Device objects for other child devices
} // End Device PCI0
} // End Scope _SB
Weitere Möglichkeiten
Die in den beiden vorherigen Beispielen gezeigten Techniken können kombiniert werden, um Konfigurationen zu unterstützen, die sowohl Busleistung als auch Seitenbandleistung verwenden.
Gerätetreiberanforderungen
Der Besitzer der Energierichtlinie für ein Gerät (in der Regel der Funktionstreiber) teilt dem Betriebssystem mit, ob der Übergang des Geräts von D3hot zu D3cold aktiviert werden soll. Der Treiber kann diese Informationen in der INF-Datei angeben, die das Gerät installiert. Oder der Treiber kann die SetD3ColdSupport-Routine zur Laufzeit aufrufen, um die Übergänge des Geräts zu D3cold dynamisch zu aktivieren oder zu deaktivieren. Durch aktivieren eines Geräts die Eingabe von D3cold garantiert ein Treiber das folgende Verhalten:
Das Gerät kann einen Übergang von D3hot zu D3cold tolerieren, wenn der Computer in S0 verbleiben soll.
Das Gerät funktioniert ordnungsgemäß, wenn es von D3cold zu D0 zurückkehrt.
Ein Gerät, das beide Anforderungen nicht erfüllt, ist nach der Eingabe von D3cold möglicherweise nicht verfügbar, bis der Computer neu gestartet wird oder in einen Ruhezustand versetzt wird. Wenn das Gerät in der Lage sein muss, ein Aktivierungsereignis aus einem Dx-Zustand mit geringem Stromverbrauch zu signalisieren, darf der Eintrag zu D3cold nur aktiviert werden, wenn der Treiber sicher ist, dass das Aktivierungssignal des Geräts in D3cold funktioniert.
Weitere Informationen finden Sie unter Unterstützen von D3cold in einem Treiber.