E/S de uso geral (GPIO)

Os circuitos integrados System on a Chip (SoC) fazem uso extensivo de pinos de E/S de uso geral (GPIO). Para plataformas baseadas em SoC, o Windows define uma abstração geral para hardware GPIO, e essa abstração requer suporte do namespace ACPI (Advanced Configuration and Power Interface).

A abstração GPIO é suportada pelas definições de especificação ACPI 5.0 listadas neste artigo.

Para verificar se o controlador GPIO atende a todos os requisitos da plataforma Windows, consulte Lista de verificação de requisitos do controlador GPIO.

Dispositivos controladores GPIO

O Windows suporta controladores GPIO. Os controladores GPIO fornecem uma variedade de funções para dispositivos periféricos, incluindo interrupções, sinalização de entrada e sinalização de saída. Os recursos GPIO são modelados como um dispositivo controlador GPIO no namespace. A extensão de estrutura GPIO (GpioClx) modela o dispositivo controlador GPIO como sendo particionado em algum número de bancos de pinos. Cada banco de pinos tem 64 ou menos pinos configuráveis. Os bancos em um controlador GPIO são ordenados em relação à posição de seus pinos dentro do espaço de pinos GPIO relativo ao controlador. Por exemplo, o banco 0 contém pinos 0-31 no controlador, o banco 1 contém pinos 32-63 e assim por diante. Todos os bancos têm o mesmo número de pinos, exceto o último banco, que pode ter menos. Os bancos são importantes para o firmware ACPI porque o firmware deve reportar o mapeamento de recursos de interrupção do sistema para bancos, conforme descrito na seção objetos de namespace GPIO abaixo.

Cada pino em um banco tem um conjunto de parâmetros (por exemplo, saída, interrupção sensível ao nível, entrada anti-ruído, e assim por diante) que descrevem como o pino deve ser configurado.

Controladores GPIO e interrupções ActiveBoth

Uma característica de alguns controladores GPIO é a capacidade de gerar interrupções em ambas as bordas de um sinal (bordas de subida, também conhecidas como ActiveHigh, e bordas de descida, também conhecidas como ActiveLow). Isso é útil numa variedade de aplicações, incluindo a interface de botões, em que tanto os eventos de pressionamento quanto de liberação do botão (uma extremidade e a extremidade oposta) são significativos. Esse recurso é conhecido como "ActiveBoth".

Logicamente, os sinais ActiveBoth têm um estado ativo e inativo, seja uma ativação momentânea (por exemplo, botões de pressão) ou uma ativação indefinidamente longa (por exemplo, inserção de um conector de fone de ouvido). A deteção de borda para interrupções ActiveBoth pode ser implementada no hardware do controlador GPIO (ActiveBoth em hardware) ou pode ser emulada no software do driver GPIO (ActiveBoth emulado). O Windows requer que os controladores GPIO que implementam ActiveBoth devem usar ActiveBoth emulado. Isso é necessário para garantir um tratamento robusto de interrupções duplas para todos os cenários. No suporte à emulação ActiveBoth, aplicam-se os seguintes requisitos de hardware:

1. Os controladores GPIO que suportam interrupções ActiveBoth devem suportar interrupções de modo de nível e devem suportar a reprogramação da polaridade da interrupção dinamicamente em tempo de execução.

2. Para minimizar o risco de erros de E/S, o Windows prefere o uso de controladores GPIO mapeados em memória em vez de controladores GPIO conectados ao SPB. Na verdade, para o dispositivo Windows Button Array (PNP0C40), é necessário que as interrupções GPIO do ActiveBoth para este dispositivo se conectem a um controlador GPIO mapeado na memória, e não a um controlador conectado ao SPB. Para determinar quais interrupções de botão devem ser ActiveBoth, consulte a seção Dispositivos de botão no tópico Outros objetos de namespace ACPI .

3. Para estabelecer um estado inicial determinístico para sinais de interrupção ActiveBoth, a pilha de dispositivos GPIO do Windows garante que a primeira interrupção gerada após a conexão da interrupção pelo driver será sempre para o estado declarado do sinal. A pilha assume ainda que o estado declarado de todas as linhas de interrupção ActiveBoth é nível lógico baixo (a borda ActiveLow) por padrão. Se esse não for o caso em sua plataforma, você pode substituir o padrão incluindo o método de Device-Specific do controlador GPIO (_DSM) no namespace do controlador. Para obter mais informações sobre esse método, consulte GPIO Controller Device-Specific Method (_DSM).

O terceiro requisito na lista anterior implica que o driver para um dispositivo que usa ActiveBoth pode receber uma interrupção imediatamente após inicializar (conectar-se a) a interrupção, se o sinal no pino GPIO estiver no estado declarado naquele momento. Isso é possível, e até provável para alguns dispositivos (por exemplo, fones de ouvido), e deve ser suportado no driver.

Para suportar o ActiveBoth emulado, o driver do controlador GPIO deve ativar a adesão à emulação ActiveBoth implementando uma função de retorno de chamada CLIENT_ReconfigureInterrupt e definindo o sinalizador EmulateActiveBoth na estrutura de informações básicas que a função de retorno de chamada CLIENT_QueryControllerBasicInformation do driver fornece ao GpioClx. Para obter mais informações, consulte General-Purpose drivers de Entrada/Saída (GPIO).

Objetos de namespace GPIO

Os controladores GPIO e os periféricos que se conectam a eles são enumerados pela ACPI. A conexão entre eles é descrita usando os Descritores de Recursos de Conexão GPIO. Para obter mais informações, consulte a seção 6.4.3.8, "Descritores de conexão", da especificação ACPI 5.0.

Identificação de dispositivos e objetos de configuração

O namespace ACPI de um dispositivo controlador GPIO inclui o seguinte:

• Um objeto de ID de hardware (_HID) compatível com ACPI atribuído pelo fornecedor.
• Um conjunto de recursos consumidos (_CRS) objeto.
• Um objeto Unique ID (_UID), se houver mais de uma instância do controlador GPIO no namespace (ou seja, dois ou mais nós de namespace que têm os mesmos objetos de identificação de dispositivo).

O _CRS do controlador GPIO contém todos os recursos (espaço de endereço para registos, interrupções do sistema e assim por diante) consumidos por todos os bancos no controlador GPIO. O mapeamento de recursos de interrupção para bancos é representado na ordem em que os recursos de interrupção estão listados no _CRS—ou seja, a primeira interrupção listada é atribuída ao banco 0, a seguinte é atribuída ao banco 1, e assim por diante. Os bancos podem compartilhar recursos de interrupção, caso em que a interrupção é listada uma vez para cada banco conectado a ela, em ordem bancária, e é configurada como compartilhada.

Descritores de recursos de conexão GPIO

A relação entre periféricos e os pinos GPIO aos quais eles estão conectados é descrita ao sistema operacional pelos descritores de recursos de conexão GPIO. Esses descritores de recursos podem definir dois tipos de conexões GPIO: conexões de interrupção GPIO e conexões de E/S GPIO. Os periféricos incluem descritores de conexão GPIO nos seus _CRS para todas as entradas/saídas GPIO e pinos de interrupção conectados. Se uma interrupção conectada for compatível com despertar (capaz de acordar o sistema de um estado ocioso de baixo consumo de energia), ela deverá ser configurada como ExclusiveAndWake ou SharedAndWake. Para obter mais informações, consulte Gerenciamento de energia do dispositivo.

Os descritores são definidos na secção 6.4.3.8.1, "GPIO Connection Descriptor", da especificação ACPI 5.0. As macros ASL Resource Template para esses descritores são descritas na seção 19.5.53, "GpioInt (GPIO Interrupt Connection Resource Descriptor Macro)", da especificação ACPI 5.0.

Eventos ACPI sinalizados pelo GPIO

ACPI define um modelo de evento de plataforma que permite que eventos de hardware na plataforma sejam sinalizados e comunicados ao driver ACPI. O Windows fornece um serviço de notificação para comunicar eventos da plataforma a drivers de dispositivo. Vários drivers de caixa de entrada dependem desse serviço para fornecer suporte a dispositivos definidos pela ACPI, como Botão de Energia do Método de Controle, Dispositivo LID, Bateria do Método de Controle, Zona Térmica e assim por diante. Para obter mais informações sobre notificações, consulte a seção 5.6.5, "GPIO-Signaled ACPI Events", da especificação ACPI.

Para plataformas SoC, as interrupções GPIO são usadas para sinalizar eventos da plataforma. Qualquer dispositivo de namespace ("dispositivo ACPI Event Source") que sinaliza eventos para seu driver usando o operador ASL Notify requer o seguinte:

• O nó de namespace do controlador GPIO ao qual o sinal de evento ACPI está conectado deve incluir um recurso GpioInt para esse pino no objeto ACPI Event Information (_AEI) (ver seção 2.4.2.3.1, "Objeto ACPI Event Information (_AEI)", abaixo). O recurso GpioInt deve ser configurado como não compartilhado (Exclusivo).

• O nó do controlador também deve conter um método de controlo Edge (_Exx), Level (_Lxx) ou Event (_EVT) para cada pino listado no objeto _AEI.

O driver ACPI manipula a interrupção GPIO listada e avalia o método de controle de Borda, Nível ou Evento para ela. O método de controle desativa o evento de hardware, se necessário, e executa o operador Notify necessário no nó de namespace do dispositivo de origem do evento. Em seguida, o Windows envia a notificação para o driver do dispositivo. Vários eventos podem ser sinalizados no mesmo recurso GpioInt se o método de controle de eventos puder consultar o hardware para determinar qual evento ocorreu. O método deve então notificar o dispositivo correto com o código de notificação correto.

Objeto ACPI Event Information (_AEI) Como mencionado anteriormente, o namespace do controlador GPIO deve conter o objeto _AEI para oferecer suporte a eventos ACPI. O objeto _AEI (veja a seção 5.6.5.2 na especificação ACPI 5.0) retorna um buffer de modelo de recurso contendo apenas descritores GpioInt que sinalizam eventos ACPI por meio desse controlador GPIO. Cada descritor corresponde a um dispositivo de origem de eventos ACPI e é dedicado a esse dispositivo (não compartilhado entre dispositivos).

Regiões de operação GeneralPurposeIO (OpRegions)

Os controladores GPIO são frequentemente usados pelo firmware da plataforma para suportar qualquer número de recursos de hardware da plataforma, como controlar energia e relógios ou definir modos em dispositivos. Para suportar o uso de E/S GPIO de métodos de controle ASL, ACPI 5.0 define um novo tipo de OpRegion, "GeneralPurposeIO".

GeneralPurposeIO OpRegions (veja a seção 5.5.2.4.4 da especificação ACPI 5.0) são declaradas dentro do escopo do namespace do dispositivo controlador GPIO cujo driver manipulará a E/S. As declarações de campo GeneralPurposeIO (ver secção 5.5.2.4.4.1 da especificação ACPI 5.0) atribuem nomes a pinos GPIO que devem ser acedidos dentro de uma GeneralPurposeIO OpRegion. Os Recursos de Conexão GpioIO (ver seção 19.5.53 da especificação ACPI 5.0) são usados dentro da declaração de campo para especificar o(s) número(s) de pino e a configuração para uma referência de campo específica. O número total de bits de campo nomeados após um descritor de conexão deve ser igual ao número de pinos listados no descritor.

Os campos em uma OpRegion podem ser declarados em qualquer lugar no namespace e acessados de qualquer método no namespace. A direção dos acessos a um GeneralPurposeIO OpRegion é determinada pelo primeiro acesso (leitura ou gravação) e não pode ser alterada.

Como o acesso ao OpRegion é fornecido pelo driver do dispositivo controlador GPIO (o "OpRegion Handler"), os métodos devem ter cuidado para não acessar o OpRegion até que o driver esteja disponível. O código ASL pode rastrear o estado do manipulador OpRegion incluindo um método Region (_REG) no dispositivo controlador GPIO (veja a seção 6.5.4 da especificação ACPI 5.0). Além disso, o objeto OpRegion Dependencies (_DEP) (consulte a seção 6.5.8 da especificação ACPI 5.0) pode ser usado em qualquer dispositivo que tenha um método de acesso aos campos GPIO OpRegion, se necessário. Consulte a seção Dependências de dispositivo no tópico Objetos de namespace de gerenciamento de dispositivos para uma discussão sobre quando usar _DEP. É importante que os drivers não recebam recursos de E/S GPIO que também são atribuídos a GeneralPurposeIO OpRegions. As Opregions são para uso exclusivo de métodos de controlo ASL.