From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4C9C5E9E311 for ; Wed, 11 Feb 2026 15:05:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9540810E60B; Wed, 11 Feb 2026 15:05:54 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="NuG9WlOO"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5F04710E60B for ; Wed, 11 Feb 2026 15:05:54 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 12F9844539; Wed, 11 Feb 2026 15:05:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD4D7C4CEF7; Wed, 11 Feb 2026 15:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770822353; bh=ScbyhUmnF5OgA8EcbauwwMYSqHxJsLpyDEnuR07pqz8=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=NuG9WlOOulXVANBtG7VZjS9npHb0LtXRvb4+CFMsVbHJc1x70yAmVyBJ6fdYzc8pG HHjXiYShK5/fMyfgPvlbhyReQS1qQj2W+3sfPNgOIsuushVxzEVqiuFbTJ+oHiwhR9 f8s8RO7BcvI3ip91QgYf3TYrfPVXkDUToVorcLCo95cyPgtC0HThYhtAe6yt+Ittm/ d0hBbiQQU/4Y+GCy7+f020F8ZvjTOHzunEEWpfH/Qfs6R6aJDKeWgJnzzuemce/eG/ 1bd5kWVQbCaY2lsiNzyS0lFDWL385siPaHiP026ZcfKftLCn5EcJXIiZs2+FY9WTam 0APZfVDOubwHQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 11 Feb 2026 16:05:48 +0100 Message-Id: Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions Cc: "Alice Ryhl" , =?utf-8?q?Christian_K=C3=B6nig?= , "Philipp Stanner" , , "David Airlie" , "Simona Vetter" , "Gary Guo" , "Benno Lossin" , "Daniel Almeida" , "Joel Fernandes" , , , , , , To: "Boris Brezillon" From: "Danilo Krummrich" References: <20260205095727.4c3e2941@fedora> <20260209155843.725dcfe1@fedora> <20260210101525.7fb85f25@fedora> <4e84306c-5cec-4048-a7eb-a364788baa89@amd.com> <20260211112049.089b2656@fedora> <20260211121223.78674f22@fedora> <20260211160059.6e0d3b60@fedora> In-Reply-To: <20260211160059.6e0d3b60@fedora> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed Feb 11, 2026 at 4:00 PM CET, Boris Brezillon wrote: > On Wed, 11 Feb 2026 15:38:32 +0100 > "Danilo Krummrich" 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" wrote: =20 >> >> I.e. sharing a workqueue between JobQs is fine, but we have to ensure= they can't >> >> be used for anything else. =20 >> > >> > Totally agree with that, and that's where I was going with this specia= l >> > DmaFenceWorkqueue wrapper/abstract, that would only accept >> > scheduling MaySignalDmaFencesWorkItem objects. =20 >>=20 >> Not sure if it has to be that complicated (for a first shot). At least f= or 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 wo= rk on the (shared) JobQueue workqueue" part. I think drivers can just have a sepa= rate workqueue for such use-cases. > [1]https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/gpu/drm/pant= hor/panthor_sched.c#L1913