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 eles são binários instaláveis, eles podem ser atualizados em tempo real 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 nenhuma função na construção da hierarquia de namespace acpi porque a hierarquia de namespace deve ser fornecida no firmware DSDT. Quando o driver ACPI avalia um método em runtime, ele marcar em relação aos métodos implementados do 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 depurar 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 as ferramentas de desenvolvimento e depuração com as quais 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.

Os PEPs são carregados muito cedo para que seus serviços estejam disponíveis para o driver de 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 PEP para serviços de DPM (gerenciamento de energia do dispositivo) e ACPI, é aconselhável usar identificadores PEP separados, mas isso é apenas uma questão de preferência. Ao compartilhar o identificador, o estado do DPM e do ACPI pode ser acompanhado 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 são usados, o estado do DPM e do ACPI será rastreado separadamente, mas o gerenciamento do tempo de vida do identificador é mais simples. Nesse caso, o identificador pode ser destruído quando a notificação de cancelamento de registro correspondente é enviada.

Para simplificar o processo de trabalhar 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 acpi em recursos do BIOS.

Os 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 concluído, um PEP poderá solicitar que a PoFx consulte 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 de PEP_NOTIFY_ACPI_WORK para PEPs que implementam o manipulador de notificação somente ACPI (AcceptAcpiNotification).

Tópicos relacionados

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