Gerenciamento de energia da câmera

Modos de gerenciamento de energia

Os componentes off-System on a Chip (SoC) do subsistema de câmera devem dar suporte a dois modos de gerenciamento de energia. Os componentes da câmera devem dar suporte a um modo ativo no qual o dispositivo de câmera está transmitindo conteúdo ativamente para um aplicativo. Além disso, os componentes da câmera devem dar suporte a um modo removido por energia no qual o dispositivo de câmera está desativado, a energia é removida e o dispositivo de câmera consome zero watts. A tabela a seguir descreve os modos de gerenciamento de energia ativos e removidos por energia para o dispositivo de câmera.

Mode	Descrição	Estado de energia do dispositivo (Dx)	Média de consumo de energia	Sair da latência para ativo	Mecanismo de transição
Ativo (streaming)	O dispositivo de câmera está transmitindo conteúdo ativamente para um aplicativo. O conteúdo pode ser de movimento completo, visualização ou captura de fotos.	Sim	Sensor, AF e flash específicos.	N/D	Transição D0 iniciada pelo software. (Um aplicativo iniciou o streaming definindo o estado de um pino de captura como KSSTATE_ACQUIRE.)
Energia – removido	O dispositivo de câmera não está transmitindo conteúdo para nenhum aplicativo. Nenhum contexto é preservado no sensor da câmera, no dispositivo flash ou no mecanismo de foco automático.	Sim	Zero watts	< 200 milissegundos para o primeiro quadro (confira a tabela a seguir.)	Transição D3 iniciada pelo software. (O estado de todos os pinos de streaming foi definido como qualquer valor diferente de KSSTATE_RUN.)

Nota O Windows espera que o tempo de transição do modo ativo para o modo removido por energia (a latência desativada) seja inferior a 100 milissegundos. A maioria dos esforços de gerenciamento de energia é focada em reduzir o tempo de transição do modo removido por energia para o modo ativo (a latência em).

Os mesmos dois modos de gerenciamento de energia, ativos e removidos por energia, devem ser compatíveis com as unidades de processamento de imagem no SoC. O fornecedor do SoC define os componentes individuais que compõem as unidades de processamento de imagem e seus estados de gerenciamento de energia. Recomendamos que um único driver controle as unidades de processamento de imagem no SoC e que todas as unidades de processamento de imagem para captura de câmera sejam apresentadas ao PEP (plug-in do power engine) como um único componente gerenciado por energia.

Mecanismos de gerenciamento de energia de software

Tanto as unidades de processamento de imagem on-System on a Chip (SoC) quanto os componentes de câmera off-SoC devem consumir energia (zero watts) quando o sistema estiver em espera conectado e a tela estiver desativada. O principal mecanismo de software para o gerenciamento de energia é a contagem de referência do pin de captura da câmera. Essa contagem de referência é mantida pelo driver do controlador de câmera, que é um minidriver AVStream. Esse mecanismo básico de gerenciamento de energia pode ser usado sempre que o sistema é ativado, incluindo os horários em que a exibição do sistema é ativada.

O driver do controlador de câmera deve encaminhar transições de estado de gerenciamento de energia para os drivers que controlam componentes fora do SoC, como o sensor da câmera, o foco automático e o flash. Em resposta, os drivers que controlam esses dispositivos devem tomar medidas específicas para alterar os estados de energia e remover ou aplicar energia.

Arquitetura de driver recomendada

O subsistema da câmera deve ser exposto ao Windows por meio de um único minidriver AVStream chamado driver de controlador de câmera. Recomendamos que o driver do controlador de câmera não acesse o hardware diretamente e não os componentes de hardware de gerenciamento de energia diretamente. Em vez disso, o driver do controlador de câmera deve encaminhar o gerenciamento de energia e as solicitações de hardware para outros drivers que compõem o subsistema da câmera.

O hardware de processamento de imagem no SoC deve ser gerenciado por energia pelo PEP (plug-in do power engine) do SoC. O hardware de processamento de imagem deve ser gerenciado por um driver WDF (Estruturas de Driver do Windows) e esse driver deve habilitar a cooperação com o PEP definindo o membro IdleTimeout na estrutura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS como SystemManagedIdleTimeout. Essa configuração permite que o PEP controle qualquer topologia de compartilhamento de relógio e power rail exclusiva para o hardware soc. O driver que controla a unidade de processamento de imagem no SoC deve representar toda a unidade de processamento de imagem como um único componente gerenciado por energia para que os recursos padrão do WDF para o gerenciamento de energia possam ser usados.

Os componentes do subsistema de câmera off-SoC devem ser gerenciados por um ou mais drivers KMDF (Kernel-Mode Driver Framework ). Os drivers para os componentes fora do SoC devem fazer a transição para o estado D3 (removido por energia) quando seus componentes não forem mais necessários para captura de câmera. Além disso, os drivers para os componentes fora do SoC devem habilitar o D3cold, o que permite que o subsistema ACPI subjacente altere o estado das linhas GPIO para aplicar e remover energia. Para obter mais informações, consulte Suporte a D3cold em um driver.

O diagrama de bloco a seguir mostra a arquitetura de driver recomendada.

Todos os drivers que compõem o subsistema da câmera, incluindo o driver do controlador de câmera, o driver da unidade de processamento de imagem e os drivers para os componentes da câmera off-SoC, devem ser enumerados no mesmo arquivo de instalação do driver (.inf). Todos os drivers de subsistema de câmera devem ser membros da classe de configuração do dispositivo PnP de imagem. O ClassGuid para dispositivos de imagem é {6bdd1fc6-810f-11d0-bec7-08002be2092f}.

Cada driver que representa um único componente de câmera deve ser enumerado como um único dispositivo no namespace ACPI.

Estados ativos e removidos por energia

O driver do controlador de câmera deve fazer a transição dos dispositivos de câmera para o estado removido por energia quando nenhum aplicativo estiver transmitindo conteúdo do dispositivo de câmera. Um aplicativo pode interromper o streaming porque foi fechado pelo usuário ou está em transição para o segundo plano e está suspenso.

Se um aplicativo iniciar o streaming de uma câmera cujos dispositivos estão no estado de energia removida, o driver do controlador de câmera deverá fazer a transição dos dispositivos de câmera de volta para o estado ativo dentro de 100 milissegundos.

Para alterar os estados de energia dos vários componentes do subsistema de câmera, os drivers do controlador de câmera usam interfaces proprietárias para se comunicar com os outros drivers que compõem o subsistema da câmera. Para consultar a interface apropriada, um driver de subsistema de câmera deve usar o método padrão, que é enviar uma solicitação de E/ S IRP_MN_QUERY_INTERFACE que recupera um conjunto de ponteiros de função.

O driver do controlador de câmera deve colocar o dispositivo de câmera no estado de energia removida quando todos os pinos de streaming tiverem entrado no estado KSSTATE_STOP . O Windows suspende automaticamente os aplicativos em primeiro plano quando o usuário pressiona o botão de energia e o sistema entra em espera conectado. Quando um aplicativo de captura é suspenso, as APIs de captura de câmera fornecidas pelo Windows Runtime são notificadas e alterarão o estado dos pinos de captura da câmera, fazendo com que eles entrem no estado KSSTATE_STOP.

Quando o primeiro pino de streaming entra no estado KSSTATE_ACQUIRE , o driver do controlador de câmera deve colocar o dispositivo de câmera, incluindo a unidade de processamento de imagem no SoC, no estado ativo.

Funcionalidade de câmera associada

O sensor de câmera e os dispositivos flash podem ter funções adicionais no nível da plataforma que devem ser gerenciadas pelo driver. Essas funções podem incluir o seguinte:

• Habilitar, desabilitar e configurar o sensor de câmera no barramento I2C.
• Configurando a taxa de intermitência flash e o nível de brilho sobre o barramento I2C.
• Detectando condições térmicas do módulo flash por meio de linhas GPIO do módulo flash para o SoC.

Para implementar essas funções, os desenvolvedores de driver de dispositivo de câmera devem usar os métodos e as diretrizes resumidos na tabela a seguir.

Função	Descrição	Conexão de hardware/firmware	Mecanismo de software
Configuração do sensor	Enumerar os recursos do hardware do sensor de câmera ou configurar seu modo de operação atual.	Comunicação pelo barramento I2C. Os recursos de I2C são descritos no método _CRS no dispositivo de câmera no namespace ACPI.	A interface de solicitação de entrada/saída (E/S) do SPB (barramento periférico simples) é usada para se comunicar com o controlador de host I2C e o dispositivo de sensor de câmera.
Detecção de eventos de sensor	Gere eventos ou indique status usando linhas GPIO do sensor da câmera para o SoC.	Recursos de GPIO fornecidos para o dispositivo de câmera. Esses recursos são descritos no método _CRS no dispositivo de câmera no namespace ACPI. O GPIO fixa que os eventos de sinal devem ser descritos como recursos de interrupção do GPIO.	A interrupção é processada pelo driver em resposta ao evento GPIO. A interface de solicitação de E/S do SPB é usada para se comunicar com o dispositivo de sensor para determinar a causa da interrupção.
Configuração flash	Configure o dispositivo flash para taxa de intermitência, número de LEDs conectados ou outras propriedades.	Comunicação pelo barramento I2C. Os recursos de I2C são descritos no método _CRS no dispositivo de câmera no namespace ACPI.	A interface de solicitação de E/S do SPB é usada para se comunicar com o controlador de host I2C e o dispositivo de sensor de câmera.
Coordenação com o driver de unidade de processamento de imagem	Inicie e coordene a captura com o circuito de processamento de imagem no SoC.	N/D	A interface privada é exposta pelo driver que gerencia as unidades de processamento de imagem.

Enumeração de dispositivo de câmera

Para identificar dispositivos de câmera na plataforma, os aplicativos normalmente consultam o gerenciador de Plug and Play (PnP) em busca de instâncias de dispositivos de câmera. Cada instância PnP corresponde a um único dispositivo de câmera. Para identificar essa instância, o integrador do sistema define um dispositivo de câmera no namespace ACPI. Um dispositivo de câmera pode transmitir conteúdo para apenas um aplicativo por vez. No entanto, um aplicativo pode transmitir de vários dispositivos de câmera simultaneamente.

Cada dispositivo de câmera representado pelo driver do controlador de câmera (o minidriver AVStream) deve ser enumerado no namespace ACPI como um dispositivo separado que é filho do driver gráfico.

Como um caso especial, se a plataforma SoC não for capaz de transmitir simultaneamente conteúdo de todos os dispositivos de câmera na plataforma em qualquer combinação de resoluções ou modos relatados, um único dispositivo de câmera poderá ser enumerado. No entanto, essa implementação requer uma consideração cuidadosa e deve ser realizada apenas em colaboração direta com a Microsoft.

Os dispositivos que representam o restante do subsistema da câmera, incluindo a unidade de processamento de imagem no SoC e o sensor de câmera off-SoC, o focalizador automático e o flash, devem ser enumerados como um ou mais dispositivos no namespace ACPI. A unidade de processamento de imagem no SoC deve ser enumerada como um dispositivo separado dos dispositivos que representam os componentes off-SoC da câmera.

Lista de verificação de gerenciamento de energia da câmera

Os integradores do sistema, os fornecedores de sensores de câmera e os fornecedores do SoC (System on a Chip) devem usar a lista de verificação neste artigo para garantir que o design de gerenciamento de energia do sistema seja compatível com Windows 10.

• O integrador do sistema deve se comunicar e colaborar com o fornecedor do SoC ao selecionar componentes do sensor de câmera e integrar dispositivos de câmera.
• O desenvolvedor do driver do controlador de câmera deve fazer o seguinte:
  • Desative a energia do hardware da câmera quando os aplicativos não estiverem mais transmitindo conteúdo do dispositivo de câmera. (Isso ocorre quando todos os pinos de captura estão no estado KSSTATE_STOP.)
  • Ative a energia do hardware da câmera quando um aplicativo iniciar o streaming de qualquer um dos pinos de captura no dispositivo de câmera.
  • Desenvolva um driver KMDF que gerencia a unidade de processamento de imagem no SoC. O driver do controlador de câmera deve usar interfaces de driver personalizadas para informar o driver da unidade de processamento de imagem para iniciar ou encerrar a captura da câmera.
  • Verifique se o driver da unidade de processamento de imagens está registrado na PoFx (estrutura de gerenciamento de energia) do Windows para que o PEP fornecido pelo fornecedor do SoC possa controlar o gerenciamento de energia do hardware da unidade de processamento de imagem.
  • Desenvolva um driver WDF (Estruturas de Driver do Windows) para gerenciar cada componente de hardware que gerencia o hardware da câmera fora do SoC, incluindo o sensor da câmera, o foco automático e o flash opcional. O driver do controlador de câmera deve usar interfaces de driver personalizadas para informar os drivers para que o hardware da câmera off-SoC inicie ou encerre a captura da câmera.
  • Verifique se os drivers que gerenciam o hardware da câmera off-SoC iniciam uma transição D3 quando os componentes da câmera devem ser desligados para que a ACPI seja informada sobre a transição D3 e possa remover a energia dos componentes. • Verifique se os drivers que gerenciam o hardware da câmera fora do SoC iniciam uma transição D0 quando os componentes da câmera devem ser ligados para que a ACPI seja informada da transição D0 e possa aplicar energia aos componentes.
  • Desenvolva qualquer código de driver para gerenciar a configuração do hardware do sensor de câmera ou do dispositivo flash.
  • Informe o integrador do sistema sobre a ordenação esperada de todos os recursos GPIO e I2C necessários para gerenciar o hardware do sensor de câmera ou o dispositivo flash.
  • Verifique se todos os drivers que compõem o subsistema da câmera estão enumerados no mesmo arquivo de instalação do driver (.inf).
  • Verifique se todos os drivers que compõem o subsistema de câmera são membros da classe de configuração do dispositivo PnP de imagem. O ClassGuid para dispositivos de imagem é {6bdd1fc6-810f-11d0-bec7-08002be2092f}.
• O integrador do sistema deve projetar o firmware acpi da plataforma para fazer o seguinte:
  • Enumerar cada dispositivo de câmera como um dispositivo separado no namespace acpi.
  • Inclua um objeto _PLD em cada dispositivo de câmera no namespace ACPI para indicar se a câmera está na parte frontal ou traseira do computador.
  • Inclua um recurso de energia na raiz do namespace acpi para cada dispositivo de câmera. Todos os componentes de hardware off-SoC para um determinado dispositivo de câmera (sensor, AF, flash e assim por diante) devem estar em um recurso de energia.
  • Implemente os métodos de controle _ON e _OFF para cada recurso de energia para alterar o estado do pino GPIO do SoC que impulsiona o hardware de alternância do power rail.
  • Forneça os métodos _PR0 e _PR3 em cada dispositivo de câmera no namespace para fazer referência ao recurso de energia para cada dispositivo de câmera e seu hardware associado.
  • Forneça um objeto _CRS em cada dispositivo de câmera no namespace ACPI para enumerar os recursos GPIO e I2C para o sensor da câmera e o hardware flash. Os recursos GPIO e I2C devem estar na ordem especificada pelo desenvolvedor do driver do sensor de câmera.
• O integrador do sistema deve projetar o hardware da plataforma e o roteamento de energia para que:
  • Cada dispositivo de câmera tem seu próprio trilho de alimentação, que pode ser controlado independentemente dos trilhos de alimentação para os outros dispositivos de câmera, e que pode ser ligado e desligado por um pino GPIO do SoC.
• O integrador do sistema deve testar e verificar se:
  • O hardware do dispositivo de câmera não consome energia (zero watts) quando o dispositivo de câmera não está em uso por um aplicativo. O integrador do sistema deve usar o hardware instrumentado para medir esse consumo de energia.