Administración de energía de la cámara

Modos de administración de energía

Los componentes fuera del sistema en un chip (SoC) del subsistema de cámara deben admitir dos modos de administración de energía. Los componentes de la cámara deben admitir un modo activo en el que el dispositivo de cámara transmite activamente contenido a una aplicación. Además, los componentes de la cámara deben admitir un modo de eliminación de energía en el que el dispositivo de cámara está apagado, se quita la alimentación y el dispositivo de cámara consume cero vatios. En la tabla siguiente se describen los modos de administración de energía activos y eliminados para el dispositivo de cámara.

Mode	Descripción	Estado de alimentación del dispositivo (Dx)	Consumo medio de energía	Latencia de salida a activa	Mecanismo de transición
Activo (streaming)	El dispositivo de cámara transmite activamente contenido a una aplicación. El contenido puede ser de movimiento completo, vista previa o captura de fotos todavía.	Sí	Sensor, AF y específico del flash.	N/D	Transición D0 iniciada por software. (Una aplicación ha iniciado el streaming estableciendo el estado de un pin de captura en KSSTATE_ACQUIRE).
Potencia: se ha quitado	El dispositivo de cámara no transmite contenido a ninguna aplicación. No se conserva ningún contexto en el sensor de cámara, el dispositivo flash o el motor de enfoque automático.	Sí	0 Vatios	< 200 milisegundos al primer fotograma (vea la siguiente tabla).	Transición D3 iniciada por software. (El estado de todas las patillas de streaming se ha establecido en cualquier valor distinto de KSSTATE_RUN).

Nota Windows espera que el tiempo de transición del modo activo al modo de eliminación de energía (la latencia desactivada) sea inferior a 100 milisegundos. La mayoría del esfuerzo de administración de energía se centra en reducir el tiempo de transición del modo quitado de energía al modo activo (la latencia).

Los mismos dos modos de administración de energía, activos y eliminados, deben ser compatibles con las unidades de procesamiento de imágenes on-SoC. El proveedor de SoC define los componentes individuales que componen las unidades de procesamiento de imágenes y sus estados de administración de energía. Se recomienda que un único controlador controle las unidades de procesamiento de imágenes on-SoC y que todas las unidades de procesamiento de imágenes para la captura de cámara se presenten al complemento del motor de energía (PEP) como un único componente administrado por energía.

Mecanismos de administración de energía de software

Se espera que tanto el sistema en una unidad de procesamiento de imágenes de chip (SoC) como los componentes de la cámara off-SoC no consuman energía (cero vatios) cuando el sistema está en espera conectado y la pantalla está desactivada. El mecanismo de software principal para la administración de energía es el recuento de referencias del pin de captura de cámara. El controlador del controlador de cámara mantiene este recuento de referencias, que es un minidriver AVStream. Este mecanismo básico de administración de energía se puede usar en cualquier momento en que el sistema esté activado, incluidas las horas en las que se enciende la pantalla del sistema.

El controlador de la cámara debe reenviar las transiciones de estado de administración de energía a los controladores que controlan componentes fuera del SoC, como el sensor de cámara, el enfoque automático y el flash. En respuesta, los controladores que controlan estos dispositivos deben tomar medidas específicas para cambiar los estados de energía y para quitar o aplicar energía.

Arquitectura de controlador recomendada

El subsistema de cámara debe exponerse a Windows a través de un único minidriver AVStream denominado controlador de cámara. Se recomienda que el controlador de controlador de cámara no acceda directamente al hardware y no directamente a los componentes de hardware de administración de energía. En su lugar, el controlador de cámara debe reenviar las solicitudes de administración de energía y hardware a otros controladores que componen el subsistema de cámara.

El hardware de procesamiento de imágenes on-SoC debe ser administrado por el complemento del motor de alimentación soC (PEP). El hardware de procesamiento de imágenes debe administrarse mediante un controlador de Windows Driver Frameworks (WDF) y este controlador debe habilitar la cooperación con el PEP estableciendo el miembro IdleTimeout en la estructura de WDF_DEVICE_POWER_POLICY_IDLE_SETTINGSen SystemManagedIdleTimeout. Esta configuración permite al PEP controlar cualquier reloj y topología de uso compartido de raíl de alimentación que sea única para el hardware soC. El controlador que controla la unidad de procesamiento de imágenes en el SoC debe representar toda la unidad de procesamiento de imágenes como un único componente administrado por energía para que se puedan usar las funcionalidades predeterminadas de WDF para la administración de energía.

Los componentes del subsistema de cámara off-SoC deben administrarse mediante uno o varios controladores del marco de controladores del modo kernel (KMDF). Los controladores de los componentes off-SoC deben pasar al estado de apagado (D3) cuando sus componentes ya no son necesarios para la captura de cámara. Además, los controladores de los componentes off-SoC deben habilitar D3cold, lo que permite al subsistema ACPI subyacente cambiar el estado de las líneas GPIO para aplicar y quitar energía. Para obtener más información, vea Compatibilidad con D3cold en un controlador.

En el diagrama de bloques siguiente se muestra la arquitectura de controladores recomendada.

Todos los controladores que componen el subsistema de cámara ( incluido el controlador de la cámara, el controlador de unidad de procesamiento de imágenes y los controladores de los componentes de la cámara fuera de SoC) deben enumerarse en el mismo archivo de instalación del controlador (.inf). Todos los controladores del subsistema de cámara deben ser miembros de la clase de configuración de dispositivos PnP de creación de imágenes. ClassGuid para dispositivos de creación de imágenes es {6bdd1fc6-810f-11d0-bec7-08002be2092f}.

Cada controlador que representa un único componente de cámara debe enumerarse como un único dispositivo en el espacio de nombres ACPI.

Estados activos y eliminados de energía

El controlador de cámara debe realizar la transición de los dispositivos de cámara al estado de eliminación de energía cuando ninguna aplicación transmite contenido desde el dispositivo de cámara. Una aplicación puede detener el streaming porque el usuario la ha cerrado o se realiza la transición al segundo plano y se suspende.

Si una aplicación inicia el streaming desde una cámara cuyos dispositivos están en estado de eliminación de energía, el controlador de cámara debe volver a realizar la transición de los dispositivos de cámara al estado activo en 100 milisegundos.

Para cambiar los estados de potencia de los distintos componentes del subsistema de cámara, los controladores de controlador de cámara usan interfaces propietarias para comunicarse con los demás controladores que componen el subsistema de cámara. Para consultar la interfaz adecuada, un controlador del subsistema de cámara debe usar el método estándar, que es enviar una solicitud de E /S IRP_MN_QUERY_INTERFACE que recupere un conjunto de punteros de función.

El controlador de cámara debe colocar el dispositivo de cámara en estado de apagado cuando todos los pines de streaming han entrado en el estado KSSTATE_STOP . Windows suspende automáticamente las aplicaciones en primer plano cuando el usuario presiona el botón de encendido y el sistema entra en espera conectado. Cuando se suspende una aplicación de captura de cámara, se notifican las API de captura de cámara proporcionadas por el Windows Runtime y cambiarán el estado de las patillas de captura de cámara, lo que les hará entrar en el estado KSSTATE_STOP.

Cuando la primera patilla de streaming entra en el estado KSSTATE_ACQUIRE , el controlador de cámara debe colocar el dispositivo de cámara, incluida la unidad de procesamiento de imágenes on-SoC, en estado activo.

Funcionalidad de cámara asociada

El sensor de cámara y los dispositivos flash pueden tener funciones adicionales de nivel de plataforma que el controlador debe administrar. Estas funciones pueden incluir lo siguiente:

• Habilitación, deshabilitación y configuración del sensor de cámara a través del bus I2C.
• Configurando la velocidad de ráfaga flash y el nivel de brillo sobre el bus I2C.
• Detección de condiciones térmicas desde el módulo flash a través de líneas GPIO desde el módulo flash hasta el SoC.

Para implementar estas funciones, los desarrolladores de controladores de dispositivos de cámara deben usar los métodos y las instrucciones que se resumen en la tabla siguiente.

Función	Descripción	Conexión de hardware/firmware	Mecanismo de software
Configuración del sensor	Enumerar las funcionalidades del hardware del sensor de cámara o configurar su modo de funcionamiento actual.	Comunicación a través del bus I2C. Los recursos I2C se describen en el método _CRS bajo el dispositivo de cámara en el espacio de nombres ACPI.	La interfaz de solicitud de entrada/salida (E/S) de bus periférico simple (SPB) se usa para comunicarse con el controlador de host I2C y el dispositivo del sensor de cámara.
Detección de eventos del sensor	Genere eventos o indique el estado mediante líneas GPIO del sensor de cámara al SoC.	Recursos gpIO proporcionados al dispositivo de cámara. Estos recursos se describen en el método _CRS en el dispositivo de cámara en el espacio de nombres ACPI. Los patillas GPIO que indican los eventos de señal deben describirse como recursos de interrupción de GPIO.	El controlador procesa la interrupción en respuesta al evento GPIO. La interfaz de solicitud de E/S de SPB se usa para comunicarse con el dispositivo sensor para determinar la causa de la interrupción.
Configuración de Flash	Configure el dispositivo flash para la velocidad de ráfaga, el número de LED conectados u otras propiedades.	Comunicación a través del bus I2C. Los recursos I2C se describen en el método _CRS bajo el dispositivo de cámara en el espacio de nombres ACPI.	La interfaz de solicitud de E/S de SPB se usa para comunicarse con el controlador de host I2C y el dispositivo del sensor de cámara.
Coordinación con el controlador de unidad de procesamiento de imágenes	Inicie y coordine la captura con los circuitos de procesamiento de imágenes en el SoC.	N/D	La interfaz privada se expone mediante el controlador que administra las unidades de procesamiento de imágenes.

Enumeración de dispositivos de cámara

Para identificar dispositivos de cámara en la plataforma, las aplicaciones suelen consultar el administrador de Plug and Play (PnP) para instancias de dispositivos de cámara. Cada instancia de PnP corresponde a un único dispositivo de cámara. Para identificar esta instancia, el integrador del sistema define un dispositivo de cámara en el espacio de nombres ACPI. Un dispositivo de cámara puede transmitir contenido a una sola aplicación cada vez. Sin embargo, una aplicación puede transmitir desde varios dispositivos de cámara simultáneamente.

Cada dispositivo de cámara representado por el controlador de la cámara (el minidriver AVStream) debe enumerarse en el espacio de nombres ACPI como un dispositivo independiente que sea un elemento secundario del controlador de gráficos.

Como caso especial, si la plataforma SoC no es capaz de transmitir contenido simultáneamente desde todos los dispositivos de cámara de la plataforma en cualquier combinación de sus resoluciones o modos notificados, se puede enumerar un único dispositivo de cámara en su lugar. Sin embargo, esta implementación requiere una consideración cuidadosa y solo debe realizarse en colaboración directa con Microsoft.

Los dispositivos que representan el resto del subsistema de cámara ( incluida la unidad de procesamiento de imágenes on-SoC y el sensor de cámara off-SoC, el foco automático y el flash) deben enumerarse como uno o varios dispositivos en el espacio de nombres ACPI. La unidad de procesamiento de imágenes on-SoC debe enumerarse como un dispositivo independiente de los dispositivos que representan los componentes off-SoC de la cámara.

Lista de comprobación de administración de energía de la cámara

Los integradores de sistemas, los proveedores de sensores de cámara y el sistema en un chip (SoC) deben usar la lista de comprobación de este artículo para asegurarse de que su diseño de administración de energía del sistema es compatible con Windows 10.

• El integrador del sistema debe comunicarse y colaborar con el proveedor de SoC al seleccionar componentes del sensor de cámara e integrar dispositivos de cámara.
• El desarrollador del controlador de cámara debe hacer lo siguiente:
  • Desactive la alimentación en el hardware de la cámara cuando las aplicaciones ya no transmiten contenido desde el dispositivo de cámara. (Esto ocurre cuando todos los pines de captura están en estado KSSTATE_STOP).
  • Active la alimentación en el hardware de la cámara cuando una aplicación inicie el streaming desde cualquiera de los pines de captura del dispositivo de cámara.
  • Desarrolle un controlador KMDF que administre la unidad de procesamiento de imágenes on-SoC. El controlador de cámara debe usar interfaces de controlador personalizadas para indicar al controlador de unidad de procesamiento de imágenes que inicie o finalice la captura de la cámara.
  • Asegúrese de que el controlador de unidad de procesamiento de imágenes está registrado con el marco de administración de energía de Windows (PoFx) para que el PEP proporcionado por el proveedor de SoC pueda controlar la administración de energía del hardware de la unidad de procesamiento de imágenes.
  • Desarrolle un controlador de Windows Driver Frameworks (WDF) para administrar cada componente de hardware que administre el hardware de la cámara fuera del SoC, incluido el sensor de cámara, el foco automático y el flash opcional. El controlador de cámara debe usar interfaces de controlador personalizadas para indicar a los controladores que el hardware de la cámara fuera del SoC inicie o finalice la captura de la cámara.
  • Asegúrese de que los controladores que administran el hardware de la cámara fuera del SoC inician una transición D3 cuando los componentes de la cámara deben apagarse para que ACPI se informe de la transición D3 y pueda quitar energía de los componentes. • Asegúrese de que los controladores que administran el hardware de la cámara fuera del SoC inician una transición D0 cuando los componentes de la cámara deben encenderse para que ACPI se informe de la transición D0 y pueda aplicar energía a los componentes.
  • Desarrolle cualquier código de controlador para administrar la configuración del hardware del sensor de cámara o el dispositivo flash.
  • Informe al integrador del sistema sobre el orden esperado de los recursos GPIO e I2C necesarios para administrar el hardware del sensor de cámara o el dispositivo flash.
  • Asegúrese de que todos los controladores que componen el subsistema de cámara se enumeran en el mismo archivo de instalación de controladores (.inf).
  • Asegúrese de que todos los controladores que componen el subsistema de cámara son miembros de la clase de configuración de dispositivos PnP de creación de imágenes. ClassGuid para dispositivos de creación de imágenes es {6bdd1fc6-810f-11d0-bec7-08002be2092f}.
• El integrador del sistema debe diseñar el firmware ACPI de la plataforma para hacer lo siguiente:
  • Enumere cada dispositivo de cámara como un dispositivo independiente en el espacio de nombres ACPI.
  • Incluya un objeto _PLD debajo de cada dispositivo de cámara en el espacio de nombres ACPI para indicar si la cámara está en la parte delantera o posterior del equipo.
  • Incluya un recurso de energía en la raíz del espacio de nombres ACPI para cada dispositivo de cámara. Todos los componentes de hardware fuera de SoC para un dispositivo de cámara determinado (sensor, AF, flash, etc.) deben estar en un recurso de alimentación.
  • Implemente los métodos de control _ON y _OFF para cada recurso de alimentación para cambiar el estado del pin GPIO desde el SoC que controla el hardware de conmutación de raíl de alimentación.
  • Proporcione los métodos _PR0 y _PR3 en cada dispositivo de cámara del espacio de nombres para hacer referencia al recurso de energía para cada dispositivo de cámara y su hardware asociado.
  • Proporcione un objeto _CRS en cada dispositivo de cámara del espacio de nombres ACPI para enumerar los recursos GPIO e I2C para el sensor de cámara y el hardware flash. Los recursos GPIO e I2C deben estar en el orden especificado por el desarrollador del controlador del sensor de cámara.
• El integrador de sistemas debe diseñar el hardware de la plataforma y el enrutamiento de energía para que:
  • Cada dispositivo de cámara tiene su propio raíl de alimentación, que se puede controlar independientemente de los raíles de alimentación para los demás dispositivos de cámara, y que se pueden encender y desactivar mediante un pin GPIO desde el SoC.
• El integrador del sistema debe probar y comprobar que:
  • El hardware del dispositivo de cámara no consume energía (cero vatios) cuando una aplicación no usa el dispositivo de cámara. El integrador del sistema debe utilizar hardware instrumentado para medir este consumo de energía.