How Does the Hexagon NPU Look Upstream in the Snapdragon X2 Linux Preview?

One-line answer: The preview is for kernel, distro, and enablement people, on a Debian userspace and a custom kernel. Hexagon is aimed at upstream FastRPC rather than a permanent out-of-tree module. Before an OEM ships, the open gaps are the NPU runtime, power, and per-laptop differences.

At Snapdragon Summit 2026 Qualcomm announced a Linux Early Developer Preview for Snapdragon X2 Series laptops. This post is only how the Hexagon NPU sits relative to upstream. Register-level access is out of scope. There is no bench log from a laptop in front of me. The Qualcomm developer blog returned 403 while this draft was checked, so the account below is Phoronix, heise, and How-To Geek on the announcement, read against Canonical’s Ubuntu post. Year-end and 2027 dates show up in secondary coverage. They are not treated as fixed.

Who on the kernel and distro side is this preview for?

One-line answer: Kernel developers, distro maintainers, and hardware enablement — not a consumer installer. The combination that keeps coming up is Debian 13 “Trixie” userspace plus Qualcomm’s custom kernel.

heise’s account of the audience is kernel and driver developers, distribution maintainers, and enablement teams. Phoronix on 23 September 2026 splits the status: a lot of the initial enablement is already upstream, while Hexagon NPU work and Adreno support in Mesa are still moving. Boot (UEFI, systemd-boot), USB, PCIe, and UART/I²C/SPI are reported as that front half. None of that, by itself, means the NPU is open.

The scope that coverage repeats is X2 Series laptops. Desktops, earlier Snapdragon X machines, and other development boards are described as outside this preview. Support is also described as varying by processor variant and laptop design. A distro publishing a concept image and a vendor putting a certified image on a product are already different stories in the reporting. This post does not list the machines on a concept ISO. It also does not lock the month of certification, because secondary writeups do not agree.

The public repo qualcomm-linux/qcom-deb-images is Debian Trixie recipes whose README focus is mainline images for IoT boards. Do not treat it as the X2 laptop preview.

What path reaches Hexagon without an out-of-tree driver?

One-line answer: In the kernel, the documented path is mainline FastRPC. A demo on the preview kernel is not the same fact as that driver landing in a distro kernel.

How-To Geek quotes Qualcomm’s blog: the priority is upstreaming the drivers that unlock real workloads, and the Hexagon NPU connects to on-device inference through fastRPC. Freedreno, Turnip, and Rusticl are the Adreno path. They are not the same device.

The kernel binding qcom,fastrpc defines FastRPC as remote calls between the application processor and a DSP. Labels include compute domains such as cdsp. Child nodes are compute context banks. The binding does not name a model format. “Without an out-of-tree driver” means a distro stops carrying its own patch module and brings X2 up on this IPC. It does not mean the whole inference stack lives in the tree.

The layers are still split:

  • The preview image is a custom kernel. “We intend to upstream this” and “the tree you flash today matches mainline” are different sentences.
  • accel/qda v2 on lkml, 17 August 2026, proposes replacing misc FastRPC with a DRM accelerator, in-tree. Review rejected binding a second driver to a compatible that already has one. This draft did not confirm whether that series is in the kernel distros are shipping as of 2 October 2026. That is neither “carry an out-of-tree module” nor “the uAPI is settled.”
  • Firmware and the inference runtime stay outside the kernel tree. It’s FOSS reports a prebuilt-firmware Debian path and an account path with firmware source. Recheck that split on the portal. This draft did not reproduce the build.

So the thing you can see without an out-of-tree driver is the kernel’s FastRPC contract. Quantized models and DSP firmware are not implied to be in-tree.

What gaps should you check before an OEM ships?

One-line answer: After boot and a desktop, the NPU runtime, power, per-laptop differences, and the distance to a certified image are still open.

Phoronix leaves power, thermals, and reliability as further work next to the Hexagon effort. Before an OEM image ships, the kernel and distro side still has these gaps:

  1. Which device inference actually uses. A visible CDSP still leaves the model on the CPU until runtime and firmware are present. OpenCL compute landing on Adreno is not Hexagon. Split them in the log. An NPU ceiling in a company introduction is a spec label. This post does not include a measurement that the preview reproduced it.
  2. Variant and laptop design. Coverage says support differs by design. A feature open on one reference machine is not evidence about another OEM’s firmware. That check is the device’s DTB and firmware, and this post does not perform it.
  3. Concept image versus shipping image. A distro concept build that reaches a desktop, and the certified Ubuntu Canonical described for products, are separated in the reporting. The month between them stays unconfirmed because it is secondary. Canonical’s own post only targets Ubuntu support for 2027.
  4. The previous generation’s gap. heise uses the long distance between boot and daily use on X1 as background. The X2 preview is an announcement aimed at shortening that distance. It is not a measurement of a shipping laptop.

Nothing here was confirmed by borrowing a board. The gaps are the layers the announcement and the upstream review have not closed.

Sources