Dominando o Subsistema de Controle de Pinos para Drivers de Dispositivos Linux

Nota do Editor: Linux Embarcado está se tornando a espinha dorsal da Internet das Coisas, e drivers de dispositivo são a ponte entre aplicações e hardware. Em "Linux Device Drivers Development", o autor John Madieu oferece um guia detalhado e rico em código para construir esses drivers.

Este trecho — Capítulo 14 do livro — mergulha em controle de pinos e GPIOs, área crítica para desenvolvedores que precisam interligar hardware customizado com o kernel. A primeira parte introduz o subsistema de controle de pinos.

Adaptado de Linux Device Drivers Development, por John Madieu.

---

Capítulo 14. Subsistema de Controle de Pinos e GPIO
Por John Madieu

No Linux embarcado, drivers quase sempre interagem com GPIOs ou configuram multiplexação de pinos. Um "pino" é a linha de saída física de um componente, e muitos SoCs reutilizam o mesmo pino para várias funções. Por exemplo, o pino i.MX6QDL MX6QDL_PAD_SD3_DAT1 pode servir como linha de dados SD, linha UART RTS/CTS, linha FlexCAN Rx, ou GPIO genérico.

O processo de selecionar a função de um pino é chamado pin muxing, e o componente do kernel que orquestra isso é o pin controller. Na segunda parte deste capítulo exploraremos o subsistema General Purpose Input/Output (GPIO), uma função comum de pino.

Neste capítulo você irá:

• Percorrer o subsistema de controle de pinos e aprender como declarar nós de pin‑control na Device Tree.
• Comparar a API GPIO legada baseada em inteiros com a interface mais nova baseada em descritores.
• Lidar com GPIOs que também são usados como interrupções.
• Explorar interfaces sysfs dedicadas ao gerenciamento de GPIO.

Subsistema de controle de pinos

O subsistema pinctrl gerencia multiplexação e configuração de pinos. Dispositivos que requerem um arranjo específico de pinos devem descrever esse arranjo na Device Tree. O driver do pin‑controller parseia essas descrições e programa o controlador de I/O do SoC conforme necessário.

O subsistema oferece:

• Multiplexação de pinos — reutilizar um único pino para múltiplas funções (UART TX, GPIO, HSI, etc.) por grupo ou por pino.
• Configuração de pinos — definir propriedades elétricas como pull‑up/pull‑down, drive strength, debounce, e mais.

Note que este livro foca no uso da API do pin‑controller; não cobre escrita de um driver de pin‑controller em si.

Pinctrl e a Device Tree

Na Device Tree, um nó de pin‑controller descreve todos os grupos de pinos e funções disponíveis. Cada grupo recebe um ID inteiro, opcionalmente acompanhado por um pinctrl-name que mapeia nomes legíveis por humanos para IDs.

O binding de um dispositivo especifica os estados de pino que ele requer. Duas propriedades vinculam um dispositivo a estados de pino:

• pinctrl- — uma lista de phandles apontando para nós de configuração de pino. Múltiplas entradas permitem que um dispositivo seja configurado por vários pin controllers ou para combinar múltiplos nós para um único controller.
• pinctrl-name — uma lista paralela atribuindo nomes a cada ID de estado. Estado 0 geralmente é nomeado default e segue a lista padrão definida em include/linux/pinctrl/pinctrl-state.h.

Abaixo está um trecho típico de Device Tree mostrando configuração de pino para dois dispositivos:

Cada linha segue o formato <PIN_FUNCTION> <PIN_SETTING>:

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x80000000 MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1 

O primeiro token (MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09) identifica a função do pino; o segundo token (0x80000000) codifica bits de configuração (pull‑up/down, drive strength, etc.). Essas macros são definidas em arquivos de header específicos da arquitetura como arch/arm/boot/dts/imx6q-pinfunc.h.

Para programar um estado de pino em código de driver, siga estes passos durante a inicialização (tipicamente em probe()):

struct pinctrl *pinctrl; pinctrl = devm_pinctrl_get_select_default(&pdev->dev); if (IS_ERR(pinctrl)) dev_warn(&pdev->dev, "pins are not configured from the driver"); 

O helper pinctrl_get_select_default() recupera e aplica automaticamente o estado default. Se um dispositivo fornece um estado init, o core aplicará esse estado antes do probe() e então reverterá para default depois, a menos que o driver o altere.

Quando terminar, libere o controller com pinctrl_put(pinctrl) ou use a variante resource‑managed devm_pinctrl_put(pinctrl).

Aqui está um exemplo concreto do arquivo am335x-evm.dts:

dcan1: d_can@481d0000 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&d_can1_pins>; };

No driver correspondente:

pinctrl = devm_pinctrl_get_select_default(&pdev->dev); if (IS_ERR(pinctrl)) dev_warn(&pdev->dev, "pins are not configured from the driver");

No momento em que o probe() do driver roda, a configuração de pino default já está em vigor.

A próxima parcela cobrirá o subsistema GPIO em detalhes.

Reimpresso com permissão da Packt Publishing. Copyright © 2017 Packt Publishing

---

John Madieu é engenheiro de kernel e Linux embarcado baseado em Paris. Desenvolve drivers e BSPs para clientes em automação, transporte, saúde, energia e defesa. John trabalha na EXPEMB, pioneira em design computer‑on‑module, e é um advogado ativo de open‑source que acredita que compartilhamento de conhecimento acelera inovação.