通过

对 ACPI 服务使用 PEP

  • 项目

本主题提供有关将平台扩展插件 (PE) 用于 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) 提供了将 ACPI 资源转换为 BIOS 资源的PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES帮助程序例程。

PEP 负责计划无法同步执行的工作以响应来自 PoFx 的 ACPI 通知，但使用的方法由 PEP 开发人员确定。 通常，PEP 会在某个内部队列上对工作进行排队，然后根据需要启动工作线程。 此外，工作可能需要等待某些外部事件 (例如设备中断) ，并将在该事件的上下文中进行处理。 工作完成后，PEP 可以通过调用 PEP_KERNEL_INFORMATION_STRUCT_V3-RequestWorker> () 来请求 PoFx 查询工作。 作为响应，PoFx 将为实现 DPM 通知处理程序 (AcceptDeviceNotification) 的 PE 发送PEP_DPM_WORK通知，或者为实现仅 ACPI 通知处理程序的 PE 发送 PEP_NOTIFY_ACPI_WORK通知 ， (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 通知