Requisitos de firmware para D3cold
A partir de Windows 8, los dispositivos pueden entrar en el subestable de alimentación D3cold incluso cuando el sistema permanece en estado de alimentación S0. En este tema se describen los requisitos de firmware para implementar la compatibilidad con D3cold para un dispositivo insertado. La siguiente explicación está pensada para ayudar a los desarrolladores de firmware a permitir que sus dispositivos insertados entren y salgan de D3cold de forma confiable.
Además, los requisitos del controlador de dispositivo para admitir D3cold se describen brevemente. Para obtener más información sobre la compatibilidad del controlador de dispositivo con D3cold, consulte Compatibilidad con D3cold en un controlador.
Introducción
Los estados de alimentación del dispositivo se definen en la especificación ACPI y en diversas especificaciones de bus. La especificación del bus PCI tiene, desde que introdujo la administración de energía PCI, dividió el estado de alimentación del dispositivo D3 (apagado) en dos subes estados, D3hot y D3cold. Esta distinción se agregó a la especificación ACPI en ACPI 3.0 y se extendió en ACPI 4.0. Windows siempre ha admitido los subes estados D3, pero Windows 7 y versiones anteriores de Windows solo admiten el subestamento D3cold solo cuando toda la máquina sale del estado de alimentación del sistema S0 (en funcionamiento) para entrar en un estado de suspensión o hibernación, normalmente S3 o S4. A partir de Windows 8, los controladores de dispositivos pueden permitir que sus dispositivos entren en el estado D3cold incluso mientras el sistema permanece en S0.
D3hot, que a menudo se denomina "D3", es el estado de "apagado suave" del dispositivo. En este estado, un examen de bus puede detectar el dispositivo y los comandos enviados al dispositivo pueden provocar que se vuelva a encender. En D3cold, se quitan todas las fuentes de alimentación, con la posible excepción de una pequeña cantidad de energía para controlar la lógica de reactivación del dispositivo. Por ejemplo, para dispositivos PCI Express (PCIe), la fuente de alimentación del dispositivo principal, Vcc, se desactiva con frecuencia en una transición a D3cold. Apagar Vcc puede reducir el consumo de energía y ampliar el tiempo que una plataforma de hardware móvil puede ejecutarse con una carga de batería. Cuando un dispositivo está en D3cold, no se puede detectar mediante un examen de bus y no puede recibir comandos. La restauración de la potencia de VCC mueve el dispositivo a un estado no inicializado, que suele ser equivalente al estado D0. Después, el software debe volver a inicializar el dispositivo para ponerlo en estado de trabajo.
Colocar un dispositivo en D3cold no significa necesariamente que se hayan quitado todas las fuentes de alimentación del dispositivo, sino que solo se quita la fuente de alimentación principal, Vcc. La fuente de alimentación auxiliar, Vaux, también se puede quitar si no es necesaria para la lógica de reactivación. Sin embargo, un dispositivo que podría ser necesario para indicar un evento de reactivación al procesador debe poder dibujar suficiente energía para operar la lógica de reactivación. Por ejemplo, una tarjeta de interfaz de red Ethernet (NIC) cuya fuente de alimentación principal se quita podría extraer suficiente energía del cable Ethernet. O bien, la alimentación en espera a una NIC de Wi-Fi podría suministrarse desde un origen fuera de la interfaz PCIe, en cuyo caso la interfaz PCIe puede estar completamente desactivada.
En la siguiente explicación, se describe un conjunto de requisitos para habilitar las transiciones de estado de energía del dispositivo a D3cold. Estos requisitos se dividen en las dos categorías siguientes:
Requisitos de firmware y plataforma
Requisitos del controlador de dispositivo
La primera de estas dos categorías es el foco principal de esta discusión. Se presenta una breve introducción a la segunda categoría. Para obtener más información sobre los requisitos del controlador de dispositivo, consulte Compatibilidad con D3cold en un controlador.
Requisitos de firmware y plataforma
En la siguiente explicación, se presentan los requisitos de firmware y plataforma para habilitar D3cold para estos dos casos:
Cuando el dispositivo se enumera en ACPI.
Cuando el dispositivo se enumera mediante su bus primario.
La mayoría de las siguientes discusiones son específicas de PCIe. Sin embargo, los principios generales que se describen aquí se aplican en gran medida a otros autobuses.
Abstraer algunos detalles, la transición de D3cold a D0 se desencadena al volver a aplicar la potencia VCC al dispositivo incrustado. La nueva aplicación de energía restaura eficazmente la conexión del dispositivo al bus. Windows lee los identificadores del dispositivo para distinguir entre los dos casos siguientes:
Se quitó un dispositivo y se reemplazó por otro dispositivo.
Se quitó el mismo dispositivo y, a continuación, se reinsertó.
Si los identificadores coinciden, el controlador de dispositivo reinicializa el dispositivo. Si los identificadores no coinciden, Windows descarga el controlador de dispositivo y compila una nueva pila de controladores para el nuevo dispositivo. PCIe, por ejemplo, consulta el identificador de proveedor, el identificador de dispositivo y los identificadores del subsistema (que se dividen en identificadores de subproceso y subproveedores en algunas versiones de la especificación). Estos identificadores deben coincidir con los del dispositivo conectado previamente después de que se vuelva a aplicar la alimentación (y transcurre el período de espera especificado por bus); De lo contrario, Windows considerará que el nuevo dispositivo es diferente del anterior.
Caso 1: Un dispositivo incrustado se enumera en ACPI
Si un dispositivo incrustado no se puede detectar mediante mecanismos definidos por una especificación de bus como PCIe o USB, pero el dispositivo está conectado permanentemente (o al menos la conexión está dedicada a un dispositivo conocido), este dispositivo se puede describir en el firmware de la plataforma por ACPI _HID o objetos _CID. Estos objetos permiten enumerar el dispositivo mediante OSPM. ("OSPM" es un término definido en la especificación ACPI. Significa, de forma flexible, "software que no es firmware". OSPM enumera un dispositivo solo cuando ningún enumerador de bus puede detectar el identificador del dispositivo. Por ejemplo, OSPM enumera los dispositivos de un bus ISA. Además, los dispositivos de un sistema en un chip (SoC) a menudo se enumeran mediante ACPI porque están en tejido no enumerable. Algunos ejemplos de estos dispositivos son los controladores de host USB y SD.
Firmware de la plataforma (enumerado en ACPI)
OSPM usa \_SB._OSC para transmitir funcionalidades de OSPM para toda la plataforma al firmware de la plataforma. El firmware de la plataforma debe establecer el bit 2 en el valor devuelto \_SB._OSC para indicar a OSPM que el dispositivo admite _PR3. Para obtener más información, consulte la sección 6.2.10.2, "Platform-Wide OSPM Capabilities", en la especificación ACPI 5.0.
Dispositivo incrustado (detectado únicamente a través de ACPI)
Para admitir D3cold, el firmware de la plataforma debe implementar los siguientes objetos de recursos de energía ACPI para el dispositivo incrustado:
_PR0: este objeto se evalúa como los requisitos de energía del dispositivo en el estado de alimentación del dispositivo D0 (totalmente activado). El valor devuelto es la lista de recursos de energía que el dispositivo requiere en el estado D0.
_PR2: este objeto se evalúa como los requisitos de energía del dispositivo en el estado de alimentación del dispositivo D2. El valor devuelto es la lista de recursos de energía que el dispositivo requiere en el estado D2. Tenga en cuenta que, por motivos históricos, Windows espera que _PR2 esté presente siempre que _PR0 esté presente. Si D2 se implementa en el hardware, _PR2 enumera los recursos de energía necesarios para D2. Si no se implementa D2, _PR2 enumera los mismos recursos que _PR0.
_PR3: este objeto se evalúa como los requisitos de energía del dispositivo en el estado de alimentación del dispositivo D3hot. El valor devuelto es la lista de recursos de energía que el dispositivo requiere en el estado D3hot.
Para cada recurso de energía identificado en cualquier objeto _PRx, se deben implementar los métodos de control siguientes:
_OFF: establezca el recurso de energía en el estado de apagado (apague el recurso).
_ON: establezca el recurso de energía en el estado activado (encendido del recurso).
_STA: este objeto se evalúa como el estado de encendido o apagado actual del recurso de alimentación (0: desactivado, 1: activado).
Una transición a D3cold se produce cuando ACPI ejecuta el método de control _OFF en los recursos de energía enumerados en _PR3. Tenga en cuenta que si el controlador de funciones del dispositivo indica compatibilidad con D3cold, esta compatibilidad no implica que todas las transiciones a D3 produzcan transiciones rápidas a D3cold. Es posible que el dispositivo entre y permanezca en D3hot durante un período prolongado y, a continuación, vuelva a D0 sin entrar en D3cold, o entra en D3cold más adelante.
Dispositivo primario (enumerado en ACPI)
No es necesario que un dispositivo primario pueda administrarse con energía. Sin embargo, si un dispositivo primario está administrado con energía, Windows nunca apaga este dispositivo si alguno de sus elementos secundarios (dispositivos dependientes) no está en D3.
Ejemplo (enumerado en ACPI)
En el diagrama de bloques siguiente se muestra un dispositivo incrustado (etiquetado como EMBD) en un bus del sistema. La alimentación principal (Vcc) y la alimentación auxiliar (Vaux) para el dispositivo se pueden activar y desactivar de forma independiente a través del bloque etiquetado como Lógica de alimentación.
En el siguiente ejemplo de código ASL se describen los recursos de energía utilizados por el dispositivo incrustado en el diagrama anterior. Este ejemplo comienza con una declaración de un método de control _OSC que describe las funciones del controlador de dispositivo. A continuación, se declaran los dos recursos de energía del dispositivo: los nombres de recursos PVCC y PVAX se asignan a las fuentes de alimentación principal y auxiliar del dispositivo, Vcc y Vaux. Por último, se enumeran los requisitos de recursos de energía para cada estado de alimentación del dispositivo que admite el dispositivo y se describen las funcionalidades de reactivación del dispositivo.
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
Caso 2: Un dispositivo incrustado está enumerado por bus
Si el dispositivo incrustado se ajusta a una especificación de bus común, como PCIe o USB, este dispositivo se puede detectar a través de mecanismos definidos por bus y la alimentación se puede suministrar parcialmente o totalmente a través del bus. Si este dispositivo no está alimentado por otros recursos de energía de banda lateral, la fuente de alimentación principal del dispositivo es el vínculo que conecta el dispositivo al controlador de bus primario. Los dispositivos enumerados por bus se pueden identificar mediante el objeto _ADR en la definición del dispositivo incrustado. Se usa un objeto _ADR para proporcionar OSPM con la dirección de un dispositivo en el bus primario del dispositivo incrustado. Esta dirección se usa para vincular la representación del bus del dispositivo (como se ve en el hardware del bus) a la representación del dispositivo de la plataforma (como se ve en el firmware ACPI). (La codificación de direcciones _ADR es específica del bus. Para obtener más información, vea la sección 6.1.1, "_ADR (dirección)", en la especificación ACPI 5.0). Cuando se emplea este mecanismo, la compatibilidad con D3cold debe coordinarse con el controlador de bus primario.
Si la fuente de alimentación principal de un dispositivo incrustado es el vínculo que conecta este dispositivo a su bus primario, el requisito clave para colocar el dispositivo en D3cold es apagar el vínculo. Para obtener más información sobre la transición a D3cold, consulte el gráfico de estado en Estados de energía del dispositivo.
Firmware de la plataforma (enumerado en bus)
OSPM usa \_SB._OSC para transmitir funcionalidades de OSPM para toda la plataforma al firmware de la plataforma. El firmware de la plataforma debe establecer el bit 2 en el valor devuelto \_SB._OSC para indicar a OSPM que el dispositivo admite _PR3. Para obtener más información, consulte la sección 6.2.10.2, "Platform-Wide OSPM Capabilities", en la especificación ACPI 5.0.
Dispositivo incrustado (enumerado en bus)
No se requieren cambios ACPI específicos de D3cold. En este caso, siempre y cuando el controlador y la plataforma del dispositivo hayan indicado compatibilidad con D3cold, el vínculo de bus que suministra alimentación al dispositivo incrustado se puede desactivar cuando el bus primario sale de D0 y entra en un estado de bajo consumo Dx. La transición del dispositivo incrustado de D3hot a D3cold se produce cuando se quita la alimentación del vínculo. El estado Dx que entra el bus primario puede ser cualquier estado que haga que la fuente de alimentación del vínculo se desactive.
Dispositivo primario (enumerado en bus)
El descriptor ACPI del bus primario debe hacer lo siguiente:
Implemente _S0W(Dx). Este objeto especifica Dx como el estado D de menor potencia desde el que el dispositivo secundario (incrustado) puede reactivarse cuando el sistema está en estado S0.
Defina los recursos de energía para representar el vínculo que conecta el dispositivo secundario (incrustado) al bus primario. Además, los objetos _ON, _OFF y _STA deben definirse para este recurso de energía. El ejemplo de código ASL que sigue a esta lista describe la potencia de vínculo como dos recursos, PVC1 y PVX1. Para cada uno de estos recursos, se definen _ON, _OFF y objetos _STA.
Si "Dx" (el estado D de menor potencia; ver el primer elemento de lista) es D3cold, proporcione un objeto _PR3 que incluya los recursos de energía que requiere el dispositivo secundario (incrustado) para D3hot (por ejemplo, Vcc y Vaux). Si se requieren las mismas fuentes de alimentación para D0, D2 y D3hot, _PR0, _PR2 y _PR3 todos especifiquen los mismos recursos de energía. Estos recursos solo se desactivan cuando el dispositivo secundario entra en D3cold.
Por motivos históricos, Windows espera que _PR2 esté presente cada vez que _PR0 esté presente. Si D2 se implementa en el hardware, _PR2 enumera los recursos de energía necesarios para D2. Si no se implementa D2, _PR2 enumera los mismos recursos que _PR0.
Implemente _PR0. La lista de recursos del objeto _PR0 del bus primario debe incluir los recursos que impulsan el vínculo que conecta el bus primario al dispositivo secundario (incrustado).
Ejemplo (enumerado en bus)
La configuración de hardware de ejemplo del diagrama de bloques siguiente muestra dos formas diferentes de habilitar D3cold para dispositivos PCIe. En primer lugar, un punto de conexión (con la etiqueta ENDP) está conectado a un puerto raíz PCIe (RP01) y recibe energía auxiliar de su dispositivo primario a través de un vínculo PCIe. En segundo lugar, el dispositivo de audio HD del diagrama no tiene ningún vínculo estándar a su dispositivo primario (el controlador PCI etiquetado PCI0) y, por tanto, se modela de forma similar al caso enumerado por ACPI.
El dispositivo RP01 de este diagrama tiene una fuente de alimentación principal, Vcc1 y una fuente de alimentación auxiliar, Vaux1. Del mismo modo, el dispositivo HD Audio tiene una fuente de alimentación principal, Vcc2 y una fuente de alimentación auxiliar, Vaux2.
En el código ASL siguiente se describe el controlador de bus primario (PCI0) y los recursos de energía necesarios para los dispositivos ENDP y HD Audio que se muestran en el diagrama anterior.
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
Otras posibilidades
Las técnicas que se muestran en los dos ejemplos anteriores se pueden combinar para admitir configuraciones que usan la potencia de bus y la potencia de banda lateral.
Requisitos del controlador de dispositivo
El propietario de la directiva de energía de un dispositivo (normalmente el controlador de función) indica al sistema operativo si se debe habilitar la transición del dispositivo de D3hot a D3cold. El controlador puede proporcionar esta información en el archivo INF que instala el dispositivo. O bien, el controlador puede llamar a la rutina SetD3ColdSupport en tiempo de ejecución para habilitar o deshabilitar dinámicamente las transiciones del dispositivo a D3cold. Al permitir que un dispositivo escriba D3cold, un controlador garantiza el siguiente comportamiento:
El dispositivo puede tolerar una transición de D3hot a D3cold cuando el equipo debe permanecer en S0.
El dispositivo funcionará correctamente cuando vuelva a D0 desde D3cold.
Un dispositivo que no cumple cualquiera de los requisitos podría, después de escribir D3cold, no estar disponible hasta que se reinicie el equipo o entre en estado de suspensión. Si el dispositivo debe poder indicar un evento de reactivación desde cualquier estado dx de bajo consumo que entre, la entrada a D3cold no debe estar habilitada a menos que el controlador esté seguro de que la señal de reactivación del dispositivo funcionará en D3cold.
Para obtener más información, vea Compatibilidad con D3cold en un controlador.