public inbox for rust-for-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Timur Tabi" <ttabi@nvidia.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"Eliot Courtney" <ecourtney@nvidia.com>,
	"John Hubbard" <jhubbard@nvidia.com>,
	<rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH 5/6] gpu: nova-core: skip the IFR header if present
Date: Mon, 13 Apr 2026 13:53:52 +0900	[thread overview]
Message-ID: <DHRRBHH7VJGB.2JGN9MQRRVQ6Q@nvidia.com> (raw)
In-Reply-To: <20260410203722.1586938-6-ttabi@nvidia.com>

On Sat Apr 11, 2026 at 5:37 AM JST, Timur Tabi wrote:
> The GPU's ROM may begin with an Init-from-ROM (IFR) header that precedes
> the PCI Expansion ROM images (VBIOS).  When present, the PROM shadow
> method must parse this header to determine the offset where the PCI ROM
> images actually begin, and adjust all subsequent reads accordingly.
>
> On most GPUs this is not needed because the IFR microcode has already
> applied the ROM offset so that PROM reads transparently skip the header.
> On GA100, for whatever reason, the IFR offset is not applied to PROM
> reads.  Therefore, the search for the PCI expansion must skip the IFR
> header, if found.

I like this commit message a lot because it made it really easy for me
to understand why we are doing this. Could we concisely put a comment in
the code as well explaining why it's necessary?

>
> Signed-off-by: Timur Tabi <ttabi@nvidia.com>
> ---
>  drivers/gpu/nova-core/vbios.rs | 39 +++++++++++++++++++++++++++++++++-
>  1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/nova-core/vbios.rs b/drivers/gpu/nova-core/vbios.rs
> index e726594eb130..a7ec68448a4a 100644
> --- a/drivers/gpu/nova-core/vbios.rs
> +++ b/drivers/gpu/nova-core/vbios.rs
> @@ -89,13 +89,50 @@ struct VbiosIterator<'a> {
>      last_found: bool,
>  }
>  
> +/// IFR signature: ASCII "NVGI" as a little-endian u32.
> +const IFR_SIGNATURE: u32 = 0x4947564E;
> +/// ROM directory signature: ASCII "RFRD" as a little-endian u32.
> +const ROM_DIRECTORY_SIGNATURE: u32 = 0x44524652;

I wonder if we can use the bindings for some of these constants,
including the fixed value offsets below. I found these values in OpenRM
in dev_bus.h, for example (but it was in tu102 so even though the values
are the same not sure if it's semantically correct):

```
#define NV_PBUS_IFR_FMT_FIXED0                        0x00000000 /*       */
#define NV_PBUS_IFR_FMT_FIXED0_SIGNATURE                    31:0 /*       */
#define NV_PBUS_IFR_FMT_FIXED0_SIGNATURE_VALUE        0x4947564E /*       */
#define NV_PBUS_IFR_FMT_FIXED1                        0x00000004 /*       */
#define NV_PBUS_IFR_FMT_FIXED1_VERSIONSW                    15:8 /*       */
#define NV_PBUS_IFR_FMT_FIXED1_FIXED_DATA_SIZE             30:16 /*       */
#define NV_PBUS_IFR_FMT_FIXED2                        0x00000008 /*       */
#define NV_PBUS_IFR_FMT_FIXED2_TOTAL_DATA_SIZE              19:0 /*       */
```

Unfortunately IIUC we can't use the bitfield range specifies via
bindgen, but the FIXEDX offsets and some of the signature values might
be doable via bindings. WDYT?

> +
>  impl<'a> VbiosIterator<'a> {
>      fn new(dev: &'a device::Device, bar0: &'a Bar0) -> Result<Self> {
> +        let sig = bar0.try_read32(ROM_OFFSET)?;
> +
> +        let current_offset = if sig == IFR_SIGNATURE {
> +            let fixed1 = bar0.try_read32(ROM_OFFSET + 4)?;
> +            let version = ((fixed1 >> 8) & 0xff) as u8;
> +
> +            match version {
> +                // Note: We do not actually expect to see v1 or v2 on these GPUs
> +                1 | 2 => {
> +                    let fixed_data_size = ((fixed1 >> 16) & 0x7fff) as usize;
> +                    bar0.try_read32(ROM_OFFSET + fixed_data_size + 4)? as usize

Should this be an error instead if we don't expect to see it?

> +                }
> +                3 => {
> +                    let fixed2 = bar0.try_read32(ROM_OFFSET + 8)?;
> +                    let total_data_size = (fixed2 & 0x000f_ffff) as usize;

What about using the bitfield! macro to define bitfields for these
things? e.g.

```
bitfield! {
    struct IfrFixed1(u32) {
        15:8 version as u8;
        30:16 fixed_data_size as u16;
    }
}

bitfield! {
    struct IfrFixed2(u32) {
        19:0 total_data_size as u32;
    }
}
```

> +                    let dir_offset = bar0.try_read32(ROM_OFFSET + total_data_size)? as usize + 4096;

What about making an inline constant for 4096?

> +                    let dir_sig = bar0.try_read32(ROM_OFFSET + dir_offset)?;
> +                    if dir_sig != ROM_DIRECTORY_SIGNATURE {
> +                        dev_err!(dev, "could not find IFR ROM directory\n");
> +                        return Err(EINVAL);
> +                    }
> +                    bar0.try_read32(ROM_OFFSET + dir_offset + 8)? as usize
> +                }
> +                _ => {
> +                    dev_err!(dev, "unsupported IFR header version {}\n", version);
> +                    return Err(EINVAL);
> +                }
> +            }
> +        } else {
> +            0
> +        };
> +
>          Ok(Self {
>              dev,
>              bar0,
>              data: KVec::new(),
> -            current_offset: 0,
> +            current_offset,
>              last_found: false,
>          })
>      }


  reply	other threads:[~2026-04-13  4:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-10 20:37 [PATCH 0/6] gpu: nova-core: add GA100 support Timur Tabi
2026-04-10 20:37 ` [PATCH 1/6] gpu: nova-core: use correct fwsignature for GA100 Timur Tabi
2026-04-13  4:10   ` Eliot Courtney
2026-04-10 20:37 ` [PATCH 2/6] gpu: nova-core: do not consider 0xBB77 as a valid PCI ROM header signature Timur Tabi
2026-04-13  4:11   ` Eliot Courtney
2026-04-10 20:37 ` [PATCH 3/6] gpu: nova-core: only boot FRTS if it actually exists Timur Tabi
2026-04-13  4:19   ` Eliot Courtney
2026-04-13 19:49     ` Timur Tabi
2026-04-13 23:48       ` Timur Tabi
2026-04-14 18:10         ` Timur Tabi
2026-04-15  2:35           ` Eliot Courtney
2026-04-10 20:37 ` [PATCH 4/6] gpu: nova-core: add FbHal::frts_size() for GA100 support Timur Tabi
2026-04-14  1:04   ` Alexandre Courbot
2026-04-14  3:13     ` Timur Tabi
2026-04-14  6:03       ` Alexandre Courbot
2026-04-10 20:37 ` [PATCH 5/6] gpu: nova-core: skip the IFR header if present Timur Tabi
2026-04-13  4:53   ` Eliot Courtney [this message]
2026-04-14 20:42     ` Timur Tabi
2026-04-10 20:37 ` [PATCH 6/6] gpu: nova-core: enable GA100 Timur Tabi
2026-04-13  4:20   ` Eliot Courtney

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=DHRRBHH7VJGB.2JGN9MQRRVQ6Q@nvidia.com \
    --to=ecourtney@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=ttabi@nvidia.com \
    /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