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 603F5EA810C for ; Tue, 10 Feb 2026 13:15:35 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 80A4910E1AB; Tue, 10 Feb 2026 13:15:34 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="pfOZklSu"; dkim-atps=neutral Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) by gabe.freedesktop.org (Postfix) with ESMTPS id E767510E1AB for ; Tue, 10 Feb 2026 13:15:33 +0000 (UTC) Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-b8db12d8c65so950960466b.3 for ; Tue, 10 Feb 2026 05:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770729332; x=1771334132; darn=lists.freedesktop.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=9VV/JxScsbsZ/xttmVg7Jcxlx8uiC2eXBQsyDkGahJE=; b=pfOZklSuTwPDuseoAVFotTl9lmmb9WxyvB0vYyzhAKEnJYIbuh04DdfQW0Sp+xSjbb 5kERrJ0xOPD5qFoZkW6F/ICFFHoIx3chNiX8rNai0Tf3bITopEI7TEJoel67nvVFy5qe czJhHzjTYfcdb43KLI95yPSxPbS5gT+9iqN+ooQLnKYbADlocQluzLHuJzHSxrhDgGb4 52I9RtH61U9tCVhgpiCjVaLgbN1Pl0CqmFzPsSr4mAfQSijg2BJp6g3iAVBTkbSQbq/N gHeTC4OtZsqDsNm4jONvHwQEhuKNJOi7kyB2NdjZm9jsO9dNA0LkJU59brIpvTWZmr8c ii4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770729332; x=1771334132; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9VV/JxScsbsZ/xttmVg7Jcxlx8uiC2eXBQsyDkGahJE=; b=P3JIMRxClv8kWTwyGQQU73pg5fo92hF0EgnqX2dGnkwnsjvcsOmyb0u15Y0LtYarPD PFvzbz35nHXilL4vhsW3ewpNgjp1Wo7DKb0Gop4wg5NJkSOq34ZLVeF0Pwxt+5wM6fLk lSTagBsUMtLBwoUqTNuzcyHgBEQeRB5SYt8uN1x/GhZRlDPFyZT0QHgGeWiAD1LCH6mN lFn50qjPyqxY97oaL7Cv6U56ZwGuX5rgGUAAVbhhj+6i7cc6T2jJ8dB5b6V7FqaYchz3 1msXw0D0qaRYFGQfDP2PEF3onixxlm65ZdyglvURYJptknCCNOcK8YQDXbqNcH4SPYZM o48A== X-Forwarded-Encrypted: i=1; AJvYcCXA7ewpiNdZotc1Nbp7vr/8X28rijFvdr3vZVT6Wj/YOO3t30UGqyMFhch8ttU1MW9jA22TxPBIjvc=@lists.freedesktop.org X-Gm-Message-State: AOJu0YwV1/SoTZrd/3g65Tul35UbbS+MEdx42zCBHum7x3pTEIUgo51w jYLA5gwWrVJsy4NhpVruQQxEwmPq7yVpdJncz1TSLAMbwdZHw6nJT6IKcQDZAsxcHK1+SMocM1e zJ92G1i240aEcj5JjkA== X-Received: from ejblc1.prod.google.com ([2002:a17:906:f901:b0:b88:4d07:231]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:906:6a15:b0:b88:4e9d:bc63 with SMTP id a640c23a62f3a-b8f5438238fmr102094466b.6.1770729332186; Tue, 10 Feb 2026 05:15:32 -0800 (PST) Date: Tue, 10 Feb 2026 13:15:31 +0000 In-Reply-To: <20260210133617.0a4be958@fedora> Mime-Version: 1.0 References: <20260203081403.68733-4-phasta@kernel.org> <20260205095727.4c3e2941@fedora> <20260209155843.725dcfe1@fedora> <20260210101525.7fb85f25@fedora> <20260210133617.0a4be958@fedora> Message-ID: Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions From: Alice Ryhl To: Boris Brezillon Cc: "Christian =?utf-8?B?S8O2bmln?=" , Philipp Stanner , phasta@kernel.org, Danilo Krummrich , David Airlie , Simona Vetter , Gary Guo , Benno Lossin , Daniel Almeida , Joel Fernandes , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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 Tue, Feb 10, 2026 at 01:36:17PM +0100, Boris Brezillon wrote: > On Tue, 10 Feb 2026 10:15:04 +0000 > Alice Ryhl wrote: > > > impl MustBeSignalled<'_> { > > /// Drivers generally should not use this one. > > fn i_promise_it_will_be_signalled(self) -> WillBeSignalled { ... } > > > > /// One way to ensure the fence has been signalled is to signal it. > > fn signal_fence(self) -> WillBeSignalled { > > self.fence.signal(); > > self.i_promise_it_will_be_signalled() > > } > > > > /// Another way to ensure the fence will be signalled is to spawn a > > /// workqueue item that promises to signal it. > > fn transfer_to_wq( > > self, > > wq: &Workqueue, > > item: impl DmaFenceWorkItem, > > ) -> WillBeSignalled { > > // briefly obtain the lock class of the wq to indicate to > > // lockdep that the signalling path "blocks" on arbitrary jobs > > // from this wq completing > > bindings::lock_acquire(&wq->key); > > bindings::lock_release(&wq->key); > > > > // enqueue the job > > wq.enqueue(item, wq); > > > > // The signature of DmaFenceWorkItem::run() promises to arrange > > // for it to be signalled. > > self.i_promise_it_will_be_signalled() > > } > > I guess what's still missing is some sort of `transfer_to_hw()` > function and way to flag the IRQ handler taking over the fence > signaling token. Yes, transfer to hardware needs to be another piece of logic similar to transfer to wq. And I imagine there are many ways such a transfer to hardware could work. Unless you have a timeout on it, in which case the WillBeSignalled is satisfied by the fact you have a timeout alone, and the signalling that happens from the irq is just an opportunistic signal from outside the dma fence signalling critical path. >From dma-fence.c: * * The only exception are fast paths and opportunistic signalling code, which * calls dma_fence_signal() purely as an optimization, but is not required to * guarantee completion of a &dma_fence. The usual example is a wait IOCTL * which calls dma_fence_signal(), while the mandatory completion path goes * through a hardware interrupt and possible job completion worker. Well ... unless triggering timeouts can block on GFP_KERNEL allocations... Alice