From: "Danilo Krummrich" <dakr@kernel.org>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>, nouveau@lists.freedesktop.org
Subject: Re: [PATCH] drm/nouveau/gsp: add support for GA100
Date: Sun, 15 Feb 2026 20:05:09 +0100 [thread overview]
Message-ID: <DGFRQ88IPT2W.2AOQQRWS4BHQY@kernel.org> (raw)
In-Reply-To: <20260209224036.3283326-1-ttabi@nvidia.com>
On Mon Feb 9, 2026 at 11:40 PM CET, Timur Tabi wrote:
> GA100 is a compute-only variant of GA102 that boots GSP-RM like a Turing.
>
> Although architecturally like an Ampere, GA100 uses the same GSP-RM
> firmware files as Turing, and therefore must boot it like Turing does.
> In addition, as a compute-only part, GA100 has no display engine,
> no VBIOS, and no graphics (GR) engine.
>
> Since it doesn't have VBIOS, there is no FWSEC firmware, and so there is
> no FRTS region that needs to be reserved or initialized.
>
> Although Nouveau now supports GA100, there is currently no real support
> for this GPU with either Clover or Rusticl/NVK, as both require a 3D
> engine. This is in contrast with GH100, which does contain a GR engine
> and is supported.
>
> Also note that this patch partially reverts commit e8b3627bec35 ("nouveau:
> don't attempt fwsec on sb on newer platforms."), which added fwsec
> pointers to struct ga100_gsp erroneously.
Can you please also explain the consequences of this? It also very much sounds
like the patch needs a Fixes: tag?
Also can you please use scripts/get_maintainer.pl and send the patch to all
maintainers?
> @@ -343,9 +348,12 @@ tu102_gsp_oneinit(struct nvkm_gsp *gsp)
> if (ret)
> return ret;
>
> - ret = nvkm_gsp_fwsec_frts(gsp);
> - if (WARN_ON(ret))
> - return ret;
> + /* Only boot FWSEC-FRTS if it actually exists */
> + if (gsp->fb.wpr2.frts.size) {
> + ret = nvkm_gsp_fwsec_frts(gsp);
> + if (WARN_ON(ret))
Since we are about to change this, I don't think this should be a WARN_ON().
Most of the error paths within nvkm_gsp_fwsec_frts() already print an error
message with nvkm_error() or use WARN_ON() themselves.
Besides that, I don't think WARN_ON() is the correct tool for this, as we are
not violating some invariant when this fails, it's just a normal runtime error.
Thanks,
Danilo
prev parent reply other threads:[~2026-02-15 19:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 22:40 [PATCH] drm/nouveau/gsp: add support for GA100 Timur Tabi
2026-02-09 22:54 ` John Hubbard
2026-02-15 0:36 ` Dave Airlie
2026-02-15 19:05 ` Danilo Krummrich [this message]
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=DGFRQ88IPT2W.2AOQQRWS4BHQY@kernel.org \
--to=dakr@kernel.org \
--cc=airlied@redhat.com \
--cc=nouveau@lists.freedesktop.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