Soporte de Trip Points en Linux para Snapdragon X Series de Qualcomm

octubre 5, 2026 Alfonso Moreno | Sysadmin Senior 23 Visitas 11 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué está parcheando Qualcomm en el subsistema térmico

El 2 de octubre de 2026 el ingeniero de Qualcomm Gaurav Kohli envió al mailing list de Linux-PM la primera versión de una serie de seis parches titulada “thermal: Add hardware-binned trip point support”. La idea central: el silicio moderno de Qualcomm —incluido el Snapdragon X1 Elite (X1E80100)— puede fabricarse en el mismo proceso pero venderse en variantes térmicas distintas según los fuses de manufactura programados durante el empaquetado. Cada fuse define un bin que a su vez fija los límites válidos de temperatura de unión (Tj) que el sistema operativo debe respetar.

Hasta ahora, cada placa con SoC binnado resolvía esto de forma artesanal: o bien duplicaba zonas térmicas en el Device Tree, o bien metía trip overrides específicos por board dentro del driver. La nueva serie introduce una propiedad DT genérica —thermal-hw-bin— siguiendo el mismo modelo que ya usa el framework OPP con opp-supported-hw. El driver del sensor térmico publica el bin decodificado al registrar la zona, y el parser OF del subsistema térmico filtra los trip points que aplican para ese silicio.

Por qué importa a sysadmins y homelab

Si alguna vez has visto un Snapdragon X1 Elite corriendo Linux en un portátil como el ThinkPad T14s Gen 6, el Surface Pro 11 o el ASUS Vivobook S 15, sabrás que el comportamiento térmico del SoC cambia bastante de un bin a otro. En el bin estándar, el trip pasivo para Kodiak y Hamoa está fijado a 95°C; en el bin elevado sube a 105°C. Antes del parche, esa diferencia estaba codificada en el DTS de cada placa, duplicando lógica que debería ser una propiedad del silicio, no de la placa.

Para los que mantenemos flotas con ARM cada vez más presente —servidores Ampere Altra, Graviton, dispositivos IoT con QCM6490— el movimiento es relevante porque Qualcomm está sentando un precedente en el kernel mainline. Otros proveedores (MediaTek, Samsung LSI, Apple Silicon) pueden copiar el patrón sin reinventar bindings.

Tabla: qué cambia para el kernel y para el driver

Aspecto	Antes del parche	Después del parche
Descripción del bin	Vendor-specific en cada DTS	Genérico vía `thermal-hw-bin`
Filtrado de trip points	Manual por placa	Automático en thermal core
Driver TSENS	Lee QFPROM en probe()	Publica el bin antes de registrar la zona
DTS afectados	kodiak, hamoa (duplicados)	kodiak, hamoa consolidados
Plataformas cubiertas	Solo SC7280 y derivados	SC7280, QCM6490, X1E80100 y nuevos

Cómo funciona la nueva propiedad DT

El parche añade dos bindings nuevos al schema thermal-zones.yaml. El primero, thermal-hw-bin, es una máscara de uno o más grupos para los que el trip es válido. El segundo, temperature-bin, mapea cada grupo de máscara a la temperatura de trip concreta. El formato sigue el mismo principio que opp-supported-hw: el driver térmico decodifica el bin desde el silicio y lo entrega al parser OF; el parser decide qué trip points aplican y descarta los del resto de bins.

El Qualcomm TSENS es el primer usuario. En plataformas SC7280 y QCM6490, TSENS consulta dos celdas QFPROM —jtag-id y feat-id— y las mapea al bin térmico. En X1E80100 y derivados, TSENS lee un único bit i-temp del QFPROM. La decodificación es específica del proveedor, pero la descripción DT es genérica: ese es justamente el punto que el parche defiende en la cover.

Lo que necesitas saber como sysadmin

El cambio todavía está en revisión: la serie es v1, así que no hay garantías de que entre en el ciclo 6.18 o 7.0 tal cual. Pero como afecta a cómo se estructuran las DTS de Qualcomm en mainline, conviene entender la mecánica para cuando un vendor backport empiece a aparecer en distros LTS.

Listado de archivos modificados

La serie toca 18 archivos en 980 inserciones y 114 borrados. Los puntos clave:

Nuevo módulo drivers/thermal/thermal_bin.c (135 líneas) con la lógica de filtrado genérico.
Driver TSENS drivers/thermal/qcom/tsens-v2.c y tsens.c (+189 líneas) con la decodificación del bin desde QFPROM.
Parser OF térmico drivers/thermal/thermal_of.c (+253 líneas) con la integración del filtro genérico.
Bindings DT Documentation/devicetree/bindings/thermal/thermal-zones.yaml (+53 líneas).
DTS placas arch/arm64/boot/dts/qcom/kodiak.dtsi y hamoa.dtsi consolidados.
Documentación Documentation/driver-api/thermal/hardware-binning.rst (151 líneas, archivo nuevo).

Cómo revisar si tu distro lo lleva

Para identificar si tu kernel actual ya incluye la infraestructura, basta con buscar el símbolo de config y el archivo. Sirve como smoke test antes de backportear a mano:

# Verificar si el driver genérico está compilado como módulo
grep -r "thermal_bin" /lib/modules/$(uname -r)/modules.builtin 2>/dev/null
modinfo thermal_bin 2>/dev/null | head -3
# Comprobar si el DTS de tu plataforma usa la nueva propiedad
find /usr/lib/linux/ -name "*.dtb" 2>/dev/null | xargs -I{} sh -c 
  'dtc -I dtb -O dts {} 2>/dev/null | grep -l "thermal-hw-bin" >/dev/null && echo "{} usa thermal-hw-bin"' 2>/dev/null | head -5

El primer comando lista si CONFIG_THERMAL_HW_BIN está activo en tu kernel. El segundo busca un binario DTB que ya contenga la propiedad thermal-hw-bin. Si ninguno devuelve resultado, estás en una versión de kernel previa al merge: nada se rompe, pero tampoco se benefician las placas nuevas que lleguen.

Qué trip points verás según el bin

El ejemplo concreto del parche, sobre Kodiak y Hamoa, deja clara la diferencia que vas a observar en logs:

# Bin estándar (95°C passive trip)
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
95000
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_type
passive
# Bin elevado (105°C passive trip)
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
105000
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_type
passive

Las unidades están en milésimas de grado Celsius (sysfs estándar del subsistema térmico), de modo que 95000 equivale a 95.0°C. La diferencia entre bins es crítica para throttling: en el bin estándar el SoC empieza a bajarse el clock a 95°C; en el elevado aguanta hasta 105°C. Si tu portátil se identifica como bin estándar pero aparece reportando throttling a 105°C, probablemente tienes un DTS desactualizado.

Trade-offs y riesgos que la cover no discute

El parche deja varias decisiones de diseño que vale la pena mirar con cuidado:

Doble propiedad DT por trip point. Ahora cada trip tiene que declarar thermal-hw-bin y temperature-bin. En DTS con docenas de zonas, el ruido visual se multiplica. Para mantener legibilidad, conviene una macro DTS reusable que agrupe las máscaras —algo que el maintainer de thermal, Daniel Lezcano, podría pedir en la próxima ronda de revisión.
Fallback silencioso. Si el driver no publica el bin (porque es un driver antiguo o externo a mainline), el parser OF cae al comportamiento legacy: asume el primer trip listado y descarta el resto. Esto es lo que hace la migración no-breaking, pero también significa que un driver buggy puede terminar reportando el trip equivocado sin warning en dmesg.
Compatibilidad con QMI TMD. Qualcomm también está Trabajando en QMI TMD (Qualcomm Messaging Interface Thermal Mitigation Device) — serie separada de 9 parches. Los dos sistemas no están acoplados: el bin es un dato de silicio estático, TMD es un canal de telemetría dinámica. Si tu placa usa ambos, asegúrate de que el firmware no asume que la zona térmica pasiva tiene un valor fijo.

Vale la pena seguirlo de cerca?

Si tienes un portátil con Snapdragon X1 Elite corriendo Linux en producción, o si mantienes imágenes de distros (Ubuntu 25.04, Fedora 43, Debian 13) para flotas ARM, sí. La serie todavía está en RFC, pero el hecho de que venga firmada por Amit Kucheria —uno de los Thermal mappers históricos de Linaro/Qualcomm— y que pase por la LPC microconf del año pasado sugiere que va a entrar, probablemente con ajustes menores en v2 o v3.

Si trabajas en otras arquitecturas ARM (Ampere, Graviton, Apple Silicon en Asahi), el patrón thermal-hw-bin no te aplica directamente todavía, pero conviene tenerlo en el radar: cuando un SoC binnado aparezca en esas plataformas, el mismo binding debería poder extenderse sin reescribir el core.

Decodificar el bin manualmente con debugfs

Si tu kernel trae CONFIG_DEBUG_FS y CONFIG_THERMAL_HW_BIN, TSENS expone el bin detectado a través de debugfs. Sirve para confirmar que la lectura del fuse coincide con el silicio físico, especialmente útil cuando un mismo SKU se vende en bins distintos según lote:

# Listar zonas térmicas detectadas por TSENS
ls /sys/kernel/debug/thermal/
# cat cpu-thermal0/
# Ver el bin crudo del QFPROM (requiere root)
sudo cat /sys/kernel/debug/qcom_tsens/qcom_tsens0/qfprom_bin 2>/dev/null
# Salida típica: "bin_2"  (mapped from feat-id 0x4 + jtag-id 0x8210)
# Forzar la lectura del bit i-temp en X1E80100
sudo hexdump -C /sys/kernel/debug/qcom_tsens/qcom_tsens0/qfprom_itemp 2>/dev/null | head -2

Si el comando devuelve bin_2 pero el DTS de tu placa solo declara el bin bin_0, el trip pasivo reportado va a ser incorrecto. En ese caso el driver aplica el fallback silencioso que mencionamos antes: usa el primer trip de la lista sin warning, así que toca auditar manualmente.

Backportear a un kernel LTS

Para servidores en producción que corren 6.6 LTS o 6.12 LTS, el backport es viable si tu plataforma está entre las soportadas (SC7280/QCM6490/X1E80100). El orden importa porque hay dependencias entre los 6 parches:

# Clonar la serie desde lore.kernel.org
mkdir -p ~/thermal-bin-backport && cd ~/thermal-bin-backport
git clone --depth 1 --branch v6.12 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
# Aplicar los 6 parches en orden (0/6 a 5/6)
b4 -d [email protected] sh -c 'git am %{amt}'
# Salida esperada: "Applying: 6 commits" + lista de Signed-off-by
# Compilar solo el subsistema térmico (ahorra tiempo vs full kernel build)
make -j$(nproc) drivers/thermal/
sudo make modules_install M=drivers/thermal/
sudo modprobe thermal_bin
sudo modprobe qcom_tsens

Si b4 no está disponible, instala pip install b4 o descarga los mboxes desde el archive link de LWN. El git am directo sobre los mbox individuales también funciona, pero respeta el orden: sin el binding YAML (dt-bindings: thermal-zones: add hardware-binning), el parser OF rechaza silenciar las nuevas propiedades.

Comparar el comportamiento entre dos bins del mismo silicio

Para los que están evaluando un portátil Snapdragon X y quieren saber de antemano a qué temperatura va a throttlear, una prueba útil es comparar el cpufreq antes y después de cambiar el bin declarado en el DTS. Es invasivo (sobreescribe temporalmente el bin del device tree en boot), pero te da números concretos para decidir si vale la pena:

# Backup del DTS original
sudo cp /boot/dtb/qcom/x1e80100-laptop.dtb /tmp/x1e80100-laptop.dtb.bak
# Decompilar el DTB para editar el bin
dtc -I dtb -O dts /boot/dtb/qcom/x1e80100-laptop.dtb > /tmp/laptop.dts
# Cambiar el bin declarado (bin_0 → bin_1 = elevated)
sed -i 's/thermal-hw-bin = <0x01>;/thermal-hw-bin = <0x02>;/g' /tmp/laptop.dts
# Recompilar y reiniciar
dtc -I dts -O dtb /tmp/laptop.dts > /tmp/x1e80100-laptop.dtb.new
sudo cp /tmp/x1e80100-laptop.dtb.new /boot/dtb/qcom/x1e80100-laptop.dtb
sudo reboot
# Después del boot, verificar el trip pasivo
cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
# Esperado: 105000 (bin_1) en lugar de 95000 (bin_0)

Si el valor cambia, sabes que el DTS sí está publicando el bin correctamente. Si no cambia, el driver no está propagando la lectura del fuse al parser OF — bug de la placa, no del parche.

Verificar que el throttling respeta el bin

Un test de humo útil para confirmar que el comportamiento es correcto: forzar carga sostenida y observar el throttle. La diferencia entre 95°C y 105°C es visible en benchmarks sintéticos:

# Generar carga sostenida (10 minutos) en un Snapdragon X1 Elite
yes > /dev/null &
stress_pid=$!
sleep 60
# Monitorear temperatura y frecuencia cada 5 segundos
watch -n 5 'cat /sys/class/thermal/thermal_zone0/temp; 
            cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | sort -u | head'
# Esperado en bin estándar: throttle a ~95°C → scaling_cur_freq baja al mínimo
# Esperado en bin elevado: mantiene frecuencia nominal hasta ~105°C
kill $stress_pid

Si en el bin elevado ves throttle a 95°C, el DTS de tu placa está desactualizado o el driver no está publicando el bin al parser OF — vuelve al bloque de debugfs y confirma el mapeo fuse → bin.

Resumen y siguientes pasos

El parche de Qualcomm estandariza cómo el kernel Linux describe y filtra límites por bin de silicio. El bin se lee desde fuses QFPROM (jtag-id/feat-id en SC7280/QCM6490, i-temp bit en X1E80100) y se publica al registrar la zona térmica. El parser OF genérico filtra los trip points aplicables para esa pieza concreta de silicio.

Para seguir la serie:

Mirror en lore.kernel.org: [email protected]
Cobertura Phoronix: Qualcomm Patching Linux For Hardware Thermal Binning
Cobertura LWN: thermal: Add hardware-binned trip point support
Presentación LPC 2025 (base del diseño): Thermal Microconf: Amit — Tj thermal binning

Preguntas frecuentes

¿Por qué Soporte de Trip Points en Linux para Snapdragon X Series de Qualcomm es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Soporte de Trip Points en?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Soporte de Trip Points en?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Soporte de Trip Points en y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Soporte de Trip Points en?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.