El subsistema IIO: por qué los sensores tienen su propio mundo

Un acelerómetro, un conversor analógico-digital, un sensor de temperatura y un giroscopio no son teclados ni ventiladores, y sin embargo el kernel necesitaba una casa común para todos ellos. Esa casa es IIO —Industrial I/O—, el subsistema que unifica cómo se describen, se leen y se transmiten los datos de sensores y conversores. No es un capricho de nomenclatura: sin IIO, cada fabricante inventaría su propio char device, sus propias unidades y su propio formato, y userspace tendría que aprenderlos uno a uno. IIO impone un contrato, y ese contrato es lo que hace que iio_read_channel_processed devuelva grados Celsius vengan del chip que vengan.

Qué cubre IIO y por qué existe

IIO, en drivers/iio/, agrupa dispositivos que miden o generan magnitudes analógicas: conversores ADC y DAC, acelerómetros, giroscopios, magnetómetros, sensores de luz, de temperatura, de presión, de humedad, de proximidad, potenciómetros digitales. Lo que tienen en común no es la física sino el patrón de uso: producen valores numéricos que representan una magnitud del mundo, a menudo a alta frecuencia, y userspace quiere leerlos con unidades conocidas y, a veces, en ráfagas con marca de tiempo.

Antes de IIO, cada driver de sensor resolvía esto por su cuenta. Uno exponía un char device con un ioctl propietario; otro colgaba números crudos de un archivo de debugfs; un tercero mentía sobre las unidades. IIO sustituye ese caos por un modelo de datos declarativo: el dispositivo se describe como un conjunto de canales, cada canal tiene un tipo y unos atributos, y el núcleo se encarga de exponerlos de forma uniforme. El módulo del núcleo se llama industrialio.

flowchart TD
HW[Sensores y conversores: ADC, acelerometro, temperatura] --> Core[Nucleo IIO industrialio]
Core -->|ABI de sysfs| SysFS[Userspace: lectura puntual]
Core -->|char device iio:deviceN| Buf[Userspace: captura con buffer]
Core -->|linux/iio/consumer.h| InK[Consumidores en el kernel: thermal, hwmon, input]

La ABI de sysfs: raw, scale y offset

Cada dispositivo IIO aparece en /sys/bus/iio/devices/iio:deviceN/, y sus canales se exponen como archivos con un esquema de nombres rígido: dirección (in para lectura, out para salida), tipo (voltage, accel, temp…), índice y atributo. La clave del modelo es que el valor bruto y su conversión a unidades físicas viajan por separado:

$ ls /sys/bus/iio/devices/iio:device0/
name              in_accel_x_raw    in_accel_y_raw    in_accel_z_raw
in_accel_scale    sampling_frequency               buffer0   trigger0

$ cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw
-16543
$ cat /sys/bus/iio/devices/iio:device0/in_accel_scale
0.000598

La regla universal de IIO para obtener la magnitud física es:

valor_fisico = (raw + offset) * scale

Con los números de arriba: -16543 * 0.000598 da unos -9.89, es decir cerca de -1 g en la unidad canónica del acelerómetro, metros por segundo al cuadrado. El offset —ausente aquí, luego cero— corrige el cero del sensor; el scale traduce cuentas del ADC a unidades reales. Separar raw de scale no es burocracia: permite leer el valor crudo a máxima velocidad sin dividir en el camino caliente, y deja la conversión, más cara, para quien la necesite.

Las unidades son parte del contrato, fijadas en Documentation/ABI/testing/sysfs-bus-iio. Un acelerómetro reporta en metros por segundo al cuadrado; un giroscopio en radianes por segundo; un magnetómetro en Gauss; la temperatura en milésimas de grado Celsius; el voltaje en milivoltios; la presión en kilopascales; la luz en lux. Cualquier driver que exponga in_temp_scale promete que raw * scale son milésimas de grado, sea un termopar o un diodo.

Dos caminos de datos

IIO ofrece dos formas de sacar datos, pensadas para necesidades opuestas. La lectura puntual por sysfs es cómoda y lenta: cada cat in_voltage0_raw es una syscall que dispara una conversión y devuelve un número. Sirve para consultas esporádicas —¿qué temperatura hace?— pero no para muestrear a kilohercios, porque el coste por muestra es enorme y no hay marca de tiempo precisa.

El camino con buffer, por el contrario, entrega ráfagas de muestras a través del char device /dev/iio:deviceN. Un trigger marca el ritmo, el driver empuja cada conjunto de muestras a un buffer con su marca de tiempo, y userspace las lee en bloque. Es el camino para adquisición continua a alta frecuencia. La lección 33.5 lo construye entero; aquí basta con saber que existe y por qué la ABI separa desde el principio “leer un valor” de “muestrear un flujo”.

IIO frente a input y hwmon

La pregunta natural es por qué un acelerómetro no vive en el subsistema input, que ya maneja teclados y ratones. La respuesta es que input modela eventos de interfaz humana —una tecla EV_KEY, un eje absoluto EV_ABS— con semántica de interacción, no un flujo de medidas físicas con unidades y marcas de tiempo a miles de muestras por segundo. Un acelerómetro para detectar la orientación de la pantalla puede tener un puente hacia input, pero su naturaleza es de sensor.

Tampoco encaja en hwmon, el subsistema de monitorización de salud del hardware: temperaturas de CPU, voltajes de la placa, velocidad de ventiladores. hwmon tiene semántica fija y orientada a supervisar la máquina, no a adquirir señales arbitrarias con buffers y triggers. De hecho, la relación entre ambos es tan estrecha que existe un puente, iio_hwmon, que expone canales IIO como si fueran sensores hwmon cuando lo que quieres es justamente monitorizar.

El otro superpoder de IIO son los consumidores dentro del kernel. Gracias a <linux/iio/consumer.h>, otro driver puede leer un canal IIO sin pasar por userspace: una zona térmica que necesita la temperatura de un ADC llama a iio_read_channel_processed y recibe grados; un driver de batería lee la tensión de una celda. El device tree conecta consumidor y sensor con la propiedad io-channels, y el driver toma el canal por su nombre:

#include <linux/iio/consumer.h>

struct fan_ctl {
        struct iio_channel *temp;   /* canal IIO de otro driver */
};

static int fan_probe(struct platform_device *pdev)
{
        struct fan_ctl *f = /* ... reservado con devm_kzalloc ... */;
        int millicelsius, ret;

        /* "ambient" enlaza con io-channel-names en el device tree */
        f->temp = devm_iio_channel_get(&pdev->dev, "ambient");
        if (IS_ERR(f->temp))
                return PTR_ERR(f->temp);

        /* magnitud ya convertida a la unidad estandar: milesimas de grado */
        ret = iio_read_channel_processed(f->temp, &milicelsius);
        if (ret < 0)
                return ret;

        dev_info(&pdev->dev, "temperatura ambiente: %d.%03d C\n",
                 milicelsius / 1000, milicelsius % 1000);
        return 0;
}

El driver del ventilador no sabe ni le importa qué chip mide la temperatura: pide un canal por su nombre lógico y recibe grados. El sensor se describe una vez y lo consumen tanto userspace como el resto del kernel.