Gerenciamento de Energia de Sensores

Um computador móvel normalmente incorpora dispositivos de sensor, como um ALS (sensor de luz ambiente), acelerômetro 3D, giroscópio 3D ou magnetômetro 3D. Quando um dispositivo de sensor não está sendo usado pelo sistema operacional ou por um aplicativo, o software de gerenciamento de energia pode alternar o dispositivo para um modo de baixa energia para reduzir o consumo de energia. Em um computador que dá suporte ao modelo de energia em espera moderno, espera-se que os dispositivos de sensor mudem para um modo de baixa potência logo após o computador entrar em espera moderno e permanecer nesse modo até que o computador saia do modo de espera moderno.

Este artigo explica como implementar o gerenciamento de energia para dispositivos de sensor. Além disso, este artigo discute o gerenciamento de energia do microcontrolador de sensor opcional (também chamado de sensor fusion hub ou o MCU do sensor) e dispositivos de sensor agregados. (por exemplo, um dispositivo de sensor de bússola pode ser implementado agregando um acelerômetro, um giroscópio e um magnetômetro sob o controle de um microcontrolador do sensor. O microcontrolador expõe esses dispositivos de sensor ao Windows como um único dispositivo de sensor lógico.)

Sensores e microcontrolador de sensor

O hardware do sensor é fundamental para a experiência móvel moderna. Começando com Windows 10, uma infraestrutura de sistema avançada está disponível para expor e gerenciar vários dispositivos de sensor. Essa infraestrutura simplifica o desenvolvimento de aplicativos que incorporam informações de sensor e que dão suporte a cenários internos críticos do Windows, como rotação automática de tela ou alteração do brilho da exibição com base na luz ambiente.

Durante o runtime do sistema, sensores individuais podem ser desligados quando não estão em uso. Os requisitos para usar um dispositivo de sensor específico são comunicados ao dispositivo e seus drivers por meio da API do Sensor do Windows. Quando um dispositivo de sensor não está sendo usado pelo sistema operacional ou por nenhum aplicativo, o dispositivo pode ser desligado pelo driver do sensor ou pelo firmware que está sendo executado no microcontrolador do sensor.

Depois que a exibição do sistema é desativada e a plataforma de hardware entra em espera moderna, todos os dispositivos de sensor e microcontroladores de sensor opcionais que ainda não estão em estados de baixa potência devem entrar em seus estados de baixa potência e espera dentro de alguns segundos para que a plataforma como um todo possa entrar em um estado de baixa potência. No entanto, os drivers de sensor não monitoram diretamente as transições de e para o modo de espera moderno para determinar quando os dispositivos de sensor devem ser ligados e desligados. Em vez disso, o driver do sensor deve permitir que o dispositivo receba energia quando o dispositivo estiver sendo usado ativamente por um ou mais clientes, que podem ser aplicativos ou componentes do sistema operacional. O driver deve remover a energia do dispositivo quando nenhum cliente estiver usando o dispositivo.

Quando a extensão da classe de sensor solicita que o driver inicie o relatório de leituras de exemplo do sensor, ele chama o método de retorno de chamada EvtSensorStart do driver de sensor. Quando a extensão de classe de sensor solicita que o driver pare de relatar leituras de exemplo do sensor, ele chama o método de retorno de chamada EvtSensorStop do driver. Para obter mais informações, consulte Sobre eventos do driver do sensor.

Depois que o computador entra em espera moderno e todos os dispositivos de sensor entram em estados de baixa potência, o consumo total de energia de todo o hardware do sensor do sistema deve ser menor que um miliwatt. Os dispositivos de sensor e o microcontrolador de sensor opcional podem inserir um estado de espera de baixa potência específico para o hardware do sensor. Ou, o power rail de hardware para os dispositivos de sensor e o microcontrolador de sensor opcional podem ser desligados sob controle dos drivers do sensor e/ou do firmware ACPI do sistema.

A partir do Windows 10, o suporte é fornecido para um conjunto limitado de opções de conectividade de hardware do sensor para o silício principal ou o SoC (System on a Chip) em uma plataforma moderna em espera. As seções a seguir detalham as configurações de hardware e software com suporte, bem como seus comportamentos de gerenciamento de energia durante o modo de espera moderno e quando a plataforma está sendo usada ativamente.

Modos de gerenciamento de energia

O Windows espera que cada dispositivo de sensor ou o microcontrolador do sensor tenha três modos de energia do dispositivo — ativos, ociosos e em espera — além de um modo opcional, zero watt, removido por energia. A tabela a seguir descreve os modos de energia de um dispositivo de sensor e o microcontrolador de sensor opcional. A tabela distingue entre um modo ocioso no qual o hardware do sensor está sendo usado, mas está ocioso no momento e um modo ocioso no qual o hardware do sensor não está sendo usado.

Mode	Descrição	Média de consumo de energia	Sair da latência para ativo	Mecanismo de transição
Ativo	O dispositivo sensor e/ou microcontrolador de sensor está fornecendo ou processando ativamente alterações ambientais.	< 100 miliwatts	N/D	N/D
Ocioso (em uso)	O dispositivo sensor e/ou microcontrolador de sensor está sendo usado por um ou mais aplicativos e está aguardando para fornecer o próximo conjunto de informações do sensor para o processador main.	< 50 miliwatts	Específico do sensor	Autônomo de hardware
Ocioso (não em uso)	O dispositivo sensor e/ou microcontrolador de sensor não está sendo usado por nenhum aplicativo. Os dados de calibragem do sensor ou do microcontrolador do sensor são mantidos.	< 5 miliwatts	Específico do sensor	Comandos hid (dispositivo de interface humana) ou mensagens do Sensor Framework que descrevem o uso atual de dispositivos de sensor.
Standby	O dispositivo sensor e/ou microcontrolador de sensor não está sendo usado por nenhum aplicativo. Os dados de calibragem do sensor ou do microcontrolador do sensor são mantidos. O sensor e/ou microcontrolador do sensor não executa nenhuma ação adicional até que seja solicitado pelo software em execução no processador main.	< 1 miliwatt (para todos os sensores do sistema)	< 10 milissegundos	Várias opções: Comando HIDI2C SET_POWER(Sleep) Mensagem privada do driver de terceiros Linha GPIO do SoC para o hardware do sensor
Remoção de energia	A energia é removida do dispositivo sensor e/ou microcontrolador do sensor e todo o contexto de hardware é perdido.	0 miliwatts	< 100 milissegundos	A entidade externa remove a energia ou aplica energia por meio de firmware ACPI em resposta ao IRP de energia D3.

Observação

Na tabela anterior, o termo em espera refere-se a um modo de energia do dispositivo diferente do modo de espera moderno, que é um estado de energia de toda a plataforma.

Mecanismos de gerenciamento de energia de software

O gerenciamento de energia em tempo de execução para dispositivos de sensor e o microcontrolador do sensor é predominantemente controlado por se eles estão sendo usados. Como regra geral, espera-se que o driver do sensor e o hardware coloquem um sensor no modo de energia ociosa quando ele não estiver sendo usado pelo sistema operacional ou por um aplicativo. A Plataforma de Sensor do Windows fornece informações sobre o número de clientes do aplicativo ou do sistema operacional conectados a um determinado sensor, bem como os requisitos para o ciclo de serviço ou a taxa de dados do sensor. O driver do sensor e/ou hardware usa essas informações para fazer a transição direta do dispositivo do sensor para o modo de energia ocioso durante os horários em que o sistema está em execução e o vídeo é ativado.

Depois que a exibição do sistema for desligada e a plataforma entrar em espera moderna, o Windows espera que todos os sensores e microcontroladores de sensor insiram um modo em espera ou removido por energia.

A escolha de um mecanismo de gerenciamento de energia de software a ser usado para dispositivos de sensor e o microcontrolador de sensor opcional depende de como o hardware do sensor é exposto ao Windows pelo driver do dispositivo e como o hardware do sensor está fisicamente conectado ao SoC ou silício principal. O Windows dá suporte a dois métodos de exposição e conexão de dispositivos de sensor. Um método usa o driver de classe HID do sensor interno em uma conexão I2C, em que o driver HIDI2C interno transfere informações hid sobre a conexão I2C. O outro requer um driver de terceiros que implementa a interface do driver do sensor Universal e chama os métodos na tabela SensorscxFunctions.

As duas opções para se conectar a um sensor ou microcontrolador de sensor são comparadas na tabela a seguir. A seleção de uma das duas opções para se conectar ao hardware do sensor determina os mecanismos de gerenciamento de energia de software necessários para fazer a transição do hardware do sensor para o modo em espera ou removido por energia.

Opção de conexão	Conexão de barramento	Driver de sensor necessário	Provedor de driver	Comentários
HIDI2C	O hardware do sensor se conecta diretamente ao SoC ou ao silício principal por I2C.	Driver de classe HID do sensor + driver de classe HID-over-I2C	Microsoft. Componente de caixa de entrada começando com Windows 8.	Prós/Contras
Driver de sensor de terceiros	O hardware do sensor se conecta diretamente ao SoC ou silício principal por I2C ou UART.	Driver de terceiros que implementa SENSOR_CONTROLLER_CONFIG	Fornecedor de dispositivo de sensor.	Prós/Contras

HIDI2C

Para a opção HIDI2C, o microcontrolador de sensor opcional está fisicamente conectado ao SoC ou ao silício principal por meio de um barramento I2C. O microcontrolador expõe várias coleções HID de nível superior, uma para cada dispositivo de sensor lógico. Por exemplo, um sensor de bússola pode ser exposto por meio de HID como um dispositivo de sensor lógico que é uma agregação dos sensores acelerômetro, girômetro e magnetômetro por trás do microcontrolador do sensor. Essa é a implementação mais fácil em termos de conectividade e software, pois não requer software de terceiros para o dispositivo de sensor.

A pilha HIDI2C do Windows é semelhante à dos controladores de toque e digitalizadores de caneta, pois dá suporte a dois mecanismos de gerenciamento de energia de software: um comando HID em banda e uma transição em tempo de execução para o estado D3.

Comando HID na banda

SET_POWER(Suspensão) Enviado para o dispositivo depois que a tela é desativada e a plataforma entra em espera moderna. Esse comando pode fazer a transição do dispositivo para o modo de energia em espera.

SET_POWER(Ativado) Enviado para o dispositivo quando a plataforma existe em espera moderna e a tela é ativada novamente.

Transição em tempo de execução para o estado D3 para a pilha de dispositivos do sensor HID

D3 IRP Uma solicitação IRP_MJ_POWER que é enviada para a pilha de driver para o dispositivo imediatamente após o comando SET_POWER(Sleep). Isso instrui o dispositivo a inserir o estado de energia do dispositivo D3. Como parte da transição para D3, o firmware ACPI do sistema pode executar métodos de controle para alternar o dispositivo para o modo em espera ou removido por energia.

D0 IRP Uma solicitação IRP_MJ_POWER que é enviada para a pilha de driver para o dispositivo quando a plataforma existe em espera moderna e a tela está ativada. Isso instrui o dispositivo a inserir o estado de energia do dispositivo D0. Se necessário, o firmware acpi do sistema pode executar métodos de controle para alternar o dispositivo de volta para o modo ocioso (não em uso).

Driver de sensor de terceiros

Para o driver de sensor de terceiros, o microcontrolador do sensor está fisicamente conectado ao silício principal por meio de um barramento I2C ou UART.

O fornecedor do dispositivo de sensor deve fornecer um driver umDF (User-Mode Driver Framework) que implementa SENSOR_CONTROLLER_CONFIG interface. O driver UMDF se comunica com o dispositivo de sensor por I2C ou UART. Isso pode ser implementado várias vezes, uma vez para cada sensor que está atrás do microcontrolador do sensor. O driver de sensor de terceiros é responsável por criar e coordenar todo o gerenciamento de energia.

Espera-se que drivers de sensor de terceiros sejam criados usando o WDF (Windows Driver Frameworks) e sejam baseados no driver de exemplo Adxl354acc . O driver deve usar uma fila gerenciada por energia e configurar o estado ocioso D3 por meio de uma chamada para o método IWDFDevice3::AssignS0IdleSettingsEx . O driver deve usar os métodos IWDFDevice2::StopIdle e IWDFDevice2::ResumeIdle para indicar ao WDF quando o dispositivo está ocioso ou ativo. O driver também deve habilitar d3cold definindo o membro ExcludeD3Cold da estrutura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS como WdfFalse. Habilitar o D3cold permite que a plataforma remova a energia do dispositivo do sensor depois que ele fica ocioso e entra no estado D3.

Como prática recomendada, coloque o código específico do dispositivo no driver e coloque o código específico da plataforma no firmware acpi para habilitar o reutilização de código de driver de baixo custo em várias plataformas.

Inserindo requisitos de espera modernos

Os requisitos do driver de sensor de terceiros para gerenciamento de energia são uma função do consumo de energia em espera do hardware do sensor.

Drivers de sensor de terceiros devem iniciar uma transição para D3 quando o dispositivo de sensor estiver pronto para entrar no modo de espera ou removido por energia, mesmo que o dispositivo seja capaz de usar um mecanismo de comunicação em banda para alternar para um modo de energia que consome menos de um miliwatt. O motivo para esse requisito é que muitos motoristas de ônibus no Windows rastreiam o estado de energia do dispositivo de seus dispositivos de ponto de extremidade e desligam somente quando todos os dispositivos de ponto de extremidade são desligados. Para alguns designs de SoC e barramentos de conexão (notadamente o Barramento Serial Universal (USB), todos os dispositivos de ponto de extremidade e o controlador de host devem estar em D3 para que o SoC entre no estado de energia mais baixo durante o modo de espera moderno. A incapacidade de entrar no estado de energia mais baixo pode facilmente impedir que um sistema atende aos requisitos de espera modernos para a duração da bateria.

Se o hardware do sensor tiver um consumo de energia em espera de menos de um miliwatt para todo o hardware do sensor controlado, o driver do sensor deverá alternar automaticamente o dispositivo para o modo de espera quando os sensores (ou todos os sensores no microcontrolador) não estiverem mais em uso.

Se o hardware do sensor tiver um consumo de energia em espera maior que um miliwatt, o driver do sensor deverá executar uma transição D3 e permitir que os métodos de controle ACPI removam a energia do dispositivo do sensor. O driver do sensor deve salvar todo o estado necessário do dispositivo do sensor para que a energia possa ser removida do dispositivo durante a D3. O fornecedor de hardware do sensor deve colaborar de perto com o integrador do sistema para garantir que o hardware e o driver do sensor executem a transição D3 de forma confiável e rápida.

Importante

O driver deve salvar todo o contexto do dispositivo do sensor antes que o dispositivo insira D3 e deve restaurar todo o contexto do dispositivo do sensor depois que o dispositivo entrar em D0.

Logo após a entrada no modo de espera moderno, o Windows interrompe automaticamente o uso de todos os sensores desabilitando o uso de sensores do sistema operacional (por exemplo, luz ambiente e rotação) e suspendendo aplicativos. O driver do sensor deve agregar o estado de todo o hardware do sensor controlado e alternar esse hardware para o modo de energia do dispositivo em espera quando todos os sensores não estiverem mais em uso.

O mecanismo para alternar o dispositivo do sensor para o modo de espera pode ser projetado para usar a comunicação em banda por meio do barramento que conecta o dispositivo ao SoC. Por exemplo, um comando proprietário em espera pode ser enviado pelo barramento para o hardware do sensor. Ou o hardware do sensor pode estar conectado a uma linha GPIO que alterna o dispositivo para dentro e para fora do modo de espera.

Observação

Quando uma linha GPIO é usada para alternar o dispositivo para o modo de espera, o driver do sensor deve fazer a transição da pilha do driver para D3 e permitir que os métodos de controle ACPI para o dispositivo (por exemplo, _PS3) defina a linha GPIO para o estado necessário para colocar o hardware no modo de espera. Esse esquema permite que o driver do sensor seja escrito de maneira independente da plataforma – a linha GPIO específica, os requisitos de tempo e outras informações específicas da plataforma são codificados no firmware acpi fornecido pelo integrador do sistema e não no driver específico do dispositivo.

Saindo dos requisitos de espera modernos

Quando a plataforma sai do modo de espera moderno, o driver do sensor deve fazer a transição do hardware do sensor de volta para o modo ocioso (não em uso). À medida que os serviços do sistema forem retomados, o Windows solicitará o uso de sensores, como rotação e luz ambiente, necessários para executar funções do sistema. À medida que os aplicativos são retomados, eles podem solicitar informações do sensor. Se o hardware do sensor exigir uma mensagem em banda para retornar o dispositivo ao modo ocioso, o driver do dispositivo deverá enviar essa mensagem assim que a primeira solicitação de informações do sensor for enviada. Se o hardware do sensor exigir uma linha GPIO para sinalizar o dispositivo para retornar ao estado ocioso, o driver deverá usar essa linha GPIO para executar uma transição para D0 assim que a primeira solicitação de informações do sensor for fornecida. Nesse caso, os métodos de controle ACPI (por exemplo, _PS0) devem alternar a linha GPIO conforme necessário para iniciar a transição. Por fim, se o hardware do sensor exigiu anteriormente uma transição para o modo de energia removida porque o consumo de energia no modo de espera excede um miliwatt, o driver do sensor deve executar uma transição para D0 e permitir que os métodos de controle ACPI restaurem a energia para o dispositivo.

Configurações de energia de hardware com suporte

A configuração de gerenciamento de energia de hardware a ser usada para um dispositivo de sensor depende do consumo de energia do hardware do sensor no modo de espera e se um microcontrolador de sensor opcional gerencia o dispositivo.

Potência em espera < um miliwatt

Se o consumo de energia de um dispositivo de sensor no modo de energia em espera não exceder um miliwatt, o designer de plataforma não será necessário para anexar o hardware do sensor a um trilho de alimentação que pode ser ativado e desativado pelos métodos de controle ACPI. Um dos seguintes mecanismos é usado para alternar o sensor para o modo de energia em espera:

• Um comando HID SET_POWER(Sleep).
• Uma linha GPIO do SoC.
• Um comando proprietário enviado ao hardware do sensor pelo driver de sensor de terceiros.

Se a plataforma incluir um microcontrolador de sensor, o chip microcontrolador poderá conter um ou mais dispositivos de sensor integrados ou pode estar conectado a um ou mais dispositivos de sensor externos. Em ambos os casos, esses dispositivos de sensor estão, do ponto de vista do software, ocultos atrás do microcontrolador e invisíveis para o Windows. Se um microcontrolador de sensor e seus dispositivos de sensor agregados juntos consumirem menos de um miliwatt quando o microcontrolador e o hardware do sensor estiverem no modo de energia em espera, o designer de plataforma não precisará anexar o microcontrolador ou o hardware do sensor a um trilho de alimentação que pode ser ativado e desativado pelos métodos de controle ACPI. O microcontrolador do sensor usa um dos seguintes mecanismos para fazer a própria transição e todos os sensores que ele gerencia de e para o modo de espera:

• Um comando hidi2C SET_POWER (ou semelhante) enviado pelo barramento de comunicações.
• Uma linha GPIO do SoC.

Se o sensor exigir uma linha GPIO do SoC para iniciar transições de e para o modo de espera, o firmware de plataforma deverá fornecer um objeto _PS3 e um objeto _PS0 no namespace ACPI no dispositivo de hardware do sensor. O firmware ACPI também deve incluir uma região de operação GPIO que descreva a linha GPIO do SoC para o hardware do sensor. O método de controle _PS3 alterna a linha GPIO para alternar o dispositivo para o modo de espera e o método de controle _PS0 alterna a linha GPIO para alternar o hardware do sensor para o modo ocioso.

O diagrama de bloco a seguir mostra as opções de gerenciamento de energia para um sensor autônomo que consome menos de um miliwatt no modo de energia em espera.

Uma opção é usar a pilha HIDI2C do Windows, conforme mostrado no lado esquerdo do diagrama anterior. Nesse caso, a transição do sensor para o modo de energia em espera pode ser iniciada por um comando HID SET_POWER(Sleep) ou por um IRP D3 que o driver ACPI manipula executando o método de controle _PS3 para o sensor.

A outra opção é usar um driver de sensor de terceiros, conforme mostrado no lado direito do diagrama anterior. O driver do sensor de terceiros pode iniciar a transição para o modo de energia em espera usando um comando proprietário em banda ou enviando um IRP D3 que o driver ACPI manipula executando o método de controle _PS3 para o sensor.

O designer de plataforma pode escolher qualquer mecanismo, independentemente de os dispositivos de sensor serem integrados ou externos ao chip microcontrolador.

Potência em espera > um miliwatt

Se a plataforma incluir hardware do sensor e/ou um microcontrolador de sensor que juntos consomem mais de um miliwatt no modo de energia em espera, o hardware do sensor e o microcontrolador devem ser transferidos para o modo removido por energia quando o sistema estiver em espera moderno. Nessa configuração, o sensor, o microcontrolador opcional do sensor e todos os sensores por trás do microcontrolador devem ser colocados em um único trilho de alimentação ativado e desativado sob o controle de uma linha GPIO do SoC.

Essa configuração exige que o designer de plataforma coloque todo o hardware do sensor em um trilho de alimentação comutável, controlado por uma linha GPIO do SoC. Se várias voltagens de entrada forem necessárias para o hardware do sensor, vários comutadores, cada um controlado pela mesma linha GPIO, poderão ser usados. Além do power rail comutável, o firmware acpi da plataforma deve definir um Recurso de Energia no namespace . Este Recurso de Energia descreve o hardware do sensor e inclui os métodos _ON e _OFF responsáveis pelo uso de uma região de operação GPIO para alternar a linha GPIO do SoC.

O firmware de plataforma deve incluir uma referência ao Recurso de Energia em cada dispositivo de sensor no namespace ACPI no trilho de alimentação comutável, incluindo objetos _PR0 e _PR3.

O diagrama de bloco a seguir mostra as opções de gerenciamento de energia para hardware do sensor e/ou um microcontrolador de sensor que, juntos, consomem mais de um miliwatt no modo de energia em espera. As duas opções são usar a pilha HIDI2C do Windows, conforme mostrado no lado esquerdo do diagrama, ou usar um driver de sensor de terceiros, conforme mostrado no lado direito.

Na configuração que usa a pilha de driver HIDI2C interna, conforme mostrado no lado esquerdo do diagrama anterior, o driver HIDI2C inicia uma transição D3 depois que a exibição é desativada e a plataforma entra em espera moderna. Quando o IRP D3 flui pelo driver ACPI, o objeto _PR3 será avaliado e o Windows desativará o Recurso de Energia especificado executando o método _OFF. Se vários sensores compartilharem o Recurso do Power, o Windows contará automaticamente todos os sensores e executará o método _OFF somente depois que todos os sensores tiverem entrado em D3.

Se o hardware do sensor usar um driver de sensor de terceiros, conforme mostrado no lado direito do diagrama anterior, o fluxo de controle será o mesmo de antes, exceto que o driver do sensor é responsável por iniciar a transição para D3.

Depois que a plataforma é retomada do modo de espera moderno e um aplicativo ou o sistema operacional solicita o uso do sensor, o driver faz a transição para D0. Um IRP D0 flui pelo driver ACPI e o objeto _PR0 é avaliado para que o driver ACPI execute o método _ON para o Recurso de Energia associado. O método _ON alterna a linha GPIO para ativar o trilho de alimentação comutável. Se o sistema usar um driver de sensor de terceiros, o driver deverá solicitar um D0 IRP e iniciar uma transição para D0 imediatamente após os dados do sensor serem solicitados pelo sistema operacional ou por um aplicativo.

Preocupações de ativação

Não há nenhuma preocupação de ativação para sensores ou o microcontrolador de sensor opcional. Espera-se que os dispositivos de sensor estejam no modo de espera ou removidos por energia durante o modo de espera moderno e não devem ativar o SoC enquanto a plataforma estiver em espera moderna.

Teste e validação

É essencial para o designer do sistema verificar se o hardware do sensor entra no modo em espera ou removido por energia quando o display é desligado para espera moderno. O método usado para testar e validar o gerenciamento de energia do dispositivo depende de como o dispositivo de sensor está conectado.

Sensor conectado a HIDI2C

Se o sistema usar a pilha HIDI2C do Windows, o integrador do sistema deverá entrar em contato com o fornecedor do driver do sensor para obter informações sobre como verificar melhor se o driver executa corretamente o gerenciamento de energia. Os fornecedores de driver de sensor são incentivados a usar o rastreamento etw (Rastreamento de Eventos para Windows) para todas as decisões de gerenciamento de energia em seu driver de dispositivo e fornecer documentação de exemplo aos integradores do sistema para descrever como verificar a operação correta de gerenciamento de energia usando os eventos ETW e o WPT (Kit de Ferramentas de Desempenho do Windows).

Driver de sensor de terceiros

Se o sistema usar um driver de sensor de terceiros, o integrador do sistema deverá entrar em contato com o fornecedor do driver do sensor para obter informações sobre como verificar melhor se o driver executa corretamente o gerenciamento de energia. Os fornecedores de driver de sensor são incentivados a usar o rastreamento etw (Rastreamento de Eventos para Windows) para todas as decisões de gerenciamento de energia em seu driver de dispositivo e fornecer documentação de exemplo aos integradores do sistema para descrever como verificar a operação correta de gerenciamento de energia usando os eventos ETW e o WPT (Kit de Ferramentas de Desempenho do Windows).

Se o driver iniciar uma transição para d3 quando todos os seus dispositivos de sensor não estiverem mais sendo usados, você poderá seguir as instruções na lista a seguir para verificar se essa transição ocorre conforme o esperado e se um dispositivo de sensor retorna a D0 quando um aplicativo ou o sistema operacional precisa usar o dispositivo novamente.

O método focado em software usa a instrumentação do Windows para verificar se o IRP D3 passa pela pilha do driver do dispositivo para o dispositivo sensor. O Power Manager do Windows tem instrumentação ETW interna, que inclui instrumentação para detectar IRPs Dx (solicitações de energia do dispositivo). Para exibir essas informações em um modo manual, baixe o Kit de Ferramentas de Desempenho do Windows e instale-o no sistema em teste.

Depois de instalar o Kit de Ferramentas de Desempenho do Windows, siga estas instruções para iniciar um rastreamento XPerf no modo de usuário:

1. Abra uma janela do Prompt de Comando como Administrador.

2. Navegue até a pasta \%ProgramFiles%\Windows Kits\8.0\Windows Performance Toolkit\ .

3. Para iniciar o Xperf, execute o seguinte comando: xperf.exe -start power_session -on Microsoft-Windows-Kernel-Power

4. Faça a transição do sistema para o modo de espera moderno pressionando o botão de energia.

5. Aguarde 30 segundos.

6. Faça a transição do sistema para fora do modo de espera moderno pressionando o botão de energia.

7. Execute o seguinte comando para interromper o registro em log de eventos: xperf.exe -stop power_session

8. Converta o arquivo de rastreamento binário em .csv e formato legível por humanos: xperf.exe –i \user.etl > power.txt

9. Abra o arquivo Power.txt em um editor de texto e pesquise a ID de hardware do dispositivo do sensor. Você pode pesquisar a ID de hardware do dispositivo de sensor na guia Detalhes das propriedades do dispositivo em Gerenciador de Dispositivos em Caminho da Instância do Dispositivo. No exemplo a seguir, o caminho da instância do dispositivo do dispositivo de sensor é ACPI\MST0731\2&daba3ff&0.

10. A inicialização do IRP D3 para o dispositivo sensor é indicada por um evento do tipo Microsoft-Windows-Kernel-Power/IRP/Stop que tem o caminho da instância do dispositivo do dispositivo do sensor e um último valor de evento de 3, o que indica que o estado de destino é D3. O seguinte evento de saída do arquivo Power.txt mostra o início do IRP D3. Os dois últimos valores de parâmetro para esse evento (mostrados na extrema direita) indicam o caminho da instância do dispositivo e o estado de destino.

    Microsoft-Windows-Kernel-Power/Irp/Start, 7605393, "Unknown" (4), 256, 0,,,,, 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\MSFT0731\2&daba3ff&0", 3

11. Esse evento deve ser registrado perto do início do arquivo de saída Power.txt. O valor 0x868e2728 do parâmetro no evento de saída anterior é um ponteiro para a estrutura IRP do IRP D3. Ao pesquisar eventos subsequentes no arquivo de rastreamento que têm esse mesmo ponteiro IRP, você pode acompanhar o progresso do IRP D3 à medida que ele flui pela pilha do driver para o dispositivo de sensor.

12. Microsoft-Windows-Kernel-Power/Irp/Start, 7605393, "Unknown" (4),256, 0,,,,, 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\ATML1000\2&daba3ff&0", 3

13. Microsoft-Windows-Kernel-Power/Driver/Start, 7605416, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

14. Microsoft-Windows-Kernel-Power/Driver/Stop, 7605515, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fb56e0

15. Microsoft-Windows-Kernel-Power/Driver/Start, 7605522, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fab6a0, "\Driver\i2cdrv"

16. Microsoft-Windows-Kernel-Power/Driver/Stop, 7608342, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fab6a0

17. Microsoft-Windows-Kernel-Power/Driver/Start, 7608351, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x857ffb90, "\Driver\ACPI"

18. Microsoft-Windows-Kernel-Power/Driver/Stop, 7608416, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x857ffb90

19. Microsoft-Windows-Kernel-Power/Driver/Start, 7608424, "Unknown" (4), 20, 0,,,,, 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

Quando o driver ACPI do Windows, Acpi.sys, processa o IRP D3, Acpi.sys executa o método de controle de _PR3 correspondente. O designer de firmware do sistema fornece esse método de controle para indicar qual Recurso de Energia deve ser desativado para que o dispositivo de sensor insira o estado D3. Acpi.sys também executa o método de controle _OFF no Power Resource.

Você pode usar um processo semelhante para verificar se o dispositivo de sensor retorna a D0 quando a plataforma sai do modo de espera moderno e o vídeo é ativado. Um evento Microsoft-Windows-Kernel-Power/IRP/Start para o dispositivo sensor será registrado com um estado de destino 0 (indicando D0) imediatamente após o botão de energia ser pressionado para ativar o sistema, e o sistema operacional ou um aplicativo retomado solicita dados do sensor.

Lista de verificação de gerenciamento de energia do microcontrolador de sensor e sensor

Os integradores do sistema e os fornecedores de dispositivos de sensor devem usar a lista de verificação a seguir para garantir que o design de gerenciamento de energia do sistema seja compatível com Windows 8 e superiores.

• Selecione o hardware do sensor compatível com o driver HIDI2C interno e a pilha de driver HIDSensor.
• Selecione o hardware do sensor que tenha um consumo de energia em espera de menos de um miliwatt.
• Verifique se o hardware do sensor e o driver de terceiros (se necessário) dão suporte ao gerenciamento de energia ociosa em tempo de execução quando a exibição estiver ativada:
  • Os sensores devem ser desligados e inserir D3 automaticamente quando não estiverem sendo usados por um aplicativo ou pelo sistema operacional.
  • Os sensores devem ligar e inserir D0 automaticamente quando os dados do sensor forem solicitados por um aplicativo ou pelo sistema operacional.
  • O driver de sensor de terceiros deve ser implementado como um driver WDF e pode ser baseado no driver de exemplo SpbAccelerometer.
  • A sondagem de informações do sensor deve ser limitada e habilitada no nível de consumo de energia mais baixo possível. Por exemplo, a sondagem de um sensor analógico deve ocorrer por trás de um microcontrolador ou outro hardware de controle de baixa potência, o que pode interromper o SoC quando novos dados do sensor excederem algum valor de detecção de limite. Evite sondar o sensor em um driver que é executado periodicamente no SoC, o que pode aumentar significativamente o consumo geral de energia do sistema.
• Se o hardware do sensor usar um driver de terceiros:
  • O integrador do sistema deve se comunicar com o fornecedor do dispositivo de sensor para entender como implementar o gerenciamento de energia para o hardware do sensor.
  • Se o hardware do sensor consumir mais de um miliwatt no modo de energia em espera, coloque o hardware do sensor em um power rail autônomo controlado por uma linha GPIO do SoC. Forneça referências aos métodos de controle acpi power resource, _ON/_OFF e Power Resource no dispositivo de sensor no namespace acPI (conforme descrito abaixo).
  • Se o hardware do sensor usar uma linha GPIO do SoC para alternar o dispositivo para o modo de energia em espera, verifique se o firmware ACPI do sistema inclui os métodos de controle de _PS3 e _PS0 adequados (conforme descrito abaixo).
• Se o hardware do sensor incluir um microcontrolador de sensor que tenha dispositivos de sensor conectados atrás dele, o microcontrolador do sensor deverá ter uma maneira de desligar os dispositivos do sensor. Os dispositivos podem ser desligados usando a comunicação em banda pelo barramento que conecta o microcontrolador aos dispositivos ou uma linha GPIO do microcontrolador aos dispositivos.
• Se o hardware do sensor exigir uma linha GPIO do SoC para alternar o dispositivo para o modo de energia em espera:
  • Verifique se a linha GPIO do SoC atende aos requisitos de nível e gatilho definidos pelo fornecedor de hardware do sensor.
  • No namespace do ACPI, descreva o pino do SOC GPIO como parte de uma região de operação gpio.
  • Forneça um método de controle _PS3 no dispositivo de sensor no namespace ACPI para alternar o sinal na linha GPIO, conforme necessário, para alternar o hardware do sensor para o modo de energia em espera.
  • Forneça um método de controle _PS0 no dispositivo de sensor no namespace ACPI para alternar o sinal na linha GPIO conforme necessário para alternar o hardware do sensor para o modo ocioso ou ativo depois que o dispositivo mudar para D0.
• Se o hardware do sensor consumir mais de um miliwatt no modo de energia em espera:
  • Coloque todo o hardware do sensor em um trilho de alimentação que possa ser ligado e desativado por uma linha GPIO do SoC. Ou, se a plataforma contiver vários sensores que têm requisitos diferentes de tensão de fornecimento, forneça trilhos separados que podem ser alternados independentemente.
  • Descreva o power rail comutável como um Recurso de Energia no namespace ACPI.
  • Neste Recurso de Energia, forneça os métodos de controle _ON e _OFF que ativam e desativam o trilho de energia usando uma linha GPIO descrita como parte de uma região de operação gpio.
  • No namespace acpi, forneça objetos _PR3 e _PR0 que designam o Recurso de Energia para o hardware do sensor.
  • Verifique se os métodos _ON e _OFF incorporam quaisquer requisitos de desativação ou tempo do hardware do sensor.
• Teste e valide o gerenciamento de energia em tempo de execução dos dispositivos de sensor na plataforma. Trabalhe em estreita colaboração com o fornecedor de hardware do sensor para validar o gerenciamento de energia em tempo de execução quando a exibição do sistema estiver ativada.
• Teste e verifique se o hardware do sensor entra no modo em espera ou removido por energia quando a plataforma entra em espera moderna.
  • Se o hardware do sensor usar as pilhas de driver do sensor HIDI2C + HID incluídas no Windows, consulte Teste e validação para obter detalhes.
  • Se o hardware do sensor usar um driver de terceiros, entre em contato com o fornecedor do driver do sensor para obter a metodologia de teste recomendada.
  • Se o driver do sensor executar uma transição para D3 como parte de sua entrada para o modo em espera ou removido por energia, use o Kit de Ferramentas de Desempenho do Windows, conforme descrito em Teste e validação. Verifique se o hardware do sensor entra em D3 quando a plataforma entra em espera moderna e se o hardware do sensor entra em D0 depois que o sistema sai do modo de espera moderno e as informações do sensor são solicitadas novamente.
• Meça o consumo de energia do hardware do sensor no modo em espera ou removido por energia.
• Inicie várias transições para dentro e fora do modo de espera moderno e teste o estresse da operação dos dispositivos de sensor e dos aplicativos que usam informações do sensor quando a exibição é ativada.