All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Gary Guo" <gary@garyguo.net>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>
Cc: <nova-gpu@lists.linux.dev>, <dri-devel@lists.freedesktop.org>,
	<linux-kernel@vger.kernel.org>,
	"dri-devel" <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v3 2/2] gpu: nova-core: fix barrier usage in GSP->CPU messaging path
Date: Mon, 24 Aug 2026 21:51:17 +0900	[thread overview]
Message-ID: <DKX6RHAHBFGB.1M6PDD9BC2ILR@nvidia.com> (raw)
In-Reply-To: <20260819-rust-barrier-v3-2-d5b7bd7e6624@garyguo.net>

On Thu Aug 20, 2026 at 2:28 AM JST, Gary Guo wrote:
> In the GSP->CPU messaging path, the code reads the write pointer from GSP,
> reads the response and advances the read pointer.
>
> A LOAD->LOAD ordering is required after the write pointer read and the data
> read. Add it as this is currently missing.
>
> A LOAD->STORE ordering is required after the data read and the advance of
> read pointer. Currently a Rust `SeqCst` barrier is used, which roughly maps
> to `smp_mb(Full)`; this however does not order DMA operations (notably on
> ARM, the generate barrier orders inner shareable and not outer shareable,
> which is ordered by `dma_mb`). This ordering does not need to be in between
> read pointer read and write, because it's for ordering between the ring
> buffer data and the pointer; the RMW operation does not internally need a
> barrier (nor it has to be atomic, as CPU pointers are updated by CPU only),
> so move it to before the RMW sequence for clarity.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
> ---

Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>

      parent reply	other threads:[~2026-08-24 12:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19 17:28 [PATCH v3 0/2] gpu: nova: fix incorrect GSP barrier usage Gary Guo
2026-08-19 17:28 ` [PATCH v3 1/2] gpu: nova-core: fix barrier usage in CPU->GSP messaging path Gary Guo
2026-08-19 17:39   ` sashiko-bot
2026-08-24 12:50   ` Eliot Courtney
2026-08-24 12:56     ` Gary Guo
2026-08-24 13:03       ` Eliot Courtney
2026-08-24 13:07         ` Gary Guo
2026-08-25  0:38           ` Eliot Courtney
2026-08-19 17:28 ` [PATCH v3 2/2] gpu: nova-core: fix barrier usage in GSP->CPU " Gary Guo
2026-08-19 17:39   ` sashiko-bot
2026-08-24 12:51   ` Eliot Courtney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DKX6RHAHBFGB.1M6PDD9BC2ILR@nvidia.com \
    --to=ecourtney@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel-bounces@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nova-gpu@lists.linux.dev \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.