Gerenciamento de energia Bluetooth para plataformas modernas em espera

Um dispositivo de rádio Bluetooth permite a comunicação RF de curto alcance entre um computador e um dispositivo de entrada, um dispositivo de áudio ou outro periférico de usuário conectado a Bluetooth. Em um computador em espera moderno, o driver de um rádio Bluetooth deve gerenciar os estados de energia desse dispositivo de acordo com as diretrizes apresentadas neste artigo.

Rádio Bluetooth

Em um sistema Windows, a maneira como o estado de energia do dispositivo de rádio Bluetooth é gerenciado depende do barramento ao qual o rádio está conectado. Em plataformas de hardware que dão suporte ao modelo de energia em espera moderno, o Windows dá suporte a rádios Bluetooth que estão conectadas a UARTs ou ao Barramento Serial Universal (USB). (Em teoria, o modelo de motorista de ônibus de transporte Bluetooth introduzido no Windows 8 deve dar suporte a qualquer barramento de comunicação subjacente. Atualmente, a Microsoft verifica a compatibilidade moderna de espera somente para rádios Bluetooth que estão conectados a UARTs ou USB ou que estão integrados a um SoC (Sistema em um Chip).

Assim como nas pilhas típicas de driver do Windows, a política de energia de rádio Bluetooth é gerenciada por um único PPO (proprietário da política de energia) – especificamente BthPort (bthport.sys). O BthPort funciona em conjunto com um driver específico de transporte correspondente (UART ou USB) para direcionar adequadamente o rádio para o estado de energia desejado. No caso de USB, isso é feito por meio da Suspensão Seletiva usb por meio do controlador de host USB. No caso do UART, um motorista de barramento de transporte fornecido pelo fornecedor adicional coordena solicitações do BthPort para o dispositivo de rádio Bluetooth pela conexão de barramento específica do sistema. Para controlar o hardware, o driver usa uma combinação de comunicação de barramento em banda, coordenação com o PEP (plug-in do motor de energia) e/ou sinalização fora de banda por meio de pinos GPIO.

Os dispositivos de rádio Bluetooth normalmente dão suporte a vários modos de baixa potência, alguns dos quais podem ser proprietários do próprio dispositivo. A pilha de drivers Bluetooth do Windows exige que um rádio Bluetooth dê suporte aos três estados de energia do dispositivo a seguir:

• Ativo (D0)
• Suspensão (D2)
• Desativado (D3)

Espera-se que o gerenciamento de energia do dispositivo para um rádio Bluetooth opere de maneira consistente em todos os estados de energia do sistema. O rádio Bluetooth não entra em um modo especial de gerenciamento de energia quando o sistema entra em espera moderno. Em vez disso, o rádio Bluetooth é transferido para dentro e para fora do estado de Suspensão (D2) com base em tempos limite ociosos gerenciados pelo BthPort. Para dar suporte à ativação de espera moderna em dispositivos de entrada HID conectados a Bluetooth, o rádio permanece no estado De suspensão (D2) e está armado para ativação. Somente o dispositivo Bluetooth HID emparelhado tem permissão para ativar o sistema durante o modo de espera moderno. Espera-se que o rádio Bluetooth tenha um consumo de energia muito baixo — menos de um miliwatt — no estado Suspensão (D2) se nenhum dispositivo estiver conectado por meio de links RF. Espera-se que o consumo de energia varie de acordo com o número de dispositivos associados, os tipos desses dispositivos e seus padrões de atividade.

O rádio Bluetooth também deve dar suporte à capacidade de desativar o rádio por meio da interface do usuário de gerenciamento de rádio. Esse controle de interface do usuário é integrado ao Windows. Depois que o rádio Bluetooth é desativado por meio dessa interface do usuário, o rádio é transferido para o estado de energia Desativado (D3), no qual se espera que ele consuma quase zero watts.

Versões anteriores do Windows, incluindo Windows 8 e Windows 8 RT, exigem que o fornecedor do dispositivo Bluetooth forneça uma DLL de controle de rádio. No entanto, começando com Windows 8.1 e Windows RT 8.1, todos os rádios Bluetooth em plataformas modernas em espera devem dar suporte à Especificação Principal do Bluetooth versão 4.0. Portanto, os fornecedores não são mais obrigados a fornecer uma DLL de software para implementar a função de controle de ativação/desativação de rádio. O Windows agora manipula essa função e ignorará qualquer DLL, mesmo se presente.

Modos de gerenciamento de energia

Do ponto de vista do software, a rádio Bluetooth dá suporte a três modos de gerenciamento de energia, independentemente do barramento ao qual o rádio está conectado. O driver Bluetooth do Windows possui a definição dos três modos e gerencia as transições para dentro e para fora desses modos. A tabela a seguir descreve os três modos de energia de rádio Bluetooth.

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	O rádio Bluetooth está se comunicando ativamente com um dispositivo associado em nome de um aplicativo no sistema operacional.	D0	Varia de acordo com o cenário e os dispositivos associados.	N/D	N/D
Suspensão (principalmente ociosa com um ciclo de direitos de baixa taxa)	O rádio Bluetooth está em um estado de baixa potência. O sistema foi emparelhado com um dispositivo Bluetooth remoto, mas não há conexão entre os dois. Ou seja, o dispositivo foi desconectado. O controlador Bluetooth deve ser capaz de gerar um sinal de ativação (para o SoC se o rádio não estiver integrado) quando novos dados chegarem do dispositivo emparelhado. Ou o rádio Bluetooth não tem associações. Ou, o rádio Bluetooth tem uma conexão ativa ociosa (nenhum dado sendo enviado/recebido) e o link está no modo de detecção.	D2	< 4 miliwatts	< 100 milissegundos	O driver Bluetooth do Windows inicia uma transição D2 usando um IRP de energia D2. O driver Bluetooth do Windows inicia um IRP de espera pendente no driver de ônibus de transporte subjacente. Se o dispositivo Bluetooth estiver anexado por meio de USB, esse estado será equivalente à suspensão seletiva. (A suspensão seletiva por Bluetooth exige que o dispositivo seja marcado como com capacidade de ativação remota e auto-alimentado no descritor de dispositivo USB.)
Desativado	O rádio Bluetooth está completamente desligado (zero watts) ou em um estado de baixa potência no qual nenhum estado de rádio é preservado. O rádio Bluetooth não é capaz de gerar um sinal de ativação para o SoC nesse estado. O rádio Bluetooth também não é capaz de emitir ou receber sinais de rádio— todos os componentes de RF são desligados.	D3	Zero watts	< 2 segundos	O driver Bluetooth do Windows inicia uma transição D3 usando um IRP de energia D3. O driver do barramento de transporte ou o firmware ACPI do sistema pode remover a energia ou alternar linhas GPIO para fazer a transição do hardware de rádio Bluetooth para o estado Desativado (D3).

O rádio Bluetooth também dá suporte a um modo associado no qual o transmissor de rádio pode ser desligado pelo software em resposta a uma solicitação do usuário. Quando o rádio está habilitado para o dispositivo Bluetooth, esse dispositivo está no estado Ativo (D0) ou Suspensão (D2). Quando o rádio para o dispositivo Bluetooth é desabilitado pelo usuário, o Windows interrompe a atividade bluetooth removendo surpresa os drivers de protocolo e seus filhos e, em seguida, fazendo a transição da pilha do dispositivo de rádio para o estado Desativado (D3).

Mecanismos de gerenciamento de energia de software

O gerenciamento de energia de um dispositivo de rádio Bluetooth é controlado por transições de estado Dx do dispositivo iniciadas pelo BthPort como o PPO (proprietário da política de energia). O PPO decide quando o dispositivo faz a transição entre os estados Ativo (D0), Suspensão (D2) e Desativado (D3).

Quando o rádio não tem nenhum dispositivo associado, o Windows faz a transição do dispositivo para D2 e o mantém nesse estado até que o usuário inicie o processo de emparelhamento. Quando o rádio está associado a um ou mais dispositivos, o driver Bluetooth do Windows usa um tempo limite ocioso para decidir quando fazer a transição do rádio Bluetooth de D0 para D2. Esse algoritmo usa o padrão de uso de Bluetooth pelo sistema operacional e aplicativos para determinar quando fazer a transição do rádio para o estado D2. Por exemplo, o rádio faz a transição para D2 vários segundos após a última tecla pressionar um teclado Bluetooth se não houver outra atividade no rádio Bluetooth.

O driver Bluetooth do Windows faz a transição do dispositivo para D0 em resposta a qualquer um dos seguintes:

• O usuário inicia um processo de emparelhamento.
• Um aplicativo solicita o uso da funcionalidade Bluetooth.
• O rádio Bluetooth gerou uma solicitação de ativação com base na entrada de um dispositivo associado.

Ao contrário de outros dispositivos, o rádio Bluetooth segue o mesmo padrão de gerenciamento de energia durante o modo de espera moderno (exibição do sistema) que faz quando o sistema normalmente está operacional e a tela está ativada. Isso ocorre porque espera-se que o rádio Bluetooth esteja disponível para ativar o SoC quando a entrada for recebida de um dispositivo associado a qualquer momento durante o modo de espera moderno. Por exemplo, se um usuário tiver associado um teclado Bluetooth a um computador Windows, pressionar qualquer tecla no teclado deverá ativar o computador do modo de espera moderno e ativar a tela.

Se nenhum dispositivo estiver associado ao rádio, espera-se que o rádio seja configurado para consumir menos de um miliwatt quando estiver no estado Suspensão (D2).

Quando o rádio Bluetooth está no estado Desativado (D3), espera-se que ele consuma quase zero watts.

Notas de implementação do driver

Se o rádio Bluetooth estiver conectado por meio de um UART ou integrado ao soc em si, o fornecedor do dispositivo Bluetooth será obrigado a implementar e fornecer um driver de barramento de transporte. O motorista do ônibus de transporte é responsável pelo seguinte:

• Traduzindo solicitações de pacotes Bluetooth HCI do driver Bluetooth do Windows (Bthmini.sys) para comandos enviados pelo barramento de transporte para o rádio Bluetooth.
• Transição do dispositivo de rádio Bluetooth para vários modos de gerenciamento de energia que são mapeados para os estados de energia do dispositivo Ativo (D0), Suspensão (D2) e Desativado (D3). O driver também implementa rotinas que lidam com eventos de gerenciamento de energia.
• Configurar o rádio Bluetooth para ativar o SoC quando um dispositivo gera entrada e alterar o estado de qualquer linha GPIO opcional do SoC para o rádio Bluetooth usado para gerenciamento de energia.
• Enumeração e gerenciamento de energia de outros dispositivos (como um transmissor FM ou dispositivo GPS) que compartilham o mesmo barramento que o rádio Bluetooth. Se outros dispositivos estiverem fisicamente conectados ao barramento compartilhado, mas não forem expostos ao sistema operacional, o motorista do ônibus de transporte deverá desligar completamente esses dispositivos.

Para obter detalhes sobre como implementar um motorista de ônibus de transporte, consulte Diretrizes de manipulação de controle de energia do Driver do Barramento de Transporte para Bluetooth. Os drivers de barramento de transporte devem ser gravados usando o WDF (Windows Driver Framework). Um driver de exemplo está disponível em Driver de Barramento HCI Serial Bluetooth.

Para habilitar o gerenciamento de energia de rádio Bluetooth, o motorista do barramento de transporte deve executar as seguintes ações:

• Habilite o suporte para gerenciamento de energia ociosa em tempo de execução e exponha o suporte para os estados de energia do dispositivo Ativo (D0), Suspensão (D2) e Desativado (D3).
• Indique ao driver Bluetooth do Windows que o dispositivo de rádio Bluetooth é capaz de sinalizar eventos de ativação do estado D2.
• Suporte para armar o dispositivo de rádio Bluetooth para ativar o SoC e desarmar o sinal de ativação do dispositivo Bluetooth para o SoC. Esse suporte pode exigir o tratamento de uma ou mais interrupções de GPIO e a execução de métodos de ativação no WDF.
• Altere o estado de qualquer linha GPIO opcional do SoC para o dispositivo de rádio Bluetooth quando o dispositivo fizer a transição entre os estados Ativo (D0), Suspensão (D2) e Desativado (D3).

Se o rádio Bluetooth estiver integrado ao soc em si, o driver do barramento de transporte poderá se registrar na estrutura de gerenciamento de energia do Windows para comunicar a energia de rádio Bluetooth status a um PEP (plug-in de power-engine) específico do SoC. Isso é feito definindo o membro IdleTimeoutType da estrutura WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS com o valor SystemManagedIdleTimeout.

Se o rádio Bluetooth estiver conectado por meio de USB, a pilha interna de driver Bluetooth USB do Windows deverá ser usada. A pilha lida com todas as operações de gerenciamento de energia.

Gerenciamento de rádio

O estado do transmissor de rádio Bluetooth está vinculado diretamente ao estado de energia do dispositivo. Espera-se que o transmissor de rádio esteja ligado quando o rádio estiver no estado de energia Ativo (D0) ou Suspensão (D2). O transmissor de rádio deve ser desativado quando o rádio faz a transição para o estado Desativado (D3).

Quando o usuário desativa o rádio Bluetooth, o Windows encerra a atividade bluetooth cancelando operações de E/S pendentes e descarregando os drivers de protocolo e seus filhos. Em seguida, a pilha de driver Bluetooth do Windows emite o comando HCI_Reset para o controlador para redefinir o rádio para seu estado padrão. No estado padrão, o controlador não deve ser capaz de transmitir ou receber sinais de rádio. Por fim, o controlador faz a transição para o estado Desativado (D3).

Em resposta à transição para Desativado (D3), o motorista do barramento de transporte deve desligar o dispositivo Bluetooth para seu estado de energia mais baixo usando métodos específicos do dispositivo. Uma implementação típica é alterar o estado de uma linha GPIO do SoC para o rádio Bluetooth para desabilitar a energia para o módulo Bluetooth. Uma implementação alternativa é exigir que o firmware ACPI remova a energia do módulo Bluetooth usando métodos de controle _PS0 e _PS3.

Quando o usuário ativa o rádio Bluetooth, o Windows faz a transição do rádio para o estado Ativo (D0), reinicializa o rádio e enumera novamente os drivers de protocolo filho. Quando o rádio faz a transição para Ativo (D0), todas as linhas GPIO necessárias devem ser alternadas como parte da sequência D0 normal para o rádio Bluetooth. Se o firmware acpi foi usado para desligar o rádio, ele deve restaurar a energia usando o método de controle _PS0.

Como parte dessa sequência normal, o driver do barramento de transporte deve marcar o dispositivo como um Dispositivo Conectado Internamente definindo a ContainerId do rádio Bluetooth como um valor guid específico, {0000000-0000-000-ffff-ffffffffffff}. Isso permite que os elementos da interface do usuário de rádio do Windows detectem que o rádio Bluetooth exposto pelo driver do barramento de transporte é interno para o computador e não um rádio anexado externamente para o qual o controle de rádio não é apropriado.

Configurações de energia de hardware com suporte

A configuração de hardware de gerenciamento de energia para um rádio Bluetooth depende do barramento de comunicação. De um modo geral, espera-se que todos os rádios Bluetooth tenham os seguintes recursos de gerenciamento de energia de hardware em comum:

• Suporte para o estado Desativado (D3) como um meio de desativar o rádio em resposta a uma solicitação do usuário. Desligar o rádio coloca o rádio Bluetooth em um estado de baixa potência que é quase zero watts.
• Um mecanismo para inserir um estado de suspensão de baixa potência (D2) no qual as conexões são mantidas para dispositivos associados, mas não há transferências ativas.
• Um mecanismo para gerar uma interrupção de ativação quando um dispositivo associado tem dados para o SoC e o SoC está em um estado de baixa potência no qual o barramento ao qual o dispositivo de rádio Bluetooth está anexado não está ativo no momento.

Cada um dos barramentos com suporte (USB, UART e integração ao SoC) para o dispositivo de rádio Bluetooth dá suporte a todos os três recursos básicos de gerenciamento de energia de hardware na lista anterior. Além disso, cada rádio Bluetooth pode ter recursos de gerenciamento de energia específicos do fornecedor ou específicos do dispositivo, mas eles estão fora do escopo deste tópico.

Os fornecedores de rádio Bluetooth são incentivados a implementar recursos de gerenciamento de energia de valor agregado de forma autônoma em hardware e não exige software de driver fornecido pelo fornecedor adicional no sistema Windows. Os fornecedores de rádio Bluetooth também são incentivados a implementar seus drivers e seu software de gerenciamento de energia de uma forma que abstraa diferenças específicas da plataforma no firmware ACPI do sistema em vez de no código do driver do dispositivo ou no arquivo .inf do driver. Essa abordagem permite que um pacote de driver para o dispositivo Bluetooth seja reutilizado em plataformas adicionais sem a necessidade de uma atualização para a origem do driver, binário ou pacote de instalação assinado.

Rádio Bluetooth que está conectado por meio de um UART fora do SoC

Se o rádio Bluetooth estiver conectado por meio de um UART e estiver fisicamente localizado fora do SoC, o fornecedor de rádio Bluetooth deverá fornecer um driver de ônibus de transporte que exponha o rádio Bluetooth e quaisquer outras funções de dispositivo (por exemplo, uma rádio FM) que compartilhem o mesmo caminho de comunicação por meio do UART. O motorista do ônibus também é responsável por gerenciar todos os recursos gpio que controlam o consumo de energia e a capacidade de ativação do rádio Bluetooth.

Ao contrário de outras classes de dispositivo, as linhas GPIO que controlam a energia e a ativação do Bluetooth são gerenciadas diretamente pelo motorista do barramento de transporte em vez de serem abstraídas pelos métodos de controle ACPI. Esse esquema de controle é resultado do design do driver de barramento multifuncional que enumera o rádio Bluetooth e outras funções que compartilham a mesma porta UART. Nesse design, o driver ACPI do Windows, Acpi.sys, não é carregado nas pilhas de driver para Bluetooth e rádio FM, tornando impossível usar a execução do método de controle ACPI como uma maneira de responder a uma transição de estado Dx do dispositivo.

Quando o rádio Bluetooth está conectado à porta UART no SoC, o integrador do sistema deve usar um pino no controlador GPIO no SoC para controlar a energia do rádio. No firmware ACPI, esse pino deve ser atribuído como um recurso de E/S de GPIO ao objeto de dispositivo que representa o dispositivo raiz do driver do barramento de transporte. O pino GPIO poderá ser conectado diretamente ao rádio Bluetooth se o rádio der suporte à desativação do dispositivo com alimentação interna.

Se o rádio Bluetooth der suporte à alimentação, a fonte de alimentação do rádio Bluetooth poderá ser conectada a qualquer trilho de alimentação do sistema.

Se o rádio não der suporte a alimentação interna controlada por um pino GPIO, o integrador do sistema deverá colocar o rádio Bluetooth em um trilho de alimentação que seja comutável. O pino gpio do SoC é então conectado ao hardware de comutação de energia. Nesse design, os métodos de controle ACPI não podem ser usados para rastrear contagens de referência ou para agregar o estado de energia de vários dispositivos que compartilham o mesmo trilho de alimentação, portanto, o rádio Bluetooth deve ser isolado em seu próprio trilho de alimentação comutável.

O integrador do sistema deve usar um pino adicional no controlador GPIO no SoC para receber interrupções de ativação do rádio Bluetooth. As interrupções nesse pino devem ser capazes de acordar o SoC de seu estado de energia mais baixo. Em alguns designs de SoC, esse pin é chamado de pino DE GPIO sempre ativado porque o controlador GPIO pode detectar interrupções nesse pino o tempo todo, independentemente do estado de energia do SoC. A funcionalidade always-on pode ser limitada em hardware a um conjunto específico de pinos GPIO no SoC ou pode ser configurável no firmware. É fundamental que o integrador do sistema revise esse design com o fornecedor do SoC para garantir que a interrupção de ativação do rádio Bluetooth faça com que o SoC saia do estado de energia ocioso mais profundo. (Em todos os momentos durante o modo de espera moderno, o sistema está em S0. Sistemas de espera modernos não dão suporte a S3.)

Quando todas as funções enumeradas pelo motorista do barramento de transporte tiverem sido desligadas e o dispositivo de barramento de transporte enumerado por ACPI entrar em D3, o pino de GPIO sempre ativado poderá ser desligado. Isso ocorre quando os rádios de todas as funções de dispositivo enumeradas pelo motorista do barramento de transporte foram desativados pelo usuário.

Rádio Bluetooth em USB

Se o rádio Bluetooth estiver anexado ao SoC ou ao silício principal sobre o barramento USB, o rádio deverá ser alimentado de uma fonte diferente do barramento USB. Na especificação USB, esse rádio é descrito como auto-alimentado, e essa funcionalidade deve ser relatada nos descritores USB do dispositivo Bluetooth.

Da mesma forma, o hardware do dispositivo USB deve anunciar suporte para ativação remota, que é a capacidade do rádio Bluetooth de gerar sinalização de retomada USB em banda para ativar o controlador de host USB. A funcionalidade de ativação remota também deve ser anunciada nos descritores USB do rádio Bluetooth.

O rádio Bluetooth deve dar suporte aos recursos de ativação remota e auto-ativada para que possa entrar no estado De suspensão (D2) e habilitar a suspensão seletiva.

Se o rádio Bluetooth estiver no estado Suspensão (D2) e os dados de um dispositivo associado estiverem disponíveis para o host, o rádio Bluetooth deverá gerar a sinalização de retomada de ativação remota para ativar o host. Não há suporte para um sinal de retomada fora de banda usando uma linha GPIO para o silício principal. Espera-se que o rádio Bluetooth, incluindo seus circuitos de conexão USB, consuma menos de um miliwatt de energia no estado Sleep (D2).

Preocupações de ativação

Espera-se que o rádio Bluetooth seja capaz de gerar uma interrupção de ativação quando estiver no estado Suspensão (D2). A interrupção de ativação deve fazer com que o SoC ligue, mesmo que o SoC esteja em seu estado de energia mais baixo. A tabela a seguir resume os dois mecanismos de sinalização de ativação bluetooth.

Barramento de conexão	Caminho de sinalização de hardware	Comentários e anotações
UART (com motorista de ônibus de transporte fornecido pelo fornecedor)	GPIO do rádio Bluetooth para o SoC.	O rádio deve estar conectado a um pino GPIO que possa ativar o SoC de seu estado de energia mais baixo.
USB	Usb em banda retoma a sinalização da suspensão seletiva.	Não há suporte para a ativação gpio fora de banda.

Teste e validação

Os fornecedores de dispositivos Bluetooth são incentivados a testar e validar a operação de gerenciamento de energia do dispositivo de rádio Bluetooth.

As transições entre os estados Ativo (D0), Suspensão (D2) e Desativado (D3) podem ser facilmente observadas usando a ferramenta Xperf, conforme descrito em outras seções.

As atividades do driver Bluetooth podem ser monitoradas usando a instrumentação ETW incorporada ao Windows. O desenvolvedor do driver é incentivado a usar a instrumentação etw (Rastreamento de Eventos para Windows) para expor alterações significativas de estado de gerenciamento de energia no driver e observá-las usando a ferramenta Xperf ou o Windows Visualizador de Eventos interno.

Se o rádio Bluetooth for anexado por meio de USB, o utilitário de Powercfg.exe interno poderá ser usado junto com a opção de linha de comando /energy para validar se o rádio está entrando no estado Suspensão (D2) e está suspenso. Para usar o utilitário Powercfg.exe:

• Abra uma janela do Prompt de Comando como Administrador.
• Altere para o diretório raiz da unidade (cd \).
• Insira o comando powercfg.exe /energy.
• Aguarde os 60 segundos padrão.
• O utilitário Powercfg.exe gerará o número de erros e condições de aviso no sistema, conforme mostrado na captura de tela a seguir.
• Depois que a ferramenta grava as informações de resumo na janela do prompt de comando, ela gera um arquivo HTML chamado Energy-report.html. Abra o arquivo e procure condições de erro ou aviso do dispositivo Bluetooth USB. O resumo de exemplo a seguir relata que um dispositivo Bluetooth USB não entrou no estado Suspensão (D2) quando está ocioso.

Os fornecedores de dispositivos Bluetooth que fornecem aplicativos e drivers de perfil Bluetooth de terceiros adicionais devem verificar se seu software dá suporte à remoção surpresa e permite que a infraestrutura de gerenciamento de rádio desligue corretamente o rádio Bluetooth em tempo hábil. Esses cenários devem ser validados enquanto o perfil ou o aplicativo está em uso. Por exemplo, para drivers de áudio, deve haver streaming de áudio Bluetooth enquanto o rádio está desativado. Em seguida, o rádio deve ser ativado novamente e o fluxo de áudio reiniciado para verificar se ele ainda funciona.

Lista de verificação de gerenciamento de energia bluetooth

Os integradores do sistema, os fornecedores de rádio Bluetooth e os fornecedores de SoC devem usar a seguinte lista de verificação para garantir que o design de gerenciamento de energia do sistema seja compatível com Windows 8 e Windows 8.1:

• Determine o barramento de comunicação para o rádio Bluetooth no design do sistema. O rádio Bluetooth é conectado por UART ou anexado via USB.

• Verifique se o rádio Bluetooth dá suporte a um modo de suspensão de baixa potência que consome menos de um miliwatt quando nenhum dispositivo está associado.

  O consumo de energia do rádio Bluetooth no modo de suspensão pode variar de acordo com o número de dispositivos associados que estão atualmente presentes, mas geralmente não deve exceder cinco miliwatts a qualquer momento.

• Verifique se o rádio Bluetooth dá suporte aos seguintes recursos básicos de gerenciamento de energia necessários:

  • Suporte para o estado Desativado (D3) como uma maneira de permitir que o usuário desative o rádio.
  • Um mecanismo para inserir um estado de Suspensão (D2) de baixa potência em que as conexões são mantidas para dispositivos associados, mas não há transferências ativas.
  • Um mecanismo para ativar o SoC quando um dispositivo associado gera dados e o SoC está em um estado de baixa potência.

• Se o rádio Bluetooth estiver conectado por um barramento não USB (UART ou integrado ao SoC), o fornecedor de rádio Bluetooth deverá desenvolver um motorista de ônibus de transporte. O motorista do ônibus de transporte deve fazer o seguinte:

  • Dê suporte aos recursos e requisitos detalhados nas Diretrizes de Tratamento do Driver do Barramento de Transporte para Bluetooth.
  • Traduza solicitações Bluetooth do driver Bluetooth do Windows (Bthmini.sys) para comandos para o rádio Bluetooth pelo barramento UART ou por um barramento soC interno proprietário.
  • Transicione o dispositivo de rádio Bluetooth para vários modos de gerenciamento de energia que são mapeados para os estados Ativo (D0), Suspensão (D2) e Desativado (D3). O driver também deve implementar rotinas que lidam com IRPs de Dx (gerenciamento de energia do dispositivo).
  • Configure o rádio Bluetooth para ativar o SoC quando um dispositivo gerar entrada e alterar o estado de qualquer linha GPIO opcional que conecte o SoC ao rádio Bluetooth para fins de gerenciamento de energia.
  • Enumerar outros dispositivos (por exemplo, um transmissor FM) que podem ser compartilhados no rádio Bluetooth.
  • Use o WDF (Windows Driver Framework) para desenvolvimento de driver.
  • Seja implementado com base no Driver de Barramento HCI Serial bluetooth.

• Se o rádio Bluetooth estiver conectado via USB, o fornecedor de rádio Bluetooth deverá:

  • Habilite o suporte para suspensão seletiva no rádio.
  • Verifique se o rádio tem os recursos de ativação remota e auto-alimentação definidos no descritor de dispositivo USB.
  • Verifique se o rádio (incluindo componentes USB) consome menos de um miliwatt.

• Independentemente do barramento de conexão, o rádio Bluetooth deve fazer o seguinte para um rádio conectado internamente:

  • Verifique se todos os componentes RF estão desativados em resposta a um comando HCI_Reset que está sendo enviado ao rádio em preparação para desligar o rádio. O rádio não deve ser capaz de transmitir nem receber nenhum sinal de rádio.
  • Insira seu modo de energia mais baixo quando definido como o estado Desativado (D3).

• Se o rádio Bluetooth estiver conectado por UART, o integrador do sistema deverá conectar o sinal de ativação do rádio Bluetooth a um pino GPIO no SoC que pode ativar o SoC do estado de energia mais baixo.

  • O SoC pode exigir que os sinais de ativação sejam roteados para um conjunto limitado de pinos GPIO pré-configurados para serem sempre ativados.
  • Ou o SoC pode dar suporte à configuração de um pino gpio para um pino always-on no firmware do sistema durante a inicialização.

• O integrador do sistema deve testar e verificar se o rádio Bluetooth entra no estado Suspensão (D2) quando não há dispositivos associados.

• O integrador do sistema deve testar e verificar se o rádio Bluetooth entra no estado Suspensão (D2) quando todos os dispositivos associados não têm nenhuma transferência ativa.

• O integrador do sistema deve testar e verificar se o rádio Bluetooth pode ativar o SoC de seu estado de energia mais baixo quando o rádio estiver no estado De suspensão (D2).

• O integrador do sistema deve testar e verificar se o rádio Bluetooth não gera sinais de ativação espúrios enquanto estiver no estado Suspensão (D2).

• O integrador do sistema deve testar e verificar se o software de terceiros do complemento, como drivers de perfil e aplicativos, funciona corretamente com o gerenciamento de rádio Bluetooth. O rádio deve ser desativado e ativado enquanto o software de terceiros está ativamente em uso (por exemplo, reproduzindo áudio ou transferindo um arquivo).