On Wed, 11 Feb 2026 15:38:32 +0100 "Danilo Krummrich" <[email protected]> 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" <[email protected]> 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
