Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Ab Windows 8 können Geräte den D3cold-Unterzustand auch dann eingeben, wenn das System im S0-Energiezustand verbleibt. 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, ihre eingebetteten Geräte zuverlässig in den D3cold-Zustand zu versetzen und wieder daraus zu holen.
Darüber hinaus werden die Gerätetreiberanforderungen für die Unterstützung von D3cold kurz erläutert. Weitere Informationen zur Unterstützung des Gerätetreibers für D3cold finden Sie unter Unterstützen von D3cold in einem Treiber.
Einleitung
Geräteleistungszustände werden in der ACPI-Spezifikation und in verschiedenen Busspezifikationen definiert. Die PCI-Busspezifikation hat seit der Einführung des PCI-Energiemanagements den Stromzustand des D3 (off)-Geräts in zwei Unterzustände aufgeteilt, D3hot und D3cold. Diese Unterscheidung wurde der ACPI-Spezifikation in ACPI 3.0 hinzugefügt und in ACPI 4.0 erweitert. Windows unterstützt immer beide D3-Unterzustände, aber Windows 7 und frühere Versionen von Windows unterstützen den D3cold-Unterzustand nur, wenn der gesamte Computer den S0 -Netzstromzustand (Arbeitsbetrieb) verlässt, um in einen Ruhezustand oder Ruhezustand zu gelangen – in der Regel S3 oder S4. Ab Windows 8 können Gerätetreiber ihren Geräten die Eingabe des D3cold-Zustands ermöglichen, auch wenn das System in S0 verbleibt.
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 erneut eingeschaltet wird. In D3cold werden alle Stromquellen entfernt, mit der möglichen Ausnahme einer geringen Energiemenge, um die Aufwecklogik des Geräts zu betreiben. Für PCI Express -Geräte (PCIe) wird die Hauptstromquelle des Geräts, Vcc, häufig bei einem Übergang zu D3cold deaktiviert. Das Deaktivieren von Vcc kann den Stromverbrauch reduzieren und die Zeit verlängern, die eine mobile Hardwareplattform auf einer Akkuladung ausführen kann. Wenn sich ein Gerät in D3cold befindet, kann es nicht durch einen Busscan erkannt werden und keine Befehle empfangen. Durch das Wiederherstellen des Vcc-Stroms wird das Gerät in einen nicht initialisierten Zustand verschoben, der normalerweise dem D0-Zustand entspricht. Software muss dann das Gerät erneut initialisieren, um es in den Arbeitszustand zu versetzen.
Das Platzieren eines Geräts in D3cold bedeutet nicht unbedingt, dass alle Stromquellen für das Gerät entfernt wurden . Dies bedeutet nur, dass die Hauptstromquelle, Vcc, entfernt wird. Die Hilfsstromquelle Vaux kann auch entfernt werden, wenn sie für die Wake-Logik nicht erforderlich ist. Ein Gerät, das möglicherweise erforderlich ist, um dem Prozessor ein Wake-Ereignis zu signalisieren, muss jedoch in der Lage sein, ausreichend Energie zu beziehen, um die Aufwach-Logik zu betreiben. Beispielsweise kann eine Ethernet-Netzwerkschnittstellenkarte (NIC), deren Hauptstromquelle entfernt wird, ausreichend Energie aus dem Ethernet-Kabel ziehen. Oder die Standby-Stromversorgung an eine 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 Anforderungen beschrieben, die den Übergang des Gerätestromzustands zu D3cold ermöglichen. Diese Anforderungen sind in die folgenden beiden Kategorien unterteilt:
Firmware- und Plattformanforderungen
Gerätetreiberanforderungen
Die erste dieser beiden Kategorien ist der Schwerpunkt dieser Diskussion. Eine kurze Übersicht über die zweite Kategorie wird vorgestellt. Weitere Informationen zu den Anforderungen des Gerätetreibers finden Sie unter Unterstützen 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 vom übergeordneten Bus aufgezählt wird.
Die meisten der folgenden Diskussionen sind für PCIe spezifisch. Die hier beschriebenen allgemeinen Grundsätze gelten jedoch weitgehend auch für andere Busse.
Einige Details weggelassen, wird der Übergang von D3cold zu D0 durch erneutes Anwenden der Vcc-Stromversorgung auf das eingebettete Gerät ausgelöst. Durch erneutes Anwenden von Energie wird die Verbindung des Geräts mit dem Bus effektiv wiederhergestellt. Windows liest die IDs des Geräts vor, 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 anschließend wieder eingesetzt.
Wenn die Bezeichner übereinstimmen, wird das Gerät vom Gerätetreiber erneut initialisiert. Wenn die Bezeichner nicht übereinstimmen, entlädt Windows den Gerätetreiber und erstellt einen neuen Treiberstapel für das neue Gerät. PCIe fragt beispielsweise nach der Hersteller-ID, der Geräte-ID und den Subsystem-IDs (die in einigen Versionen der Spezifikation in Sub-Geräte- und Sub-Hersteller-IDs unterteilt sind). Diese Bezeichner müssen mit denen des zuvor angeschlossenen Geräts übereinstimmen, nachdem der Strom erneut angewendet wurde (und die vom Bus angegebene Wartezeit verstrichen ist); andernfalls berücksichtigt Windows, dass sich das neue Gerät von der vorherigen unterscheidet.
Fall 1: Ein eingebettetes Gerät wird in ACPI aufgezählt.
Wenn ein eingebettetes Gerät nicht durch Mechanismen erkannt werden kann, die durch eine Busspezifikation wie PCIe oder USB definiert sind, das Gerät jedoch dauerhaft verbunden ist (oder zumindest die Verbindung einem bekannten Gerät zugeordnet ist), kann dieses Gerät in der Plattformfirmware durch ACPI-_HID- und/oder _CID-Objekte 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 listet ein Gerät nur auf, wenn keine Busenumerator die Geräte-ID erkennen kann. Beispielsweise werden Geräte auf einem ISA-Bus von OSPM aufgezählt. Darüber hinaus werden Geräte auf einem System auf einem Chip (SoC) häufig von ACPI aufgezählt, da sie sich auf nicht aufzählbarem Stoff 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 zur Plattformfirmware zu vermitteln. Die Plattformfirmware muss Bit 2 im Rückgabewert \_SB._OSC festlegen, damit OSPM erkennt, dass das Gerät _PR3 unterstützt. Weitere Informationen finden Sie unter Abschnitt 6.2.10.2, "Platform-Wide OSPM-Funktionen", in der ACPI 5.0-Spezifikation.
Eingebettetes Gerät (nur über ACPI ermittelt)
Zur Unterstützung von D3cold sollte die Plattformfirmware die folgenden ACPI-Energieressourcenobjekte für das eingebettete Gerät implementieren:
_PR0: Dieses Objekt bewertet die Leistungsanforderungen des Geräts im Leistungszustand D0 (vollständig eingeschaltet). Der Rückgabewert ist die Liste der Energieressourcen, die das Gerät im D0-Zustand benötigt.
_PR2: Dieses Objekt wertet die Energieanforderungen 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 vorhanden ist, 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.
_PR3: Dieses Objekt wertet die Leistungsanforderungen 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 beliebigen _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 " fest (Energie für die Ressource).
_STA: Dieses Objekt wertet den aktuellen Ein - oder Aus-Zustand der Energieressource aus (0: aus, 1: ein).
Ein Übergang zu D3cold erfolgt, wenn ACPI die _OFF-Kontrollmethode auf 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 wechselt und dann entweder nach D0 zurückkehrt, ohne D3cold einzugeben oder D3cold zu einem späteren Zeitpunkt einzugeben.
Übergeordnetes Gerät (in ACPI aufgezählt)
Es ist nicht erforderlich, dass ein übergeordnetes Gerät in der Lage ist, energieverwaltet zu werden. Wenn ein übergeordnetes Gerät jedoch energieverwaltet ist, wird dieses Gerät von Windows niemals heruntergeschalten, wenn eines seiner untergeordneten Geräte (abhängige Geräte) nicht in D3 enthalten ist.
Beispiel (in ACPI aufgezählt)
Das folgende Blockdiagramm zeigt ein eingebettetes Gerät (mit der Bezeichnung EMBD) auf einem Systembus. Die Hauptleistung (Vcc) und Hilfsleistung (Vaux) zum Gerät können unabhängig von dem Block mit der Bezeichnung Power logic eingeschaltet und ausgeschaltet werden.
Ein ACPI-enumeriertes eingebettetes Gerät.
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 Steuerelementmethode, 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 Haupt- und Hilfsstromquellen des Geräts zugeordnet, Vcc und Aux. Schließlich werden die Anforderungen an die Energieressource 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 busenumeriert
Wenn das eingebettete Gerät einer gemeinsamen 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 von anderen Sideband-Energieressourcen unterstützt wird, ist die Hauptstromquelle 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 eines eingebetteten Geräts identifiziert werden. Ein _ADR-Objekt wird verwendet, um OSPM die Adresse eines Geräts auf dem übergeordneten Bus des eingebetteten Geräts bereitzustellen. Diese Adresse dient dazu, die Darstellung des Geräts auf dem Bus (wie von der Bushardware gesehen) mit der Darstellung des Geräts auf der Plattform (wie von der ACPI-Firmware gesehen) zu verknüpfen. (Die _ADR Adresscodierung ist busspezifisch. Weitere Informationen finden Sie unter Abschnitt 6.1.1, "_ADR (Adresse)", in der ACPI 5.0-Spezifikation.) Wenn dieser Mechanismus eingesetzt wird, muss die D3cold-Unterstützung mit dem übergeordneten Busfahrer koordiniert werden.
Wenn die Hauptstromquelle für ein eingebettetes Gerät der Link ist, der dieses Gerät mit seinem ü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 in Device Power States.
Plattformfirmware (bus-enumeriert)
OSPM verwendet \_SB._OSC, um plattformweite OSPM-Funktionen zur Plattformfirmware zu vermitteln. Die Plattformfirmware muss Bit 2 im Rückgabewert \_SB._OSC festlegen, damit OSPM erkennt, dass das Gerät _PR3 unterstützt. Weitere Informationen finden Sie unter Abschnitt 6.2.10.2, "Platform-Wide OSPM-Funktionen", in der ACPI 5.0-Spezifikation.
Eingebettetes Gerät (busenumeriert)
Es sind keine D3cold-spezifischen ACPI-Änderungen erforderlich. Solange der Gerätetreiber und die Plattform die Unterstützung für D3cold angegeben haben, kann die Busverbindung, die Stromversorgung an das eingebettete Gerät liefert, deaktiviert werden, wenn der übergeordnete Bus D0 verlässt und in einen Low-Power-Zustand dx wechselt. Der Übergang des eingebetteten Geräts von D3hot zu D3cold tritt auf, wenn der Strom aus der Verbindung entfernt wird. Der Dx-Zustand, in den der übergeordnete Bus wechselt, kann ein beliebiger Zustand sein, der dazu führt, dass die Stromquelle der Verbindung ausgeschaltet wird.
Übergeordnetes Gerät (busenumeriert)
Der ACPI-Deskriptor für den übergeordneten Bus muss folgende Aktionen ausführen:
Implementieren sie _S0W(Dx). Dieses Objekt gibt Dx als energieeffizientesten D-Zustand an, aus dem das untergeordnete (eingebettete) Gerät aufwachen kann, wenn sich das System im S0-Zustand befindet.
Definieren Sie Energieressourcen, um die Verknüpfung darzustellen, die das untergeordnete (eingebettete) Gerät mit dem übergeordneten Bus verbindet. Darüber hinaus sollten für diese Energieressource _ON, _OFF und _STA Objekte definiert werden. Das ASL-Codebeispiel, das auf diese Liste folgt, beschreibt die Verknüpfungsleistung als zwei Ressourcen, PVC1 und PVX1. Für jede dieser Ressourcen werden _ON, _OFF und _STA Objekte definiert.
Wenn "Dx" (der D-Zustand mit niedrigster Leistung; siehe das erste Listenelement) D3cold ist, stellen Sie ein _PR3-Objekt zur Verfügung, 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 dieselben Stromquellen erforderlich sind, geben _PR0, _PR2 und _PR3 alle dieselben Energieressourcen an. Diese Ressourcen werden nur deaktiviert, wenn das nachgeordnete Gerät in den Zustand D3cold wechselt.
Aus historischen Gründen erwartet Windows, dass _PR2 vorhanden ist, 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 mit Strom versorgen, die den übergeordneten Bus mit dem untergeordneten (eingebetteten) Gerät verbindet.
Beispiel (busenumeriert)
Die Beispielhardwarekonfiguration im folgenden Blockdiagramm zeigt zwei verschiedene Möglichkeiten, wie D3cold für PCIe-Geräte aktiviert werden kann. Erstens ist ein Endpunkt (bezeichnetes ENDP) mit einem PCIe-Stammport (RP01) verbunden und empfängt hilfsstrom vom übergeordneten Gerät über eine PCIe-Verbindung. Zweitens weist das HD-Audiogerät im Diagramm keine Standardverbindung zu seinem übergeordneten Gerät (dem PCI-Controller mit der Bezeichnung PCI0) auf und wird daher ähnlich wie der ACPI-aufgezählte Fall modelliert.
Das RP01-Gerät in diesem Diagramm verfügt über eine Hauptstromquelle, Vcc1 und eine Hilfsstromquelle, Aux1. Ebenso verfügt das HD-Audiogerät über eine Hauptstromquelle, Vcc2 und eine Hilfsstromquelle, Aux2.
Der folgende ASL-Code beschreibt den übergeordneten Buscontroller (PCI0) und die Energieressourcen, die für die ENDP- und HD-Audiogeräte im vorherigen Diagramm 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 Sidebandleistung 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 bereitstellen, 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 die Aktivierung eines Geräts in 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 keine der beiden Anforderungen erfüllt, ist nach der Eingabe von D3cold möglicherweise nicht verfügbar, bis der Computer neu gestartet wird oder in den Ruhezustand wechselt. Wenn das Gerät in der Lage sein muss, ein Wake-Ereignis von jedem Dx-Zustand mit niedrigem Energieverbrauch zu signalisieren, darf der Übergang zu D3cold nicht aktiviert werden, es sei denn, der Treiber ist sicher, dass das Wakesignal des Geräts in D3cold funktioniert.
Weitere Informationen finden Sie unter Unterstützen von D3cold in einem Treiber.