[RFC] Synx: A global synchronization framework

Synx: A global synchronization framework
==========================================

This RFC is intended to start a design discussion around Synx, a
SoC-wide synchronization framework used to coordinate fences between
Linux-hosted clients and non-Linux execution environments such as
remote processors and firmware.

The intent of Synx is not to replace dma-fence for existing in-kernel
GPU/display style synchronization. Rather, provide a global
synchronization mechanism spanning multiple subsystems and
processors, while still integrating with existing Linux primitives
such as dma-fence and sync_file where appropriate. The solution has
shown significant power and performance benefits in the last few
generations of Qualcomm mobile and XR chipsets, and is gathering more
use cases. Also, the solution is SoC-agnostic, so other vendors can
adopt it in the future if interested.

Motivation
----------

Many multimedia and accelerator pipelines on modern SoCs are no
longer strictly host-centric. Work may be produced, consumed, waited
on, or signaled by multiple execution environments, including Linux
drivers, userspace components, DSPs, ISPs, NPUs, video firmware,
camera firmware, or other remote processors.

dma-fence is a good fit when the fence state, callback list, and
lifetime are owned and progressed by Linux kernel participants.
However, for cross-processor use cases, a synchronization object must
satisfy properties that dma-fence does not currently provide:

- Cross-subsystem visibility: A fence created by one subsystem must
  be importable, waitable, and signalable by other subsystems,
  including non-Linux processors. struct dma_fence is local Linux
  kernel state and is not directly visible to remote processors or
  firmware.

- Point-to-point remote signaling: One subsystem should be able to
  signal another subsystem without interrupting the Linux host CPU
  every time in the signaling path. Since dma-fence maintains all
  waiters in the Linux, remote-to-remote synchronization has to
  unnecessarily interrupt or involve the Linux host.

- Distributed lifetime management: References may be held by Linux
  and non-Linux participants. Any subsystem must have authority to
  create and clean up fences. This requires lifetime state to be
  tracked in a shared/global table, rather than being owned solely by
  a local Linux object. dma-fence lifetime is centered around Linux
  references, which does not naturally model references held and
  released independently by remote processors.

- Race-free global synchronization: Registering a waiter and
  observing signal state must be atomic across participating
  subsystems to avoid missed wakeups/signals. Atomicity between
  remote waiter registration and remote signaling needs a
  protocol-level guarantee, not just local callback handling.

- Subsystem restart recovery: If a remote processor or firmware
  subsystem restarts, references held by the crashed subsystem must
  be released, and waiters that depend on that subsystem must be
  completed or failed in a well-defined way. Subsystem restart
  cleanup is outside the dma-fence model.

- Global composition: It should be possible to compose fences that
  were created by different subsystems or processors into a single
  aggregate synchronization object. dma_fence_array can compose
  Linux dma_fence objects, but it does not by itself solve the
  composition of globally visible synchronization handles created by
  different processors.

- Transport abstraction: Remote signaling should be independent of
  the underlying transport, for example rpmsg, mailbox, GLink or
  another SoC transport.

- Linux integration: Linux clients should be able to interoperate
  with dma-fence and sync_file where that is the right ABI or
  in-kernel interface.

Proposed model
---------------

Synx introduces a globally unique synchronization handle. The handle
indexes an entry in a global synchronization table that is
accessible to all participating subsystems. Each entry tracks: a
global handle ID, current fence state, the set of waiting and
subscribed cores or subsystems to allow point-to-point remote
signaling, a distributed reference count, and parent/child
relationships for composed fences.

The design is organized around four components:

- Handle and session management: Any subsystem, Linux or remote, may
  create or import a Synx handle and hold a reference counted against
  the global table. Handles are destroyed by the subsystem which
  releases the last reference, regardless of which subsystem it is.

- Transport abstraction: Remote wait and signal messages are
  delivered through a pluggable transport layer. The synchronization
  core is not tied to any specific backend (rpmsg, mailbox, GLink,
  etc.), enabling point-to-point remote signaling without involving
  the Linux host CPU when both producer and consumer are outside
  Linux.

- Linux interoperability: A Synx handle may be associated with a
  dma_fence or exported as a sync_file, allowing Linux kernel drivers
  and userspace to interact with Synx objects through existing
  interfaces.

- Fence composition: Aggregate fences are modeled as parent/child
  relationships between global handles. A composed fence can span
  handles created by different subsystems or processors, and its
  completion state is derived from the states of its children in the
  global table.

- Subsystem restart recovery: When a remote processor restarts, the
  global table is walked to drop all references held by that
  subsystem and to complete or fail any affected waiters according
  to the configured recovery policy.

Possible initial patch structure
---------------------------------

If the overall direction is acceptable, an initial RFC series could
be split as follows:

- Documentation describing the cross-subsystem synchronization
  problem and the Synx object model.
- Code to manage Synx sessions and handle lifetime, and
  synchronization using wait and signal.
- dma_fence and sync_file interoperability layer.
- Fence composition support.
- Transport abstraction for remote wait/signal messages.
- SSR/restart cleanup hooks for remote processors.
- A minimal Qualcomm SoC integration backend and example client.

At this stage, feedback on the model and layering would be more
useful than detailed code review. In particular, we would appreciate
guidance on whether this should be pursued as a Qualcomm SoC-specific
driver first, or whether the cross-processor synchronization pieces
are generic enough to justify a common framework.

Thanks,
Pravin