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 1CC49E9E315 for ; Wed, 11 Feb 2026 14:38:39 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7401F10E06D; Wed, 11 Feb 2026 14:38:38 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="Bd2QNiC9"; 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 D4B2110E06D for ; Wed, 11 Feb 2026 14:38:37 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 631A043EC7; Wed, 11 Feb 2026 14:38:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 049C3C4CEF7; Wed, 11 Feb 2026 14:38:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770820717; bh=LLfEZdrWMC01KnSUzsRLFapK9SAcgEquZEXKmPEaFrM=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=Bd2QNiC91p0a5SzTno7OirdVI6LrmY7vJ82fbNBDgx32FSgEgK69zLP6iCpMAd5QM Wvpj8Def+8gnIzc3VCl0heIAcs+hBaD9yEPc5SHGv8zhY4usuXbusr8pegzM4T5VNE YelRwylzUq33Eu+OFsTma7U9ttrqcb0J32s0OKHx0rVCoEO+UsOmDTuhk5b1xtyS9x FhWscwnesL52cLA/5dcFjr+Gv0iXyrL1eX4T0mb2rK/ntcAOv+96J58+VYJ8pPgUvU 1EsmfJx/9/Zs50c83DqEgEIKgm2opCoAyT07A7dE0C7IrZsOZaIKdK4LyCRYndIrAN 2M/2CVLN9BlgA== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 11 Feb 2026 15:38:32 +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> In-Reply-To: <20260211121223.78674f22@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 12:12 PM CET, Boris Brezillon wrote: > On Wed, 11 Feb 2026 12:00:30 +0100 > "Danilo Krummrich" wrote: >> I.e. sharing a workqueue between JobQs is fine, but we have to ensure th= ey 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 sa= y, struct JobQueueWorker that encapsulates a (reference counted) workqueue, bu= t does not give access to it outside of jobq.rs.