通过

设备管理命名空间对象

  • 项目

ACPI 5.0 规范定义了几种可用于管理设备的命名空间对象。 例如，设备识别对象包含连接到总线（如 I2C）的设备的识别信息，这些总线不支持子设备的硬件枚举。 其他类型的命名空间对象可以指定系统资源、描述设备依赖项，并指出哪些设备可以禁用。

Windows 中的设备标识

Windows 即插即用会根据设备枚举器提供的设备标识符查找和加载设备驱动程序。 枚举器是知道如何从设备中提取标识信息的总线驱动程序。 某些总线（如 PCI、SD 和 USB）具有硬件定义的机制来执行此提取。 对于不具有此机制的总线（如处理器总线或简单外围总线），ACPI 会定义命名空间中的标识对象。

Windows ACPI 驱动程序 Acpi.sys 会将这些对象中找到的值组合到各种设备标识符字符串中，这些字符串可以专门或一般地标识设备，具体取决于驱动程序的需求。 为标识 ACPI 枚举设备而创建的一些字符串模式包括：

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

可以打开设备管理器并检查已枚举设备的硬件 ID 和兼容 ID属性，从而查看 Windows 为设备创建的设备标识符。 可在 INF 文件中指定用以标识要为设备加载的驱动程序的每个字符串。 INF 匹配顺序是从最具体的硬件标识符（最优先的驱动程序）到最不具体的标识符（最不优先的驱动程序），以便更了解设备的特定功能的驱动程序可以替换那些不太具体（因此仅支持一部分设备功能）的驱动程序。

设备标识符只能用于 INF 匹配，并且不应由设备驱动程序分析或处理。 如果设备驱动程序需要识别为哪个特定硬件加载了该驱动程序，建议的方法是在安装时让 INF 文件设置适当的注册表项。 然后，驱动程序可以在初始化期间访问这些项，以获取所需的信息。

ACPI 中的设备标识

硬件 ID (_HID)

在 ACPI 中标识设备的最低要求是 Hardware ID (_HID) 对象。 _HID 会返回格式为“ABC[D]xxxx”的字符串，其中“ABC[D]”是用于标识设备制造商的 3 个字符或 4 个字符的字符串（“供应商 ID”），xxxx 是用于标识该供应商制造的特定设备的十六进制数字（“设备 ID”）。 供应商 ID 在整个行业必须是唯一的。 Microsoft 会分配这些字符串以确保它们是唯一的。 可以从即插即用 ID - PNPID 请求获取供应商 ID。

ACPI 5.0 还支持在 _HID 和其他标识对象中使用 PCI 分配的供应商 ID，因此你可能不需要从 Microsoft 获取供应商 ID。 有关硬件标识要求的详细信息，请参阅 ACPI 5.0 规范的第 6.1.5 节“_HID（硬件 ID）”。

兼容 ID (_CID)

Microsoft 已为与 Windows 附带的内置驱动程序兼容的设备保留供应商 ID“PNP”。 Windows 定义了许多设备 ID 以便与此供应商 ID 搭配使用，可用于加载设备的由 Windows 提供的驱动程序。 兼容 ID (_CID) 是一个单独的对象，用于返回这些标识符。 Windows 始终首选硬件 ID（由 _HID 返回）而非 INF 匹配和驱动程序选择中的兼容 ID（由 _CID 返回）。 如果供应商提供的特定于设备的驱动程序不可用，则此首选项允许将 Windows 提供的驱动程序视为默认驱动程序。 下表中的兼容 ID 是新建的，用于 SoC 平台。

兼容 ID 说明
PNP0C40 Windows 兼容的按钮数组
PNP0C50 符合 HID over-I2C 的设备
PNP0C60 可转换笔记本电脑显示器传感器设备
PNP0C70 停靠传感器设备
PNP0D10 符合 XHCI 的 USB 控制器（具有标准调试）
PNP0D15 符合 XHCI 的 USB 控制器（没有标准调试）
PNP0D20 符合 EHCI 的 USB 控制器（没有标准调试）
PNP0D25 符合 EHCI 的 USB 控制器（具有标准调试）
PNP0D40 符合 SDA 标准的 SD 主机控制器
PNP0D80 与 Windows 兼容的系统电源管理控制器

子系统 ID (_SUB)、硬件修订 (_HRV) 和类 (_CLS)

ACPI 5.0 定义了 _SUB、_HRV 和 _CLS 对象，这些对象可与 _HID 一起使用，以创建唯一性更强的标识符来标识设备的特定版本、集成或硬件修订，或指示 PCI 定义的设备类的成员身份。 这些对象通常是可选的，但 Windows 中的某些设备类可能需要这些对象。 有关这些对象的详细信息，请参阅 ACPI 5.0 规范的第 6.1 节“设备标识对象”。

为了提高可维护性，Windows 硬件认证工具包 (HCK) 要求 OEM 系统上的设备 ID 必须是“包含四个部分”的 ID。 这四个部分包括供应商 ID、设备 ID、子系统供应商 (OEM) ID 和子系统 (OEM) 设备 ID。 因此，OEM 平台需要 Subsystem ID (_SUB) 对象。

特定于设备的方法 (_DSM)

_DSM 方法在 ACPI 5.0 规范的第 9.14.1 节“_DSM（设备特定方法）”中定义。 此方法提供用于单个特定于设备的数据和控制函数，这些函数可由设备驱动程序调用，而不会与其他此类特定于设备的方法冲突。 特定设备或设备类的 _DSM 定义一个保证不与其他 UUID 冲突的 UUID (GUID)。 对于每个 UUID，_DSM 方法可以实现一组定义的函数来提供数据或执行驱动程序的控制函数。 特定于类的数据和数据格式在单独的设备类专用规范中提供，并在 ACPI 的特定于设备的方法中也进行了讨论。

地址 (_ADR) 和唯一 ID (_UID)

设备标识还有其他三项要求：

  • 对于连接到可枚举硬件父总线（例如 SDIO、USB HSIC）但具有特定于平台的功能或控件（例如，边带电源或唤醒中断）的设备，不使用 _HID。 相反，设备标识符由父总线驱动程序创建（如前所述）。 但在这种情况下，地址对象 (_ADR) 需要位于设备的 ACPI 命名空间中。 此对象使操作系统能够将总线枚举设备与其 ACPI 描述的功能或控件相关联。
  • 在使用特定 IP 块的多个实例以使每个块具有相同设备标识对象的平台上，必须有 Unique Identifier (_UID) 对象才能使操作系统区分块。
  • 特定命名空间范围中的两台设备不能具有同一个名称。

设备配置对象

对于命名空间中标识的每个设备，设备消耗的系统资源（内存地址、中断等）也必须由 Current Resource Settings (_CRS) 对象报告。 支持报告多个可能的资源配置 (_PRS)，以及更改设备资源配置 (_SRS) 的控制，但这是可选的。

SoC 平台的新增功能是设备可以使用的 GPIO 和简单外围总线 (SPB) 资源。 有关详细信息，请参阅常规用途 I/O (GPIO) 和简单外围总线 (SPB)。

SoC 平台还新增了常规用途的固定 DMA 描述符。 FixedDMA 描述符支持由许多系统设备共享 DMA 控制器硬件。 静态分配给特定系统设备的 DMA 资源（请求行和通道寄存器）列在 FixedDMA 描述符中。 有关详细信息，请参阅 ACPI 5.0 规范的第 19.5.49 节“FixedDMA（DMA 资源描述符宏）”。

设备状态更改

出于各种原因，可以禁用或移除 ACPI 枚举的设备。 提供了 Status (_STA) 对象，以便将此类状态更改传达给操作系统。 有关 _STA 的说明，请参阅 ACPI 5.0 规范的第 6.3.7 部分。 Windows 使用 _STA 来确定设备是否应被枚举、显示为已禁用或对用户不可见。 固件中的此控件适用于许多应用程序，包括停靠和 USB OTG 主机到函数切换。

此外，ACPI 还提供一种通知机制，ASL 可使用该机制向驱动程序通知平台中的事件，例如作为停靠的一部分移除的设备。 通常，当 ACPI 设备的状态发生更改时，固件必须执行“设备检查”或“总线检查”通知，使 Windows 重新枚举设备并重新评估其 _STA。 有关 ACPI 通知的信息，请参阅 ACPI 5.0 规范的第 5.6.6 节“设备对象通知”。

启用/禁用

作为 Windows 即插即用的一部分，驱动程序必须能够由用户或系统动态启用和禁用（例如，用于更新驱动程序）。

On-SoC 设备集成到 SoC 芯片中，无法移除。 大多数 on-SoC 设备的驱动程序可以免除启用和禁用的要求。 对于那些不免除这些要求的驱动程序，有一些驱动程序接口用于指示驱动程序支持有序移除。 有关详细信息，请参阅 Microsoft Connect 网站上标题为“减少 SoC 驱动程序的 PNP 要求”的文档。

如果驱动程序支持有序移除，并且可以禁用设备硬件（也就是说，可以将设备配置为停止访问其分配的资源），则设备的 ACPI 命名空间节点可以包含 Disable (_DIS) 对象。 每当移除驱动程序时，操作系统都会评估此方法。 使用 _DIS 时具有以下附加要求：

  • 每当禁用设备时，_STA 必须清除“已启用并解码其资源”位。
  • 设备必须提供 Set Resource Settings (_SRS) 对象才能重新启用设备硬件，并在 _STA 中设置上述位。

有关详细信息，请参阅 ACPI 5.0 规范的第 6.2.3 节 (_DIS)、6.2.15 节 (_SRS) 和第 6.3.7 节 (_STA)。

服务依赖项

通常，特定平台上的设备之间存在硬件依赖关系。 Windows 要求描述所有此类依赖项，以使其可确保所有设备在系统动态变化（设备电源已移除、驱动程序已停止和启动等）时正常运行。 在 ACPI 中，按以下方式描述设备之间的依赖关系：

  1. 命名空间层次结构。 作为子设备（列为另一设备的命名空间中的设备）的任何设备都依赖于父设备。 例如，USB HSIC 设备依赖于它连接到的端口（父级）和控制器（祖父级）。 同样，系统内存管理单元 (MMU) 设备命名空间中列出的 GPU 设备依赖于 MMU 设备。

  2. 连接资源。 连接到 GPIO 或 SPB 控制器的设备依赖于这些控制器。 通过将连接资源纳入设备的 _CRS 中来描述这种类型的依赖项。

  3. OpRegion 依赖项。 对于使用 OpRegions 执行 I/O 的 ASL 控件方法，操作系统不会隐式知道依赖项，因为它们仅在控制方法评估期间确定。 此问题适用于 GeneralPurposeIO 和 GenericSerialBus OpRegions，其中即插即用驱动程序提供对该区域的访问权限。 为了缓解此问题，ACPI 定义了 OpRegion Dependency (_DEP) 对象。 _DEP 应该用在控件方法引用 OpRegion（HW 资源）的任何设备命名空间中，上述 1 或 2 均不适用于引用的 OpRegion 的连接资源。 有关详细信息，请参阅 ACPI 5.0 规范的第 6.5.8 节“_DEP（操作区域依赖项）”。

设备驱动程序之间也可能存在软件依赖关系。 也必须描述这些依赖关系。

有关更多信息，请参见以下资源：