Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions

[Boris Brezillon <boris.brezillon@collabora.com>]

On Wed, 11 Feb 2026 15:38:32 +0100
"Danilo Krummrich" <dakr@kernel.org> wrote:

> On Wed Feb 11, 2026 at 12:12 PM CET, Boris Brezillon wrote:
> > On Wed, 11 Feb 2026 12:00:30 +0100
> > "Danilo Krummrich" <dakr@kernel.org> wrote:  
> >> I.e. sharing a workqueue between JobQs is fine, but we have to ensure they can't
> >> be used for anything else.  
> >
> > Totally agree with that, and that's where I was going with this special
> > DmaFenceWorkqueue wrapper/abstract, that would only accept
> > scheduling MaySignalDmaFencesWorkItem objects.  
> 
> Not sure if it has to be that complicated (for a first shot). At least for the
> JobQ it would probably be enough to have a helper to create a new, let's say,
> struct JobQueueWorker that encapsulates a (reference counted) workqueue, but
> does not give access to it outside of jobq.rs.

Except we need to schedule some work items that are in the
DMA-signaling path but not directly controlled by the jobq.rs
implementation (see [1] for the post-execution work we schedule in
panthor).

The two options I can think of are:

1. Add a an unsafe interface to schedule work items on the wq attached
   to JobQ. Safety requirements in that case being compliance with the
   DMA-fence signalling rules.
2. The thing I was describing before, where we add the concept of
   DmaFenceWorkqueue that can only take MaySignalDmaFencesWorkItem. We
   can then have a DmaFenceWorkqueue that's global, and pass it to the
   JobQueue so it can use it for its own work item.

We could start with option 1, sure, but since we're going to need to
schedule post-execution work items that have to be considered part of
the DMA-signalling path, I'd rather have these concepts clearly defined
from the start.

Mind if I give this DmaFenceWorkqueue/MaySignalDmaFencesWorkItem a try
to see what it looks like a get the discussion going from there
(hopefully it's just a thin wrapper around a regular
Workqueue/WorkItem, with an extra dma_fence_signalling annotation in
the WorkItem::run() path), or are you completely against the idea?

[1]https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/gpu/drm/panthor/panthor_sched.c#L1913