[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251118132520.266179-2-phasta@kernel.org>
Date: Tue, 18 Nov 2025 14:25:16 +0100
From: Philipp Stanner <phasta@...nel.org>
To: Alice Ryhl <aliceryhl@...gle.com>,
Danilo Krummrich <dakr@...nel.org>,
Christian König <ckoenig.leichtzumerken@...il.com>,
Tvrtko Ursulin <tursulin@...ulin.net>,
Alexandre Courbot <acourbot@...dia.com>,
Daniel Almeida <daniel.almeida@...labora.com>,
Boris Brezillon <boris.brezillon@...labora.com>,
Dave Airlie <airlied@...hat.com>,
Lyude Paul <lyude@...hat.com>,
Peter Colberg <pcolberg@...hat.com>
Cc: dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org,
Philipp Stanner <phasta@...nel.org>
Subject: [RFC WIP 0/3] DRM Jobqueue
It is time to share a sneek peek into the DRM JQ design. It's all highly
WIP, but I hope that it transfers the general design idea.
I can compile this code, but it cannot actually submit anything yet.
Patch 1 of this series can be ignored. It solves a blocker in the Rust
infrastructure and is included so that interested factions can build the
code.
Patch 2 contains a slightly modified version of the already published
DMA fence RFC [1]. This version removes the DmaFenceNames trait callbacks and
replaces the name strings with dummies. Reason being that these strings
are only ever accessed through certain accessor functions which the Rust
DmaFence currently does not expose anyways, and the only user in C is
i915 [2].
The trait caused some trouble while compiling because for JQ's hw_fence
we don't need to pass fence data, but it was mandatory since that
data hosted said trait, but also needs to be pinned etc.
Patch 3 is the actual JQ code as it exists so far. Please see that
patch's commit message for the current state.
I'll revisit my DmaFence RFC soon and try to get it in line with
Christian's life time rework [3] and fix some other issues and implement the
feedback which the RFC received so far.
Feedback for JQ is obviously welcome; the most notable problem I'm
currently having is with the list implementation. I don't know yet how I
can get job_lists to work with jobs containing the driver's generic data
`T` – data which the JQ by the way doesn't need to access, it just wants
to pass it back to the driver later in run_job().
Greetings,
Philipp
[1] https://lore.kernel.org/dri-devel/20250918123100.124738-2-phasta@kernel.org/
[2] https://elixir.bootlin.com/linux/v6.18-rc4/A/ident/dma_fence_timeline_name
[3] https://lore.kernel.org/dri-devel/20251113145332.16805-1-christian.koenig@amd.com/
Philipp Stanner (3):
rust: list: Add unsafe for container_of
rust: sync: Add dma_fence abstractions
rust/drm: Add initial jobqueue sceleton
rust/bindings/bindings_helper.h | 1 +
rust/helpers/dma_fence.c | 23 ++
rust/helpers/helpers.c | 1 +
rust/helpers/spinlock.c | 5 +
rust/kernel/drm/jq.rs | 398 +++++++++++++++++++++++++
rust/kernel/drm/mod.rs | 2 +
rust/kernel/list/impl_list_item_mod.rs | 12 +-
rust/kernel/sync.rs | 2 +
rust/kernel/sync/dma_fence.rs | 380 +++++++++++++++++++++++
9 files changed, 818 insertions(+), 6 deletions(-)
create mode 100644 rust/helpers/dma_fence.c
create mode 100644 rust/kernel/drm/jq.rs
create mode 100644 rust/kernel/sync/dma_fence.rs
--
2.49.0
Powered by blists - more mailing lists