Qualcomm posted a request for comments on August 6 proposing Synx for the Linux kernel, a synchronization framework that extends fences beyond the parts of a system Linux actually runs. On a modern system on chip, the kernel is one execution environment among several, sharing silicon with DSPs, sensor hubs, camera processors and firmware that never run Linux at all. Synx aims to give all of them one vendor neutral way to wait on each other. It does not replace dma-fence, it sits alongside it. The code has been shipping downstream in Qualcomm mobile and XR devices for several generations, and this is the attempt to bring it upstream.
The short answer
Synx is a synchronization framework Qualcomm wants in the mainline Linux kernel. It coordinates fences between Linux hosted clients and execution environments that do not run Linux, such as firmware and remote processors on the same system on chip. It is explicitly designed to complement dma-fence and sync_file rather than replace them, and it is presented as SoC agnostic rather than Qualcomm specific. The code already ships in Qualcomm devices through vendor trees.
Here is the assumption baked into most of the kernel's synchronization primitives: the two things waiting on each other are both things Linux knows about. On a phone or a headset built in 2026, that assumption stopped being true a while ago.
The gap
A modern system on chip is a collection of processors that happen to share a die. There is the application processor running Linux, and then there is a DSP running its own firmware, a sensor hub, an image signal processor, a security subsystem, sometimes a dedicated compositor for display, each with its own execution environment and its own idea of time.
Buffers move between them constantly. A camera frame is produced by the ISP, processed on a DSP, composited by something else and handed to the display. Only some of those steps involve a Linux driver, and the rest involve firmware the kernel booted but does not schedule.
Linux has excellent tools for the part it owns. dma-fence is a kernel object representing "this buffer will be ready", sync_file exposes one to userspace as a file descriptor you can poll, and together they solved explicit synchronization for graphics well enough that the design has lasted a decade. What neither was built for is a fence whose other end lives in firmware.
The current answer to that is vendor specific inter processor communication: a bespoke mechanism per SoC family, each one implemented, ported and maintained separately, none of them shared. Anyone who has carried a board support package forward across kernel versions knows what that costs.
What Synx proposes
Qualcomm's RFC, posted on August 6 and led by Pravin Kumar Ravi, describes Synx as a global synchronization framework spanning different parts of a SoC. The stated goal is coordinating fences between Linux hosted clients and non Linux execution environments, including remote processors and firmware, through one vendor neutral interface.
Two design decisions in the proposal are worth reading carefully.
The first is that it does not replace dma-fence. The RFC is explicit that existing GPU and display synchronization stays where it is, and that Synx complements dma-fence and sync_file where appropriate. That is the right posture for something asking to be carried in the kernel, and it is the difference between an addition and a rewrite.
The second is the claim to be SoC agnostic. The framework is presented as something other vendors could adopt, not as a Qualcomm subsystem with a generic name. Whether that holds up is a question for review rather than for a press cycle, and it is the single most important question in the whole proposal.
Not new code, which cuts both ways
This is not a design being sketched for the first time. A synx-kernel tree has been published on CodeLinaro under Qualcomm's open source vendor projects, and synx driver code has been present in Android kernels for Qualcomm platforms for years, historically living under the multimedia platform directories. What is being proposed upstream is production code with a shipping history.
In its favour, that is real validation. Most RFCs for a new framework arrive as an idea with a prototype. This one arrives having run in the hands of a very large number of devices across several product generations, and Qualcomm says the approach delivered significant power and performance benefits over that period.
Against it, code that grew inside a vendor tree carries vendor assumptions, and they are usually in the interfaces rather than the implementation. The concepts a framework exposes tend to mirror the hardware it was written for. Upstream review exists precisely to find those and ask whether they generalise, and a decade of vendor code being offered to mainline suggests the answer is usually "some of them do".
The number that is missing
Qualcomm's benefit claim is qualitative. Significant power and performance improvements, across the last few generations of mobile and XR chipsets, with no figures attached in the proposal as reported.
We find the claim mechanically plausible. If a fence can be signalled directly between two processors on the die, you remove a wake up and a round trip through the kernel from a path that may run many times per frame, and on a battery powered device removing wake ups is most of the work. That is a real effect and it is exactly the kind of thing that does not show up in a throughput benchmark.
Plausible is not measured. For a first RFC that is acceptable, because the opening question is whether the abstraction is correct rather than how fast it is. But a maintainer being asked to carry a new cross subsystem framework will want numbers before merging, and providing them early is cheaper than being asked for them in revision four.
What to watch
Whether a second vendor shows up. The strongest argument for a SoC agnostic framework in mainline is another silicon vendor saying they would use it, and the weakest position for one is being the only user. MediaTek, NXP and Rockchip all have the same architectural problem.
Whether the discussion converges on extending dma-fence instead. That is the natural counter proposal, and it is not obviously wrong. The reviewers who know that code will have an opinion quickly.
Whether the security model survives contact. A fence that can be signalled by firmware the kernel does not schedule is a fence whose completion the kernel is trusting someone else to report honestly, and the RFC will have to say what happens when that trust is misplaced or the remote side simply hangs.
If you maintain a board support package for an ARM SoC, this is worth following. Nothing lands soon, and cross subsystem frameworks rarely land on the first revision, but the direction of travel matters more than the timeline.
Sources and further reading
- Qualcomm proposes Synx for the Linux kernel with significant power and performance benefits, Phoronix, August 6, 2026
- synx-kernel, Qualcomm open source vendor project on CodeLinaro
- Buffer sharing and synchronization, the dma-buf and dma-fence documentation
- Sync file API guide, kernel documentation
- Bridging the synchronization gap on Linux, Collabora
Frequently asked questions
What problem does Synx solve that dma-fence does not?
Scope. A dma-fence is a kernel object: it lives in Linux memory, it is signalled by kernel code or by a driver on behalf of hardware, and every participant in the handshake is something the kernel knows about. That works well for the case it was designed for, which is a GPU rendering a buffer and a display controller waiting on it, both driven by Linux drivers. It works less well when one side of the handshake is firmware on a DSP that was booted by a remote processor subsystem and does not have a Linux driver mediating each step. Today those cases get solved with vendor specific IPC, one implementation per SoC family, none of them shared. Synx proposes a single framework for that class of handoff, expressed once rather than reinvented per vendor, and interoperating with dma-fence and sync_file where the two worlds meet.
Is this actually new code, or something Qualcomm has been shipping already?
It has been shipping. A synx-kernel tree exists publicly on CodeLinaro under Qualcomm's open source vendor projects, and synx driver code has been present in Android kernels for Qualcomm platforms for years, historically under the multimedia platform directories. So this is not a design being proposed for the first time, it is production code from vendor trees being offered upstream. That distinction matters in both directions. In its favour, the design has been exercised across several generations of shipping hardware, which is more validation than most RFCs arrive with. Against it, code that grew inside one vendor's tree tends to carry that vendor's assumptions in its interfaces, and the review will spend most of its energy on exactly that question.
What are the claimed benefits, and how solid are they?
Qualcomm states that the approach has delivered significant power and performance benefits across the last few generations of its mobile and XR chipsets. That claim is plausible on its mechanics, because the alternative to a shared fence is usually a round trip through the kernel to wake something up, and on a battery powered device those round trips are exactly what you are trying to eliminate. It is also, as posted, unquantified. There are no benchmark numbers, no power measurements and no before and after comparison in the proposal as reported. For an RFC that is not disqualifying, since the first round of review is about whether the abstraction is right rather than how fast it is. But numbers will be asked for, and a maintainer weighing a new cross subsystem framework will reasonably want them before merging anything.
Who would this affect if it lands?
Directly, people working on SoC integration: camera pipelines, XR compositors, sensor fusion, audio offload, anything where a buffer is produced by one processor on the die and consumed by another. Indirectly, anyone maintaining a board support package for an ARM SoC, because the current alternative is per vendor synchronization plumbing that has to be ported and maintained separately. The interesting part is the framing as SoC agnostic. If MediaTek, NXP, Rockchip or anyone else with the same architecture adopts it, the win is one abstraction across vendors rather than one more vendor framework in tree. If nobody else adopts it, that is a much weaker case for carrying it in the kernel, and reviewers will say so.
What happens next with an RFC like this?
Usually a long conversation. An RFC posted to the kernel mailing lists is a request for direction rather than a merge candidate, and a proposal that crosses subsystem boundaries needs buy in from more than one maintainer. The likely discussion points are predictable: whether this belongs as a new framework or as an extension of the existing dma-fence and sync_file infrastructure, whether the userspace facing interface is stable enough to be an ABI commitment, how the security model works when a fence can be signalled by firmware the kernel does not control, and whether a second vendor is interested. Expect several revisions over months rather than weeks. Kernel frameworks that touch multiple subsystems rarely land on the first attempt, and the ones that do are usually the ones that arrived with a co-maintainer from another company.