Поделиться через


Требования к встроенному ПО для D3cold

Начиная с Windows 8 устройства могут переходить в дополнительное состояние питания D3cold, даже если система остается в состоянии питания S0. В этом разделе описываются требования к встроенному ПО для реализации поддержки D3cold для встроенного устройства. Следующее обсуждение призвано помочь разработчикам встроенного ПО, чтобы их встроенные устройства могли надежно входить в D3cold и выходить из нее.

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

Введение

Состояния питания устройства определяются в спецификации ACPI и в различных спецификациях шины. Спецификация шины PCI, так как она представила управление питанием PCI, разделяет состояние питания устройства D3 (off) на два вложенных состояния, D3hot и D3cold. Это различие было добавлено в спецификацию ACPI в ACPI 3.0 и расширено в ACPI 4.0. Windows всегда поддерживала оба вложенных состояния D3, но Windows 7 и более ранние версии Windows поддерживают вложенное состояние D3cold только в том случае, если весь компьютер выходит из состояния питания системы S0 (работающей), чтобы перейти в спящий режим или состояние гибернации ( обычно S3 или S4). Начиная с Windows 8, драйверы устройств могут позволить своим устройствам переходить в состояние D3cold, даже если система остается в S0.

D3hot, который часто называют просто "D3", является состоянием "мягкого выключения" устройства. В этом состоянии устройство может быть обнаружено с помощью сканирования шины, а команды, отправленные на устройство, могут привести к его повторному включению. В D3cold все источники питания удаляются, за исключением небольшого количества энергии для работы логики пробуждения устройства. Например, для устройств PCI Express (PCIe) источник питания main устройства Vcc часто отключается при переходе на D3cold. Отключение Vcc может снизить энергопотребление и увеличить время работы мобильной аппаратной платформы при заряде батареи. Если устройство находится в D3cold, оно не может быть обнаружено при проверке шины и не может получать команды. Восстановление питания Vcc переводит устройство в неинициализированное состояние, которое обычно эквивалентно состоянию D0. Затем программное обеспечение должно повторно инициализировать устройство, чтобы привести его в рабочее состояние.

Помещение устройства в D3cold не обязательно означает, что все источники питания устройства были удалены. Это означает, что будет удален только main источник питания Vcc. Вспомогательный источник питания Vaux также может быть удален, если он не требуется для логики пробуждения. Однако устройство, которое может потребоваться для передачи процессору сигнала о событии пробуждения, должно иметь достаточную мощность для работы логики пробуждения. Например, сетевой интерфейс Ethernet карта (NIC), main источник питания которого удален, может черпать достаточно питания от кабеля Ethernet. Кроме того, питание в режиме ожидания для сетевого адаптера Wi-Fi может предоставляться из источника за пределами интерфейса PCIe. В этом случае интерфейс PCIe можно полностью отключить.

В следующем обсуждении описан набор требований для включения перехода состояния питания устройства на D3cold. Эти требования делятся на следующие две категории:

  • Требования к встроенному ПО и платформе

  • Требования к драйверу устройства

Первая из этих двух категорий является main в центре внимания данного обсуждения. Представлен краткий обзор второй категории. Дополнительные сведения о требованиях к драйверам устройств см. в разделе Поддержка D3cold в драйвере.

Требования к встроенному ПО и платформе

В следующем обсуждении для этих двух случаев представлены требования к встроенному ПО и платформе для включения D3cold:

  • При перечислении устройства в ACPI.

  • Когда устройство перечисляется его родительской шиной.

Большинство из следующих обсуждений относятся к PCIe. Однако общие принципы, описанные здесь, в значительной степени применимы и к другим автобусам.

Если абстрагировать некоторые детали, переход с D3cold на D0 активируется путем повторного применения питания Vcc к встроенному устройству. Повторное применение питания эффективно восстанавливает подключение устройства к шине. Windows считывает идентификаторы устройства, чтобы различать следующие два варианта:

  • Устройство было удалено и заменено другим устройством.

  • То же устройство было удалено, а затем повторно вложено.

Если идентификаторы совпадают, драйвер устройства повторно инициализирует устройство. Если идентификаторы не совпадают, Windows выгружает драйвер устройства и создает новый стек драйверов для нового устройства. PCIe, например, запрашивает идентификатор поставщика, идентификатор устройства и идентификаторы подсистемы (которые в некоторых версиях спецификации разбиваются на идентификаторы подустройства и субдоверсия). Эти идентификаторы должны соответствовать идентификаторам ранее подключенного устройства после повторного применения питания (и истечения периода ожидания, указанного в шине); в противном случае Windows будет считать новое устройство отличным от предыдущего.

Вариант 1. Внедренное устройство перечисляется в ACPI

Если встроенное устройство невозможно обнаружить с помощью механизмов, определенных спецификацией шины, таких как PCIe или USB, но устройство подключено постоянно (или по крайней мере подключение выделено известному устройству), это устройство может быть описано в встроенном ПО платформы acpi _HID и (или) _CID объектов. Эти объекты позволяют OSPM перечислить устройство. (OSPM — это термин, определенный в спецификации ACPI. Это означает, свободно, "программное обеспечение, которое не является встроенным ПО.") OSPM перечисляет устройство только в том случае, если ни перечислитель шины не может обнаружить идентификатор устройства. Например, устройства в шине ISA перечисляются OSPM. Кроме того, устройства в системе на микросхеме (SoC) часто перечисляются acpi, так как они находятся на неперечисленной структуре. Примерами таких устройств являются хост-контроллеры USB и SD.

Встроенное ПО платформы (перечислено в ACPI)

OSPM использует \_SB._OSC для передачи возможностей OSPM на уровне платформы встроенному ПО платформы. Встроенное ПО платформы должно задать бит 2 в возвращаемом значении \_SB._OSC, чтобы указать OSPM, что устройство поддерживает _PR3. Дополнительные сведения см. в разделе 6.2.10.2 "Возможности OSPM на уровне платформы" в спецификации ACPI 5.0.

Встроенное устройство (обнаруживается исключительно через ACPI)

Для поддержки D3cold встроенное ПО платформы должно реализовать следующие объекты ресурсов питания ACPI для встроенного устройства:

  • _PR0. Этот объект оценивает требования устройства к энергопотреблению в состоянии питания устройства D0 (полностью включено). Возвращаемое значение — это список ресурсов питания, необходимых устройству в состоянии D0.

  • _PR2. Этот объект оценивает требования устройства к энергопотреблению в состоянии питания устройства D2. Возвращаемое значение — это список ресурсов питания, необходимых устройству в состоянии D2. Обратите внимание, что по историческим причинам Windows ожидает, что _PR2 будет присутствовать при каждом _PR0. Если D2 реализован в оборудовании, _PR2 перечислены ресурсы питания, необходимые для D2. Если D2 не реализован, _PR2 перечисляет те же ресурсы, что и _PR0.

  • _PR3. Этот объект оценивает требования устройства к энергопотреблению в состоянии питания устройства D3hot. Возвращаемое значение — это список ресурсов питания, необходимых устройству в состоянии D3hot.

  • Для каждого ресурса питания, определенного в любом объекте _PRx, необходимо реализовать следующие методы управления:

    • _OFF. Установите для ресурса питания состояние выключения (выключение ресурса).

    • _ON. Задайте для ресурса питания состояние on (включение ресурса).

    • _STA: этот объект оценивает текущее состояние включения или выключения ресурса питания (0: выключено, 1: включено).

Переход на D3cold происходит, когда ACPI запускает метод управления _OFF для ресурсов питания, перечисленных в _PR3. Обратите внимание, что если драйвер функции устройства указывает на поддержку D3cold, эта поддержка не означает, что все переходы на D3 приводят к быстрому переходу на D3cold. Возможно, устройство входит и остается в D3hot в течение длительного периода времени, а затем либо возвращается в D0, не вводя D3cold, либо переходит в D3cold позже.

Родительское устройство (перечисляется в ACPI)

Для родительского устройства не требуется управлять питанием. Однако если родительское устройство управляется питанием, Windows никогда не выключит это устройство, если какие-либо из его дочерних устройств (зависимых устройств) не находятся в D3.

Пример (перечисляется в ACPI)

На следующей блок-схеме показано встроенное устройство (с меткой EMBD) в системной шине. Main питания (Vcc) и вспомогательного питания (Vaux) к устройству можно независимо включать и выключать с помощью блока с меткой "Логика питания".

встроенное устройство с перечислением acpi.

В следующем примере кода ASL описываются ресурсы питания, используемые внедренным устройством на предыдущей схеме. Этот пример начинается с объявления метода управления _OSC, описывающего возможности драйвера устройства. Затем объявляются два ресурса питания устройства— имена ресурсов PVCC и PVAX назначаются main и вспомогательным источникам питания устройства, Vcc и Vaux. Наконец, перечислены требования к ресурсам питания для каждого состояния питания устройства, которое поддерживает устройство, и описаны возможности пробуждения устройства.

Scope (\_SB)
{
     Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
     {  
          ... // This must indicate support for _PR3.
     }

     PowerResource(PVCC,0,0) // Power resource representing the main power for the device.
                             // Required for the device to be fully functional (D0).
     {
          Name(_STA,VAR1)        // Return the state of the power resource.
          Method(_ON,0x0) {...}  // Turn on the power resource and set VAR1 to 1.
          Method(_OFF,0x0) {...} // Turn off the power resource and set VAR1 to 0.
     }

     PowerResource(PVAX,0,0) // Power resource representing the auxiliary power for the device.
                             // Required for low-power, less-functional states (e.g., D3hot).
     {
          Name(_STA,VAR2)
          Method(_ON,0x0) {...}
          Method(_OFF,0x0) {...}
     }

     Device(EMBD) // An ACPI-enumerated device on the processor bus that supports D3Cold
     {
               Name(_HID, ...)
               ... // Other (non-power) objects for this device

          // Indicate support for D0.
               Name(_PR0, Package() {PVCC, PVAX}) // Power resources required for D0

          // Indicate support for D1 (optional)...

          // Indicate support for D2.
               Name(_PR2, Package() {PVCC, PVAX}) // If D2 is implemented in the hardware,
                                                  //  list the power resources needed by D2.
                                                  // If D2 is not implemented, list the same
                                                  //  resources as _PR3.

          // Indicate support for D3Cold.
               Name(_PR3, Package() {PVCC, PVAX}) // Power resource for D3. These will be 
                                                  //  turned off ONLY if drivers opt-in to D3cold.
 
          // Indicate support for wake. Required for entry into D3cold, even if the device doesn't
          // need or have a wake mechanism.
               Name(_S0W, 4) // The existence of this object indicates that the platform is
                             //  capable of handling wake events from this device while in S0. 
                             // The value of this object indicates the lowest D-state this device
                             //  can be in to trigger wake events that can be handled while the
                             //  platform is in S0.

          // Enable wake events (optional) 
          //  If this device actually does generate wake events, there must be a way for OSPM to
          //  enable and disable them. The mechanism for this depends on the platform hardware:
               /*
               Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
                               //  if there are power resources required only for wake.
               Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
                
               Method(_DSW, 3) {...} // Can be used with either of the above, if wake enablement
                                     // varies depending on the target S-state and D-state.
               */
     }  // End of Device EMBD
} End Scope \_SB

Случай 2. Внедренное устройство перечисляется в шине

Если встроенное устройство соответствует общей спецификации шины, например PCIe или USB, это устройство можно обнаружить с помощью определенных в шине механизмов, а питание может быть предоставлено частично или полностью через шину. Если это устройство не питается от других ресурсов питания боковой полосы, источником питания устройства main является соединение, которое подключает устройство к родительскому контроллеру шины. Устройства с перечислением в шине можно идентифицировать с помощью объекта _ADR в определении внедренного устройства. Объект _ADR используется для предоставления OSPM адреса устройства в родительской шине встроенного устройства. Этот адрес используется для привязки представления устройства в шине (как показано оборудованием шины) с представлением устройства платформы (как показано в встроенном ПО ACPI). (Кодировка адреса _ADR зависит от шины. Дополнительные сведения см. в разделе 6.1.1 "_ADR (адрес)" в спецификации ACPI 5.0. При использовании этого механизма поддержка D3cold должна быть согласована с водителем родительского автобуса.

Если main источником питания для встроенного устройства является связь, которая подключает это устройство к его родительской шине, ключевым требованием для размещения устройства в D3cold является выключение канала. Дополнительные сведения о переходе на D3cold см. в графе состояний в разделе Состояния питания устройства.

Встроенное ПО платформы (перечисление в шине)

OSPM использует \_SB._OSC для передачи возможностей OSPM на уровне платформы встроенному ПО платформы. Встроенное ПО платформы должно задать бит 2 в возвращаемом значении \_SB._OSC, чтобы указать OSPM, что устройство поддерживает _PR3. Дополнительные сведения см. в разделе 6.2.10.2 "Возможности OSPM для всей платформы" в спецификации ACPI 5.0.

Внедренное устройство (с перечислением в шине)

Изменения ACPI для D3cold не требуются. В этом случае, если драйвер устройства и платформа указали поддержку D3cold, канал шины, подавающий питание на встроенное устройство, можно отключить, когда родительский автобус выходит из D0 и переходит в состояние Dx с низким энергопотреблением. Переход встроенного устройства с D3hot на D3cold происходит при отключении питания из канала. Состояние Dx, в которое входит родительская шина, может быть любым состоянием, которое приведет к отключению источника питания связи.

Родительское устройство (с перечислением в шине)

Дескриптор ACPI для родительской шины должен выполнять следующие действия.

  • Реализация _S0W(Dx). Этот объект указывает Dx в качестве D-состояния с наименьшей мощностью, из которого дочернее (встроенное) устройство может пробуждение, когда система находится в состоянии S0.

  • Определите ресурсы питания, чтобы представить ссылку, соединяющую дочернее (внедренное) устройство с родительской шиной. Кроме того, для этого ресурса питания необходимо определить объекты _ON, _OFF и _STA. Пример кода ASL, следующий за этим списком, описывает питание связи как два ресурса: PVC1 и PVX1. Для каждого из этих ресурсов определяются объекты _ON, _OFF и _STA.

  • Если "Dx" (D-состояние с наименьшей мощностью; см. первый элемент списка) — D3cold, укажите объект _PR3, включающий ресурсы питания, необходимые дочернему (встроенному) устройству для D3hot (например, Vcc и Vaux). Если для D0, D2 и D3hot требуются одни и те же источники питания, то _PR0, _PR2 и _PR3 укажите одни и те же ресурсы питания. Эти ресурсы отключаются, только если дочернее устройство входит в D3cold.

    По историческим причинам Windows ожидает, что при каждом _PR0 будет присутствовать _PR2. Если D2 реализован на оборудовании, _PR2 перечисляет ресурсы питания, необходимые для D2. Если D2 не реализован, _PR2 перечисляет те же ресурсы, что и _PR0.

  • Реализация _PR0. Список ресурсов в объекте _PR0 для родительской шины должен включать ресурсы, которые питают канал, соединяющий родительскую шину с дочерним (внедренным) устройством.

Пример (с перечислением в шине)

В примере конфигурации оборудования на следующей блок-схеме показаны два разных способа включения D3cold для устройств PCIe. Во-первых, конечная точка (с меткой ENDP) подключается к корневому порту PCIe (RP01) и получает вспомогательное питание от родительского устройства через канал PCIe. Во-вторых, устройство HD Audio на схеме не имеет стандартной связи с родительским устройством (контроллер PCI с меткой PCI0) и поэтому смоделировано аналогично регистру с перечислением ACPI.

встроенное устройство с перечислением шины.

Устройство RP01 на этой схеме имеет main источник питания Vcc1 и вспомогательный источник питания Vaux1. Аналогично, устройство HD Audio имеет main источник питания Vcc2 и вспомогательный источник питания Vaux2.

Следующий код ASL описывает контроллер родительской шины (PCI0) и ресурсы питания, необходимые для устройств ENDP и HD Audio , показанных на предыдущей схеме.

Scope (_SB)
{
     Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
     {  
          ... // This must indicate support for _PR3.
     }

     PowerResource(PVC1,0,0) // Power resource representing Vcc1 for the RP01 device.
                             // Required for the device(s) to be fully functional (D0).
     {
          Name(_STA,VAR0)
          Method(_ON,0x0) {...}
          Method(_OFF,0x0) {...}
     }

     PowerResource(PVX1,0,0) // Power resource representing Vaux1 for the RP01 device.
                             // Required for low-power, less-functional states (e.g., D3hot).
     {
          Name(_STA,VAR1)
          Method(_ON,0x0) {...}
          Method(_OFF,0x0) {...}
     }

     PowerResource(PVC2,0,0) // Power resource representing Vcc2 for the HD device.
                             // Required for the device(s) to be fully functional (D0).
     {
          Name(_STA,VAR2)
          Method(_ON,0x0) {...}
          Method(_OFF,0x0) {...}
     }

     PowerResource(PVX2,0,0) // Power resource representing Vaux2 for the HD device.
                             // Required for low-power, less-functional states (e.g., D3hot).
     {
          Name(_STA,VAR3)
          Method(_ON,0x0) {...}
          Method(_OFF,0x0) {...}
     }

     ... // Power resources for other child devices

     Device(PCI0) // The PCI root complex
     {
          Name(_HID, EISAID("PNP0A08"))  // ACPI enumerated
          Method(_OSC, 4, NotSerialized) // PCIe-specific Capabilities Check.
          {     
               ... // This must support hand-off of PCIe control to the OS.
          }
          ... // Other (non-power) objects for this device

          Device(RP01) // PCIe Root Port 1
          {
                    Name(_ADR, "...") // Bus enumerated
                    ... // Other (non-power) objects for this device
    
               // Indicate support for D0.
                    Name(_PR0, Package() {PVC1, PVX1}) // Power resources required for D0.
                                                       // Includes the Link Power for ENDP.

               // Indicate support for D1 (optional)...

               // Indicate support for D2.
                    Name(_PR2, Package(){PVC1, PVX1}) 

               // Indicate support for wake. Required for entry into D3cold, even if the
               // device doesn't need or have a wake mechanism.
                    Name(_S0W, 4) // The existence of this object indicates the platform
                                  //  is capable of handling wake events from this device
                                  //  while the platform is in S0. 
                                  // The value of this object indicates the lowest D-state
                                  //  this device can be in to trigger wake events that 
                                  //  can be handled while the platform is in S0.

               // Enable wake events (optional) 
               //  If this device actually does generate wake events, there must be a way
               //  for OSPM to enable and disable them. The mechanism for this depends on
               //  the platform hardware:

                    /*
                    Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
                                    //  if there are power resources required only for wake.
                    Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.

                    Method(_DSW, 3) {...} // Can be used with both of the above, if wake
                                          //  enablement varies depending on the target 
                                          //  S-state and D-state.
                    */

                    Device(ENDP) // This device supports D3cold. No power-related objects
                                 // are required.
                    {
                         Name(_ADR, "...")  // Bus enumerated
                         ... // Other (non-power) objects
                    }  // End of Device ENDP
          }  // End of Device RP01

          Device(HD) // A PCIe Bus0 device (HD Audio) that supports D3cold. Note that
                     //  this case is modeled similar to the ACPI-enumerated case
                     //  because device HD has no standard link to its parent.
          {
                    Name(_ADR, "...") // Bus enumerated
                    ... // Other (non-power) objects for this device
    
               // Indicate support for D0.
                    Name(_PR0, Package() {PVC2, PVX2}) // Power resources required for D0
                            
               // Indicate support for D1 (optional)...

               // Indicate support for D2.
                    Name(_PR2, Package(){PVC2, PVX2})

               // Indicate support for D3Cold.
                    Name(_PR3, Package() {PVC2, PVX2}) // Power resource for D3; These will
                                                       //  be turned off ONLY if drivers
                                                       //  opt-in to D3cold.
 
               // Indicate support for wake. Required for entry into D3cold, even if the
               // device doesn't need or have a wake mechanism.
                    Name(_S0W, 4) // The existence of this object indicates that the platform
                                  //  is capable of handling wake events from this device 
                                  //  while the platform is in S0. 
                                  // The value of this object indicates the lowest D-state
                                  //  this device can be in to trigger wake events that can
                                  //  be handled while the platform is in S0.

               // Enable wake events (optional). 
               //  If this device actually does generate wake events, there must be a way for
               //  OSPM to enable and disable them. The mechanism for this depends on the HW:
                    /*
                    Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
                                    //  if there are power resources required only for wake.
                    Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.

                    Method(_DSW, 3) {...} // Can be used with both of the above, if wake
                                          //  enablement varies depending on the target
                                          //  S-state and D-state.
                    */
          }  // End Device HD

          ... // Device objects for other child devices

     }  // End Device PCI0
}  // End Scope _SB

Другие возможности

Методы, показанные в двух предыдущих примерах, можно объединить для поддержки конфигураций, использующих питание шины и питание боковой полосы.

Требования к драйверу устройства

Владелец политики питания для устройства (обычно драйвер функции) сообщает операционной системе, следует ли включить переход устройства с D3hot на D3cold. Драйвер может указать эти сведения в INF-файле, который устанавливает устройство. Или драйвер может вызвать подпрограмму SetD3ColdSupport во время выполнения, чтобы динамически включать или отключать переходы устройства на D3cold. Включив устройство для входа в D3cold, драйвер гарантирует следующее поведение:

  • Устройство может переносить переход с D3hot на D3cold, когда компьютер останется в S0.

  • Устройство будет работать правильно, когда оно вернется в D0 из D3cold.

Устройство, которое не соответствует требованиям, после ввода D3cold может быть недоступно до тех пор, пока компьютер не перезагрузится или не перейдет в спящий режим. Если устройство должно иметь возможность сигнализировать о событии пробуждения из любого состояния Dx с низким энергопотреблением, которое оно входит, вход в D3cold не должен быть включен, если драйвер не уверен, что сигнал пробуждения устройства будет работать в D3cold.

Дополнительные сведения см. в разделе Поддержка D3cold в драйвере.