All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "John Hubbard" <jhubbard@nvidia.com>
Cc: "Timur Tabi" <ttabi@nvidia.com>,
	"dakr@kernel.org" <dakr@kernel.org>,
	"a.hindborg@kernel.org" <a.hindborg@kernel.org>,
	"Shashank Sharma" <shashanks@nvidia.com>,
	"boqun.feng@gmail.com" <boqun.feng@gmail.com>,
	"lossin@kernel.org" <lossin@kernel.org>,
	"Zhi Wang" <zhiw@nvidia.com>, "simona@ffwll.ch" <simona@ffwll.ch>,
	"tmgross@umich.edu" <tmgross@umich.edu>,
	"alex.gaynor@gmail.com" <alex.gaynor@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ojeda@kernel.org" <ojeda@kernel.org>,
	"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>,
	"bjorn3_gh@protonmail.com" <bjorn3_gh@protonmail.com>,
	"Eliot Courtney" <ecourtney@nvidia.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"airlied@gmail.com" <airlied@gmail.com>,
	"aliceryhl@google.com" <aliceryhl@google.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"gary@garyguo.net" <gary@garyguo.net>,
	"Alistair Popple" <apopple@nvidia.com>
Subject: Re: [PATCH v10 03/28] gpu: nova-core: Hopper/Blackwell: basic GPU identification
Date: Fri, 17 Apr 2026 16:27:19 +0900	[thread overview]
Message-ID: <DHV935P8FJU1.XZRWWSGFFE8U@nvidia.com> (raw)
In-Reply-To: <8fb6c933-0cad-40b7-be0f-5aea648f56f7@nvidia.com>

On Tue Apr 14, 2026 at 6:29 AM JST, John Hubbard wrote:
> On 4/13/26 2:21 PM, Timur Tabi wrote:
>> On Mon, 2026-04-13 at 14:08 -0700, John Hubbard wrote:
>>>> Can you add something to the patch description that explains why Blackwell, unlike all of the
>>>> olther architectures, is represented by two Architecture enums?
>>>
>>> How's this:
>>>
>>> Blackwell uses two Architecture variants because the hardware itself
>>> exposes two distinct architecture IDs in NV_PMC_BOOT_0: 0x1A for
>
> This is really what drove it, for me, though: the hardware itself
> saw fit to identify these two variants as architectures. It's
> encoded into the very fabric of space-time itself! haha :)
>
>>> GB10x (GB100, GB102) and 0x1B for GB20x (GB202, GB203, GB205, GB206,
>>> GB207). Open RM maps these into separate chip families with distinct
>>> HAL routing and different firmware signature sections.
>> 
>> We don't need two arch's for Ampere to handle different firmware signature sections.  Looking
>> through your patches, the vast majority do this:
>> 
>> 	Architecture::BlackwellGB10x | Architecture::BlackwellGB20x
>> 
>> Looking through your patches, it seems overkill to separate these two.  The one or two instances
>> where it makes a difference, an if-statement will suffice.

I have to agree here, if we didn't split then the architecture IDs
`0x1a` and `0x1b` would need to both map to Blackwell, which makes them
impossible to represent correctly using an enum.

And granted, there are lots of

  `Architecture::BlackwellGB10x | Architecture::BlackwellGB20x`

in the code, but that catches the attention only because the variants
share the same prefix. If `BlackwellGB20x` was named something
completely different, it would go unnoticed (just like we often include
`Ada` in the same match arms as `Blackwell`).

So while it does look a bit strange to have 2 Blackwells, it does
reflect the hardware architecture correctly and doing things differently
would result in more complexity/incorrectness. For instance until v8
there was only a single Blackwell architecture with the ID `0x1b`,
leaving `0x1a` completely unmanaged.

  reply	other threads:[~2026-04-17  7:27 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-11  2:49 [PATCH v10 00/28] gpu: nova-core: firmware: Hopper/Blackwell support John Hubbard
2026-04-11  2:49 ` [PATCH v10 01/28] gpu: nova-core: factor .fwsignature* selection into a new find_gsp_sigs_section() John Hubbard
2026-04-11  2:49 ` [PATCH v10 02/28] gpu: nova-core: use GPU Architecture to simplify HAL selections John Hubbard
2026-04-20 16:06   ` Gary Guo
2026-04-11  2:49 ` [PATCH v10 03/28] gpu: nova-core: Hopper/Blackwell: basic GPU identification John Hubbard
2026-04-11  3:58   ` Timur Tabi
2026-04-13 21:08     ` John Hubbard
2026-04-13 21:21       ` Timur Tabi
2026-04-13 21:29         ` John Hubbard
2026-04-17  7:27           ` Alexandre Courbot [this message]
2026-04-17  7:49             ` Alexandre Courbot
2026-04-20 16:08   ` Gary Guo
2026-04-11  2:49 ` [PATCH v10 04/28] gpu: nova-core: add Copy/Clone to Spec and Revision John Hubbard
2026-04-20 16:17   ` Gary Guo
2026-04-11  2:49 ` [PATCH v10 05/28] gpu: nova-core: set DMA mask width based on GPU architecture John Hubbard
2026-04-20 16:17   ` Gary Guo
2026-04-11  2:49 ` [PATCH v10 06/28] gpu: nova-core: move GFW boot wait into a GPU HAL John Hubbard
2026-04-11  2:49 ` [PATCH v10 07/28] gpu: nova-core: Hopper/Blackwell: skip GFW boot waiting John Hubbard
2026-04-11  2:49 ` [PATCH v10 08/28] gpu: nova-core: Blackwell: calculate reserved FB heap size John Hubbard
2026-04-17 14:23   ` Alexandre Courbot
2026-04-18  1:42     ` John Hubbard
2026-04-20 16:20   ` Gary Guo
2026-04-11  2:49 ` [PATCH v10 09/28] gpu: nova-core: Hopper/Blackwell: new location for PCI config mirror John Hubbard
2026-04-17 14:23   ` Alexandre Courbot
2026-04-18  1:46     ` John Hubbard
2026-04-18  1:54       ` John Hubbard
2026-04-20  3:10         ` Alexandre Courbot
2026-04-11  2:49 ` [PATCH v10 10/28] gpu: nova-core: refactor SEC2 booter loading into BooterFirmware::run() John Hubbard
2026-04-11  2:49 ` [PATCH v10 11/28] gpu: nova-core: Hopper/Blackwell: integrate FSP boot path into boot() John Hubbard
2026-04-17 14:24   ` Alexandre Courbot
2026-04-11  2:49 ` [PATCH v10 12/28] gpu: nova-core: don't assume 64-bit firmware images John Hubbard
2026-04-11  2:49 ` [PATCH v10 13/28] gpu: nova-core: add support for 32-bit " John Hubbard
2026-04-11  2:49 ` [PATCH v10 14/28] gpu: nova-core: add auto-detection of 32-bit, 64-bit " John Hubbard
2026-04-11  2:49 ` [PATCH v10 15/28] gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stub John Hubbard
2026-04-11  2:49 ` [PATCH v10 16/28] gpu: nova-core: Hopper/Blackwell: add FMC firmware image, in support of FSP John Hubbard
2026-04-11  2:49 ` [PATCH v10 17/28] gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waiting John Hubbard
2026-04-17 14:24   ` Alexandre Courbot
2026-04-11  2:49 ` [PATCH v10 18/28] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction John Hubbard
2026-04-17 14:24   ` Alexandre Courbot
2026-04-11  2:49 ` [PATCH v10 19/28] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations John Hubbard
2026-04-11  2:49 ` [PATCH v10 20/28] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure John Hubbard
2026-04-11  2:49 ` [PATCH v10 21/28] gpu: nova-core: add MCTP/NVDM protocol types for firmware communication John Hubbard
2026-04-11  2:49 ` [PATCH v10 22/28] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging John Hubbard
2026-04-11  2:49 ` [PATCH v10 23/28] gpu: nova-core: Hopper/Blackwell: add FspCotVersion type John Hubbard
2026-04-11  2:49 ` [PATCH v10 24/28] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap John Hubbard
2026-04-20  2:52   ` Alexandre Courbot
2026-04-11  2:49 ` [PATCH v10 25/28] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot John Hubbard
2026-04-11  2:49 ` [PATCH v10 26/28] gpu: nova-core: Blackwell: use correct sysmem flush registers John Hubbard
2026-04-20 14:02   ` Alexandre Courbot
2026-04-11  2:49 ` [PATCH v10 27/28] gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heap John Hubbard
2026-04-20  7:02   ` Alexandre Courbot
2026-04-11  2:49 ` [PATCH v10 28/28] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling John Hubbard
2026-04-17 14:34 ` [PATCH v10 00/28] gpu: nova-core: firmware: Hopper/Blackwell support Alexandre Courbot
2026-04-30  1:42 ` Alexandre Courbot

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=DHV935P8FJU1.XZRWWSGFFE8U@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=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=ecourtney@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=shashanks@nvidia.com \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=zhiw@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 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.