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 de un dispositivo. Por ejemplo, un conjunto de objetos puede especificar los recursos de energía que requiere un dispositivo en cada estado de energía de dispositivo compatible. 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 los estados de energía 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 de la forma en que las plataformas implementan 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 gestionados energéticamente por PoFx a través de un complemento de motor de energía específico del SoC (microPEP) que conoce los detalles de los controles de energía 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 en 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 algunos conjuntos de dispositivos lo hacen, usar la gestión de energía de dispositivos ACPI por sí sola o en combinación con el microPEP para la gestión de energía de dispositivos en el SoC.

Como se describe en Administración de energía de dispositivos en ACPI, Windows admite las funcionalidades 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 la energía del dispositivo completamente eliminada durante los períodos de inactividad en tiempo de ejecución. Esta capacidad puede mejorar significativamente la duración de la batería. Sin embargo, todos los componentes afectados deben admitir la desconexión de energía 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 activación del controlador D3cold, vea 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, numerados de D0 (funcionamiento total 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 energía 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, se puede habilitar un dispositivo para reactivarse desde un estado de baja potencia debido a un evento de hardware y, si es necesario, para sacar la plataforma también de un estado inactivo.

La plataforma indica su compatibilidad con D3cold otorgándole al sistema operativo el control de la característica "Soporte _PR3" (bit 2) cuando se solicita usando el Método de Capacidades de OSPM para toda la plataforma. Para obtener más información, vea la sección 6.2.10.2, "Funcionalidades de OSPM para toda la plataforma", en la especificación ACPI 5.0.

Los dispositivos gestionados por energía usan objetos secundarios para describir al sistema operativo sus capabilidades de energía. 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 raíles 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, "Declaración de un objeto de recurso 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 necesitan 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 energía del dispositivo compatible. Cuando el controlador de dispositivo decide realizar la transición a un nuevo estado de energía, 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.

Si una plataforma determinada admite la funcionalidad D3cold, y el controlador de dispositivo para un dispositivo elige utilizar D3cold, los recursos de energía del dispositivo _PR3, si no están siendo utilizados por otro 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 energía del dispositivo (_PSx)

Hay un método de Estado de energía, _PSx, donde x = 0, 1, 2 o 3, para cada estado de energía de dispositivo compatible Dx. Este método es opcional, pero, si está presente, se invoca antes de que se desactiven los recursos de energía para el estado y después de activar los recursos de energía para el estado. _PSx está pensado para realizar cualquier acción específica de la plataforma necesaria en torno al ciclo de energía. _PSx no debe acceder a los registros de los dispositivos asignados al controlador de función, acceder a los registros estándar de bus asignados al controlador del bus o activar o desactivar recursos de energía, 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 están en un estado de bajo consumo y hacer que la plataforma se active para gestionarlos. Para habilitar esta característica, Windows necesita información sobre las funcionalidades de la plataforma y el dispositivo.

Estado de activación del dispositivo Sx (_SxW)

En una plataforma determinada, hay una asignación específica entre los estados del 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 energía del sistema compatible, 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 para reactivarse desde un estado de inactividad 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 del sistema de bajo consumo. Para obtener más información sobre _S0W, vea 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 un estado de inactividad de bajo consumo 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 o no el despertar.

Cualquier estado D se puede designar como el estado compatible con reactivación con menor potencia, 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 de interrupción y GpioInt en la sección 6.4.3.6, "Descriptor de interrupción extendido", y en la sección 6.4.3.8.1, "Descriptores de conexión GPIO", de la especificación ACPI 5.0.

Activación del despertar

En función del escenario de usuario o de la directiva del sistema, los dispositivos compatibles con reactivación pueden estar realmente armados o no para la reactivación. Por lo tanto, las interrupciones que admiten reactivación pueden estar habilitadas o no mientras el dispositivo está inactivo. Además de habilitar interrupciones, Windows usa los siguientes mecanismos para habilitar la reactivación en un dispositivo.

Despertar 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 próximo período de inactividad de suspensión o 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. Tanto el estado D de destino para el dispositivo como el estado S de destino para el sistema se proporcionan. La combinación de estado D y estado S siempre se ajustará a 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 activarse para que un dispositivo se habilite para el despertar. 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 de PC tradicionales (hardware ACPI completo).