Объекты пространства имен управления устройствами

Спецификация ACPI 5.0 определяет несколько типов объектов пространства имен, которые можно использовать для управления устройствами. Например, объекты идентификации устройств содержат идентификационные сведения для устройств, подключающихся к автобусам, таких как I2C, которые не поддерживают аппаратное перечисление дочерних устройств. Другие типы объектов пространства имен могут указывать системные ресурсы, описывать зависимости устройств и указывать, какие устройства можно отключить.

Идентификация устройств в Windows

Windows Plug and Play находит и загружает драйверы устройств на основе идентификатора устройства, предоставленного перечислителем устройства. Перечислители — это водители шины, которые знают, как извлечь идентификационную информацию с устройства. Некоторые автобусы (например, 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

Чтобы просмотреть идентификаторы устройств, создаваемые Windows для вашего устройства, откройте диспетчер устройств и проверьте свойства Идентификаторы оборудования и Совместимые идентификаторы перечисленного устройства. Каждую из этих строк можно указать в INF-файле, чтобы определить драйвер для загрузки устройства. Порядок сопоставления INF — от наиболее конкретного идентификатора оборудования (наиболее предпочтительного драйвера) до наименее определенного идентификатора (наименее предпочтительного драйвера), поэтому драйверы, которые знают больше о конкретных функциях устройства, могут заменить менее специфичные (и, следовательно, поддерживают только подмножество функций устройства).

Идентификаторы устройств должны использоваться только для сопоставления INF и никогда не должны анализироваться или обрабатываться драйвером устройства. Если драйверу устройства необходимо определить конкретное оборудование, для которого он был загружен, рекомендуется установить в INF-файле соответствующие разделы реестра во время установки. Затем драйвер может получить доступ к этим ключам во время инициализации, чтобы получить необходимые сведения.

Идентификация устройств в ACPI

Идентификатор оборудования (_HID)

Минимальным требованием для идентификации устройства в ACPI является объект Hardware ID (_HID). _HID возвращает строку в формате "ABC[D]xxxx", где "ABC[D]" — это строка из 3 символов или 4 символов, идентифицирующая изготовителя устройства ("Идентификатор поставщика"), а xxxx — шестнадцатеричное число, определяющее конкретное устройство, изготовленное этим поставщиком ("Идентификатор устройства"). Идентификаторы поставщиков должны быть уникальными для всей отрасли. Корпорация Майкрософт выделяет эти строки, чтобы убедиться, что они уникальны. Идентификаторы поставщиков можно получить по Plug and Play ИДЕНТИФИКАТОР — запрос PNPID.

ACPI 5.0 также поддерживает использование идентификаторов поставщиков, назначаемых PCI, в _HID и других объектах идентификации, поэтому вам может не потребоваться получать идентификатор поставщика от Корпорации Майкрософт. Дополнительные сведения о требованиях к идентификации оборудования см. в разделе 6.1.5 "_HID (идентификатор оборудования)" спецификации ACPI 5.0.

Совместимый идентификатор (_CID)

Корпорация Майкрософт зарезервировала идентификатор поставщика "PNP" для устройств, совместимых с драйверами папки "Входящие", поставляемыми с Windows. Windows определяет ряд идентификаторов устройств для использования с этим идентификатором поставщика, которые можно использовать для загрузки предоставленного Windows драйвера для устройства. Для возврата этих идентификаторов используется отдельный объект , совместимый идентификатор (_CID). Windows всегда предпочитает идентификаторы оборудования (возвращаемые _HID) вместо совместимых идентификаторов (возвращаемых _CID) при сопоставлении INF и выборе драйвера. Этот параметр позволяет рассматривать драйвер, предоставляемый Windows, как драйвер по умолчанию, если предоставленный поставщиком драйвер устройства недоступен. Совместимые идентификаторы в следующей таблице созданы для использования с платформами SoC.

Идентификатор подсистемы (_SUB), редакция оборудования (_HRV) и класс (_CLS)

ACPI 5.0 определяет объекты _SUB, _HRV и _CLS, которые можно использовать вместе с _HID для создания идентификаторов, которые более уникальным образом идентифицируют конкретную версию, интеграцию или версию оборудования устройства, или для указания членства в классе устройств, определяемом PCI. Как правило, эти объекты являются необязательными, но могут потребоваться для определенных классов устройств в Windows. Дополнительные сведения об этих объектах см. в разделе 6.1, "Объекты идентификации устройств" спецификации ACPI 5.0.

Для удобства обслуживания существует требование комплекта сертификации оборудования Windows (HCK), чтобы идентификаторы устройств в oem-системах были "четырехкомпонентными". Четыре части — это идентификатор поставщика, идентификатор устройства, идентификатор поставщика подсистемы (OEM) и идентификатор устройства подсистемы (OEM). Поэтому для платформ OEM требуется объект идентификатора подсистемы (_SUB).

Метод Device-Specific (_DSM)

Метод _DSM определен в разделе 9.14.1, "_DSM (метод для конкретного устройства)" спецификации ACPI 5.0. Этот метод предоставляет отдельные, зависящие от устройства функции данных и управления, которые могут вызываться драйвером устройства без конфликта с другими методами, зависящими от устройства. _DSM для определенного устройства или класса устройства определяет UUID (GUID), который гарантированно не будет конфликтовать с другими идентификаторами UUID. Для каждого UUID существует набор определенных функций, которые метод _DSM может реализовать для предоставления данных или выполнения управляющих функций для драйвера. Данные и форматы данных для конкретных классов предоставляются в отдельных спецификациях класса устройств, а также рассматриваются в Device-Specific методах ACPI.

Адрес (_ADR) и уникальный идентификатор (_UID)

Существует три дополнительных требования для идентификации устройств:

• Для устройств, которые подключаются к аппаратной перечисляемой родительской шине (например, SDIO, USB HSIC), но имеют функции или элементы управления для конкретной платформы (например, питание боковой полосы или прерывание пробуждения), _HID не используется. Вместо этого идентификатор устройства создается родительским водителем автобуса (как обсуждалось ранее). Однако в этом случае объект address (_ADR) должен находиться в пространстве имен ACPI для устройства. Этот объект позволяет операционной системе связать устройство с перечислением шины с функциями или элементами управления, описанными в ACPI.
• На платформах, где используется несколько экземпляров определенного ip-блока, чтобы каждый блок был один и тот же объект идентификации устройств, объект Уникальный идентификатор (_UID) необходим, чтобы операционная система могла различать блоки.
• Два устройства в определенной области пространства имен не могут иметь одинаковые имена.

Объекты конфигурации устройств

Для каждого устройства, определенного в пространстве имен, системные ресурсы (адреса памяти, прерывания и т. д.), используемые устройством, также должны сообщаться объектом Current Resource Settings (_CRS). Отчеты о нескольких возможных конфигурациях ресурсов (_PRS) и элементах управления для изменения конфигурации ресурсов устройства (_SRS) поддерживаются, но являются необязательными.

Новыми для платформ SoC являются GPIO и простые ресурсы периферийной шины (SPB), которые может использовать устройство. Дополнительные сведения см. в разделе общего назначения ввода-вывода (GPIO) и простой периферийной шины (SPB).

Кроме того, новым для платформ SoC является фиксированный дескриптор DMA общего назначения. Дескриптор FixedDMA поддерживает совместное использование оборудования контроллера DMA рядом системных устройств. Ресурсы DMA (регистры строки запроса и каналов), статически выделенные для определенного системного устройства, перечислены в дескрипторе FixedDMA. Дополнительные сведения см. в разделе 19.5.49 , "FixedDMA (макрос дескриптора ресурсов DMA)" спецификации ACPI 5.0.

Изменение состояния устройства

Устройства с перечислением ACPI могут быть отключены или удалены по различным причинам. Объект Status (_STA) предоставляется для передачи таких изменений состояния операционной системе. Описание _STA см. в разделе 6.3.7 спецификации ACPI 5.0. Windows использует _STA, чтобы определить, должно ли устройство быть перечислено, отображаться как отключено или невидимо для пользователя. Этот элемент управления в встроенном ПО полезен для многих приложений, включая закрепление и переключение между узлами и функциями USB OTG.

Кроме того, ACPI предоставляет механизм уведомления, который ASL может использовать для уведомления драйверов о событиях на платформе, таких как устройство, которое удаляется в составе док-станции. Как правило, при изменении состояния устройства ACPI встроенное ПО должно выполнить уведомление "проверка устройства" или "проверка шины", чтобы Windows повторно перечислила устройство и повторно оценила его _STA. Сведения об уведомлениях ACPI см. в разделе 5.6.6, "Уведомления об объекте устройства" спецификации ACPI 5.0.

Включить/выключить

Как часть Windows Plug and Play, драйверы должны быть динамически включены и отключены пользователем или системой (например, для обновления драйвера).

Устройства, подключенные к SoC, интегрированы в микросхему SoC и не могут быть удалены. Драйверы для большинства устройств в SoC можно исключить из требований к включению и отключению. Для тех драйверов, которые не исключаются, существуют интерфейсы драйверов, указывающие, что драйвер поддерживает упорядоченный удаление. Дополнительные сведения см. в документе "Снижение требований PNP для драйверов SoC" на веб-сайте Microsoft Connect.

Если драйвер поддерживает упорядоченное удаление и оборудование устройства может быть отключено (то есть устройство может быть настроено для прекращения доступа к назначенным ресурсам), узел пространства имен ACPI для устройства может включать объект Disable (_DIS). Этот метод будет оцениваться операционной системой при каждом удалении драйвера. Использование _DIS предъявляет следующие дополнительные требования.

• _STA должен очищать бит "включено и декодирование его ресурсов" всякий раз, когда устройство отключено.
• Устройство должно предоставить объект Set Resource Settings (_SRS), чтобы повторно включить оборудование устройства и задать указанный выше бит в _STA.

Дополнительные сведения см. в разделах 6.2.3 (_DIS), 6.2.15 (_SRS) и 6.3.7 (_STA) спецификации ACPI 5.0.

Зависимости устройств

Как правило, между устройствами на определенной платформе существуют аппаратные зависимости. Windows требует, чтобы все такие зависимости были описаны, чтобы обеспечить правильную работу всех устройств по мере динамического изменения в системе (выключение устройства, остановка и запуск драйверов и т. д.). В ACPI зависимости между устройствами описываются следующими способами.

1. Иерархия пространства имен. Любое устройство, являющееся дочерним (перечисленным как устройство в пространстве имен другого устройства), зависит от родительского устройства. Например, USB-устройство HSIC зависит от порта (родительского) и контроллера (бабушка и дедушка), к которому оно подключено. Аналогичным образом устройство GPU, указанное в пространстве имен устройства системного устройства управления памятью (MMU), зависит от устройства MMU.

2. Подключения к ресурсам. Устройства, подключенные к контроллерам GPIO или SPB, зависят от этих контроллеров. Этот тип зависимости описывается включением ресурсов подключения в _CRS устройства.

3. Зависимости OpRegion. Для методов управления ASL, использующих OpRegions для выполнения операций ввода-вывода, зависимости неявно известны операционной системе, так как они определяются только во время оценки метода управления. Эта проблема применима к OpRegions GeneralPurposeIO и GenericSerialBus, в которых драйверы Plug and Play предоставляют доступ к региону. Чтобы устранить эту проблему, ACPI определяет объект зависимости OpRegion (_DEP). _DEP следует использовать в любом пространстве имен устройства, в котором на opRegion (ресурс HW) ссылается метод элемента управления, и ни 1, ни 2 выше уже не применяется к указанному ресурсу подключения OpRegion. Дополнительные сведения см. в разделе 6.5.8, "_DEP (зависимости области операций)" спецификации ACPI 5.0.

Кроме того, между драйверами устройств могут быть зависимости программного обеспечения. Эти зависимости также должны быть описаны.

Дополнительные сведения см. в следующих ресурсах:

• Сведения о зависимостях по порядку загрузки драйвера см. в разделе Указание порядка загрузки драйвера.

• Сведения о зависимостях power-relations см. в разделе:

  • IoInvalidateDeviceRelations (Чтобы активировать установление отношений власти, вызовите подпрограмму IoInvalidateDeviceRelations с DEVICE_RELATION_TYPE значением перечисления PowerRelations.)

  • IRP_MN_QUERY_DEVICE_RELATIONS

  • WdfDeviceInitSetPnpPowerEventCallbacks

  • Перечисление устройств в шине

  • Динамическое перечисление