On Wed Feb 11, 2026 at 4:00 PM CET, Boris Brezillon wrote: > 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?
Not at all, I think it's a good generalization. But I'm very skeptical about the "we allow drivers to schedule arbitrary work on the (shared) JobQueue workqueue" part. I think drivers can just have a separate workqueue for such use-cases. > [1]https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/gpu/drm/panthor/panthor_sched.c#L1913
