From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Lyude Paul" <lyude@redhat.com>,
"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 03/10] gpu: nova-core: gsp: Create wpr metadata
Date: Fri, 26 Sep 2025 10:24:18 +0900 [thread overview]
Message-ID: <DD2C8MKHDRCA.1XRV8RNPCXAN7@nvidia.com> (raw)
In-Reply-To: <e024e964c5e79b1c86dadcb8c19d14d175bcb0a7.camel@redhat.com>
On Thu Sep 25, 2025 at 5:24 AM JST, Lyude Paul wrote:
> On Mon, 2025-09-22 at 21:30 +1000, Alistair Popple wrote:
>> The GSP requires some pieces of metadata to boot. These are passed in a
>> struct which the GSP transfers via DMA. Create this struct and get a
>> handle to it for future use when booting the GSP.
>>
>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>>
>> ---
>>
>> Changes for v2:
>> - Rebased on Alex's latest version
>> ---
>> drivers/gpu/nova-core/fb.rs | 1 -
>> drivers/gpu/nova-core/firmware/gsp.rs | 3 +-
>> drivers/gpu/nova-core/firmware/riscv.rs | 6 +-
>> drivers/gpu/nova-core/gsp.rs | 1 +
>> drivers/gpu/nova-core/gsp/boot.rs | 7 +++
>> drivers/gpu/nova-core/gsp/fw.rs | 63 ++++++++++++++++++-
>> .../gpu/nova-core/gsp/fw/r570_144/bindings.rs | 2 +
>> 7 files changed, 75 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
>> index 4d6a1f452183..5580498ba2fb 100644
>> --- a/drivers/gpu/nova-core/fb.rs
>> +++ b/drivers/gpu/nova-core/fb.rs
>> @@ -87,7 +87,6 @@ pub(crate) fn unregister(&self, bar: &Bar0) {
>> ///
>> /// Contains ranges of GPU memory reserved for a given purpose during the GSP boot process.
>> #[derive(Debug)]
>> -#[expect(dead_code)]
>> pub(crate) struct FbLayout {
>> /// Range of the framebuffer. Starts at `0`.
>> pub(crate) fb: Range<u64>,
>> diff --git a/drivers/gpu/nova-core/firmware/gsp.rs b/drivers/gpu/nova-core/firmware/gsp.rs
>> index 9654810834d9..67b85e1db27d 100644
>> --- a/drivers/gpu/nova-core/firmware/gsp.rs
>> +++ b/drivers/gpu/nova-core/firmware/gsp.rs
>> @@ -127,7 +127,7 @@ pub(crate) struct GspFirmware {
>> /// Size in bytes of the firmware contained in [`Self::fw`].
>> pub size: usize,
>> /// Device-mapped GSP signatures matching the GPU's [`Chipset`].
>> - signatures: DmaObject,
>> + pub signatures: DmaObject,
>> /// GSP bootloader, verifies the GSP firmware before loading and running it.
>> pub bootloader: RiscvFirmware,
>> }
>> @@ -212,7 +212,6 @@ pub(crate) fn new<'a, 'b>(
>> }))
>> }
>>
>> - #[expect(unused)]
>> /// Returns the DMA handle of the radix3 level 0 page table.
>> pub(crate) fn radix3_dma_handle(&self) -> DmaAddress {
>> self.level0.dma_handle()
>> diff --git a/drivers/gpu/nova-core/firmware/riscv.rs b/drivers/gpu/nova-core/firmware/riscv.rs
>> index b90acfc81e78..dec33d2b631a 100644
>> --- a/drivers/gpu/nova-core/firmware/riscv.rs
>> +++ b/drivers/gpu/nova-core/firmware/riscv.rs
>> @@ -53,11 +53,11 @@ fn new(bin_fw: &BinFirmware<'_>) -> Result<Self> {
>> #[expect(unused)]
>> pub(crate) struct RiscvFirmware {
>> /// Offset at which the code starts in the firmware image.
>> - code_offset: u32,
>> + pub code_offset: u32,
>> /// Offset at which the data starts in the firmware image.
>> - data_offset: u32,
>> + pub data_offset: u32,
>> /// Offset at which the manifest starts in the firmware image.
>> - manifest_offset: u32,
>> + pub manifest_offset: u32,
>> /// Application version.
>> app_version: u32,
>> /// Device-mapped firmware image.
>> diff --git a/drivers/gpu/nova-core/gsp.rs b/drivers/gpu/nova-core/gsp.rs
>> index 0185f66971ff..2daa46f2a514 100644
>> --- a/drivers/gpu/nova-core/gsp.rs
>> +++ b/drivers/gpu/nova-core/gsp.rs
>> @@ -13,6 +13,7 @@
>> use kernel::ptr::Alignment;
>> use kernel::transmute::{AsBytes, FromBytes};
>>
>> +use crate::fb::FbLayout;
>> use fw::LibosMemoryRegionInitArgument;
>>
>> pub(crate) const GSP_PAGE_SHIFT: usize = 12;
>> diff --git a/drivers/gpu/nova-core/gsp/boot.rs b/drivers/gpu/nova-core/gsp/boot.rs
>> index fb22508128c4..1d2448331d7a 100644
>> --- a/drivers/gpu/nova-core/gsp/boot.rs
>> +++ b/drivers/gpu/nova-core/gsp/boot.rs
>> @@ -1,6 +1,8 @@
>> // SPDX-License-Identifier: GPL-2.0
>>
>> use kernel::device;
>> +use kernel::dma::CoherentAllocation;
>> +use kernel::dma_write;
>> use kernel::pci;
>> use kernel::prelude::*;
>>
>> @@ -14,6 +16,7 @@
>> FIRMWARE_VERSION,
>> };
>> use crate::gpu::Chipset;
>> +use crate::gsp::GspFwWprMeta;
>> use crate::regs;
>> use crate::vbios::Vbios;
>>
>> @@ -132,6 +135,10 @@ pub(crate) fn boot(
>> bar,
>> )?;
>>
>> + let wpr_meta =
>> + CoherentAllocation::<GspFwWprMeta>::alloc_coherent(dev, 1, GFP_KERNEL | __GFP_ZERO)?;
>> + dma_write!(wpr_meta[0] = GspFwWprMeta::new(&gsp_fw, &fb_layout))?;
>
> Not something I think we need to block this series on, but this line does make
> me wonder if we should have a variant of dma_write!() that uses
> CoherentAllocation::write(), since I think that would actually be faster then
> calling dma_write!() here.
Can you elaborate a bit on this idea? Would it be faster because it uses
a non-volatile write in this case?
On a related note, I wish we could make all these accesses to
single-instance coherent allocations non-fallible, as this is a pattern
we use often in Nova and the only thing that can fail is
`item_from_index`, which we know at build-time is valid as we are
accessing the first element.
So if we enforced a rule that `count` must be >= 0 in
`CoherentAllocation::alloc_attrs` (which is not currently enforced but
would make sense imho), we could maybe add a new variant to
`dma_read/write` that matches a non-indexed expression, and makes a
non-fallible access to the first element of the allocation? How does
that sound?
Or we could also introduce a new type for single-instance allocations if
that makes more sense.
next prev parent reply other threads:[~2025-09-26 1:24 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 [this message]
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
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=DD2C8MKHDRCA.1XRV8RNPCXAN7@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=lyude@redhat.com \
--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 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.