Dominando el subsistema de control de pines para drivers de dispositivos Linux

Nota del Editor: Embedded Linux se está convirtiendo en la columna vertebral del Internet de las Cosas, y los device drivers son el puente entre aplicaciones y hardware. En «Linux Device Drivers Development», el autor John Madieu ofrece una guía detallada y rica en código para construir estos drivers.

Este extracto —Capítulo 14 del libro— se sumerge en control de pines y GPIOs, un área crítica para desarrolladores que necesitan interconectar hardware personalizado con el kernel. La primera entrega introduce el subsistema de control de pines.

Adaptado de Linux Device Drivers Development, por John Madieu.

Capítulo 14. Subsistema de Control de Pines y GPIO
Por John Madieu

En Linux embebido, los drivers casi siempre interactúan con GPIOs o configuran multiplexación de pines. Un «pin» es la línea de salida física de un componente, y muchos SoCs reutilizan el mismo pin para varias funciones. Por ejemplo, el pin i.MX6QDL MX6QDL_PAD_SD3_DAT1 puede servir como línea de datos SD, línea UART RTS/CTS, línea FlexCAN Rx, o un GPIO genérico.

El proceso de seleccionar la función de un pin se llama pin muxing, y el componente del kernel que orquesta esto es el controlador de pines. En la segunda parte de este capítulo exploraremos el subsistema General Purpose Input/Output (GPIO), una función común de pin.

En este capítulo usted:

• Recorrerá el subsistema de control de pines y aprenderá a declarar nodos de pin-control en el Device Tree.
• Comparará la API GPIO legacy basada en enteros con la interfaz moderna basada en descriptores.
• Manejará GPIOs que también se usan como interrupciones.
• Explorará interfaces sysfs dedicadas a gestión de GPIO.

Subsistema de control de pines

El subsistema pinctrl gestiona multiplexación y configuración de pines. Dispositivos que requieren un arreglo de pines específico deben describir ese arreglo en el Device Tree. El driver del pin-controller parsea estas descripciones y programa el controlador I/O del SoC en consecuencia.

El subsistema ofrece:

• Multiplexación de pines —reutilizar un solo pin para múltiples roles (UART TX, GPIO, HSI, etc.) por grupo o por pin.
• Configuración de pines —establecer propiedades eléctricas como pull-up/pull-down, fuerza de drive, debounce y más.

Nota que este libro se enfoca en usar la API del pin-controller; no cubre escribir un driver de pin-controller en sí.

Pinctrl y el Device Tree

En el Device Tree, un nodo pin-controller describe todos los grupos de pines y funciones disponibles. A cada grupo se le asigna un ID entero, opcionalmente acompañado por un pinctrl-name que mapea nombres legibles por humanos a IDs.

El binding de un dispositivo especifica los estados de pin que requiere. Dos propiedades vinculan un dispositivo a estados de pin:

• pinctrl-<ID> —una lista de phandles apuntando a nodos de configuración de pin. Múltiples entradas permiten que un dispositivo sea configurado por varios pin controllers o combinar múltiples nodos para un solo controller.
• pinctrl-name —una lista paralela asignando nombres a cada ID de estado. El estado 0 usualmente se llama default y sigue la lista estándar definida en include/linux/pinctrl/pinctrl-state.h.

A continuación se muestra un extracto típico de Device Tree mostrando configuración de pin para dos dispositivos:

Cada línea sigue el formato <PIN_FUNCTION> <PIN_SETTING>:

MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x80000000 MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1 

El primer token (MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09) identifica la función del pin; el segundo token (0x80000000) codifica bits de configuración (pull-up/down, fuerza de drive, etc.). Estas macros están definidas en archivos de cabecera específicos de arquitectura como arch/arm/boot/dts/imx6q-pinfunc.h.

Para programar un estado de pin en código de driver, siga estos pasos durante la inicialización (típicamente en 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"); 

El helper pinctrl_get_select_default() recupera y aplica automáticamente el estado default. Si un dispositivo provee un estado init, el core lo aplicará antes de probe() y luego revertirá a default después a menos que el driver lo cambie.

Cuando termine, libere el controller con pinctrl_put(pinctrl) o use la variante resource-managed devm_pinctrl_put(pinctrl).

Aquí hay un ejemplo concreto del archivo am335x-evm.dts:

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

En el driver correspondiente:

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

Para cuando el probe() del driver se ejecuta, la configuración de pin default ya está en su lugar.

La próxima entrega cubrirá el subsistema GPIO en detalle.

Reimpreso con permiso de Packt Publishing. Copyright © 2017 Packt Publishing

John Madieu es un ingeniero de kernel y Linux embebido basado en París. Desarrolla drivers y BSPs para clientes en automatización, transporte, salud, energía y defensa. John trabaja en EXPEMB, pionero en diseño computer-on-module, y es un defensor activo de open-source que cree que compartir conocimiento acelera la innovación.