Uso de PEP para servicios ACPI

En este tema se proporciona información sobre el uso de complementos de extensión de plataforma (PEP) para servicios ACPI.

Los PEP proporcionan métodos ACPI dinámicos y en tiempo de ejecución. Las tablas estáticas (FADT, MADT, DBG2, etc.) deben implementarse en el firmware ACPI, así como en la jerarquía de dispositivos DSDT/SSDT.

Los PEP están diseñados para usarse para los métodos de administración de energía fuera del soC. Dado que son archivos binarios instalables, se pueden actualizar sobre la marcha en lugar del firmware ACPI que requiere un flash de firmware. Esto significa que podría mejorar el código de administración de energía en plataformas que ya ha enviado publicando un controlador actualizado en Windows Update. La administración de energía era la intención original de los PEP, pero se pueden usar para proporcionar o invalidar cualquier método en tiempo de ejecución ACPI arbitrario.

Los PEP no desempeñan ningún papel en la construcción de la jerarquía del espacio de nombres ACPI porque la jerarquía del espacio de nombres debe proporcionarse en el DSDT de firmware. Cuando el controlador ACPI evalúa un método en tiempo de ejecución, comprobará los métodos implementados del PEP para el dispositivo en cuestión y, si está presente, ejecutará el PEP y omitirá la versión del firmware. Sin embargo, el propio dispositivo debe definirse en el firmware.

Proporcionar administración de energía mediante PEP puede ser mucho más fácil de depurar que el código escrito para el firmware ACPI debido a las herramientas disponibles. Las herramientas para depurar firmware ACPI no están familiarizados con la mayoría de las opciones de herramientas y son limitadas. Por el contrario, los PEP se desarrollan como controladores de Windows para que los desarrolladores puedan usar las herramientas de desarrollo y depuración con las que estén más cómodos.

Cuando se utiliza un PEP en lugar de un servicio ACPI, no se necesita ninguna acción o operación especial para reclamar el rol del servicio. Cuando se implementa un método en el PEP, Windows lo usará automáticamente. Si se proporciona una versión de firmware del mismo método en el mismo dispositivo, se omitirá.

Los PEP se cargan muy pronto para que sus servicios estén disponibles para el controlador del dispositivo. Además, la capa de abstracción a través de Windows está diseñada para ser transparente para los controladores de dispositivos. El controlador debe esperar poder interactuar con sus métodos ACPI como si un PEP no estuviera en uso.

Al usar PEP para los servicios de administración de energía de dispositivos (DPM) y ACPI, es aconsejable usar controladores PEP independientes, pero esto es solo una cuestión de preferencia. Al compartir el identificador DPM y el estado ACPI se puede realizar un seguimiento fácilmente de un dispositivo porque el identificador es el mismo. Sin embargo, controlar la administración de la duración es un poco más complicado. El PEP deberá proporcionar recuento de referencias para el identificador para asegurarse de que solo se elimina después de que se hayan eliminado los servicios DPM y ACPI para ese identificador (es decir, tanto PEP_DPM_UNREGISTER_DEVICE comoPEP_NOTIFY_ACPI_UNREGISTER_DEVICE se han recibido en ese identificador). Cuando se usan diferentes identificadores, se realizará un seguimiento del estado DPM y ACPI por separado, pero la administración de la duración del controlador es más sencilla. En este caso, el identificador se puede destruir cuando se envía la notificación no registrada correspondiente.

Para simplificar el proceso de trabajo con recursos ACPI, el marco de administración de energía (PoFx) proporciona la rutina auxiliar de PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES para convertir recursos ACPI en recursos bios.

Los PEP son responsables de programar el trabajo que no se puede realizar sincrónicamente en respuesta a una notificación ACPI de PoFx, pero el método utilizado viene determinado por el desarrollador pep. Normalmente, el PEP pondrá en cola el trabajo en alguna cola interna y, a continuación, iniciará un subproceso de trabajo si es necesario. También es posible que el trabajo tenga que esperar algún evento externo (por ejemplo, interrupción del dispositivo) y se procesará en el contexto de ese evento. Una vez realizado el trabajo, un PEP puede solicitar a PoFx que consulte el trabajo invocando PEP_KERNEL_INFORMATION_STRUCT_V3-RequestWorker>(). En respuesta, PoFx enviará una notificación PEP_DPM_WORK para los PEP que implementan el controlador de notificaciones DPM (AcceptDeviceNotification) o una notificación de PEP_NOTIFY_ACPI_WORK para los PEP que implementan el controlador de notificaciones solo ACPI (AcceptAcpiNotification).

Temas relacionados

Tablas de descripción del sistema ACPI
PEP_DPM_UNREGISTER_DEVICE
PEP_NOTIFY_ACPI_UNREGISTER_DEVICE
PEP_KERNEL_INFORMATION_STRUCT_V3
PEP_DPM_WORK
PEP_NOTIFY_ACPI_WORK
RequestWorker
AcceptDeviceNotification
Notificaciones ACPI