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

В этом разделе представлена информация об использовании платформенных расширяемых плагинов (PEPs) для служб ACPI.

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

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

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

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

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

PEPs загружаются очень рано, чтобы их сервисы были доступны для драйвера устройства. Кроме того, уровень абстракции в 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.

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

таблицы ACPI системного описания
уведомления управления питанием устройств (DPM)
PEP_DPM_UNREGISTER_DEVICEPEP_NOTIFY_ACPI_UNREGISTER_DEVICEPEP_KERNEL_INFORMATION_STRUCT_V3
RequestWorker
AcceptDeviceNotification
уведомления ACPI

  • Last updated on