Usando PEPs para serviços ACPI

Este tópico fornece informações sobre como usar PEPs (plug-ins de extensão de plataforma) para serviços ACPI.

Os PEPs fornecem métodos ACPI dinâmicos de runtime. As tabelas estáticas (FADT, MADT, DBG2 etc.) devem ser implementadas no firmware ACPI, bem como na hierarquia de dispositivos DSDT/SSDT.

Os PEPs devem ser usados para métodos de gerenciamento de energia fora do SoC. Como são binários instaláveis, eles podem ser atualizados on-the-fly em vez do firmware ACPI que requer um flash de firmware. Isso significa que você pode melhorar seu código de gerenciamento de energia em plataformas que já enviou postando um driver atualizado no Windows Update. O gerenciamento de energia era a intenção original para PEPs, mas eles podem ser usados para fornecer ou substituir qualquer método arbitrário de runtime do ACPI.

PePs não desempenham nenhum papel na construção da hierarquia de namespace acpi porque a hierarquia de namespace deve ser fornecida no DSDT de firmware. Quando o driver ACPI avaliar um método em runtime, ele verificará os métodos implementados pelo PEP para o dispositivo em questão e, se presente, ele executará o PEP e ignorará a versão do firmware. No entanto, o próprio dispositivo deve ser definido no firmware.

Fornecer gerenciamento de energia usando PEPs pode ser muito mais fácil de depurar do que o código escrito para o firmware ACPI devido às ferramentas disponíveis. As ferramentas para depuração de firmware ACPI não são familiares para a maioria e as opções de ferramenta são limitadas. Por outro lado, os PEPs são desenvolvidos como drivers do Windows para que os desenvolvedores possam usar qualquer ferramenta de desenvolvimento e depuração com as quais eles estão mais confortáveis.

Ao usar um PEP no lugar de um serviço ACPI, nenhuma ação ou operação especial é necessária para reivindicar a função do serviço. Quando um método é implementado no PEP, o Windows o usará automaticamente. Se uma versão de firmware do mesmo método no mesmo dispositivo for fornecida, ela será ignorada.

PEPs são carregados muito cedo para que seus serviços estejam disponíveis para o driver do dispositivo. Além disso, a camada de abstração por meio do Windows foi projetada para ser transparente para drivers de dispositivo. O driver deve esperar poder interagir com seus métodos ACPI como se um PEP não estivesse em uso.

Ao usar o PEP para serviços de DPM (gerenciamento de energia de dispositivo) e ACPI, é recomendável usar identificadores PEP separados, mas isso é apenas uma questão de preferência. Ao compartilhar o identificador, o DPM e o estado da ACPI podem ser rastreados facilmente para um dispositivo porque o identificador é o mesmo. No entanto, lidar com o gerenciamento de tempo de vida é um pouco mais complicado. O PEP precisará fornecer a contagem de referência para o identificador para garantir que ele só seja excluído depois que os serviços DPM e ACPI tiverem sido derrubados para esse identificador (ou seja, PEP_DPM_UNREGISTER_DEVICE e PEP_NOTIFY_ACPI_UNREGISTER_DEVICE foram recebidos nesse identificador). Quando diferentes identificadores forem usados, o DPM e o estado da ACPI serão rastreados separadamente, mas o gerenciamento de tempo de vida é mais simples. Nesse caso, o identificador pode ser destruído quando a notificação de cancelamento de registro correspondente for enviada.

Para simplificar o processo de trabalho com recursos de ACPI, a PoFx (estrutura de gerenciamento de energia) fornece a rotina auxiliar PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES para converter recursos de ACPI em recursos do BIOS.

PePs são responsáveis por agendar trabalhos que não podem ser executados de forma síncrona em resposta a uma notificação de ACPI da PoFx, mas o método usado é determinado pelo desenvolvedor pep. Normalmente, o PEP enfileirará o trabalho em alguma fila interna e iniciará um thread de trabalho, se necessário. Também é possível que o trabalho precise aguardar algum evento externo (por exemplo, interrupção do dispositivo) e será processado no contexto desse evento. Depois que o trabalho for feito, um PEP poderá solicitar a PoFx para consultar o trabalho invocando PEP_KERNEL_INFORMATION_STRUCT_V3-RequestWorker>(). Em resposta, a PoFx enviará uma notificação PEP_DPM_WORK para PEPs que implementam o manipulador de notificação do DPM (AcceptDeviceNotification) ou uma notificação PEP_NOTIFY_ACPI_WORK para PEPs que implementam o manipulador de notificação somente ACPI (AcceptAcpiNotification).

Tabelas de descrição do 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
Notificações de ACPI