Hardware de la cámara
Información general de la topología
En términos de compatibilidad con controladores de Windows, el subsistema de cámara contiene componentes fuera del sistema en un chip (SoC), como el sensor de cámara, una unidad de enfoque automático opcional y flash, y posiblemente otro hardware asociado. El hardware de la cámara también incluye las unidades de procesamiento de imágenes on-SoC.
El hardware de procesamiento de imágenes on-SoC debe ser administrado por el complemento del motor de alimentación (PEP) proporcionado por el proveedor de SoC. El hardware de procesamiento de imágenes debe enumerarse como un único dispositivo en ACPI y administrado por un controlador de Windows Driver Framework (WDF). Habilite la administración del sistema del tiempo de espera de inactividad del dispositivo de procesamiento de imágenes para que el PEP pueda controlar cualquier reloj y topología de uso compartido de raíl de alimentación que sea única para el SoC. Cualquier hardware de procesamiento de imágenes on-SoC debe apagarse siempre que el dispositivo de cámara esté apagado.
Algunos diseños de SoC tienen un bloque de función compartido que realiza la captura de cámara y otros procesamientos de imágenes y gráficos. En una plataforma que usa este tipo de SoC, el PEP proporcionado por el proveedor de SoC debe hacer referencia al uso de este bloque compartido y apagarlo cuando todos los clientes están inactivos.
En algunas plataformas, el hardware de procesamiento de imágenes on-SoC puede compartirse entre dos o más dispositivos de cámara. En este caso, el hardware de procesamiento de imágenes se multiplexa entre los dispositivos de cámara. Los componentes de cada dispositivo de cámara deben describirse de forma independiente en el espacio de nombres ACPI y deben enumerarse como objetos de dispositivo independientes para el administrador de Windows Plug and Play.
Windows requiere que Windows pueda usar (es decir, transmitir contenido de) ambas cámaras (o todas) al mismo tiempo con cualquier combinación de los modos y resoluciones compatibles con las cámaras individuales. Los proveedores de SoC que no pueden cumplir este requisito deben trabajar directamente con Microsoft para obtener instrucciones sobre cómo implementar sus controladores y firmware del sistema.
Configuración de energía admitida
Windows admite una única configuración de administración de energía de hardware para dispositivos de cámara en plataformas modernas en espera. En resumen, cada sensor de cámara debe estar conectado al sistema en un chip (SoC) a través de un vínculo MIPI-CSI y, opcionalmente, puede conectarse a un bus I2C y a uno o varios pines GPIO. El dispositivo del sensor de cámara, su flash opcional y cualquier otro componente de cámara off-SoC debe colocarse en un raíl de alimentación que el firmware ACPI pueda encender y apagar.
Si, además de un vínculo MIPI-CSI, el dispositivo de cámara tiene patillas I2C o GPIO para controlar el sensor de cámara o el dispositivo flash, estas patillas deben enrutarse a las patillas correspondientes del controlador I2C o del controlador GPIO en el SoC. El integrador del sistema debe enumerar los recursos I2C y GPIO para el sensor de cámara y el dispositivo flash en un objeto _CRS bajo el dispositivo de cámara en el espacio de nombres ACPI.
Nota El integrador del sistema debe trabajar con el desarrollador del controlador del subsistema de cámara para determinar cómo esperan que se ordenen los recursos GPIO e I2C. Por ejemplo, un controlador que recibe dos recursos I2C distingue entre ellos en función del orden en que aparecen en la lista de recursos. Del mismo modo, un controlador que recibe tres recursos gpIO espera que estos recursos se muestren en un orden determinado. El integrador del sistema debe enumerar los recursos I2C y GPIO en el mismo orden en el objeto _CRS.
El sensor de cámara y el dispositivo flash deben colocarse en un raíl de alimentación que los métodos de control ACPI pueden activar y apagar. Se recomienda usar una patilla GPIO desde el SoC para controlar el hardware del conmutador de alimentación. El GPIO debe enumerarse en una región de operación GPIO para que los métodos de control ACPI puedan cambiar su estado. El integrador del sistema debe describir el recurso de alimentación de un dispositivo de cámara (sensor, flash o cualquier otro componente de cámara) en el espacio de nombres ACPI. Este recurso debe incluir un método _ON y un método _OFF para cambiar el estado de la señal GPIO enrutada al hardware del conmutador de alimentación. En el dispositivo de cámara del espacio de nombres ACPI, el integrador del sistema debe proporcionar un objeto _PR0 y un objeto _PR3 que haga referencia al recurso de energía.
Cuando el controlador de controlador de cámara detecta que todos los pines de streaming han entrado en el estado KSSTATE_STOP, usa una interfaz privada para indicar a los controladores que controlan los componentes de la cámara off-SoC que capturan ya no son necesarios. A su vez, estos controladores llaman al método IWDFDevice2::ResumeIdle para indicar al marco del controlador que su hardware está inactivo. En respuesta, el marco de trabajo del controlador inicia una transición a D3, lo que hace que un IRP D3 fluya a través de la pila del controlador del dispositivo de cámara. (Un IRP D3 es un IRP IRP_MJ_POWER que especifica un valor de enumeración DEVICE_POWER_STATE de PowerDeviceD3). El controlador ACPI de Windows, Acpi.sys, observará el IRP D3 y ejecutará el método _OFF del recurso de energía identificado por el objeto _PR3 bajo el dispositivo de cámara en el espacio de nombres ACPI.
En la última frase del párrafo anterior se supone que el recurso de energía no proporciona energía a ningún dispositivo que no sea el dispositivo de una cámara. Si otros dispositivos tienen referencias a este recurso de energía, Acpi.sys ejecutará el método _OFF solo después de que todos los demás dispositivos que hagan referencia al recurso de energía hayan pasado a D3. Para obtener más información, vea Habilitación de transiciones a D3cold.
Devolver el hardware de la cámara al estado de energía activo es un proceso similar. Cuando el controlador de la cámara detecta el primer pin de captura de secuencia para entrar en el estado KSSTATE_ACQUIRE, el controlador de cámara se comunica con los controladores para los demás componentes on-SoC y off-SoC que componen el subsistema de cámara. En respuesta, el controlador que controla la unidad de procesamiento de imágenes on-SoC llama al método IWDFDevice2::StopIdle, que informa al PEP de que el hardware de la unidad de procesamiento de imágenes debe estar encendido. El controlador de la cámara indica a los controladores que controlan los componentes de la cámara fuera de SoC que deben volver al estado activo. A su vez, estos controladores llaman a StopIdle para informar al marco del controlador de que el hardware ya no está inactivo, lo que hace que un IRP D0 fluya a través de la pila del controlador del dispositivo de cámara. (Un IRP D0 es un IRP IRP_MJ_POWER que especifica un valor de enumeración DEVICE_POWER_STATE de PowerDeviceD0). Acpi.sys responde al IRP D0 ejecutando el método _ON del recurso de energía identificado por el objeto _PR0 bajo el dispositivo de cámara en el espacio de nombres ACPI.
Si la plataforma tiene varios dispositivos de cámara, cada dispositivo de cámara debe tener su propio recurso de alimentación y raíl de alimentación conmutable de forma independiente que se describe en el espacio de nombres ACPI. Para cada dispositivo de cámara del espacio de nombres ACPI, el integrador del sistema debe proporcionar un objeto _PLD que indique si el dispositivo de cámara está en la parte delantera o posterior del equipo. Si un dispositivo de cámara está integrado en la tapa de un equipo con factor de forma de clamshell y se enfrenta al usuario cuando la tapa está abierta, el objeto _PLD de este dispositivo debe indicar que la cámara está en la parte delantera de la plataforma. Si un dispositivo de cámara está integrado en la tapa de un equipo de factor de forma de clamshell y se aleja del usuario cuando la tapa está abierta, el objeto _PLD de este dispositivo debe indicar que la cámara está en la parte posterior del sistema.
Problemas de reactivación
El hardware del dispositivo de cámara no debe admitir la reactivación. Windows no espera que los dispositivos de cámara puedan reactivar el SoC desde su estado de energía más bajo durante el modo de espera moderno. Muchos teléfonos móviles permiten que el SoC se despierte cuando el usuario presiona el botón de la cámara. Windows trata el botón de cámara como un dispositivo de entrada de usuario cuya operación es independiente de la integración del sytem o la administración de energía del dispositivo de cámara, su sensor y flash opcional.