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

Спецификация 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 ID - PNPID Request.

ACPI 5.0 также поддерживает использование идентификаторов поставщиков, назначенных PCI, в _HID и других объектах идентификации, поэтому вам может не потребоваться получать идентификатор поставщика от Microsoft. Дополнительные сведения о требованиях к идентификации оборудования см. в разделе 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 может реализовать для предоставления данных или выполнения функций управления для драйвера. Данные и форматы данных для определенных классов предоставляются в отдельных спецификациях для конкретного класса устройства, а также рассматриваются в методах ACPI Device-Specific.

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

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

• Для устройств, которые подключаются к шине, перечисляемой аппаратными средствами (например, SDIO, USB HSIC), но у которых есть функции или элементы управления, специфичные для платформы (например, питание бокового канала или прерывание пробуждения), _HID не используется. Вместо этого идентификатор устройства создается родительским драйвером шины (как описано ранее). Однако в этом случае объект адреса (_ADR) должен находиться в пространстве имен ACPI для устройства. Этот объект позволяет операционной системе связывать устройство, перечисленное шиной, с функциями или элементами управления, описанными в ACPI.
• На платформах, на которых используются несколько экземпляров определенного IP-блока, и каждый из них имеет одни и те же идентификационные объекты устройства, объект Unique Identifier (_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 драйверы должны иметь возможность динамически включаться и отключаться пользователем или системой (например, для обновления самого драйвера).

Устройства on-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 для выполнения операций ввода-вывода, зависимости неявно известны операционной системой, так как они определяются только во время оценки методов управления. Эта проблема применима к GeneralPurposeIO и GenericSerialBus OpRegions, в которых драйверы Plug and Play предоставляют доступ к региону. Чтобы устранить эту проблему, ACPI определяет объект зависимостей OpRegion (_DEP). _DEP следует использовать в любом пространстве имен устройства, в котором метод управления ссылается на ресурс OpRegion (HW), и ни один из пунктов 1 или 2 выше не применяется к ресурсу подключения OpRegion. Дополнительные сведения см. в разделе 6.5.8 , "_DEP (зависимости региона операции)" спецификации ACPI 5.0.

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

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

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

• Зависимости властных отношений см. в разделе

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

  • IRP_MN_QUERY_DEVICE_RELATIONS

  • WdfDeviceInitSetPnpPowerEventCallbacks

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

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