From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Alistair Popple" <apopple@nvidia.com>,
<rust-for-linux@vger.kernel.org>,
<dri-devel@lists.freedesktop.org>, <dakr@kernel.org>,
<acourbot@nvidia.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"John Hubbard" <jhubbard@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org
Subject: Re: [PATCH v2 06/10] gpu: nova-core: gsp: Create rmargs
Date: Fri, 26 Sep 2025 16:27:04 +0900 [thread overview]
Message-ID: <DD2JYDPBOKA8.2QCK0P7CR1T3V@nvidia.com> (raw)
In-Reply-To: <20250922113026.3083103-7-apopple@nvidia.com>
On Mon Sep 22, 2025 at 8:30 PM JST, Alistair Popple wrote:
> Initialise the GSP resource manager arguments (rmargs) which provide
> initialisation parameters to the GSP firmware during boot. The rmargs
> structure contains arguments to configure the GSP message/command queue
> location.
>
> These are mapped for coherent DMA and added to the libos data structure
> for access when booting GSP.
>
> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>
> ---
>
> Changes for v2:
> - Rebased on Alex's latest series
> ---
> drivers/gpu/nova-core/gsp.rs | 29 +++++++++++++++-
> drivers/gpu/nova-core/gsp/cmdq.rs | 14 ++++++--
> drivers/gpu/nova-core/gsp/fw.rs | 19 +++++++++++
> .../gpu/nova-core/gsp/fw/r570_144/bindings.rs | 33 +++++++++++++++++++
> 4 files changed, 91 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gsp.rs b/drivers/gpu/nova-core/gsp.rs
> index 3d4028d67d2e..bb08bd537ec4 100644
> --- a/drivers/gpu/nova-core/gsp.rs
> +++ b/drivers/gpu/nova-core/gsp.rs
> @@ -17,7 +17,10 @@
> use crate::fb::FbLayout;
> use crate::gsp::cmdq::GspCmdq;
>
> -use fw::LibosMemoryRegionInitArgument;
> +use fw::{
> + LibosMemoryRegionInitArgument, GSP_ARGUMENTS_CACHED, GSP_SR_INIT_ARGUMENTS,
> + MESSAGE_QUEUE_INIT_ARGUMENTS,
> +};
>
> pub(crate) mod cmdq;
>
> @@ -33,6 +36,7 @@ pub(crate) struct Gsp {
> pub logintr: CoherentAllocation<u8>,
> pub logrm: CoherentAllocation<u8>,
> pub cmdq: GspCmdq,
> + rmargs: CoherentAllocation<GSP_ARGUMENTS_CACHED>,
> }
>
> /// Creates a self-mapping page table for `obj` at its beginning.
> @@ -90,12 +94,35 @@ pub(crate) fn new(pdev: &pci::Device<device::Bound>) -> Result<impl PinInit<Self
>
> // Creates its own PTE array
> let cmdq = GspCmdq::new(dev)?;
> + let rmargs =
> + create_coherent_dma_object::<GSP_ARGUMENTS_CACHED>(dev, "RMARGS", 1, &mut libos, 3)?;
> + let (shared_mem_phys_addr, cmd_queue_offset, stat_queue_offset) = cmdq.get_cmdq_offsets();
> +
> + dma_write!(
> + rmargs[0].messageQueueInitArguments = MESSAGE_QUEUE_INIT_ARGUMENTS {
> + sharedMemPhysAddr: shared_mem_phys_addr,
> + pageTableEntryCount: cmdq.nr_ptes,
> + cmdQueueOffset: cmd_queue_offset,
> + statQueueOffset: stat_queue_offset,
> + ..Default::default()
> + }
> + )?;
> + dma_write!(
> + rmargs[0].srInitArguments = GSP_SR_INIT_ARGUMENTS {
> + oldLevel: 0,
> + flags: 0,
> + bInPMTransition: 0,
> + ..Default::default()
> + }
> + )?;
> + dma_write!(rmargs[0].bDmemStack = 1)?;
Wrapping our bindings is going to help clean up this code as well.
First, types named in CAPITALS_SNAKE_CASE are not idiomatic Rust and
look like constants. And it's not even like the bindings types are
consistently named that way, since we also have e.g. `GspFwWprMeta` - so
let's give them a proper public name and bring some consistency at the
same time.
This will make all the fields from `GSP_ARGUMENTS_CACHED` invisible to
this module as they should be, so the wrapping `GspArgumentsCached` type
should then have a constructor that receives a referene to the command
queue and takes the information is needs from it, similarly to
`GspFwWprMeta`. This will reduce the 3 `dma_write!` into a single one.
Then we should remove `get_cmdq_offsets`, which is super confusing. I am
also not fond of `cmdq.nr_ptes`. More on them below.
>
> Ok(try_pin_init!(Self {
> libos,
> loginit,
> logintr,
> logrm,
> + rmargs,
> cmdq,
> }))
> }
> diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs b/drivers/gpu/nova-core/gsp/cmdq.rs
> index a9ba1a4c73d8..9170ccf4a064 100644
> --- a/drivers/gpu/nova-core/gsp/cmdq.rs
> +++ b/drivers/gpu/nova-core/gsp/cmdq.rs
> @@ -99,7 +99,6 @@ fn new(dev: &device::Device<device::Bound>) -> Result<Self> {
> Ok(Self(gsp_mem))
> }
>
> - #[expect(unused)]
> fn dma_handle(&self) -> DmaAddress {
> self.0.dma_handle()
> }
> @@ -218,7 +217,7 @@ pub(crate) struct GspCmdq {
> dev: ARef<device::Device>,
> seq: u32,
> gsp_mem: DmaGspMem,
> - pub _nr_ptes: u32,
> + pub nr_ptes: u32,
> }
>
> impl GspCmdq {
> @@ -231,7 +230,7 @@ pub(crate) fn new(dev: &device::Device<device::Bound>) -> Result<GspCmdq> {
> dev: dev.into(),
> seq: 0,
> gsp_mem,
> - _nr_ptes: nr_ptes as u32,
> + nr_ptes: nr_ptes as u32,
> })
> }
>
> @@ -382,6 +381,15 @@ pub(crate) fn receive_msg_from_gsp<M: GspMessageFromGsp, R>(
> .advance_cpu_read_ptr(msg_header.rpc.length.div_ceil(GSP_PAGE_SIZE as u32));
> result
> }
> +
> + pub(crate) fn get_cmdq_offsets(&self) -> (u64, u64, u64) {
> + (
> + self.gsp_mem.dma_handle(),
> + core::mem::offset_of!(Msgq, msgq) as u64,
> + (core::mem::offset_of!(GspMem, gspq) - core::mem::offset_of!(GspMem, cpuq)
> + + core::mem::offset_of!(Msgq, msgq)) as u64,
> + )
> + }
So this thing returns 3 u64s, one of which is actually a DMA handle,
while the two others are technically constants. The only thing that
needs to be inferred at runtime is the DMA handle - all the rest is
static.
So we can make the two last returned values associated constants of
`GspCmdq`:
impl GspCmdq {
/// Offset of the data after the PTEs.
const POST_PTE_OFFSET: usize = core::mem::offset_of!(GspMem, cpuq);
/// Offset of command queue ring buffer.
pub(crate) const CMDQ_OFFSET: usize = core::mem::offset_of!(GspMem, cpuq)
+ core::mem::offset_of!(Msgq, msgq)
- Self::POST_PTE_OFFSET;
/// Offset of message queue ring buffer.
pub(crate) const STATQ_OFFSET: usize = core::mem::offset_of!(GspMem, gspq)
+ core::mem::offset_of!(Msgq, msgq)
- Self::POST_PTE_OFFSET;
`GspArgumentsCached::new` can then import `GspCmdq` and use these to
initialize its corresponding members.
Remains `nr_ptes`. It was introduced in the previous patch as follows:
let nr_ptes = size_of::<GspMem>() >> GSP_PAGE_SHIFT;
Which turns out to also be a constant! So let's add it next to the others:
impl GspCmdq {
...
/// Number of page table entries for the GSP shared region.
pub(crate) const NUM_PTES: usize = size_of::<GspMem>() >> GSP_PAGE_SHIFT;
And you can remove `GspCmdq::nr_ptes` altogether.
With this, `GspArgumentsCached::new` can take a reference to the
`GspCmdq` to initialize from, grab its DMA handle, and initialize
everything else using the constants we defined above. We remove a bunch
of inconsistently-named imports from `gsp.rs`, and replace
firmware-dependent incantations to initialize our GSP arguments with a
single constructor call that tells exactly what it does in a single
line.
next prev parent reply other threads:[~2025-09-26 7:27 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 11:30 [PATCH v2 00/11] gpu: nova-core: Boot GSP to RISC-V active Alistair Popple
2025-09-22 11:30 ` [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask Alistair Popple
2025-09-22 15:25 ` Boqun Feng
2025-09-22 16:08 ` Danilo Krummrich
2025-09-23 2:16 ` John Hubbard
2025-09-23 4:29 ` Alistair Popple
2025-09-26 12:00 ` Danilo Krummrich
2025-09-29 0:19 ` Alistair Popple
2025-09-29 7:06 ` Danilo Krummrich
2025-09-29 7:39 ` Alistair Popple
2025-09-29 12:49 ` Danilo Krummrich
2025-10-01 1:31 ` [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask^[ Alistair Popple
2025-09-24 19:43 ` [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask Lyude Paul
2025-09-22 11:30 ` [PATCH v2 02/10] gpu: nova-core: Create initial Gsp Alistair Popple
2025-09-23 14:20 ` Alexandre Courbot
2025-09-24 20:13 ` Lyude Paul
2025-09-24 20:50 ` John Hubbard
2025-09-24 21:07 ` Lyude Paul
2025-09-24 21:15 ` John Hubbard
2025-09-22 11:30 ` [PATCH v2 03/10] gpu: nova-core: gsp: Create wpr metadata Alistair Popple
2025-09-24 20:24 ` Lyude Paul
2025-09-26 1:24 ` Alexandre Courbot
2025-09-29 0:29 ` Alistair Popple
2025-09-29 14:54 ` Alexandre Courbot
2025-09-26 1:24 ` Alexandre Courbot
2025-09-29 0:38 ` Alistair Popple
2025-09-22 11:30 ` [PATCH v2 04/10] gpu: nova-core: Add a slice-buffer (sbuffer) datastructure Alistair Popple
2025-09-24 20:36 ` Lyude Paul
2025-09-29 0:44 ` Alistair Popple
2025-09-22 11:30 ` [PATCH v2 05/10] gpu: nova-core: gsp: Add GSP command queue handling Alistair Popple
2025-09-22 19:16 ` Timur Tabi
2025-09-24 22:03 ` Lyude Paul
2025-09-25 6:32 ` Alistair Popple
2025-09-26 2:20 ` Alexandre Courbot
2025-09-29 1:06 ` Alistair Popple
2025-09-29 7:24 ` Danilo Krummrich
2025-09-26 4:37 ` Alexandre Courbot
2025-09-29 6:19 ` Alistair Popple
2025-09-29 14:34 ` Alexandre Courbot
2025-09-29 14:38 ` Miguel Ojeda
2025-09-29 14:45 ` Alexandre Courbot
2025-09-30 11:41 ` Alistair Popple
2025-09-30 11:58 ` Miguel Ojeda
2025-10-01 0:42 ` Alistair Popple
2025-09-30 0:36 ` Alistair Popple
2025-09-30 10:33 ` Danilo Krummrich
2025-09-30 13:36 ` Alexandre Courbot
2025-09-22 11:30 ` [PATCH v2 06/10] gpu: nova-core: gsp: Create rmargs Alistair Popple
2025-09-24 22:05 ` Lyude Paul
2025-09-26 7:27 ` Alexandre Courbot [this message]
2025-09-29 6:36 ` Alistair Popple
2025-09-29 7:18 ` Danilo Krummrich
2025-09-29 7:49 ` Alistair Popple
2025-09-22 11:30 ` [PATCH v2 07/10] gpu: nova-core: gsp: Create RM registry and sysinfo commands Alistair Popple
2025-09-22 19:10 ` Timur Tabi
2025-09-23 4:40 ` Alistair Popple
2025-09-23 4:46 ` Timur Tabi
2025-09-24 22:11 ` Lyude Paul
2025-09-22 11:30 ` [PATCH v2 08/10] nova-core: falcon: Add support to check if RISC-V is active Alistair Popple
2025-09-22 19:12 ` Timur Tabi
2025-09-23 1:07 ` John Hubbard
2025-09-23 4:23 ` Timur Tabi
2025-09-23 4:42 ` Alistair Popple
2025-09-24 22:12 ` Lyude Paul
2025-09-22 11:30 ` [PATCH v2 09/10] nova-core: falcon: Add support to write firmware version Alistair Popple
2025-09-24 22:14 ` Lyude Paul
2025-09-22 11:30 ` [PATCH v2 10/10] nova-core: gsp: Boot GSP Alistair Popple
2025-09-24 22:15 ` Lyude Paul
2025-09-24 22:24 ` John Hubbard
2025-09-25 3:09 ` Timur Tabi
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=DD2JYDPBOKA8.2QCK0P7CR1T3V@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox