Использование PEP для служб ACPI

  • Статья

В этом разделе содержатся сведения об использовании подключаемых модулей расширения платформы (PEP) для служб ACPI.

PeP предоставляют динамические методы ACPI среды выполнения. Статические таблицы (FADT, MADT, DBG2 и т. д.) должны быть реализованы в встроенном ПО ACPI, а также в иерархии устройств DSDT/SSDT.

PeP предназначены для использования для методов управления питанием вне SoC. Так как они являются устанавливаемыми двоичными файлами, их можно обновлять на лету, а не встроенное ПО ACPI, для которого требуется флэш-память встроенного ПО. Это означает, что вы можете улучшить код управления питанием на уже отправленных платформах, разместив обновленный драйвер на клиентский компонент Центра обновления Windows. Управление питанием было первоначальной целью для PEP, но их можно использовать для предоставления или переопределения любого произвольного метода среды выполнения ACPI.

PeP не играют никакой роли в построении иерархии пространства имен ACPI, так как иерархия пространства имен должна быть указана в встроенном ПО DSDT. Когда драйвер ACPI оценивает метод во время выполнения, он будет проверка с внедренными методами PEP для соответствующего устройства, и, если он имеется, он выполнит PEP и проигнорирует версию встроенного ПО. Однако само устройство должно быть определено во встроенном ПО.

Управление питанием с помощью PEP может быть гораздо проще в отладке, чем код, написанный для встроенного ПО ACPI из-за доступных средств. Средства для отладки встроенного ПО ACPI не знакомы большинству, а их возможности ограничены. В отличие от этого, PEP разрабатываются как драйверы Windows, чтобы разработчики могли использовать любые средства разработки и отладки, с которыми они наиболее удобны.

При использовании PEP вместо службы ACPI не требуется никаких специальных действий или операций, чтобы претендовать на роль службы. Если метод реализован в PEP, Windows будет использовать его автоматически. Если на том же устройстве указана версия встроенного ПО того же метода, она будет игнорироваться.

PeP загружаются очень рано, чтобы их службы были доступны для драйвера устройства. Кроме того, уровень абстракции в Windows разработан таким образом, чтобы быть прозрачным для драйверов устройств. Драйвер должен ожидать возможности взаимодействия с методами ACPI, как если бы PEP не использовался.

При использовании PEP для служб управления питанием устройств (DPM) и ACPI рекомендуется использовать отдельные дескрипторы PEP, но это только вопрос предпочтения. При совместном использовании дескриптора состояние DPM и ACPI можно легко отслеживать для устройства, так как дескриптор совпадает. Однако управление жизненным циклом обработки немного сложнее. PeP должен предоставить подсчет ссылок для дескриптора, чтобы убедиться, что он удаляется только после того, как службы DPM и ACPI были удалены для этого дескриптора (т. е. PEP_DPM_UNREGISTER_DEVICE и PEP_NOTIFY_ACPI_UNREGISTER_DEVICE были получены в этом дескрипторове). При использовании разных дескрипторов состояние DPM и ACPI будет отслеживаться отдельно, но управление жизненным циклом обработки проще. В этом случае дескриптор может быть уничтожен при отправке соответствующего уведомления об отмене регистрации.

Чтобы упростить процесс работы с ресурсами ACPI, платформа управления питанием (PoFx) предоставляет PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES вспомогательные процедуры для преобразования ресурсов ACPI в ресурсы BIOS.

PeP отвечают за планирование работы, которая не может выполняться синхронно в ответ на уведомление ACPI от PoFx, но используемый метод определяется разработчиком PEP. Как правило, PEP помещит в очередь работу в какой-то внутренней очереди, а затем запускает рабочий поток, если это необходимо. Возможно также, что работа должна дождаться какого-то внешнего события (например, прерывания устройства) и будет обрабатываться в контексте этого события. После завершения работы PEP может запросить PoFx для запроса работы, вызвав PEP_KERNEL_INFORMATION_STRUCT_V3-RequestWorker>(). В ответ PoFx отправит уведомление PEP_DPM_WORK для PEP, которые реализуют обработчик уведомлений DPM (AcceptDeviceNotification) или уведомление PEP_NOTIFY_ACPI_WORK для PEP, которые реализуют обработчик уведомлений только ACPI (AcceptAcpiNotification).

Таблицы описания системы ACPI
PEP_DPM_UNREGISTER_DEVICE
PEP_NOTIFY_ACPI_UNREGISTER_DEVICE
PEP_KERNEL_INFORMATION_STRUCT_V3
PEP_DPM_WORK
PEP_NOTIFY_ACPI_WORK
RequestWorker
AcceptDeviceNotification
Уведомления ACPI