为 PortCls 音频驱动程序实现 PnP 再平衡

PnP 再平衡用于某些需要重新分配内存资源的 PCI 方案中。

可以在两个主要场景中触发再平衡：

1. PCI 热插拔：用户插入设备，PCI 总线没有足够的资源来加载新设备的驱动程序。 属于此类别的一些设备示例包括 Thunderbolt、USB-C 和 NVME 存储。 在此场景中，内存资源需要重新排列和合并（重新平衡），以支持要添加的其他设备。
2. PCI 可调整大小的 BAR：成功将设备驱动程序加载到内存中后，它会请求其他资源。 一些设备示例包括高端显卡和存储设备。 有关视频驱动程序支持的详细信息，请参阅可调整大小的 BAR 支持。 本主题介绍为 PortCls 音频驱动程序实现 PnP 再平衡需要执行的操作。

Windows 10 版本 1511 和更高版本的 Windows 中提供 PnP 再平衡。

再平衡要求

如果满足以下条件，Portcls 音频驱动程序能够支持再平衡：

• 微型端口必须向 Portcls 注册 IAdapterPnpManagement 接口。
• 微型端口必须从 IAdapterPnpManagement::GetSupportedRebalanceType 返回 PcRebalanceRemoveSubdevices。
• 拓扑和 WaveRT 是支持的两种端口类型。

为了支持在有活动音频流时再平衡，portcls 音频驱动程序需要满足这两个附加要求之一。

• 驱动程序支持音频流的 IMiniportWaveRTInputStream::GetReadPacket 和 IMiniportWaveRTOutputStream 数据包接口。 这是建议的选项。

OR

• 如果驱动程序不支持流获取/写入 IMiniportWaveRT，则不得支持 KSPROPERTY_RTAUDIO_POSITIONREGISTER 和 KSPROPERTY_RTAUDIO_CLOCKREGISTER。 在此场景中，音频引擎将使用 IMiniportWaveRTStream::GetPosition。

发生再平衡时的音频流行为

如果触发再平衡，当存在活动音频流时，并且驱动程序为活动音频流提供再平衡，则所有活动音频流都将停止，并且不会自动重启它们。

IPortClsPnp COM 接口

IPortClsPnp 是端口类驱动程序 (PortCl) 向适配器公开的 PnP 管理接口。

IPortClsPnp 继承自 IUnknown，还支持以下方法：

• IPortClsPnp::RegisterAdapterPnpManagement
• IPortClsPnp::UnregisterAdapterPnpManagement

音频微型端口驱动程序可以使用 Portcls 导出或通过在 WaveRT 端口对象上公开的 IPortClsPnp COM 接口 IPortClsPnp 注册 PNP 通知接口。 使用 IPortClsPnp::RegisterAdapterPnpManagement 和 IPortClsPnp::UnregisterAdapterPnpManagement 注册和注销。

所需的 PortCls 导出 DDI

IAdapterPnpManagement 是适配器在想要接收 PnP 管理消息时应实现和注册的接口。 使用 PcRegisterAdapterPnpManagement 向 PortCls 注册此接口。 使用 PcUnregisterAdapterPnpManagement 向 PortCls 注销此接口。

所需的驱动程序 DDI

必须实现以下 IAdapterPnpManagement DDI 才能支持再平衡。

• 处理 QueryStop 时，Portcls 调用 IAdapterPnpManagement::GetSupportedRebalanceType。 微型端口会返回 PC_REBALANCE_TYPE 枚举中定义的支持的再平衡类型。

  请注意，Portcls 会在进行此调用之前获取设备全局锁，因此微型端口必须尽快执行此调用。

• IAdapterPnpManagement::PnpQueryStop 是在成功执行 QueryStop IRP 之前由 portcls 调用的。 这只是一个通知，调用不返回值。

  请注意，Portcls 会在进行此调用之前获取设备全局锁，因此微型端口必须尽快执行此调用。 当停止挂起时，Portcls 将阻止（保留）任何新的创建请求。

• 处理 CanceStop IRP 时，由 portcls 调用 IAdapterPnpManagement::PnpCancelStop。 这只是通知。 即使以前未收到 PnpQueryStop 通知，微型端口也可以接收 PnpCancelStop。 应编写微型端口以适应此行为。 例如，当 QueryStop 逻辑在 Portcls 有机会将此通知转发到微型端口之前使 IRP 失败时，就会出现这种情况。 在此场景中，PnP 管理器仍会调用 PnP 取消停止。

  请注意，Portcls 会在进行此调用之前获取设备全局锁，因此微型端口必须尽快执行此调用。 当停止挂起时，Portcls 将阻止（保留）任何新的创建请求。 当取消挂起的停止时，PortCls 将重启所有已挂起的创建请求。

• 停止所有 Ioctl 操作并将活动流从 [run|pause|acquire] 状态移动到 [stop] 状态后，Portcls 调用 IAdapterPnpManagement::PnpStop。 保存设备全局锁时不会进行此调用。 因此，微型端口有机会等待其异步操作（工作项、dpc、异步线程）并注销其音频子设备。 从此调用返回之前，微型端口必须确保已释放所有 h/w 资源。

  请注意，微型端口不得等待当前微型端口/流对象被删除，因为目前还不清楚现有音频客户端何时释放当前句柄。 在不使系统崩溃的情况下，PnpStop 线程无法永久阻止，即这是 PnP/Power 线程。

IMiniportPnpNotify

IMiniportPnpNotify 是一个可选接口，允许微型端口对象（音频子设备）接收 PnP 状态更改通知。

微型端口有机会接收他们已注册的每个音频子设备的 PnP 停止通知。 若要接收此通知，子设备必须支持 IMiniportPnpNotify。 在此接口上仅定义了 IMiniportPnpNotify::PnpStop 通知。

IMiniportPnpNotify 接口在 WaveRT 和拓扑上均可用。

请注意，由于 Portcls 会在进行此调用之前获取设备全局锁，因此微型端口必须尽快执行此调用。 当其他线程/工作项正在等待设备全局锁时，微型端口不得在处理此调用时等待其他活动，以防止死锁。 如果需要，微型端口可以在 IAdapterPnpManagement::PnpStop 调用中等待。