From nobody Sun Jun 14 11:25:05 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95FB034403F; Thu, 2 Apr 2026 15:25:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775143529; cv=none; b=HEaGvNI8AYHWcxsoThjGESj56EqRATQkfWJdLxUC8gdOCL8i3aRru72CbFs7e6YH73xcAIWyZpZgKHPz9S8BqXIfFTm2Q88H/32N8Q7CSvGn2bYN4l+GWwKNuW4c1eEa9CjsYLB/mjo7XtZZoppfKmCjfrokx4ZH+LJbEVxY/MM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775143529; c=relaxed/simple; bh=xhCfedEVrgNyKr1DnCyfjrBfs37cxy3biI06+Ypg+4c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZiSgnc6liY5cVbwaghi2rH2rt1x1o8lOvnkCKqohJRlSSyfN7afcbwXXBOQbbl0p8UpiXU/INbRHfpKs4kar+AJ5+9LgOPGl2m52Kf+1zDxy57b5pwkUzcTFeKFEQYVZF74X6Clp4qkr3xiNvEqhrhCFjIfbDXIpg/FFO4f6qzk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u2szK5EQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u2szK5EQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C79FAC2BCB2; Thu, 2 Apr 2026 15:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775143529; bh=xhCfedEVrgNyKr1DnCyfjrBfs37cxy3biI06+Ypg+4c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:Reply-To:From; b=u2szK5EQABMsAPFYy8mBZDK+tw5TJ9Jb97ejNonPomb60WjK7cm9YdgvJ08GHfFx0 WJNFVYVgQzVyu6qQWWw7oquCAMk+uyI9XJxzf9UyKcljCufusNJ2D6Ysv52Gnlbdcg pybdeQgMmvUF9v0hrJxuZmJ4my/jxRk0pjTdSAznVXqpIECdS+2xQZpouklOsMRJHd ZPPhDZAXwJuguR47XdvG6SIs/xpCiuAAfnqoo9hD6Lyl/UuEfI+qJGtvUsBm0y2ucL J9QjNwk97R3rhjDx9wzdDKlxuPXCeAaBoTEiwnQ1fSxGYt2t/Ya2GOeleX5e4Q6qP4 Q/lXl/z2d9YFQ== From: Gary Guo To: Miguel Ojeda , Boqun Feng , Gary Guo , =?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich Cc: Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, lkmm@lists.linux.dev Subject: [PATCH 1/3] rust: sync: add helpers for mb, dma_mb and friends Date: Thu, 2 Apr 2026 16:24:34 +0100 Message-ID: <20260402152443.1059634-3-gary@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260402152443.1059634-2-gary@kernel.org> References: <20260402152443.1059634-2-gary@kernel.org> Reply-To: Gary Guo Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gary Guo They supplement the existing smp_mb, smp_rmb and smp_wmb. Signed-off-by: Gary Guo Reviewed-by: Eliot Courtney --- rust/helpers/barrier.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/rust/helpers/barrier.c b/rust/helpers/barrier.c index fed8853745c8..dbc7a3017c78 100644 --- a/rust/helpers/barrier.c +++ b/rust/helpers/barrier.c @@ -2,6 +2,36 @@ =20 #include =20 +__rust_helper void rust_helper_mb(void) +{ + mb(); +} + +__rust_helper void rust_helper_rmb(void) +{ + rmb(); +} + +__rust_helper void rust_helper_wmb(void) +{ + wmb(); +} + +__rust_helper void rust_helper_dma_mb(void) +{ + dma_mb(); +} + +__rust_helper void rust_helper_dma_rmb(void) +{ + dma_rmb(); +} + +__rust_helper void rust_helper_dma_wmb(void) +{ + dma_wmb(); +} + __rust_helper void rust_helper_smp_mb(void) { smp_mb(); --=20 2.51.2 From nobody Sun Jun 14 11:25:05 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45FD133E37C; Thu, 2 Apr 2026 15:25:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775143535; cv=none; b=Mubn3zH+viCJE53WQ0i3ck9loHfgbU9LDuXyMMsieqViswMY8QP672DNIIMsRyvoqk3xfus5dTq3SDhKt1cB5NXndjOq7ksk2UwoWqkKEKlrRu3jO6pE4rMEa515qlSsfTqO7g4m4w/PoLVoQzu0zc5ShNguQj3+RFIrq3Tb3g8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775143535; c=relaxed/simple; bh=66uKRPN7TVakVzjWrjwY/JAdlsLoFP/ckXmV7Ra6ork=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qXTQBUF3qBB8LB5pNn6qCgvi8Yt7xJMll0aXhSBh9adfzImWbw+BHY2iZZGjSWT3TMWNO5roowFYX52Taj75hGN5rM0nc484sMp72SJklr/5LEvC17Xc4a6GtPXrcqAcZ7YH6z7Rxn9etiryQCnMvfBTXSx/IrFZ0A0H9TUcUpA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dT7bUylh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dT7bUylh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64591C2BC9E; Thu, 2 Apr 2026 15:25:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775143535; bh=66uKRPN7TVakVzjWrjwY/JAdlsLoFP/ckXmV7Ra6ork=; h=From:To:Cc:Subject:Date:In-Reply-To:References:Reply-To:From; b=dT7bUylhcLGIhM0cbOLbGLRV8WWLhBG1Ar1m29AbnL6B+dCXpAeh6ozZZ99KhHU1Q uuw6vC6DfppBVs8KZ50/VjuREnYlS51X/brvUBc/GWHLETsJQQNIY6n0H1Z56df6bk 3cvw9BTVEGe8h9B/ofqM70svhn1f3SCT1ySHQ7gA2Q66ejQDrk+KBeAk9mYmibbS56 ePrEp2egISOrZ3ow5V5e8IVP9JViwnHKg9SZfmUzXt1PvFwcSBN/pVQv0++HhqtD80 +sMc/4isBdYqxL1ZISpX9duGpNtzc6/rsUqov12j6pmFzacQOdunhXXYownnoNP5Cw RmYsJ9QcbRgHA== From: Gary Guo To: Miguel Ojeda , Boqun Feng , Gary Guo , =?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Will Deacon , Peter Zijlstra , Mark Rutland Cc: Alan Stern , Andrea Parri , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, lkmm@lists.linux.dev Subject: [PATCH 2/3] rust: sync: generic memory barriers Date: Thu, 2 Apr 2026 16:24:35 +0100 Message-ID: <20260402152443.1059634-4-gary@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260402152443.1059634-2-gary@kernel.org> References: <20260402152443.1059634-2-gary@kernel.org> Reply-To: Gary Guo Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gary Guo Implement a generic interface for memory barriers (full system/DMA/SMP). The interface uses a parameter to force user to specify their intent with barriers. It provides `Read`, `Write`, `Full` orderings which map to the existing `rmb()`, `wmb()` and `mb()`, but also `Acquire` and `Release` which is documented to have `LOAD->{LOAD,STORE}` ordering and `{LOAD,STORE}->WRITE` ordering, although for now they're still mapped to a full `mb()`. But in the future it could be mapped to a more efficient form depending on the architecture. I included them as many users do not need the STORE->LOAD ordering, and having them use `Acquire`/`Release` is more clear on their intent in what reordering is to be prevented. Generic is used here instead of providing individual standalone functions to reduce code duplication. For example, the `Acquire` -> `Full` upgrade here is uniformly implemented for all three types. The `CONFIG_SMP` check in `smp_mb` is uniformly implemented for all SMP barriers. This could extend to `virt_mb`'s if they're introduced in the future. Signed-off-by: Gary Guo --- rust/kernel/sync/atomic/ordering.rs | 2 +- rust/kernel/sync/barrier.rs | 194 ++++++++++++++++++++++++---- 2 files changed, 168 insertions(+), 28 deletions(-) diff --git a/rust/kernel/sync/atomic/ordering.rs b/rust/kernel/sync/atomic/= ordering.rs index 3f103aa8db99..c4e732e7212f 100644 --- a/rust/kernel/sync/atomic/ordering.rs +++ b/rust/kernel/sync/atomic/ordering.rs @@ -15,7 +15,7 @@ //! - It provides ordering between the annotated operation and all the f= ollowing memory accesses. //! - It provides ordering between all the preceding memory accesses and= all the following memory //! accesses. -//! - All the orderings are the same strength as a full memory barrier (= i.e. `smp_mb()`). +//! - All the orderings are the same strength as a full memory barrier (= i.e. `smp_mb(Full)`). //! - [`Relaxed`] provides no ordering except the dependency orderings. De= pendency orderings are //! described in "DEPENDENCY RELATIONS" in [`LKMM`]'s [`explanation`]. //! diff --git a/rust/kernel/sync/barrier.rs b/rust/kernel/sync/barrier.rs index 8f2d435fcd94..0331bb353a76 100644 --- a/rust/kernel/sync/barrier.rs +++ b/rust/kernel/sync/barrier.rs @@ -7,6 +7,23 @@ //! //! [`LKMM`]: srctree/tools/memory-model/ =20 +#![expect(private_bounds, reason =3D "sealed implementation")] + +pub use super::atomic::ordering::{ + Acquire, + Full, + Release, // +}; + +/// The annotation type for read operations. +pub struct Read; + +/// The annotation type for write operations. +pub struct Write; + +struct Smp; +struct Dma; + /// A compiler barrier. /// /// A barrier that prevents compiler from reordering memory accesses acros= s the barrier. @@ -19,43 +36,166 @@ pub(crate) fn barrier() { unsafe { core::arch::asm!("") }; } =20 -/// A full memory barrier. -/// -/// A barrier that prevents compiler and CPU from reordering memory access= es across the barrier. -#[inline(always)] -pub fn smp_mb() { - if cfg!(CONFIG_SMP) { - // SAFETY: `smp_mb()` is safe to call. - unsafe { bindings::smp_mb() }; - } else { - barrier(); +trait MemoryBarrier { + fn run(); +} + +// Currently kernel only support `rmb`, `wmb` and full `mb`. +// Upgrade `Acquire`/`Release` barriers to full barriers. + +impl MemoryBarrier for Acquire +where + Full: MemoryBarrier, +{ + #[inline] + fn run() { + Full::run(); } } =20 -/// A write-write memory barrier. -/// -/// A barrier that prevents compiler and CPU from reordering memory write = accesses across the -/// barrier. -#[inline(always)] -pub fn smp_wmb() { - if cfg!(CONFIG_SMP) { +impl MemoryBarrier for Release +where + Full: MemoryBarrier, +{ + #[inline] + fn run() { + Full::run(); + } +} + +// Specific barrier implementations. + +impl MemoryBarrier for Read { + #[inline] + fn run() { + // SAFETY: `rmb()` is safe to call. + unsafe { bindings::rmb() }; + } +} + +impl MemoryBarrier for Write { + #[inline] + fn run() { + // SAFETY: `wmb()` is safe to call. + unsafe { bindings::wmb() }; + } +} + +impl MemoryBarrier for Full { + #[inline] + fn run() { + // SAFETY: `mb()` is safe to call. + unsafe { bindings::mb() }; + } +} + +impl MemoryBarrier for Read { + #[inline] + fn run() { + // SAFETY: `dma_rmb()` is safe to call. + unsafe { bindings::dma_rmb() }; + } +} + +impl MemoryBarrier for Write { + #[inline] + fn run() { + // SAFETY: `dma_wmb()` is safe to call. + unsafe { bindings::dma_wmb() }; + } +} + +impl MemoryBarrier for Full { + #[inline] + fn run() { + // SAFETY: `dma_mb()` is safe to call. + unsafe { bindings::dma_mb() }; + } +} + +impl MemoryBarrier for Read { + #[inline] + fn run() { + // SAFETY: `smp_rmb()` is safe to call. + unsafe { bindings::smp_rmb() }; + } +} + +impl MemoryBarrier for Write { + #[inline] + fn run() { // SAFETY: `smp_wmb()` is safe to call. unsafe { bindings::smp_wmb() }; - } else { - barrier(); } } =20 -/// A read-read memory barrier. +impl MemoryBarrier for Full { + #[inline] + fn run() { + // SAFETY: `smp_mb()` is safe to call. + unsafe { bindings::smp_mb() }; + } +} + +/// Memory barrier. /// -/// A barrier that prevents compiler and CPU from reordering memory read a= ccesses across the -/// barrier. -#[inline(always)] -pub fn smp_rmb() { +/// A barrier that prevents compiler and CPU from reordering memory access= es across the barrier. +/// +/// The specific forms of reordering can be specified using the parameter. +/// - `mb(Read)` provides a read-read barrier. +/// - `mb(Write)` provides a write-write barrier. +/// - `mb(Full)` provides a full barrier. +/// - `mb(Acquire)` prevents preceding read from being ordered against suc= ceeding memory +/// operations. +/// - `mb(Release)` prevents preceding memory operations from being ordere= d against succeeding +/// writes. +/// +/// # Examples +/// +/// ``` +/// # use kernel::sync::barrier::*; +/// mb(Read); +/// mb(Write); +/// mb(Acquire); +/// mb(Release); +/// mb(Full); +/// ``` +#[inline] +#[doc(alias =3D "rmb")] +#[doc(alias =3D "wmb")] +pub fn mb(_: T) { + T::run() +} + +/// Memory barrier between CPUs. +/// +/// A barrier that prevents compiler and CPU from reordering memory access= es across the barrier. +/// Does not prevent re-ordering with respect to other bus-mastering devic= es. +/// +/// Prefer using `Acquire` [loads](super::atomic::Atomic::load) to `Acquir= e` barriers, and `Release` +/// [stores](super::atomic::Atomic::store) to `Release` barriers. +/// +/// See [`mb`] for usage. +#[inline] +#[doc(alias =3D "smp_rmb")] +#[doc(alias =3D "smp_wmb")] +pub fn smp_mb>(_: T) { if cfg!(CONFIG_SMP) { - // SAFETY: `smp_rmb()` is safe to call. - unsafe { bindings::smp_rmb() }; + T::run() } else { - barrier(); + barrier() } } + +/// Memory barrier between local CPU and bus-mastering devices. +/// +/// A barrier that prevents compiler and CPU from reordering memory access= es across the barrier. +/// Does not prevent re-ordering with respect to other CPUs. +/// +/// See [`mb`] for usage. +#[inline] +#[doc(alias =3D "dma_rmb")] +#[doc(alias =3D "dma_wmb")] +pub fn dma_mb>(_: T) { + T::run() +} --=20 2.51.2 From nobody Sun Jun 14 11:25:05 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A98C3C7DF9; Thu, 2 Apr 2026 15:25:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775143541; cv=none; b=WPBAKooBdvCP7bEu2D9PCM68/+QRGQkFT0Sf/6qRr6ol8tO0Y398uTJiUUubMJVH4X59j5RM78+BTCzQLUjj/8RUHe1Yeaj1U5aleD+JdgeXA/wSG8gJCdu/PZdxmNMQVhLgMUh4enW4CFwGKtORWPqM8gRH7U6p7GqBANIT8+k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775143541; c=relaxed/simple; bh=H/ah7c8QblLITP8uZx6rQ0un/4q3xoSn//XPdWvMKg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RAmmAZJi2DiAOUqq4yxqgpG7+BBYfavsyh/8L/2Rm0OwTqU9yj9fk5wfAkkTH1/H+GgsM5W5VdxnteiYdb6cgmhVqgCaBwPXfUCE2dx2mlFYm5MJwQi/xiUwZ5+7X+TAJ84N1vnDs0FsYdxkx0xte+u/1cb1+GSfyGer3DH0gQs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WWFy+j0h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WWFy+j0h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3369C116C6; Thu, 2 Apr 2026 15:25:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775143541; bh=H/ah7c8QblLITP8uZx6rQ0un/4q3xoSn//XPdWvMKg4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:Reply-To:From; b=WWFy+j0hRa4F4bO2EyJSlQJHcjpjpFFyjoTGDTtQjbjJzxTkfZTuhsSiTyyWfX0O6 g8vteUT5Rt/P+nSlO8IOZsb+5RgeXoASrPj02F/QUpNaVWyonQeoCTK9x4dhl1XXbs jfZ5iC7mVVQxOEJ7Oxyyam5pxByJzK8iKhMs07MX/0bItN4OcZZPImdZqt6HGC7kk6 k1DslyAQTlkKWRLMW/s0H9WLkaxQtKFuZ2+GXcIanu5Y7IzXiD3HdRl/3lW8+iDFO8 eYEYAdmUgrqDX7WspZto8eIeJbVIsour5bzkBTq/QAEZZOebr9ozUc6D3ldNaWNAzo GYbFhHKTSAcFw== From: Gary Guo To: Miguel Ojeda , Boqun Feng , Gary Guo , =?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Alexandre Courbot , David Airlie , Simona Vetter Cc: Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, lkmm@lists.linux.dev, dri-devel@lists.freedesktop.org Subject: [PATCH 3/3] gpu: nova-core: fix wrong use of barriers in GSP code Date: Thu, 2 Apr 2026 16:24:36 +0100 Message-ID: <20260402152443.1059634-5-gary@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20260402152443.1059634-2-gary@kernel.org> References: <20260402152443.1059634-2-gary@kernel.org> Reply-To: Gary Guo Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gary Guo Currently, in the GSP->CPU messaging path, the current code misses a read barrier before data read. The barrier after read is updated to a DMA barrier (with release ordering desired), instead of the existing (Rust) SeqCst SMP barrier; the location of barrier is also moved to the beginning of function, because the barrier is needed to synchronizing between data and ring-buffer pointer, the RMW operation does not internally need a barrier (nor it has to be atomic, as CPU pointers are updated by CPU only). In the CPU->GSP messaging path, the current code misses a write barrier after data write and before updating the CPU write pointer. Barrier is not needed before data write due to control dependency, this fact is documented explicitly. This could be replaced with an acquire barrier if needed. Signed-off-by: Gary Guo --- drivers/gpu/nova-core/gsp/cmdq.rs | 19 +++++++++++++++++++ drivers/gpu/nova-core/gsp/fw.rs | 12 ------------ 2 files changed, 19 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs b/drivers/gpu/nova-core/gsp/= cmdq.rs index 2224896ccc89..7e4315b13984 100644 --- a/drivers/gpu/nova-core/gsp/cmdq.rs +++ b/drivers/gpu/nova-core/gsp/cmdq.rs @@ -19,6 +19,12 @@ prelude::*, sync::{ aref::ARef, + barrier::{ + dma_mb, + Read, + Release, + Write, // + }, Mutex, // }, time::Delta, @@ -258,6 +264,9 @@ fn new(dev: &device::Device) -> Result { let tx =3D self.cpu_write_ptr() as usize; let rx =3D self.gsp_read_ptr() as usize; =20 + // ORDERING: control dependency provides necessary LOAD->STORE ord= ering. + // `dma_mb(Acquire)` may be used here if we don't want to rely on = control dependency. + // SAFETY: // - We will only access the driver-owned part of the shared memor= y. // - Per the safety statement of the function, no concurrent acces= s will be performed. @@ -311,6 +320,9 @@ fn driver_write_area_size(&self) -> usize { let tx =3D self.gsp_write_ptr() as usize; let rx =3D self.cpu_read_ptr() as usize; =20 + // ORDERING: Ensure data load is ordered after load of GSP write p= ointer. + dma_mb(Read); + // SAFETY: // - We will only access the driver-owned part of the shared memor= y. // - Per the safety statement of the function, no concurrent acces= s will be performed. @@ -408,6 +420,10 @@ fn cpu_read_ptr(&self) -> u32 { =20 // Informs the GSP that it can send `elem_count` new pages into the me= ssage queue. fn advance_cpu_read_ptr(&mut self, elem_count: u32) { + // ORDERING: Ensure read pointer is properly ordered. + // + dma_mb(Release); + super::fw::gsp_mem::advance_cpu_read_ptr(&self.0, elem_count) } =20 @@ -422,6 +438,9 @@ fn cpu_write_ptr(&self) -> u32 { =20 // Informs the GSP that it can process `elem_count` new pages from the= command queue. fn advance_cpu_write_ptr(&mut self, elem_count: u32) { + // ORDERING: Ensure all command data is visible before updateing r= ing buffer pointer. + dma_mb(Write); + super::fw::gsp_mem::advance_cpu_write_ptr(&self.0, elem_count) } } diff --git a/drivers/gpu/nova-core/gsp/fw.rs b/drivers/gpu/nova-core/gsp/fw= .rs index 0c8a74f0e8ac..62c2cf1b030c 100644 --- a/drivers/gpu/nova-core/gsp/fw.rs +++ b/drivers/gpu/nova-core/gsp/fw.rs @@ -42,11 +42,6 @@ =20 // TODO: Replace with `IoView` projections once available. pub(super) mod gsp_mem { - use core::sync::atomic::{ - fence, - Ordering, // - }; - use kernel::{ dma::Coherent, dma_read, @@ -72,10 +67,6 @@ pub(in crate::gsp) fn cpu_read_ptr(qs: &Coherent= ) -> u32 { =20 pub(in crate::gsp) fn advance_cpu_read_ptr(qs: &Coherent, coun= t: u32) { let rptr =3D cpu_read_ptr(qs).wrapping_add(count) % MSGQ_NUM_PAGES; - - // Ensure read pointer is properly ordered. - fence(Ordering::SeqCst); - dma_write!(qs, .cpuq.rx.0.readPtr, rptr); } =20 @@ -87,9 +78,6 @@ pub(in crate::gsp) fn advance_cpu_write_ptr(qs: &Coherent= , count: u32) { let wptr =3D cpu_write_ptr(qs).wrapping_add(count) % MSGQ_NUM_PAGE= S; =20 dma_write!(qs, .cpuq.tx.0.writePtr, wptr); - - // Ensure all command data is visible before triggering the GSP re= ad. - fence(Ordering::SeqCst); } } =20 --=20 2.51.2