Utilisation des peps pour les services ACPI

Cette rubrique fournit des informations sur l’utilisation de plug-ins d’extension de plateforme (PEP) pour les services ACPI.

Les peps fournissent des méthodes ACPI d’exécution dynamiques. Les tables statiques (FADT, MADT, DBG2, etc.) doivent être implémentées dans le microprogramme ACPI, ainsi que dans la hiérarchie des appareils DSDT/SSDT.

Les peps sont destinés à être utilisés pour les méthodes de gestion de l’alimentation hors soC. Étant donné qu’il s’agit de fichiers binaires installables, ils peuvent être mis à jour à la volée, contrairement au microprogramme ACPI qui nécessite un flash de microprogramme. Cela signifie que vous pouvez améliorer votre code de gestion de l’alimentation sur les plateformes que vous avez déjà fournies en publiant un pilote mis à jour sur Windows Update. La gestion de l’alimentation était l’intention initiale des peps, mais elles peuvent être utilisées pour fournir ou remplacer toute méthode d’exécution ACPI arbitraire.

Les peps ne jouent aucun rôle dans la construction de la hiérarchie d’espaces de noms ACPI, car la hiérarchie d’espaces de noms doit être fournie dans le DSDT du microprogramme. Lorsque le pilote ACPI évalue une méthode au moment de l’exécution, il case activée par rapport aux méthodes implémentées par le PEP pour l’appareil en question et, le cas échéant, il exécute le PEP et ignore la version du microprogramme. Toutefois, l’appareil lui-même doit être défini dans le microprogramme.

La gestion de l’alimentation à l’aide des peps peut être beaucoup plus facile à déboguer que du code écrit pour le microprogramme ACPI en raison des outils disponibles. Les outils de débogage du microprogramme ACPI ne sont pas familiers pour la plupart et les options d’outils sont limitées. En revanche, les PEP sont développés en tant que pilotes Windows afin que les développeurs puissent utiliser les outils de développement et de débogage avec lesquels ils sont le plus à l’aise.

Lors de l’utilisation d’un peps à la place d’un service ACPI, aucune action ou opération spéciale n’est nécessaire pour revendiquer le rôle du service. Lorsqu’une méthode est implémentée dans le PEP, Windows l’utilise automatiquement. Si une version de microprogramme de la même méthode sur le même appareil est fournie, elle est ignorée.

Les peps sont chargés très tôt afin que leurs services soient disponibles pour le pilote de périphérique. En outre, la couche d’abstraction via Windows est conçue pour être transparente pour les pilotes de périphérique. Le pilote doit s’attendre à pouvoir interagir avec ses méthodes ACPI comme si un PEP n’était pas utilisé.

Lorsque vous utilisez PEP pour les services de gestion de l’alimentation des appareils (DPM) et ACPI, il est recommandé d’utiliser des handles PEP distincts, mais ce n’est qu’une question de préférence. Lors du partage du handle, les états DPM et ACPI peuvent être facilement suivis pour un appareil, car le handle est le même. Toutefois, la gestion de la durée de vie est un peu plus compliquée. Le PEP doit fournir le décompte des références pour le handle afin de s’assurer qu’il n’est supprimé qu’après que les services DPM et ACPI ont été supprimés pour ce handle (c’est-à-dire, les PEP_DPM_UNREGISTER_DEVICE et les PEP_NOTIFY_ACPI_UNREGISTER_DEVICE ont été reçus sur ce handle). Lorsque différents handles sont utilisés, l’état DPM et l’état ACPI sont suivis séparément, mais la gestion de la durée de vie des handles est plus simple. Dans ce cas, le handle peut être détruit lors de l’envoi de la notification de désinscription correspondante.

Pour simplifier le processus d’utilisation des ressources ACPI, l’infrastructure de gestion de l’alimentation (PoFx) fournit la routine d’assistance PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES pour convertir les ressources ACPI en ressources BIOS.

Les PEP sont responsables de la planification du travail qui ne peut pas être effectué de manière synchrone en réponse à une notification ACPI de PoFx, mais la méthode utilisée est déterminée par le développeur PEP. En règle générale, le pep met en file d’attente le travail sur une file d’attente interne, puis démarre un thread de travail si nécessaire. Il est également possible que le travail ait besoin d’attendre un événement externe (par exemple, une interruption de l’appareil) et qu’il soit traité dans le contexte de cet événement. Une fois le travail terminé, un pep peut demander à PoFx d’interroger le travail en appelant PEP_KERNEL_INFORMATION_STRUCT_V3-RequestWorker>(). En réponse, PoFx envoie une notification PEP_DPM_WORK pour les peps qui implémentent le gestionnaire de notification DPM (AcceptDeviceNotification) ou une notification PEP_NOTIFY_ACPI_WORK pour les peps qui implémentent le gestionnaire de notification ACPI uniquement (AcceptAcpiNotification).

Rubriques connexes

Tables de description système ACPI
PEP_DPM_UNREGISTER_DEVICE
PEP_NOTIFY_ACPI_UNREGISTER_DEVICE
PEP_KERNEL_INFORMATION_STRUCT_V3
PEP_DPM_WORK
PEP_NOTIFY_ACPI_WORK
RequestWorker
AcceptDeviceNotification
Notifications ACPI