From: Eliot Courtney <ecourtney@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>,
Alexandre Courbot <acourbot@nvidia.com>,
Alice Ryhl <aliceryhl@google.com>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
Benno Lossin <lossin@kernel.org>, Gary Guo <gary@garyguo.net>
Cc: John Hubbard <jhubbard@nvidia.com>,
Alistair Popple <apopple@nvidia.com>,
Timur Tabi <ttabi@nvidia.com>,
nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
Eliot Courtney <ecourtney@nvidia.com>
Subject: [PATCH v2 00/10] gpu: nova-core: blackwell follow-ups and fixes
Date: Fri, 03 Jul 2026 19:22:04 +0900 [thread overview]
Message-ID: <20260703-blackwell-fixes-v2-0-8e3d8bc32bb9@nvidia.com> (raw)
Several fixes and clean-ups for blackwell related functionality. In
particular:
- FSP communication hardening
- Fix for Coherent allocation lifetime issues during FMC boot
- Convert some raw DMA handle stores into &Coherent stores to help
prevent future issues with the allocation not staying alive long
enough
- Make FbLayout code more obvious and correct
Currently, the frts vidmem offset is calculated based on the non-wpr
heap size and pmu reservation size, but AFAICT this is not right. The
fb layout actually looks like:
| non-wpr heap | WPR2 .. FRTS | PMU reserved | ... | VGA workspace |
It's just by coincidence + generous alignment that the values happened
to match with something more like pmu reserved size + vga workspace.
Originally, I thought it would make sense to use the offset of
FbLayout::frts to compute frts vidmem offset, but actually the offsets
in FbLayout AFAICT don't make sense on post-FSP.
`FbLayout` is used for both pre and post FSP architectures. FbLayout
contains ranges for each region of framebuffer, but on post FSP
architectures, only the size is actually used by GSP. The offsets are
not decided by the driver. So, for post FSP architectures FbLayout
contains essentially guesses for the offsets. Instead, make separate
types so that we only store the information that's actually needed.
This includes the actual reserved size after the pmu reservation so we
can properly compute the frts offset.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
---
Changes in v2:
- Rebased on top of 20260629-nova-bootcontext-v4-0-5539d8469590@nvidia.com
- Dropped applied patches ("falcon: gsp: move PRIV target mask constants"
and "fsp: move FMC firmware loading into wait_secure_boot")
- Dropped "gsp: keep FMC boot params DMA region alive during error" -
will finish discussion/fix on the bootcontext series from Alex
- Drop "fsp: try to enforce exclusive access to FSP channel" as not
necessary.
- Added some extra fixes around the falcon "halted" state
- Drop "wait for FSP boot earlier" since FSP is now at Gpu level in the
bootcontext series from Alex
- Don't reset FSP queue pointers on error
- Add r-b from Alistair
- Return EMSGSIZE not EIO for FSP queue return message too big
- Link to v1: https://patch.msgid.link/20260615-blackwell-fixes-v1-0-f2853e49ff7d@nvidia.com
---
Eliot Courtney (10):
gpu: nova-core: fsp: limit FSP receive message allocation size
gpu: nova-core: fsp: catch bogus queue pointer issues
gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations
gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enough
gpu: nova-core: split FbLayout into FSP and non-FSP versions
gpu: nova-core: correct FRTS vidmem offset calculation
gpu: nova-core: rename heap size field
gpu: nova-core: return non-WPR heap size as u64 from HALs
gpu: nova-core: correct RISC-V HALTED field
gpu: nova-core: wait for RISC-V HALTED on FSP unload
drivers/gpu/nova-core/falcon.rs | 11 ++++
drivers/gpu/nova-core/falcon/fsp.rs | 23 ++++++--
drivers/gpu/nova-core/falcon/hal.rs | 5 ++
drivers/gpu/nova-core/falcon/hal/ga102.rs | 7 +++
drivers/gpu/nova-core/falcon/hal/tu102.rs | 4 ++
drivers/gpu/nova-core/fb.rs | 84 +++++++++++++++++++++++----
drivers/gpu/nova-core/fb/hal.rs | 5 +-
drivers/gpu/nova-core/fb/hal/ga100.rs | 6 +-
drivers/gpu/nova-core/fb/hal/ga102.rs | 6 +-
drivers/gpu/nova-core/fb/hal/gb100.rs | 9 ++-
drivers/gpu/nova-core/fb/hal/gb202.rs | 9 ++-
drivers/gpu/nova-core/fb/hal/gh100.rs | 8 ++-
drivers/gpu/nova-core/fb/hal/tu102.rs | 14 ++++-
drivers/gpu/nova-core/fsp.rs | 70 ++++++++++++++---------
drivers/gpu/nova-core/gsp.rs | 6 +-
drivers/gpu/nova-core/gsp/boot.rs | 26 ++++-----
drivers/gpu/nova-core/gsp/fw.rs | 95 ++++++++++++++++++++++++-------
drivers/gpu/nova-core/gsp/hal.rs | 4 +-
drivers/gpu/nova-core/gsp/hal/gh100.rs | 40 +++++++------
drivers/gpu/nova-core/gsp/hal/tu102.rs | 31 +++++-----
drivers/gpu/nova-core/gsp/sequencer.rs | 18 +++---
drivers/gpu/nova-core/regs.rs | 2 +-
22 files changed, 344 insertions(+), 139 deletions(-)
---
base-commit: a73a398a68ca9b9e5116a617562471f16b8310c4
change-id: 20260608-blackwell-fixes-30c9358c90a0
prerequisite-change-id: 20260619-nova-bootcontext-401d6107e8fb:v4
prerequisite-patch-id: f0a0ce0462acc6881b0255d041605544baf85636
prerequisite-patch-id: 1d7f7da1c7c40eef0b3e522c2a0a4fa00b286bb1
prerequisite-patch-id: 43c5946acdef0a11227b405f6acd3480c7bbb79d
prerequisite-patch-id: 5ebfed11498a63a7e5652a0a4ee50ff4d1a188e0
prerequisite-patch-id: 04f4e5dfde6f418544eae9d44737521bb1ca571b
prerequisite-patch-id: 1ac856805341457a1f54c26a4b0a29ac40f635be
prerequisite-patch-id: 8c16161b095920e6b0c8f6ce40cd209a93437857
prerequisite-patch-id: eedb6aac0de88ef016ccbe5431e7ac723a0b8f23
prerequisite-patch-id: fdfc2db6deecbd77d098bbc8e0f74ad09efa5a3e
prerequisite-patch-id: 923137f8d2664b73dbf55df106816f8edf912f76
prerequisite-patch-id: bf5cf0653180963ccac35495dae05d1f2c8b1d70
prerequisite-patch-id: dfd10bc2d272d344b6746ce3a05c73773b743696
prerequisite-patch-id: 4980eb81d7fd2438bae1b535746795e4eb43725e
Best regards,
--
Eliot Courtney <ecourtney@nvidia.com>
next reply other threads:[~2026-07-03 10:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 10:22 Eliot Courtney [this message]
2026-07-03 10:22 ` [PATCH v2 01/10] gpu: nova-core: fsp: limit FSP receive message allocation size Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 02/10] gpu: nova-core: fsp: catch bogus queue pointer issues Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 03/10] gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 04/10] gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enough Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 05/10] gpu: nova-core: split FbLayout into FSP and non-FSP versions Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 06/10] gpu: nova-core: correct FRTS vidmem offset calculation Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 07/10] gpu: nova-core: rename heap size field Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 08/10] gpu: nova-core: return non-WPR heap size as u64 from HALs Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 09/10] gpu: nova-core: correct RISC-V HALTED field Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 10/10] gpu: nova-core: wait for RISC-V HALTED on FSP unload 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=20260703-blackwell-fixes-v2-0-8e3d8bc32bb9@nvidia.com \
--to=ecourtney@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--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