From: Danilo Krummrich <dakr@kernel.org>
To: Alexandre Courbot <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" <benno.lossin@proton.me>,
"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>,
"Jonathan Corbet" <corbet@lwn.net>,
"John Hubbard" <jhubbard@nvidia.com>,
"Ben Skeggs" <bskeggs@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 17/19] gpu: nova-core: compute layout of the FRTS region
Date: Tue, 13 May 2025 18:41:56 +0200 [thread overview]
Message-ID: <aCN2VIIKYGcVtctN@pollux> (raw)
In-Reply-To: <20250507-nova-frts-v3-17-fcb02749754d@nvidia.com>
On Wed, May 07, 2025 at 10:52:44PM +0900, Alexandre Courbot wrote:
> FWSEC-FRTS is run with the desired address of the FRTS region as
> parameter, which we need to compute depending on some hardware
> parameters.
>
> Do this in a `FbLayout` structure, that will be later extended to
> describe more memory regions used to boot the GSP.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpu/nova-core/gpu.rs | 4 ++
> drivers/gpu/nova-core/gsp.rs | 3 ++
> drivers/gpu/nova-core/gsp/fb.rs | 108 +++++++++++++++++++++++++++++++++++++
> drivers/gpu/nova-core/nova_core.rs | 1 +
> drivers/gpu/nova-core/regs.rs | 27 ++++++++++
> 5 files changed, 143 insertions(+)
>
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index 4bf7f72247e5320935a517270b5a0e1ec2becfec..a3d96639706e808305cce66416778d2bf6e7e683 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -7,6 +7,7 @@
> use crate::driver::Bar0;
> use crate::falcon::{gsp::Gsp, sec2::Sec2, Falcon};
> use crate::firmware::Firmware;
> +use crate::gsp::fb::FbLayout;
> use crate::regs;
> use crate::util;
> use crate::vbios::Vbios;
> @@ -239,6 +240,9 @@ pub(crate) fn new(
>
> let _sec2_falcon = Falcon::<Sec2>::new(pdev.as_ref(), spec.chipset, bar, true)?;
>
> + let fb_layout = FbLayout::new(spec.chipset, bar)?;
> + dev_dbg!(pdev.as_ref(), "{:#x?}\n", fb_layout);
> +
> let _bios = Vbios::new(pdev, bar)?;
>
> Ok(pin_init!(Self {
> diff --git a/drivers/gpu/nova-core/gsp.rs b/drivers/gpu/nova-core/gsp.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..27616a9d2b7069b18661fc97811fa1cac285b8f8
> --- /dev/null
> +++ b/drivers/gpu/nova-core/gsp.rs
> @@ -0,0 +1,3 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +pub(crate) mod fb;
> diff --git a/drivers/gpu/nova-core/gsp/fb.rs b/drivers/gpu/nova-core/gsp/fb.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..f28ded59469d52daf39e5d19c09efd7bf08fee92
> --- /dev/null
> +++ b/drivers/gpu/nova-core/gsp/fb.rs
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +use core::ops::Range;
> +
> +use kernel::prelude::*;
> +
> +use crate::driver::Bar0;
> +use crate::gpu::Chipset;
> +use crate::regs;
> +
> +fn align_down(value: u64, align: u64) -> u64 {
> + value & !(align - 1)
> +}
Can this go in the previous patch, i.e. "rust: num: Add an upward alignment
helper for usize"?
> +
> +/// Layout of the GPU framebuffer memory.
> +///
> +/// Contains ranges of GPU memory reserved for a given purpose during the GSP bootup process.
> +#[derive(Debug)]
> +#[expect(dead_code)]
> +pub(crate) struct FbLayout {
> + pub fb: Range<u64>,
> +
> + pub vga_workspace: Range<u64>,
> + pub bios: Range<u64>,
> +
> + pub frts: Range<u64>,
Please remove the empty lines.
> +}
> +
> +impl FbLayout {
> + pub(crate) fn new(chipset: Chipset, bar: &Bar0) -> Result<Self> {
> + let fb = {
> + let fb_size = vidmem_size(bar, chipset);
> +
> + 0..fb_size
> + };
> + let fb_len = fb.end - fb.start;
Isn't this the same as fb_size? Why not just write it as
let fb_size = vidmem_size(bar, chipset);
let fb = 0..fb_size;
> +
> + let vga_workspace = {
> + let vga_base = vga_workspace_addr(bar, fb_len, chipset);
> +
> + vga_base..fb.end
> + };
> +
> + let bios = vga_workspace.clone();
Why? And why store the same thing twice in FbLayout? If it's really needed,
clone it in the constructor below and add a comment why it's the same.
> +
> + let frts = {
> + const FRTS_DOWN_ALIGN: u64 = 0x20000;
> + const FRTS_SIZE: u64 = 0x100000;
> + let frts_base = align_down(vga_workspace.start, FRTS_DOWN_ALIGN) - FRTS_SIZE;
> +
> + frts_base..frts_base + FRTS_SIZE
> + };
> +
> + Ok(Self {
> + fb,
> + vga_workspace,
> + bios,
> + frts,
> + })
> + }
> +}
I'd probably wrap those helpers below in
mod hal { ... }
or even a new file fb/hal.rs to make their purpose obvious.
> +/// Returns `true` if the display is disabled.
> +fn display_disabled(bar: &Bar0, chipset: Chipset) -> bool {
> + if chipset >= Chipset::GA100 {
> + regs::NV_FUSE_STATUS_OPT_DISPLAY_MAXWELL::read(bar).display_disabled()
> + } else {
> + regs::NV_FUSE_STATUS_OPT_DISPLAY_AMPERE::read(bar).display_disabled()
> + }
> +}
> +
> +/// Returns the video memory size in bytes.
> +fn vidmem_size(bar: &Bar0, chipset: Chipset) -> u64 {
> + if chipset >= Chipset::GA102 {
Is GA102 intentional or should this also be GA100?
> + (regs::NV_PGC6_AON_SECURE_SCRATCH_GROUP_42::read(bar).value() as u64) << 20
Why isn't this shift part of the register abstraction?
> + } else {
> + let local_mem_range = regs::NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE::read(bar);
> + let size =
> + (local_mem_range.lower_mag() as u64) << ((local_mem_range.lower_scale() as u64) + 20);
Same here. Please make this part of the register abstraction as it is done in
previous patches.
> +
> + if local_mem_range.ecc_mode_enabled() {
> + size / 16 * 15
> + } else {
> + size
> + }
> + }
> +}
> +
> +/// Returns the vga workspace address.
> +fn vga_workspace_addr(bar: &Bar0, fb_size: u64, chipset: Chipset) -> u64 {
> + let base = fb_size - 0x100000;
What's this offset? How do you guarantee that this never underflows?
> + let vga_workspace_base = if display_disabled(bar, chipset) {
> + regs::NV_PDISP_VGA_WORKSPACE_BASE::read(bar)
> + } else {
> + return base;
> + };
> +
> + if !vga_workspace_base.status_valid() {
> + return base;
> + }
> +
> + let addr = (vga_workspace_base.addr() as u64) << 16;
Where does this shift come from? Shouldn't this be part of the register
abstraction?
> + if addr < base {
> + fb_size - 0x20000
What's this offset? Can this ever underflow?
> + } else {
> + addr
> + }
> +}
> diff --git a/drivers/gpu/nova-core/nova_core.rs b/drivers/gpu/nova-core/nova_core.rs
> index ff6d0b40c18f36af4c7e2d5c839fdf77dba23321..202e978e56f024de3ae8b178e65b63c2cea244e1 100644
> --- a/drivers/gpu/nova-core/nova_core.rs
> +++ b/drivers/gpu/nova-core/nova_core.rs
> @@ -8,6 +8,7 @@
> mod falcon;
> mod firmware;
> mod gpu;
> +mod gsp;
> mod regs;
> mod util;
> mod vbios;
> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
> index b5c6eeb6ed873a06b4aefcb375f4944eb0b20597..15ec9b7e69694ff198b5353d562fc1aff5eefd3f 100644
> --- a/drivers/gpu/nova-core/regs.rs
> +++ b/drivers/gpu/nova-core/regs.rs
> @@ -53,6 +53,12 @@ pub(crate) fn chipset(self) -> Result<Chipset, Error> {
> 23:0 adr_63_40 as u32;
> });
>
> +register!(NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE @ 0x00100ce0 {
> + 3:0 lower_scale as u8;
> + 9:4 lower_mag as u8;
> + 30:30 ecc_mode_enabled as bool;
> +});
> +
> /* PGC6 */
>
> register!(NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_PRIV_LEVEL_MASK @ 0x00118128 {
> @@ -64,6 +70,27 @@ pub(crate) fn chipset(self) -> Result<Chipset, Error> {
> 31:0 value as u32;
> });
>
> +register!(NV_PGC6_AON_SECURE_SCRATCH_GROUP_42 @ 0x001183a4 {
> + 31:0 value as u32;
> +});
> +
> +/* PDISP */
> +
> +register!(NV_PDISP_VGA_WORKSPACE_BASE @ 0x00625f04 {
> + 3:3 status_valid as bool;
> + 31:8 addr as u32;
> +});
> +
> +/* FUSE */
> +
> +register!(NV_FUSE_STATUS_OPT_DISPLAY_MAXWELL @ 0x00021c04 {
> + 0:0 display_disabled as bool;
> +});
> +
> +register!(NV_FUSE_STATUS_OPT_DISPLAY_AMPERE @ 0x00820c04 {
> + 0:0 display_disabled as bool;
> +});
> +
> /* PFALCON */
>
> register!(NV_PFALCON_FALCON_IRQSCLR @ +0x00000004 {
>
> --
> 2.49.0
>
next prev parent reply other threads:[~2025-05-13 16:42 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 13:52 [PATCH v3 00/19] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 01/19] rust: dma: expose the count and size of CoherentAllocation Alexandre Courbot
2025-05-13 12:15 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 02/19] gpu: nova-core: derive useful traits for Chipset Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 03/19] gpu: nova-core: add missing GA100 definition Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 04/19] gpu: nova-core: take bound device in Gpu::new Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 05/19] gpu: nova-core: define registers layout using helper macro Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 06/19] gpu: nova-core: fix layout of NV_PMC_BOOT_0 Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 07/19] gpu: nova-core: move Firmware to firmware module Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 08/19] rust: make ETIMEDOUT error available Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 09/19] gpu: nova-core: wait for GFW_BOOT completion Alexandre Courbot
2025-05-13 14:07 ` Danilo Krummrich
2025-05-16 12:16 ` Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 10/19] gpu: nova-core: add DMA object struct Alexandre Courbot
2025-05-13 14:25 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 11/19] gpu: nova-core: register sysmem flush page Alexandre Courbot
2025-05-13 14:47 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 12/19] gpu: nova-core: add helper function to wait on condition Alexandre Courbot
2025-05-13 14:50 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 13/19] gpu: nova-core: add falcon register definitions and base code Alexandre Courbot
2025-05-13 16:19 ` Danilo Krummrich
2025-05-16 12:19 ` Alexandre Courbot
2025-05-16 12:26 ` Danilo Krummrich
2025-05-07 13:52 ` [PATCH v3 14/19] gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTS Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 15/19] rust: num: Add an upward alignment helper for usize Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 16/19] nova-core: Add support for VBIOS ucode extraction for boot Alexandre Courbot
2025-05-13 17:19 ` Danilo Krummrich
2025-05-20 7:55 ` Joel Fernandes
2025-05-20 9:30 ` Danilo Krummrich
2025-05-20 13:43 ` Joel Fernandes
2025-05-20 15:01 ` Danilo Krummrich
2025-05-20 15:11 ` Joel Fernandes
2025-05-20 15:36 ` Danilo Krummrich
2025-05-20 16:02 ` Joel Fernandes
2025-05-20 18:13 ` Joel Fernandes
2025-05-20 21:32 ` Dave Airlie
2025-05-21 3:17 ` Joel Fernandes
2025-05-14 16:23 ` Danilo Krummrich
2025-05-19 22:59 ` Joel Fernandes
2025-05-20 7:18 ` Joel Fernandes
2025-05-16 20:38 ` Timur Tabi
2025-05-20 6:35 ` Joel Fernandes
2025-05-07 13:52 ` [PATCH v3 17/19] gpu: nova-core: compute layout of the FRTS region Alexandre Courbot
2025-05-13 16:41 ` Danilo Krummrich [this message]
2025-05-17 13:42 ` Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 18/19] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS Alexandre Courbot
2025-05-14 16:38 ` Danilo Krummrich
2025-05-19 14:24 ` Alexandre Courbot
2025-05-07 13:52 ` [PATCH v3 19/19] gpu: nova-core: load and " Alexandre Courbot
2025-05-14 16:42 ` Danilo Krummrich
2025-05-13 13:10 ` [PATCH v3 00/19] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Danilo Krummrich
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=aCN2VIIKYGcVtctN@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bskeggs@nvidia.com \
--cc=corbet@lwn.net \
--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=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.