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.
Dieses Thema enthält Informationen zur Verwendung von Plattformerweiterungs-Plug-Ins (PEPs) für ACPI-Dienste.
PEPs bieten dynamische ACPI-Laufzeitmethoden. Die statischen Tabellen (FADT, MADT, DBG2 usw.) müssen in der ACPI-Firmware sowie in der DSDT/SSDT-Gerätehierarchie implementiert werden.
PEPs sollen für Off-SoC-Energiemanagementmethoden verwendet werden. Da sie installierbare Binärdateien sind, können sie direkt im Gegensatz zu ACPI-Firmware aktualisiert werden, die einen Firmware-Flash erfordert. Dies bedeutet, dass Sie Ihren Energieverwaltungscode auf Plattformen verbessern können, die Sie bereits geliefert haben, indem Sie einen aktualisierten Treiber unter Windows Update veröffentlichen. Die Energieverwaltung war die ursprüngliche Absicht für PEPs, sie können jedoch verwendet werden, um beliebige ACPI-Laufzeitmethoden bereitzustellen oder außer Kraft zu setzen.
PEPs spielen bei der Erstellung der ACPI-Namespacehierarchie keine Rolle, da die Namespacehierarchie in der Firmware-DSDT bereitgestellt werden muss. Wenn der ACPI-Treiber eine Methode zur Laufzeit auswertet, überprüft er die implementierten Methoden des PEP für das betreffende Gerät, und wenn vorhanden, führt er den PEP aus und ignoriert die Firmwareversion. Das Gerät selbst muss jedoch in der Firmware definiert werden.
Die Fehlersuche bei der Energieverwaltung mit PEPs kann deutlich einfacher sein als bei Code, der für die ACPI-Firmware geschrieben wurde, da hierfür geeignete Werkzeuge verfügbar sind. Tools zum Debuggen der ACPI-Firmware sind den meisten nicht vertraut, und die Tooloptionen sind eingeschränkt. Im Gegensatz dazu werden PEPs als Windows-Treiber entwickelt, damit Entwickler alle Entwicklungs- und Debuggingtools verwenden können, mit denen sie am besten vertraut sind.
Wenn Sie einen PEP anstelle eines ACPI-Diensts verwenden, ist keine besondere Aktion oder Operation erforderlich, um die Rolle des Diensts geltend zu machen. Wenn eine Methode im PEP implementiert wird, verwendet Windows sie automatisch. Wenn eine Firmwareversion derselben Methode auf demselben Gerät bereitgestellt wird, wird sie ignoriert.
PEPs werden sehr früh geladen, sodass ihre Dienste für den Gerätetreiber verfügbar sind. Darüber hinaus ist die Abstraktionsebene über Windows für Gerätetreiber transparent. Der Fahrer sollte erwarten, dass er mit seinen ACPI-Methoden interagieren kann, als ob ein PEP nicht verwendet wurde.
Bei der Verwendung von PEP für gerätestromverwaltung (DPM) und ACPI-Dienste ist es ratsam, separate PEP-Handles zu verwenden, aber dies ist nur eine Frage der Vorliebe. Beim Teilen des Handles können der DPM- und der ACPI-Zustand eines Geräts problemlos nachverfolgt werden, da das Handle dasselbe bleibt. Die Verwaltung der Handle-Lebensdauer ist jedoch ein wenig komplizierter. Der PEP muss eine Referenzzählung für das Handle bereitstellen, um sicherzustellen, dass es nur dann gelöscht wird, nachdem sowohl DPM- als auch ACPI-Dienste für dieses Handle zurückgezogen wurden (d. h. sowohl PEP_DPM_UNREGISTER_DEVICE als auch PEP_NOTIFY_ACPI_UNREGISTER_DEVICE auf diesem Handle empfangen wurden). Wenn verschiedene Handles verwendet werden, wird der DPM- und ACPI-Zustand separat nachverfolgt, die Verwaltung der Lebensdauer der Handles ist jedoch einfacher. In diesem Fall kann das Handle zerstört werden, wenn die entsprechende Benachrichtigung zur Aufhebung der Registrierung gesendet wird.
Um die Arbeit mit ACPI-Ressourcen zu vereinfachen, bietet das Power Management Framework (PoFx) die PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES Hilfsroutine zum Konvertieren von ACPI-Ressourcen in BIOS-Ressourcen.
PEPs sind für die Planung von Arbeiten verantwortlich, die nicht synchron als Reaktion auf eine ACPI-Benachrichtigung von PoFx ausgeführt werden können, aber die verwendete Methode wird vom PEP-Entwickler bestimmt. In der Regel stellt der PEP die Aufgaben in eine interne Warteschlange und startet dann bei Bedarf einen Arbeitsthread. Es ist auch möglich, dass die Arbeit auf ein externes Ereignis (z. B. Geräteunterbrechung) warten muss und im Kontext dieses Ereignisses verarbeitet wird. Sobald die Arbeit abgeschlossen ist, kann ein PEP PoFx anfordern, um nach Arbeit zu fragen, indem es PEP_KERNEL_INFORMATION_STRUCT_V3->RequestWorker() aufruft. Als Antwort sendet PoFx eine PEP_DPM_WORK Benachrichtigung für PEPs, die den DPM-Benachrichtigungshandler (AcceptDeviceNotification) oder eine PEP_NOTIFY_ACPI_WORK Benachrichtigung für PEPs implementieren, die den ACPI-only-Benachrichtigungshandler (AcceptAcpiNotification) implementieren.
Zugehörige Themen
ACPI-Systembeschreibungstabellen
DPM-Benachrichtigungen (Device Power Management)
PEP_DPM_UNREGISTER_DEVICEPEP_NOTIFY_ACPI_UNREGISTER_DEVICEPEP_KERNEL_INFORMATION_STRUCT_V3
RequestWorker
AcceptDeviceNotification
ACPI-Benachrichtigungen