Gerenciamento de energia do receptor GNSS para plataformas modernas em espera

Artigo
06/19/2023

Este tópico discute o gerenciamento de energia do GNSS (Global Navigation Satellite System) para plataformas modernas compatíveis com espera.

Um computador Windows que implementa o modelo de energia em espera moderno também pode conter um dispositivo GNSS (Global Navigation Satellite System). Um dispositivo GNSS permite que o usuário obtenha informações de posicionamento de alta precisão de um sistema de navegação satélite, como o GPS (Global Positioning Systems) ou o GLONASS (Global Orbiting Navigation Satellite System). Depois que a plataforma de hardware entra em espera moderna, o dispositivo GNSS deve entrar em um modo de operação de baixa potência no qual consome não mais de 1 mW de energia. O dispositivo GNSS deve permanecer nesse modo até que a plataforma saia do modo de espera moderno.

Os dispositivos GNSS que dão suporte ao GPS e ao GLONASS (Global Orbiting Navigation Satellite System) estão disponíveis há algum tempo, mas dispositivos GNSS mais recentes dão suporte a sistemas de navegação satélite, como o BDS (BeiDou Navigation Satellite System) e o Galileo.

Uma plataforma de espera moderna normalmente é criada em torno de um circuito integrado do System on a Chip (SoC). O Windows dá suporte às seguintes opções para adicionar um dispositivo GNSS a essa plataforma:

Incorpore um módulo de banda larga móvel (MBB) que contém um dispositivo GNSS integrado. Esse método é comum em telefones celulares.
Selecione um SoC que contém um dispositivo GNSS integrado.
Use um barramento de baixa potência, como I2C, SPI ou UART, para conectar um dispositivo GNSS autônomo ao SoC.

Se possível, o integrador do sistema deve selecionar um dispositivo GNSS que implementa um modo de suspensão de baixa energia no qual o dispositivo consome não mais do que 1 mW de energia. O fornecedor do dispositivo GNSS deve fornecer um driver de sensor de localização que traduza dados de localização do dispositivo GNSS para o formulário exigido pelos aplicativos cliente. Esses aplicativos se conectam ao dispositivo GNSS por meio da API de Localização do Windows. O driver do sensor de localização para o dispositivo GNSS controla as seguintes informações:

O número de clientes atualmente conectados ao dispositivo GNSS por meio da API de Localização.
O estado da opção de ativação/desativação do dispositivo GNSS. O usuário controla essa opção por meio do aplicativo Configurações do Windows. Para obter mais informações, consulte Integrando o gerenciamento de rádio.

O driver do sensor de localização usa essas informações para determinar quando o dispositivo GNSS está ocioso para que ele possa ser colocado em um modo de baixa potência. Um dispositivo GNSS está sendo usado ativamente somente se um ou mais clientes estiverem conectados ao dispositivo. Caso contrário, o dispositivo fica ocioso.

Para estender a duração da bateria do sistema, o acesso ao dispositivo GNSS é restrito durante o modo de espera moderno. Aplicativos de tela de bloqueio podem acessar informações de cerca geográfica e posição durante o modo de espera moderno. No entanto, aplicativos de tela sem bloqueio podem usar a API de Localização para obter dados de localização do dispositivo GNSS somente enquanto a exibição estiver ativada e a plataforma estiver interagindo com o usuário. Logo após a exibição desativar e a plataforma entrar em espera moderna, todos os aplicativos que não têm tela de bloqueio que tenham conexões com o dispositivo GNSS serão automaticamente desconectados pelo Windows e os aplicativos serão suspensos.

Modos de gerenciamento de energia

Espera-se que o receptor GNSS tenha quatro modos de gerenciamento de energia, conforme descrito abaixo.

Modos de energia do receptor GNSS

Modo de Energia do Dispositivo	Descrição	Estado de Energia do Dispositivo (Dx)	Estado de rádio (conforme mostrado ao usuário)	Número de clientes conectados	Consumo médio de energia (mW)	Mecanismo de Transição
Ativo (aquisição)	O receptor GNSS está adquirindo uma correção de satélite.	D0	Ativado	>= 1	~200 mW	N/D
Ativo (Rastreamento de 1 Hz)	O receptor GNSS adquiriu uma correção satélite e está fornecendo dados para um ou mais aplicativos periodicamente.	D0	Ativado	>= 1	~100 mW (específico do dispositivo)	N/D
Modo de suspensão	O receptor GNSS não tem clientes conectados O hardware do receptor GNSS ainda tem energia aplicada para preservar o contexto no dispositivo e reduzir o tempo de latência de retomada para o modo Ativo.	D3(D3hot)	Desativado ou ativado	0	<1 mW (específico do dispositivo)	Iniciado por software. Esse é o estado de suspensão seletiva para rádios GNSS anexados diretamente ao barramento do Barramento Serial Universal (USB) ou a um dispositivo composto USB.
Energia removida	O receptor GNSS não tem clientes conectados, o rádio é desligado e toda a energia do receptor GNSS foi removida por uma entidade externa.	D3(D3cold)	Desativado ou ativado	0	0 mW	Iniciado por software e requer coordenação de hardware para remover energia.

O driver de software para o receptor GNSS também precisa lidar com o gerenciamento de rádio, conforme descrito abaixo.

Requisitos de implementação da plataforma

Uma plataforma de espera moderna tem várias opções para integrar fisicamente um receptor GNSS. O receptor GNSS pode fazer parte de um dispositivo autônomo que está conectado ao SoC por um barramento de comunicações de baixa potência. O receptor GNSS também pode ser integrado a um rádio de banda larga móvel (MBB), pois receptores GNSS são comuns em telefones celulares. Por fim, o receptor GNSS pode ser integrado ao próprio SoC.

Essas várias opções apresentam um desafio ao integrador do sistema ao determinar qual implementação selecionar para uma plataforma que requer funcionalidade GNSS. Para plataformas de espera modernas do Windows, os integradores de sistema são recomendados para integrar o GNSS na seguinte ordem de prioridade:

Se o sistema estiver equipado com um rádio MBB, use o receptor GNSS integrado ao módulo MBB.
Se o sistema estiver equipado com um SoC que tenha um receptor GNSS integrado, use o receptor GNSS integrado ao SoC.
Integre um receptor GNSS autônomo anexado ao SoC em um barramento de comunicações de baixa potência (como UART, SPI ou I2C).

O integrador do sistema não deve expor nenhum receptor GNSS desnecessário ao Windows. Na presença de vários receptores GNSS expostos ao sistema operacional, o Windows NÃO agregará as informações de localização de todos os dispositivos GNSS.

Mecanismo de gerenciamento de energia de software

Espera-se que os dispositivos GNSS em plataformas Windows sejam gerenciados por um driver umDF (User-Mode Driver Framework) que usa o modelo de Extensão de Classe de Sensor do Windows e implementa a interface ISensorDriver. Esse driver GNSS é chamado de driver de sensor de localização e espera-se que ele gerencie o receptor GNSS subjacente e forneça dados às solicitações de aplicativo para obter informações de localização.

Visão geral e modelo de aplicativo

Os drivers do sensor de localização usam o número de clientes de aplicativos conectados como o mecanismo primário para determinar quando o dispositivo GNSS pode entrar no modo de suspensão ou energia removida. O driver do sensor de localização também é responsável por se comunicar com uma biblioteca de gerenciador de rádio fornecida pelo fornecedor GNSS que permite que o usuário controle se o rádio GNSS estiver habilitado ou desabilitado. O driver do sensor de localização pode usar o número de clientes conectados e a preferência do usuário pelo estado de rádio para garantir que o dispositivo GNSS esteja em um modo de suspensão de baixa potência ou energia removida sempre que possível.

Os aplicativos da Microsoft Store gerenciam o tempo de vida de aplicativos em primeiro plano e em segundo plano e, portanto, têm influência significativa no número de clientes de aplicativos conectados ao driver do sensor de localização. Um aplicativo em primeiro plano solicita informações de localização por meio da API de Localização do Windows. Quando o aplicativo em primeiro plano é alternado para o plano de fundo pelo usuário, o modelo de aplicativo da Microsoft Store garante que o aplicativo cliente seja desconectado do receptor GNSS.

Esse mecanismo de modelo de aplicativo permite que o driver do sensor de localização acompanhe facilmente o número de clientes de aplicativos conectados. Sempre que não houver nenhum cliente de aplicativo conectado, o driver do sensor de localização poderá fazer a transição do dispositivo GNSS para um modo de suspensão ou energia removida.

Quando o sistema entra em espera moderno, o Windows suspenderá automaticamente todos os aplicativos em primeiro plano, resultando no driver do sensor de localização observando o número de clientes conectados que fazem a transição para zero.

Integrando o gerenciamento de rádio

O driver do sensor de localização também deve implementar uma interface para se comunicar com a biblioteca do gerenciador de rádio fornecida pelo fornecedor. A biblioteca do gerenciador de rádio permite que o Windows exponha um controle de rádio de dispositivo GNSS "ativado/desativado" no aplicativo Configurações do Windows.

Requisitos de implementação do driver do sensor de localização

O driver do sensor de localização deve colocar o dispositivo GNSS em um estado D3 de baixa potência quando o dispositivo GNSS não estiver em uso. O dispositivo GNSS não está em uso quando não há clientes conectados no momento ou o GNSS foi desabilitado por meio do gerenciador de rádio.

O driver do sensor de localização deve persistir o dispositivo GNSS no estado D3 o tempo todo quando o dispositivo GNSS tiver sido desabilitado por meio do gerenciador de rádio. Esse requisito impede que o driver use uma fila gerenciada por energia e simplesmente encaminhe solicitações de clientes conectados. O driver do sensor de localização deve usar uma fila não gerenciada por energia para E/S e gerenciar ocioso diretamente usando os métodos StopIdle e ResumeIdle . O sensor de localização deve continuar a ser o proprietário da política de energia para a pilha de driver do dispositivo GNSS. O driver deve definir o valor de bPowerManaged como FALSE ao chamar IWDFDevice::CreateIoQueue para criar a fila de E/S.

Conforme mencionado acima, o driver usa o número de clientes conectados e o estado do rádio do gerenciador de rádio para determinar se o dispositivo GNSS está ocioso. Quando o dispositivo GNSS está ocioso, o driver chama o método ResumeIdle, o que faz com que a estrutura do driver inicie uma transição D3. A estrutura do driver executará a implementação do driver do método OnD0Exit .

Quando o dispositivo GNSS deve ser reativado devido a um novo cliente conectado ou ligar o rádio, o driver chama o método StopIdle . A estrutura do driver executará a implementação do driver do método OnD0Entry . Observe que o driver deve executar o método StopIdle com o parâmetro WaitForD0 definido como FALSE.

O diagrama de estado fornecido abaixo ilustra essa relação e serve como um guia para o desenvolvedor de driver para quando chamar os métodos StopIdle e ResumeIdle .

Como o driver é responsável por controlar se o dispositivo está ocioso, ele deve gerenciar diretamente a fila de E/S e os acessos resultantes do dispositivo de hardware.

O driver do sensor de localização deve implementar os métodos IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend e IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Observe que a estrutura do driver chamará IPnpCallbackSelfManagedIo::OnSelfManagedIoInit quando o dispositivo for iniciado, inclusive na inicialização do sistema. As chamadas subsequentes são para o retorno de chamada IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart . Essas interfaces devem ser registradas quando a estrutura de driver chama o método CreateDevice.

O IPnpCallbackSelfManagedIo::OnSelfManagedIoRestart sinaliza o driver do sensor de localização que solicita para o driver pode interagir diretamente com o hardware do dispositivo GNSS, incluindo solicitações de retornos de chamada ISensorDriver:: . Observe que a estrutura do driver garante que o hardware do dispositivo possa ser acessado nos métodos OnD0Exit e OnD0Entry .

Da mesma forma, quando o método IPnpCallbackSelfManagedIo::OnSelfManagedIoSuspend é chamado pela estrutura, o driver deve concluir todas as solicitações ISensorDriver imediatamente antes de retornar de OnSelfManagedIoSuspend. O driver não poderá acessar o hardware do dispositivo se isso puder impedir que qualquer uma dessas solicitações seja concluída dentro de um segundo. Se o driver do sensor de localização tiver uma solicitação pendente para o hardware do dispositivo GNSS, a solicitação deverá ser cancelada se não puder ser concluída de outra forma sem violar essa restrição de tempo.

Se o driver não interagir diretamente com um dispositivo de hardware ou todas as solicitações de hardware pendentes forem concluídas em um segundo, o driver deverá implementar o método OnSelfManagedIoSuspend usando o seguinte procedimento:

Defina um sinalizador global indicando que o dispositivo está inativo.
Chame o método StopSynchronously na fila do WDF (Windows Driver Frameworks).
Interrompa qualquer outro trabalho assíncrono que acesse o hardware do dispositivo GNSS.
Chame o método Start na fila do WDF.
Desmarque o sinalizador global definido na etapa 1.

Para obter um exemplo de código que executa essas operações, consulte a implementação OnSelfManagedIoSuspend no Driver de Exemplo de Geolocalização de Sensores (UMDF Versão 1).

Se o driver interagir diretamente com um dispositivo de hardware, todas as solicitações pendentes para o hardware deverão ser canceladas antes de liberar a fila de E/S. O driver deve implementar o método OnSelfManagedIoSuspend usando o seguinte procedimento:

Defina um sinalizador global indicando que o dispositivo está inativo.
Chame o método Stop na fila do WDF.
Cancele todas as solicitações de hardware pendentes para permitir que todos os threads de retorno de chamada do ISensorDriver sejam concluídos.
Chame o método StopSynchronously na fila do WDF.
Interrompa qualquer outro trabalho assíncrono que acesse o hardware do dispositivo GNSS.
Chame o método Start na fila do WDF.
Desmarque o sinalizador global definido na etapa 1.

Todos os drivers de sensor de localização devem limpar de forma síncrona a fila de E/S dentro de sua implementação do método OnSelfManagedIoFlush .

Modos de suspensão e energia removidos

Os dispositivos GNSS podem dar suporte a um modo de suspensão e a um modo de energia removido quando o dispositivo tem o contexto local preservado e ainda podem responder a solicitações sobre o barramento de comunicações sem sinalização externa. (Normalmente, um dispositivo no modo de energia removida não pode responder a solicitações de barramento.) O driver do sensor de localização deve ser gravado para entender se o dispositivo subjacente é capaz do modo de energia removida. O driver do sensor de localização deve habilitar d3cold somente se o dispositivo subjacente for capaz do modo de energia removida e o driver for capaz de salvar/restaurar o contexto e inicializar novamente o dispositivo. Caso contrário, o sensor de localização deve continuar a usar D3 como seu estado ocioso, mas não habilitar D3cold. Isso permite que os drivers de barramento e filtro subjacentes coloquem o dispositivo no modo de suspensão de baixa potência e não no modo de energia removida.

Quando o driver do sensor de localização indica que ele dá suporte a D3cold e inicia uma transição D3, os drivers de barramento e filtro subjacentes são responsáveis por remover a energia do dispositivo. O mecanismo pode ser implementado pelo ACPI no caso de dispositivos GNSS conectados a UART. Ou o mecanismo pode ser habilitado por uma combinação do driver de hub USB e do driver ACPI no caso de dispositivos GNSS enumerados por USB.

Se o dispositivo GNSS estiver no SoC, o driver proprietário e o firmware do fornecedor de SoC implementados nos drivers subjacentes serão responsáveis por remover a energia do dispositivo GNSS. Se o dispositivo GNSS consumir mais de 1 mW em seu modo de energia de suspensão, o driver GNSS, o firmware de plataforma e o hardware deverão ser projetados para colocar o dispositivo no modo de energia removida quando todos os clientes forem desconectados.

Detecção ociosa

O driver do sensor de localização para um dispositivo GNSS deve fazer a transição do dispositivo para o modo de energia de suspensão sempre que possível. Se um aplicativo solicitar um intervalo de relatório longo, o driver do sensor de localização deverá fazer a transição do dispositivo GNSS para o modo de energia de suspensão até que a próxima correção seja solicitada. O driver do sensor de localização deve fazer a transição do dispositivo GNSS para o modo de energia ativo com tempo suficiente para triangular uma correção e fornecer ao aplicativo dados de localização.

Por exemplo, suponha que o intervalo de relatório solicitado mais curto seja de 30 minutos e que o dispositivo exija um minuto para se aquecer e adquirir uma correção de local. Nesse cenário, o driver do sensor de localização deve:

Imediatamente após fornecer informações de localização, chame ResumeIdle, que fará a transição do dispositivo GNSS para o modo de suspensão (D3).
Armar um temporizador para expirar 28 minutos no futuro. (TimerExpiration = ReportInterval – WarmUpTime).
Quando o temporizador expirar, chame StopIdle, que fará a transição do dispositivo GNSS para D0.
Quando o dispositivo tiver adquirido uma correção, forneça informações de localização para o aplicativo. Nota O driver do sensor de localização deve configurar cuidadosamente o D3cold.

Se o dispositivo exigir energia contínua para obter a latência de retomada para WarmUpTime, o D3cold não deverá ser habilitado. O D3cold pode ser habilitado dinamicamente em runtime alterando o valor de ExcludeD3Cold na estrutura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS.

Quando um dispositivo GNSS conectado a USB faz a transição para o modo de suspensão (D3) com D3cold desabilitado, o dispositivo fará a transição para o estado de suspensão USB, o que economiza energia significativa do chipset e do processador. Se o driver do sensor de localização habilitar D3cold e fizer a transição para o modo de suspensão (D3), a plataforma subjacente poderá remover a energia do dispositivo mesmo quando ele estiver conectado por meio do barramento USB.

Configurações de hardware com suporte

O Windows dá suporte a quatro configurações de hardware físico para o dispositivo GNSS. O barramento de conectividade diferencia cada configuração de hardware.

GNSS conectado ao SoC por UART

Nessa configuração, o rádio GNSS é um dispositivo autônomo conectado a um UART no SoC. O rádio GNSS pode ter um ou mais GPIOs entre o rádio e o SoC para fins de transição entre os modos de energia ativa e de suspensão ou para lidar com condições de sequenciamento de redefinição e ativação.

Se o rádio GNSS consumir menos de 1 mW em seu modo de energia de suspensão, o rádio GNSS poderá estar conectado a qualquer trilho de alimentação do sistema que atenda às especificações do dispositivo.

O dispositivo GNSS deve ser declarado no namespace acpi e os GPIOs para gerenciamento de energia devem ser controlados pelos métodos de controle _PS3 e _PS0 sob o dispositivo no namespace ACPI. Os métodos _PS3 e _PS0 são executados pelo driver ACPI em resposta às transições D3 e D0 iniciadas pelo driver do sensor de localização. O integrador do sistema deve declarar os GPIOs como parte de uma região de operação GPIO no namespace ACPI.

Se o receptor GNSS consumir mais de 1 mW em seu modo de energia de suspensão, o receptor GNSS deverá estar conectado a um trilho de alimentação que possa ser ligado e desativado usando um GPIO controlado pelo firmware ACPI no SoC. Nessa configuração, o driver do sensor de localização deve habilitar d3cold. O GPIO para controlar o trilho de alimentação comutável deve ser exposto em uma região de operação gpio acpi. O integrador do sistema deve descrever um recurso de energia para o trilho de alimentação comutável, incluindo os métodos _OFF e _ON, bem como as referências ao recurso de energia no dispositivo GNSS no namespace .

O driver ACPI do Windows avaliará o método _OFF quando o driver do sensor de localização fizer a transição para D3. Quando o driver do sensor de localização fizer a transição para D0, o driver ACPI do Windows avaliará o método _ON no recurso de energia. A implementação dos métodos _OFF e _ON deve alternar o GPIO que controla o trilho de alimentação comutável e implementar quaisquer atrasos de sequenciamento de energia necessários.

GNSS integrado ao SoC

Se o dispositivo GNSS estiver fisicamente integrado ao SoC, a implementação de comunicações e gerenciamento de energia será específica para o próprio SoC.

O dispositivo GNSS ainda deve ser enumerado via ACPI, embora as comunicações com o receptor GNSS subjacente possam ocorrer por meio de um driver de transporte fornecido pelo fornecedor do SoC. Nessa configuração, o driver do sensor de localização ainda deve implementar uma transição D3 para entrar no modo de suspensão ou energia removida quando todos os clientes tiverem se desconectado. A transição D3 garante que as ferramentas de gerenciamento de energia do sistema operacional Windows e diagnóstico possam observar facilmente o estado de energia do dispositivo GNSS.

Os integradores de sistema que planejam aproveitar um rádio GNSS integrado ao soC do sistema devem consultar de perto o fornecedor do SoC para obter suporte a firmware, driver e gerenciamento de energia.

GNSS integrado a um rádio MBB conectado a USB como um dispositivo composto USB

Nota Sistemas com dispositivos GNSS no módulo MBB exigem uma consideração cuidadosa de integração. Entre em contato com seu representante da Microsoft para examinar o design de hardware, software e firmware para essas soluções.

Nessa configuração, o dispositivo GNSS é uma parte integrada do módulo MBB. O rádio GNSS pode compartilhar componentes de processamento, fonte de alimentação e antena RF com o rádio MBB. O rádio GNSS é exposto diretamente ao software como uma interface em um dispositivo composto USB. O driver do sensor de localização se comunica com o rádio GNSS diretamente pelo barramento USB usando interfaces de driver USB implementadas dentro do driver do sensor de localização.

O gerenciamento de energia do hardware GNSS é orientado por comunicações em banda com o módulo GNSS. O módulo GNSS e o driver do sensor de localização devem dar suporte a um mecanismo em banda para ativar e desativar o rádio GNSS. Esse mecanismo não deve depender do uso de gpios do SoC para o módulo MBB+GNSS.

Da mesma forma, o módulo GNSS e o driver do sensor de localização devem dar suporte à transição do dispositivo para o estado D3, de modo que o dispositivo composto USB possa entrar no estado de suspensão usb (suspensão seletiva). Todas as funções em um dispositivo composto USB devem ser suspensas para que o dispositivo composto seja suspenso. O dispositivo GNSS deve estar no modo suspensão (D3) para que a função GNSS e todo o dispositivo composto USB estejam no estado de suspensão.

Nota O dispositivo GNSS e o driver devem dar suporte à suspensão seletiva, caso contrário, o controlador de host USB no SoC não pode entrar em um modo de baixa potência e impedirá a economia de energia durante o modo de espera moderno.

Nessa configuração, o dispositivo GNSS é enumerado por meio de USB e do driver composto USB, mas é descrito no namespace ACPI. Nessa configuração, não há suporte para comunicações GPIO entre o dispositivo GNSS no módulo MBB e o SoC. O dispositivo GNSS deve permanecer enumerado para o Windows via ACPI durante todo o tempo em que a plataforma permanece no estado de energia do sistema S0, mesmo que o rádio seja desabilitado pelo usuário. O dispositivo GNSS não deve desaparecer do barramento USB durante qualquer parte do sistema a tempo.

GNSS integrado a um rádio MBB conectado a USB usando serviços de dispositivo

O designer de sistema pode optar por integrar um módulo MBB anexado por USB que contém um receptor GNSS inserido. Nessa configuração de hardware, o driver do sensor de localização se comunica com o receptor GNSS inserido por meio da interface de serviços de dispositivo de banda larga móvel, em vez de o dispositivo GNSS ser exposto como uma função USB autônoma como parte do dispositivo composto que representa todo o módulo MBB.

Nota Essa configuração não é recomendada. Os integradores do sistema que escolherem esse método de integração de dispositivo GNSS devem entrar em contato com o representante da Microsoft para validar a implementação correta. É preferível expor o dispositivo GNSS como parte de um dispositivo composto USB que representa o módulo MBB.

Nessa configuração, o dispositivo GNSS é uma parte integrada do módulo MBB. O rádio GNSS pode compartilhar componentes de processamento, fonte de alimentação e antena RF com o rádio MBB. A rádio GNSS é exposta indiretamente ao software por meio da interface de serviços de dispositivo que pode ser acessada usando a interface COM WindowsIMbnDeviceServices. O driver do sensor de localização se comunica com o rádio GNSS por meio da interface IMbnDeviceServices.

O gerenciamento de energia do hardware GNSS é orientado por comunicações em banda pela interface de serviços de dispositivo para o módulo MBB. O hardware GNSS deve dar suporte a um mecanismo em banda pela interface de serviços de dispositivo para desativar o rádio e colocar o dispositivo GNSS em um modo de baixa potência. Esses mecanismos devem ser acessíveis pelo driver do sensor de localização por meio da interface de serviços de dispositivo.

Nessa configuração, o dispositivo GNSS deve ser enumerado pela ACPI e descrito no namespace ACPI como um filho do módulo de banda larga móvel. O dispositivo GNSS não terá recursos de hardware descritos no dispositivo no namespace ACPI.

O driver do sensor de localização ainda deve executar o mesmo conjunto de diretrizes de implementação de gerenciamento de energia, conforme descrito na seção requisitos de implementação do driver anterior.

Nessa configuração, não há suporte para comunicações GPIO entre o dispositivo GNSS no módulo MBB e o SoC. Todas as comunicações de rádio e gerenciamento de energia são executadas fisicamente pelo barramento USB e expostas ao driver do sensor de localização por meio da interface de serviços de dispositivo. O dispositivo GNSS deve permanecer enumerado para o Windows via ACPI para todo o sistema a tempo, mesmo que o rádio seja desabilitado pelo usuário.

Ao implementar essa configuração de hardware, o integrador do sistema é incentivado a fazer parcerias estreitamente com o fornecedor do módulo MBB para garantir que o dispositivo GNSS seja exposto corretamente no namespace da ACPI.

Preocupações de ativação

Não há preocupações de ativação para dispositivos GNSS. Não se espera que os dispositivos GNSS ofereçam suporte à ativação do SoC de um estado de baixa energia.

Teste e validação

Fornecedores de dispositivos GNSS, fornecedores de módulo MBB e integradores de sistema devem seguir estas recomendações para testar e validar a implementação de gerenciamento de energia do dispositivo GNSS e seus componentes de software relacionados. Para obter mais informações, consulte Diretrizes de teste do GNSS (Global Navigation Satellite System).

Gerenciamento de energia do sensor de localização

O integrador do sistema deve validar se o driver do sensor de localização do dispositivo GNSS executa transições de gerenciamento de energia e entra no estado D3 quando todos os clientes são desconectados ou o rádio está desabilitado.

Os casos de teste básicos são:

Observe que o driver do sensor de localização faz a transição para D3 dentro de 10 segundos da tela desativada para espera moderna.
Observe que o driver do sensor de localização faz a transição para D3 dentro de 10 segundos após o rádio ser desativado no aplicativo Configurações do Windows.
Observe a transição do driver do sensor de localização para D0 imediatamente após sair do modo de espera moderno e iniciar um aplicativo que usa a API de Localização.

A maneira mais fácil de observar as transições de estado Dx do driver do sensor de localização é usar o Kit de Ferramentas de Desempenho do Windows para comparar com outros dispositivos de sensor do Windows. Esse método usa a instrumentação do Windows para validar se o IRP D3 está fazendo a transição por meio da pilha de driver de dispositivo que compreende o dispositivo GNSS. O gerenciador de energia do Windows inclui instrumentação ETW (Rastreamento de Eventos para Windows) interna, incluindo instrumentação para IRPs de energia do dispositivo (Dx). Para exibir essas informações em um modo manual, obtenha e instale o WPT (Windows Performance Toolkit) no sistema em teste.

Inicie um rastreamento XPerf no modo de usuário usando os seguintes comandos:

Abra um prompt de comando do administrador.
Navegue até a pasta \%ProgramFiles%\Windows Kits\8.0\Windows Performance Toolkit\ .
Inicie o Xperf: xperf.exe -start power_session -on Microsoft-Windows-Kernel-Power
Faça a transição do sistema para o modo de espera moderno usando o botão de energia.
Aguarde 120 segundos.
Faça a transição do sistema para fora do modo de espera moderno usando o botão de energia.
Aguarde 60 segundos.
Execute o seguinte comando para interromper o log de eventos: xperf.exe -stop power_session
Converta o arquivo de rastreamento binário em .csv e formato legível por humanos: xperf.exe –i \user.etl > power.txt
Abra o arquivo power.txt em um editor de texto e pesquise a ID de hardware do dispositivo GNSS. A ID de hardware do dispositivo GNSS pode ser determinada 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 GNSS é ACPI\MST0731\2&daba3ff&0.
O IRP D3 para o dispositivo GNSS é indicado por um evento do tipo Microsoft-Windows-Kernel-Power/IRP/Stop com o caminho da instância do dispositivo do dispositivo GNSS e o último valor de evento de 3 para o estado D3. A saída do evento abaixo do arquivo power.txt mostra o início do IRP D3.

Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\MSFT0731\2&daba3ff&0", 3
Esse evento deve ser registrado próximo ao início do arquivo de saída power.txt. O parâmetro 0x868e2728 no exemplo acima é um ponteiro para a estrutura D3 IRP. Ao localizar os eventos subsequentes com esse mesmo ponteiro IRP, uma exibição do IRP D3 que flui pela pilha de driver que compreende o dispositivo GNSS pode ser descoberta. Observe que o ponteiro IRP será específico do sistema e do tempo de vida da inicialização.
Microsoft-Windows-Kernel-Power/Irp/Start , 7605393, "Unknown" ( 4), 256, 0, , , , , 0x868e2728, 1, 2, 0x85fb56e0, 25, "ACPI\ATML1000\2&daba3ff&0", 3
Microsoft-Windows-Kernel-Power/Driver/Start , 7605416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\gpsdrv"
Microsoft-Windows-Kernel-Power/Driver/Stop , 7605515, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0
Microsoft-Windows-Kernel-Power/Driver/Start , 7608351, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90, "\Driver\ACPI"
Microsoft-Windows-Kernel-Power/Driver/Stop , 7608416, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x857ffb90
Microsoft-Windows-Kernel-Power/Driver/Start , 7608424, "Unknown" ( 4), 20, 0, , , , , 0x868e2728, 0x85fb56e0, "\Driver\sensdrv"

Validar se o dispositivo GNSS está retornando para D0 quando a tela está ativada é um processo semelhante. Um evento Microsoft-Windows-Kernel-Power/IRP/Start para o dispositivo GNSS será registrado com um estado de destino 0 (D0). O IRP D0 fluirá pelos drivers que compõem a pilha de dispositivos GNSS de maneira semelhante ao IRP D3.

Lista de verificação de gerenciamento de energia GNSS

Os integradores do sistema, os fornecedores de rádio GNSS e os fornecedores de SoC 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.

Integre um dispositivo GNSS à plataforma moderna com capacidade de espera na seguinte ordem de preferência de configuração:
1. Integrado com um módulo MBB (para sistemas equipados com MBB), conectado por USB.
2. Integrado ao SoC (para sistemas que têm GNSS no SoC).
3. Autônomo fora do SoC conectado a UART, I2C ou outro barramento de baixa potência.
Selecione um dispositivo GNSS que tenha um consumo médio de energia de suspensão (desativação) inferior a 1 mW, incluindo quaisquer interfaces de conexão de barramento.
Se o dispositivo GNSS tiver um consumo médio de energia de suspensão (desativação) de mais de 1 mW, o integrador do sistema e o fornecedor do dispositivo GNSS deverão dar suporte à remoção completa da energia do dispositivo GNSS quando não houver clientes de aplicativo conectados ou o rádio for desativado pelo usuário.
Verifique se o fornecedor do dispositivo GNSS fornece um driver de sensor de localização que implementa o gerenciamento de energia de runtime com base no número de clientes conectados e no estado do rádio GNSS.
Verifique se o fornecedor do dispositivo GNSS fornece uma biblioteca do gerenciador de rádio que expõe o rádio GNSS no aplicativo Configurações do Windows.

O driver do sensor de localização deve implementar uma interface privada para comunicar o estado de ativação/desativação entre a biblioteca do gerenciador de rádio fornecida pelo fornecedor e o driver do sensor de localização fornecido pelo fornecedor.
Se o GNSS for um dispositivo autônomo fora do SoC conectado via UART, I2C ou outro barramento de baixa potência, o integrador do sistema e o fornecedor do dispositivo GNSS deverão:
1. Documente todos os GPIOs entre o dispositivo GNSS e o próprio SoC.
2. Exponha quaisquer GPIOs para gerenciamento de energia como parte de uma região de operação GPIO no namespace ACPI.
Se o GNSS for um dispositivo autônomo fora do SoC conectado via UART, I2C ou outro barramento de baixa potência e o consumo médio de energia do dispositivo GNSS no modo de energia de suspensão for maior que 1 mW, o integrador do sistema e o fornecedor do dispositivo GNSS deverão:
1. Forneça um recurso de energia ACPI e métodos de controle _ON/_OFF para descrever o domínio de energia do GNSS.
2. Forneça os métodos _PR0 e _PR3 no dispositivo GNSS no namespace ACPI que se refere ao recurso de energia acPI descrito.
3. Verifique se o driver do sensor de localização faz uma transição D3 e habilita o D3cold no driver.
Se o GNSS fizer parte de um módulo MBB, o integrador do sistema e o fornecedor do dispositivo GNSS deverão:
1. Exponha o dispositivo GNSS como parte de um dispositivo composto USB.
2. Forneça um driver de sensor de localização que se comunique com o dispositivo GNSS diretamente por meio do barramento USB.
3. Verifique se o rádio está ligado/desligado e se todo o gerenciamento de energia do dispositivo GNSS pode ser executado em banda sobre o barramento USB. Nenhum GPIOs pode ser usado para alterar o estado de energia ou rádio GNSS nessa configuração de hardware.
4. Verifique se o dispositivo USB que descreve o módulo MBB ou o dispositivo composto USB que descreve o rádio MBB e GNSS entra no estado de suspensão USB durante o modo de espera moderno.
5. O driver do sensor de localização DEVE entrar no modo D3 (suspensão) quando todos os clientes estiverem desconectados ou o rádio tiver sido desativado mesmo se estiver se comunicando com o dispositivo pela interface de serviços do dispositivo.
6. Se o dispositivo GNSS for controlado pela interface de serviços de dispositivo de banda larga móvel (o que não é recomendado), o dispositivo GNSS deverá ser descrito no namespace acpi do sistema sem recursos de hardware. O dispositivo GNSS deve ser descrito como um filho do módulo de banda larga móvel no namespace ACPI.
Teste e valide se o dispositivo GNSS e o driver do sensor de localização executam o gerenciamento de energia corretamente. Valide os seguintes casos de teste no mínimo:
- Observe que o driver do sensor de localização faz a transição para D3 dentro de 10 segundos da tela desativada para espera moderna.
- Observe que o driver do sensor de localização faz a transição para D3 dentro de 10 segundos após o rádio ser desativado no aplicativo Configurações do Windows.
- Observe a transição do driver do sensor de localização para D0 imediatamente após sair do modo de espera moderno e iniciar um aplicativo que usa a API de Localização.
Valide o consumo de energia do dispositivo GNSS no estado de suspensão (D3) e verifique se ele é menor que 1 mW em média.

Share via