Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
A partir de Windows 8, los dispositivos pueden entrar en el sub estado de alimentación D3cold incluso cuando el sistema permanece en estado de energía 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 con controladores de dispositivos para D3cold, consulte Compatibilidad con D3cold en un controlador.
Introducción
Los estados de energía del dispositivo se definen en la especificación ACPI y en varias especificaciones de bus. La especificación del bus PCI ha, desde que introdujo la administración de energía PCI, dividido el estado de alimentación del dispositivo D3 (apagado) en dos subestados, 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 subestados D3, pero Windows 7 y versiones anteriores solo admiten el subestado D3cold cuando el sistema completo sale del estado de energía S0 (activo) del sistema 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 estado D3cold incluso mientras el sistema permanece en S0.
D3hot, que a menudo se llama "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 todos los orígenes de energía, con la posible excepción de una pequeña cantidad de energía para impulsar 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, un examen de bus no puede detectarlo y no puede recibir comandos. La restauración de la potencia Vcc mueve el dispositivo a un estado no inicializado, que normalmente es equivalente al estado D0. A continuación, el software debe volver a inicializar el dispositivo para ponerlo en estado de trabajo.
La colocación de 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 pueda ser necesario para indicar un evento de activación al procesador debe ser capaz de consumir suficiente energía para operar la lógica de activació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 se puede suministrar 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 su bus primario enumera el dispositivo.
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.
Al abstraer algunos detalles, la transición de D3cold a D0 se desencadena al volver a aplicar la alimentación Vcc al dispositivo integrado. 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 coinciden los identificadores, el controlador de dispositivo reinicializa el dispositivo. Si los identificadores no coinciden, Windows descarga el controlador de dispositivo y crea 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 de proveedor en algunas versiones de la especificación). Estos identificadores deben coincidir con los del dispositivo previamente conectado después de restablecer la alimentación (y transcurrido el período de espera especificado por el bus); de lo contrario, Windows considerará que se trata de un dispositivo diferente al anterior.
Caso 1: Un dispositivo incrustado se enumera en ACPI
Si un dispositivo incrustado no se puede detectar a través de 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, flexiblemente, "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 de \_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 Capacidades de OSPM", en la especificación ACPI 5.0.
Dispositivo insertado (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 insertado:
Este objeto se evalúa para determinar los requisitos de energía para el dispositivo en el estado de alimentación D0 (totalmente activado). El valor devuelto es la lista de recursos de energía que requiere el dispositivo en estado D0.
Este objeto determina los requisitos de energía del dispositivo en el estado de alimentación D2 del dispositivo. El valor devuelto es la lista de recursos de energía que requiere el dispositivo en estado D2. Tenga en cuenta que, por motivos históricos, Windows espera que _PR2 estén presentes siempre que _PR0 esté presente. Si D2 se implementa en el hardware, _PR2 enumera los recursos de energía necesarios para D2. Si D2 no se implementa, _PR2 enumera los mismos recursos que _PR0.
_PR3: Este objeto se evalúa para determinar los requisitos de energía del dispositivo en el estado de potencia D3hot. El valor devuelto es la lista de recursos de energía que requiere el dispositivo en 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 (desactive el recurso).
_ON: Configure el recurso de energía al estado activado (encender el recurso).
_STA: este objeto se evalúa como el estado actual activado o desactivado del recurso de energía (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 nunca en D3cold o entre en D3cold en un momento posterior.
Dispositivo primario (enumerado en ACPI)
No es necesario que un dispositivo padre tenga la capacidad de gestionar la energía. Sin embargo, si un dispositivo primario gestiona la energía, Windows nunca apaga este dispositivo si alguno de sus dispositivos secundarios (dispositivos dependientes) no está en D3.
Ejemplo (enumerado en ACPI)
En el diagrama de bloques siguiente se muestra un dispositivo incrustado (con la etiqueta EMBD) en un bus del sistema. La potencia principal (Vcc) y la potencia auxiliar (Vaux) para el dispositivo se pueden activar y desactivar de forma independiente a través del bloque etiquetado Lógica de energía.
En el siguiente ejemplo de código ASL se describen los recursos de energía utilizados por el dispositivo insertado 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 energía 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 embebido es enumerado por el bus
Si el dispositivo insertado se ajusta a una especificación común de bus, 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. Un objeto _ADR se usa para proporcionar OSPM con la dirección de un dispositivo en el bus primario del dispositivo incrustado. Esta dirección se utiliza para vincular la representación del bus del dispositivo (tal como la interpreta el hardware del bus) con la representación que tiene de este dispositivo la plataforma (tal como la proporciona 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, el soporte técnico D3cold debe coordinarse con el controlador primario del bus.
Si la fuente de alimentación principal de un dispositivo insertado 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 plataforma (enumerado por 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 de \_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 Capacidades de OSPM", en la especificación ACPI 5.0.
Dispositivo incrustado (enumerado en bus)
No se requieren cambios específicos de ACPI para D3cold. En este caso, siempre que el controlador del dispositivo y la plataforma 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 baja potencia Dx. La transición del dispositivo insertado de D3hot a D3cold se produce cuando se quita la alimentación del vínculo. El estado Dx en el que entra el bus primario puede ser cualquier estado que provoque que se apague la fuente de alimentación del enlace.
Dispositivo primario (enumerado en bus)
El descriptor ACPI para el 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, se deben definir _ON, _OFF y _STA objetos para este recurso de energía. El ejemplo de código ASL que sigue a esta lista describe la potencia del 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; vea 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 especifican todos los mismos recursos de suministro eléctrico. Estos recursos solo se desactivan cuando el dispositivo secundario entra en D3cold.
Por motivos históricos, Windows espera que _PR2 estén presentes siempre que _PR0 esté presente. Si D2 se implementa en el hardware, _PR2 enumera los recursos de energía necesarios para D2. Si D2 no se implementa, _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 HD Audio 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.
El siguiente código ASL 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 del 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 funciones) 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 entre en D3cold, el 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 baja potencia al 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.