Administración de energía de dispositivos
La especificación ACPI 6.3 define un conjunto de objetos de espacio de nombres para especificar la información de energía del dispositivo para un dispositivo. Por ejemplo, un conjunto de objetos puede especificar los recursos de energía que requiere un dispositivo en cada estado de alimentación de dispositivo admitido. Otro tipo de objeto puede describir la capacidad del dispositivo de reactivarse desde un estado de bajo consumo en respuesta a eventos de hardware.
Administración de energía de dispositivos en Windows
Mientras se ejecuta un sistema (es decir, el sistema está en estado de trabajo definido por ACPI, S0), los dispositivos individuales pueden realizar transiciones entre estados de alimentación del dispositivo, dependiendo de la actividad, para ahorrar energía. En los sistemas de PC tradicionales, los estados de suspensión definidos por ACPI (S1 a S4) también se usan para ahorrar energía, pero estos estados de suspensión de alta latencia y desconectados no se usan en plataformas SoC de Windows. Por lo tanto, la duración de la batería depende en gran medida de cómo implementan las plataformas la administración de energía de dispositivos en tiempo de ejecución.
Los dispositivos integrados en el SoC se pueden administrar mediante Windows Power Framework (PoFx). Estos dispositivos integrados en el marco son administrados por PoFx a través de un complemento de motor de alimentación específico de SoC (microPEP) que conoce los detalles de los controles de encendido y reloj del SoC. Para obtener más información sobre PoFx, consulte Introducción a Power Management Framework.
En el caso de los dispositivos periféricos que no están integrados en el SoC, Windows usa la administración de energía de dispositivos ACPI. Para estos dispositivos administrados por ACPI, el propietario de la directiva de energía de una pila de controladores de dispositivo (normalmente la función o el controlador de clase) toma decisiones de transición de estado de energía del dispositivo y el controlador ACPI de Windows, Acpi.sys, invoca métodos de control ASL para aplicar los controles de energía específicos de la plataforma necesarios.
Es posible, y algunas pilas de dispositivos lo hacen, usar la administración de energía de dispositivos ACPI solo o en combinación con el microPEP para la administración de energía de dispositivos en soC.
Como se describe en Administración de energía de dispositivos en ACPI, Windows admite las capacidades de administración de energía D3cold definidas en la especificación ACPI 5.0. Al usar esta compatibilidad, los dispositivos, las plataformas y los controladores pueden optar por tener energía del dispositivo completamente eliminada durante períodos de inactividad en tiempo de ejecución. Esta funcionalidad puede mejorar significativamente la duración de la batería. Sin embargo, la eliminación de energía debe ser compatible con todos los componentes afectados para poder volver a D0 correctamente. Por este motivo, los controladores (bus y función), así como la propia plataforma, deben indicar que lo admiten. Para obtener más información sobre la participación del controlador D3cold, consulte Compatibilidad con D3cold en un controlador.
Administración de energía de dispositivos en ACPI
Los dispositivos de espacio de nombres admiten hasta cuatro estados de alimentación del dispositivo, D0 numerado (función completa o "activado") a D3 (sin función o "desactivado"). Cada estado puede tener requisitos de energía diferentes, con estados con un número superior que consumen menos potencia que los estados numerados inferiores. Además, el estado D3 (off) tiene dos subestados, D3hot y D3cold. El subestado D3hot requiere que el dispositivo permanezca accesible en su bus primario para que pueda responder a comandos de software específicos del bus. Este requisito, y la potencia utilizada para cumplirlo, se quitan en D3cold. Por último, un dispositivo se puede armar para reactivarse desde un estado de bajo consumo debido a un evento de hardware y, si es necesario, para sacar también la plataforma de un estado inactivo.
La plataforma indica su compatibilidad con D3cold al conceder el control del sistema operativo de la característica "compatibilidad _PR3" (bit 2) cuando se solicita mediante el método de funcionalidades de OSPM para toda la plataforma. 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.
Los dispositivos administrados con energía usan objetos secundarios para describir sus funcionalidades de energía en el sistema operativo. En las secciones siguientes se describen estas funcionalidades y objetos.
Recursos y estados de energía
Un dispositivo declara su compatibilidad con un estado de energía al enumerar el conjunto de recursos de energía que requiere para estar en ese estado. Los recursos de alimentación ACPI representan los rieles de voltaje que potencian los dispositivos y las señales de reloj que los impulsan. Estos recursos se declaran en la raíz del espacio de nombres. Cada recurso de energía tiene un _ON y un método _OFF a través del cual se controla y un método _STA para notificar su estado. Para obtener más información, vea la sección 7.1, "Declarar un objeto de recursos de energía", de la especificación ACPI 5.0.
El controlador ACPI de Windows, Acpi.sys, supervisa las dependencias de energía entre los dispositivos que comparten recursos y, a medida que estos dispositivos pasan entre estados de energía, garantiza que solo los recursos de energía que realmente necesite un dispositivo estén activados en cualquier momento determinado.
Requisitos de recursos de energía (_PRx)
Hay un objeto Power Resource Requirements (_PRx), donde x = 0, 1, 2 o 3, para cada estado de alimentación del dispositivo compatible. Cuando el controlador de dispositivo decide realizar la transición a un nuevo estado de alimentación, Acpi.sys garantiza que los recursos de energía necesarios para el nuevo estado estén activados y que los recursos que ya no estén en uso estén desactivados.
| Estado del dispositivo admitido | Objeto de requisitos de recursos que se va a usar | Recursos que se van a incluir en el objeto requirements |
|---|---|---|
| D0 (obligatorio) | _PR0 | Toda la potencia y los relojes necesarios para la función completa del dispositivo. |
| D1 | _PR1 | Cualquier encendido o reloj necesario para la funcionalidad reducida definida por la clase de este estado. |
| D2 | _PR2 | Cualquier encendido o reloj necesario para la funcionalidad reducida definida por la clase de este estado. |
| D3hot (obligatorio) | _PR3 | Solo la alimentación o los relojes necesarios para que el dispositivo aparezca en su bus y responda a un comando específico del bus. |
Si una plataforma determinada admite la característica D3cold y el controlador de dispositivo para un dispositivo opts-in a D3cold, los recursos de alimentación de la _PR3 del dispositivo se desactivarán en algún momento después de la transición a D3Cold.
Para obtener más información sobre los requisitos de recursos de energía para un dispositivo que admite D3cold, consulte Requisitos de firmware para D3cold.
Estado de alimentación del dispositivo (_PSx)
Hay un método power State, _PSx, donde x = 0, 1, 2 o 3, para cada estado de alimentación del dispositivo compatible Dx. Este método es opcional, pero, si está presente, se invoca antes de que se desactiven los recursos de energía del estado y después de que se activen los recursos de alimentación del estado. _PSx está diseñado para realizar cualquier acción específica de la plataforma necesaria en torno al ciclo de energía. _PSx no debe tener acceso a los registros de dispositivos asignados al controlador de función, acceder a los registros estándar de bus asignados al controlador de bus o apagar los recursos de encendido o apagado, que es una operación reservada para Acpi.sys.
Funcionalidades de reactivación
Es posible que los dispositivos administrados por energía puedan detectar eventos cuando se encuentra en un estado de bajo consumo y hacer que la plataforma se desencien para controlarlos. Para habilitar esta característica, Windows necesita información sobre las funcionalidades de la plataforma y el dispositivo.
Estado de reactivación del dispositivo Sx (_SxW)
En una plataforma determinada, hay una asignación específica entre estados de dispositivo que admiten la funcionalidad de reactivación y los estados del sistema que pueden responder a eventos de reactivación. ACPI define el objeto _SxW para proporcionar esta información al sistema operativo. Hay un objeto SxW para cada estado de alimentación del sistema admitido, Sx. Dado que las plataformas SoC siempre están en S0, el único objeto de interés aquí es _S0W. Este objeto especifica la capacidad de la plataforma de reactivar desde un estado inactivo de bajo consumo en respuesta a la señal de reactivación de un dispositivo. Windows usa el objeto para determinar el estado D de destino del dispositivo durante la inactividad de bajo consumo del sistema. Para obtener más información sobre _S0W, consulte la sección 7.2.20, "_S0W (estado de reactivación del dispositivo S0)", en la especificación ACPI 5.0.
En la mayoría de las plataformas SoC, los dispositivos se administran de forma agresiva al estado D3 cuando están inactivos, y el sistema es capaz de despertarse de bajo consumo inactivo mientras el dispositivo está en este estado. Para este tipo de sistema, el objeto _S0W devuelve 3 (o 4, si también admite D3cold).
_S0W(4) es un requisito para D3Cold independientemente de si el dispositivo admite la reactivación.
Cualquier estado D se puede designar como el estado compatible con reactivación más bajo, y algunas clases de dispositivo o buses usan valores diferentes. Por ejemplo, los dispositivos conectados A SDIO y USB usan el estado D2 para este estado.
Para facilitar la migración de controladores de dispositivos de Windows 7 a Windows 8 o Windows 8.1, es posible que también sea necesario que el dispositivo proporcione _S4W. Actualmente, la única clase de dispositivo que tiene este requisito es redes (Ndis.sys).
Interrupciones compatibles con reactivación (_CRS)
La descripción del recurso de un dispositivo indica que el dispositivo es capaz de detectar y señalar un evento de reactivación marcando una interrupción como "compatible con reactivación" (ExclusiveAndWake o SharedAndWake). Los controladores de dispositivos y Windows proporcionan un control especial de estas interrupciones para asegurarse de que están habilitados cuando el dispositivo pasa a un estado de bajo consumo. Para obtener más información, vea las descripciones de los descriptores de recursos Interrupt y GpioInt de la sección 6.4.3.6, "Extended Interrupt Descriptor" y la sección 6.4.3.8.1 , "GPIO Connection Descriptors", de la especificación ACPI 5.0.
Habilitación de reactivación
Según el escenario de usuario o la directiva del sistema, los dispositivos compatibles con reactivación pueden o no estar armados para reactivación. Por lo tanto, las interrupciones compatibles con reactivación pueden estar habilitadas o no cuando el dispositivo está inactivo. Además de habilitar interrupciones, Windows usa los siguientes mecanismos para habilitar la reactivación en un dispositivo.
Reactivación de suspensión del dispositivo (_DSW)
ACPI define el objeto _DSW como una manera de que el sistema operativo informe al firmware de la plataforma ACPI sobre el siguiente período de suspensión o de inactividad de bajo consumo. Este objeto es opcional y solo se usa si la plataforma tiene una necesidad de configurar el hardware de reactivación específico de la plataforma de antemano. Se proporcionan el estado D de destino para el dispositivo y el estado S de destino para el sistema. La combinación de estado D y S-state siempre cumplirá con la información proporcionada por los objetos _SxW del dispositivo.
Recursos de energía para reactivación (_PRW)
En algunos casos, los recursos de energía adicionales deben estar activados para que un dispositivo se habilite para la reactivación. En este caso, el dispositivo puede proporcionar el objeto _PRW para enumerar esos recursos de energía adicionales. El controlador ACPI de Windows, Acpi.sys, administrará estos recursos de energía como lo hace normalmente, asegurándose de que están activados cuando un dispositivo lo necesite (es decir, un dispositivo habilitado para reactivación) y se desactiven de lo contrario.
_PRW también se usa para definir la funcionalidad de reactivación para plataformas tradicionales (hardware ACPI completo).