Управление питанием PCI и драйверы устройств
В этой статье разъясняется некоторая путаница, с которыми столкнулись поставщики в отношении того, как оборудование, которое соответствует стандарту PCI Power Management (PCI-PM), взаимодействует с драйверами устройств в операционной системе, а также о том, как PCI-PM интегрируется с ACPI. Дополнительные сведения см. в разделе https://www.uefi.org/specifications.
Драйверы устройств и управление питанием PCI
В этом обсуждении предполагается, что вы знакомы с тем, как драйверы модели драйверов Windows (WDM) обрабатывают события управления питанием, как описано в текущем windows DDK. Как правило, драйверы устройств отвечают за следующие обязанности.
Водители автобусов. Водители автобуса отвечают за перечисление, настройку и управление устройствами. Для PCI-PM драйвер PCI отвечает за чтение регистров PCI-PM для определения возможностей оборудования. Когда POWER IRP запрашивает изменение состояния питания, драйвер PCI записывает данные в регистры управления питанием PCI, чтобы установить для оборудования различные состояния Dx.
Когда устройство включено для пробуждения, драйвер PCI записывает данные в регистры PCI-PM, чтобы разрешить устройству запускать PME (ACPI также выполнит действие, см. следующий раздел). Наконец, когда ACPI определяет, что шина PCI просыпается в системе, драйвер PCI сканирует пространство конфигурации PCI в поисках того, какое устройство утверждает PME, отключает PME на этом устройстве и уведомляет драйвер для этого устройства.
Драйвер устройства. Конкретный драйвер для устройства отвечает за сохранение и восстановление контекста устройства, а также запрос на изменение состояния питания в качестве владельца политики для устройства. Когда драйвер устройства получает power IRP с запросом на более низкое изменение состояния питания устройства, драйвер устройства отвечает за сохранение любого собственного контекста устройства, необходимого для последующего включения устройства. В некоторых случаях может быть нечего спасать.
Регистры PCI-PM являются исключительно доменом драйвера PCI. Драйверу устройства IHV не требуется доступ к каким-либо из этих регистров. Это приведет к тому, что система не будет работать надежно. Драйвер устройства отвечает за выполнение только собственных действий.
Интеграция ACPI и PCI PM
Некоторые устройства, особенно видеоустройства системной платы в портативных устройствах, могут требовать как управления питанием PCI, так и ассемблера исходного языка ACPI (ASL) для полного управления устройством. Регистры управления питанием PCI будут контролировать внутреннее состояние устройства, например внутренние часы и плоскости питания. ASL будет управлять внешним состоянием, например внешними часами и плоскостями питания, или в случае с видеоконтролерами ASL будет управлять подсветкой видео. Обратите внимание, что ASL и PCI-PM можно объединять только на системных платах.
Архитектура OnNow — это многоуровневая архитектура, обрабатывая интеграцию драйвера устройства, драйвера PCI и драйвера ACPI (и ASL). В следующих сценариях показан порядок вызова драйверов для обработки этих устройств.
Примечание
Чтобы описанные выше сценарии работали должным образом, драйвер WDM должен правильно пересылать POWER IRP, как описано в текущей версии Microsoft Windows DDK.
Сценарий 1. Отключение устройства
- Драйвер устройства: сохраняет состояние защищаемого устройства.
- Драйвер PCI. Сохраняет конфигурацию Plug and Play, отключает устройство (прерывания и BAR) и помещает устройство в D3 с помощью регистров PCI-PM.
- Драйвер ACPI. Выполняет код ASL (_PS3 и _OFF для ресурсов питания, которые больше не используются) для управления состоянием за пределами микросхемы.
Сценарий 2. Управление питанием PCI и драйверы устройств
- Драйвер ACPI: выполняет asl-код (_PS0 и _ON для любых необходимых ресурсов питания OnNow) для управления состоянием, внешним для микросхемы.
- Драйвер PCI. Помещает устройство в D0 с помощью регистров PCI-PM и восстанавливает конфигурацию Plug and Play (прерывания и BAR - они могут отличаться от того, что было на устройстве ранее).
- Драйвер устройства: восстанавливает собственный контекст на устройстве.
Сценарий 3. Включение пробуждения
- Драйвер устройства: устанавливает собственные регистры в микросхеме, чтобы включить пробуждение. Например, в пробуждении сети с сопоставлением шаблонов шаблоны будут запрограммированы в адаптере.
- Драйвер PCI: задает биты активации пробуждения в регистрах PCI PM, чтобы позволить устройству утверждать PME.
- Драйвер ACPI. Включает GPE в наборе микросхем, связанном с PME (как описано в объекте _PRW, указанном в корневой шине PCI).
Сценарий 4. Пробуждение
- Драйвер ACPI. Активирует и сканирует биты состояния GPE на наличие событий пробуждения, отключает объекты групповой политики для заданных битов состояния GPE и выполняет любые _Lxx или _Exx методы, связанные с заданными битами GPE. В ответ на уведомление о пробуждении в шине PCI драйвер ACPI завершит WAIT_WAKE IRP драйвера PCI, чтобы уведомить драйвер PCI о том, что он пробуждается системы.
- Драйвер PCI: сканирует пространство конфигурации в поисках любых устройств с заданным битом состояния PME. Для каждого устройства он отключает PME и завершает WAIT_WAKE IRP для этого устройства, чтобы сообщить драйверу о том, что оно подтверждает пробуждение. Драйвер PCI прекращает сканирование для устройств пробуждения, когда он выполнил полный проход через все устройства PCI, не обнаружив ни одного утверждающего PME, и когда PME перестает утверждаться.
- Драйвер устройства. Запрашивает, чтобы устройство было помещено в D0 (см. сценарий 2) и задает все собственные регистры в микросхеме, необходимые для обработки события пробуждения.
Призыв к действию по управлению питанием PCI и драйверам устройств
- Интегрируйте возможности ACPI и PCI-PM в свои устройства, как описано в этой статье.
- Спецификация PCI Power Management доступна на веб-сайте PCI-SIG.
- Спецификация ACPI доступна по адресу https://www.uefi.org/specifications. Эта ссылка покидает сайт Microsoft.com.
- Компилятор архитектуры компонентов ACPI (ACPICA) можно найти по адресу https://acpica.org/downloads/binary-tools.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по