Freigeben über

Verwenden von PEPs für ACPI-Dienste

  • Artikel

Dieses Thema enthält Informationen zur Verwendung von Plattformerweiterungs-Plug-Ins (PEPs) für ACPI-Dienste.

PEPs stellen dynamische ACPI-Methoden zur Laufzeit bereit. 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-Energieverwaltungsmethoden verwendet werden. Da es sich um installierbare Binärdateien handelt, können sie im Gegensatz zur ACPI-Firmware aktualisiert werden, die einen Firmwareblitz erfordert. Dies bedeutet, dass Sie Ihren Energieverwaltungscode auf bereits ausgelieferten Plattformen verbessern können, indem Sie einen aktualisierten Treiber auf Windows Update veröffentlichen. Die Energieverwaltung war die ursprüngliche Absicht für PEPs, aber sie können verwendet werden, um beliebige ACPI-Laufzeitmethoden bereitzustellen oder zu überschreiben.

PEPs spielen bei der Erstellung der ACPI-Namespacehierarchie keine Rolle, da die Namespacehierarchie im Firmware-DSDT bereitgestellt werden muss. Wenn der ACPI-Treiber eine Methode zur Laufzeit auswertet, überprüft er die von PEP implementierten Methoden für das betreffende Gerät. Falls vorhanden, führt er pep aus und ignoriert die Version der Firmware. Das Gerät selbst muss jedoch in der Firmware definiert werden.

Die Bereitstellung der Energieverwaltung mithilfe von PEPs kann aufgrund der verfügbaren Tools viel einfacher zu debuggen sein als Code, der für die ACPI-Firmware geschrieben wurde. Tools zum Debuggen der ACPI-Firmware sind den meisten nicht vertraut, und die Tooloptionen sind begrenzt. Im Gegensatz dazu werden PEPs als Windows-Treiber entwickelt, sodass Entwickler alle Entwicklungs- und Debugtools verwenden können, mit denen sie am besten vertraut sind.

Bei Verwendung eines PEP anstelle eines ACPI-Diensts ist keine spezielle Aktion oder Operation erforderlich, um die Rolle des Diensts in Anspruch zu nehmen. Wenn eine Methode im PEP implementiert ist, verwendet Windows sie automatisch. Wenn eine Firmwareversion derselben Methode auf demselben Gerät bereitgestellt wird, wird sie ignoriert.

PEPs werden sehr früh geladen, damit ihre Dienste für den Gerätetreiber verfügbar sind. Darüber hinaus ist die Abstraktionsebene über Windows so konzipiert, dass sie für Gerätetreiber transparent ist. Der Treiber sollte erwarten, dass er mit seinen ACPI-Methoden interagieren kann, als ob ein PEP nicht verwendet würde.

Wenn Sie PEP sowohl für geräteseitige Energieverwaltungsdienste (DPM) als auch für ACPI-Dienste verwenden, ist es ratsam, separate PEP-Handles zu verwenden, aber dies ist nur eine Frage der Präferenz. Bei der Freigabe des Handles können DPM- und ACPI-Status für ein Gerät problemlos nachverfolgt werden, da das Handle dasselbe ist. Die Verwaltung der Lebensdauer ist jedoch etwas komplizierter. Der PEP muss die Verweiszählung für das Handle bereitstellen, um sicherzustellen, dass es erst gelöscht wird, nachdem sowohl DPM- als auch ACPI-Dienste für dieses Handle abgerissen wurden (d. h. sowohl PEP_DPM_UNREGISTER_DEVICE als auch PEP_NOTIFY_ACPI_UNREGISTER_DEVICE für dieses Handle empfangen wurden). Wenn unterschiedliche Handles verwendet werden, werden DER DPM- und ACPI-Status separat nachverfolgt, aber die Verwaltung der Lebensdauer ist 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, stellt das Power Management Framework (PoFx) die PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES Hilfsroutine bereit, um ACPI-Ressourcen in BIOS-Ressourcen zu konvertieren.

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 pep die Arbeit in eine interne Warteschlange und startet dann bei Bedarf einen Workerthread. 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 die Arbeit abzufragen, indem PEP_KERNEL_INFORMATION_STRUCT_V3-RequestWorker>() aufgerufen wird. Als Antwort sendet PoFx eine PEP_DPM_WORK Benachrichtigung für PEPs, die den DPM-Benachrichtigungshandler (AcceptDeviceNotification) implementieren, oder eine PEP_NOTIFY_ACPI_WORK Benachrichtigung für PEPs, die den acpI-only-Benachrichtigungshandler (AcceptAcpiNotification) implementieren.

ACPI-Systembeschreibungstabellen
PEP_DPM_UNREGISTER_DEVICE
PEP_NOTIFY_ACPI_UNREGISTER_DEVICE
PEP_KERNEL_INFORMATION_STRUCT_V3
PEP_DPM_WORK
PEP_NOTIFY_ACPI_WORK
RequestWorker
AcceptDeviceNotification
ACPI-Benachrichtigungen