From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "John Hubbard" <jhubbard@nvidia.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>
Cc: "Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Shashank Sharma" <shashanks@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, "David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"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" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
nova-gpu@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v12 15/22] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure
Date: Tue, 02 Jun 2026 21:21:17 +0900 [thread overview]
Message-ID: <DIYK5AGFFHSP.3PVP7YX854KWN@nvidia.com> (raw)
In-Reply-To: <20260602032111.224790-16-jhubbard@nvidia.com>
On Tue Jun 2, 2026 at 12:21 PM JST, John Hubbard wrote:
> FSP communication uses a pair of non-circular queues in the FSP
> falcon's EMEM, one for messages from the driver to FSP and one for
> replies, with the driver polling for response data. Add the queue
> registers and the low-level helpers used by the higher-level FSP
> message layer.
>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> drivers/gpu/nova-core/falcon/fsp.rs | 61 ++++++++++++++++++++++++++++-
> drivers/gpu/nova-core/regs.rs | 21 ++++++++++
> 2 files changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/falcon/fsp.rs b/drivers/gpu/nova-core/falcon/fsp.rs
> index 6b057d958115..0ec1c55213bc 100644
> --- a/drivers/gpu/nova-core/falcon/fsp.rs
> +++ b/drivers/gpu/nova-core/falcon/fsp.rs
> @@ -112,7 +112,6 @@ impl Falcon<Fsp> {
> ///
> /// `data` is interpreted as little-endian 32-bit words. Returns `EINVAL`
> /// if `offset` or the `data` length is not 4-byte aligned.
> - #[expect(dead_code)]
> fn write_emem(&mut self, bar: &Bar0, offset: u32, data: &[u8]) -> Result {
> if offset % 4 != 0 || data.len() % 4 != 0 {
> return Err(EINVAL);
> @@ -131,7 +130,6 @@ fn write_emem(&mut self, bar: &Bar0, offset: u32, data: &[u8]) -> Result {
> ///
> /// `data` is stored as little-endian 32-bit words. Returns `EINVAL` if
> /// `offset` or the `data` length is not 4-byte aligned.
> - #[expect(dead_code)]
> fn read_emem(&mut self, bar: &Bar0, offset: u32, data: &mut [u8]) -> Result {
> if offset % 4 != 0 || data.len() % 4 != 0 {
> return Err(EINVAL);
> @@ -145,4 +143,63 @@ fn read_emem(&mut self, bar: &Bar0, offset: u32, data: &mut [u8]) -> Result {
>
> Ok(())
> }
> +
> + /// Poll FSP for incoming data.
> + ///
> + /// Returns the size of available data in bytes, or 0 if no data is available.
> + ///
> + /// The FSP message queue is not circular. Pointers are reset to 0 after each
> + /// message exchange, so `tail >= head` is always true when data is present.
> + #[expect(dead_code)]
> + pub(crate) fn poll_msgq(&self, bar: &Bar0) -> u32 {
> + let head = bar.read(regs::NV_PFSP_MSGQ_HEAD).address();
> + let tail = bar.read(regs::NV_PFSP_MSGQ_TAIL).address();
> +
> + if head == tail {
> + return 0;
> + }
> +
> + // TAIL points at last DWORD written, so add 4 to get total size
> + tail.saturating_sub(head) + 4
> + }
In a later patch, `send_sync_fsp` polls this then calls `recv_msg`. But,
structurally it's possible to pass in any size to `recv_msg` and read
more than we are supposed to. What about having `recv_msg` do the
polling to get the size and return a KVec with the read out data,
instead of `send_sync_fsp`? `poll_msgq` could stay private and we can
make it public later if we need to.
> +
> + /// Writes `packet` to FSP EMEM and updates the queue pointers to notify FSP.
> + ///
> + /// Returns `EINVAL` if `packet` is empty or its length is not 4-byte aligned.
> + #[expect(dead_code)]
> + pub(crate) fn send_msg(&mut self, bar: &Bar0, packet: &[u8]) -> Result {
> + if packet.is_empty() {
> + return Err(EINVAL);
> + }
> +
> + // Write message to EMEM at offset 0 (validates 4-byte alignment)
> + self.write_emem(bar, 0, packet)?;
> +
> + // Update queue pointers. TAIL points at the last DWORD written.
> + let tail_offset = u32::try_from(packet.len() - 4).map_err(|_| EINVAL)?;
> + bar.write_reg(regs::NV_PFSP_QUEUE_TAIL::zeroed().with_address(tail_offset));
> + bar.write_reg(regs::NV_PFSP_QUEUE_HEAD::zeroed().with_address(0));
> +
> + Ok(())
> + }
> +
> + /// Reads `size` bytes from FSP EMEM into `buffer` and resets the queue pointers.
> + ///
> + /// `size` comes from `poll_msgq`. Returns `EINVAL` if `size` is 0, exceeds
> + /// `buffer`, or is not 4-byte aligned.
> + #[expect(dead_code)]
> + pub(crate) fn recv_msg(&mut self, bar: &Bar0, buffer: &mut [u8], size: usize) -> Result {
> + if size == 0 || size > buffer.len() {
> + return Err(EINVAL);
> + }
> +
> + // Read response from EMEM at offset 0 (validates 4-byte alignment)
> + self.read_emem(bar, 0, &mut buffer[..size])?;
> +
> + // Reset message queue pointers after reading
> + bar.write_reg(regs::NV_PFSP_MSGQ_TAIL::zeroed().with_address(0));
> + bar.write_reg(regs::NV_PFSP_MSGQ_HEAD::zeroed().with_address(0));
> +
> + Ok(())
> + }
I think we can remove the `size` argument and have the caller pass in
an appropriately sized slice (altho obviated by my other comment).
next prev parent reply other threads:[~2026-06-02 12:21 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 3:20 [PATCH v12 00/22] gpu: nova-core: firmware: Hopper/Blackwell support John Hubbard
2026-06-02 3:20 ` [PATCH v12 01/22] gpu: nova-core: set DMA mask width based on GPU architecture John Hubbard
2026-06-02 6:40 ` Eliot Courtney
2026-06-02 3:20 ` [PATCH v12 02/22] gpu: nova-core: Hopper/Blackwell: new location for PCI config mirror John Hubbard
2026-06-02 3:20 ` [PATCH v12 03/22] gpu: nova-core: Blackwell: compute PMU-reserved framebuffer size John Hubbard
2026-06-02 3:20 ` [PATCH v12 04/22] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap John Hubbard
2026-06-02 3:20 ` [PATCH v12 05/22] gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heap John Hubbard
2026-06-02 3:20 ` [PATCH v12 06/22] gpu: nova-core: Blackwell: use correct sysmem flush registers John Hubbard
2026-06-02 3:30 ` sashiko-bot
2026-06-02 8:00 ` Alexandre Courbot
2026-06-02 7:12 ` Eliot Courtney
2026-06-02 8:26 ` Alexandre Courbot
2026-06-02 3:20 ` [PATCH v12 07/22] gpu: nova-core: don't assume 64-bit firmware images John Hubbard
2026-06-02 3:20 ` [PATCH v12 08/22] gpu: nova-core: add support for 32-bit " John Hubbard
2026-06-02 3:20 ` [PATCH v12 09/22] gpu: nova-core: add auto-detection of 32-bit, 64-bit " John Hubbard
2026-06-02 3:20 ` [PATCH v12 10/22] gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stub John Hubbard
2026-06-02 6:50 ` Eliot Courtney
2026-06-02 3:20 ` [PATCH v12 11/22] gpu: nova-core: Hopper/Blackwell: add FMC firmware image John Hubbard
2026-06-02 7:18 ` Eliot Courtney
2026-06-02 3:21 ` [PATCH v12 12/22] gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waiting John Hubbard
2026-06-02 7:56 ` Eliot Courtney
2026-06-02 8:22 ` Alexandre Courbot
2026-06-02 3:21 ` [PATCH v12 13/22] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction John Hubbard
2026-06-02 3:32 ` sashiko-bot
2026-06-02 7:56 ` Alexandre Courbot
2026-06-02 8:11 ` Eliot Courtney
2026-06-02 8:28 ` Alexandre Courbot
2026-06-03 0:04 ` Timur Tabi
2026-06-03 0:20 ` Alexandre Courbot
2026-06-03 3:09 ` Timur Tabi
2026-06-03 3:53 ` John Hubbard
2026-06-03 16:52 ` Timur Tabi
2026-06-02 3:21 ` [PATCH v12 14/22] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations John Hubbard
2026-06-02 11:42 ` Eliot Courtney
2026-06-02 14:55 ` Alexandre Courbot
2026-06-02 15:02 ` Alexandre Courbot
2026-06-02 3:21 ` [PATCH v12 15/22] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure John Hubbard
2026-06-02 3:33 ` sashiko-bot
2026-06-03 1:14 ` Alexandre Courbot
2026-06-03 1:41 ` Eliot Courtney
2026-06-02 12:21 ` Eliot Courtney [this message]
2026-06-03 1:34 ` Alexandre Courbot
2026-06-03 4:49 ` Eliot Courtney
2026-06-03 5:00 ` Alexandre Courbot
2026-06-03 1:00 ` Alexandre Courbot
2026-06-02 3:21 ` [PATCH v12 16/22] gpu: nova-core: add MCTP/NVDM protocol types for firmware communication John Hubbard
2026-06-02 5:36 ` sashiko-bot
2026-06-03 2:41 ` Alexandre Courbot
2026-06-02 12:53 ` Eliot Courtney
2026-06-02 3:21 ` [PATCH v12 17/22] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging John Hubbard
2026-06-02 3:35 ` sashiko-bot
2026-06-02 3:21 ` [PATCH v12 18/22] gpu: nova-core: Hopper/Blackwell: select FSP Chain of Trust version John Hubbard
2026-06-02 12:55 ` Eliot Courtney
2026-06-02 3:21 ` [PATCH v12 19/22] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot John Hubbard
2026-06-02 3:40 ` sashiko-bot
2026-06-03 5:23 ` Alexandre Courbot
2026-06-03 5:19 ` Alexandre Courbot
2026-06-02 3:21 ` [PATCH v12 20/22] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling John Hubbard
2026-06-02 3:38 ` sashiko-bot
2026-06-03 5:45 ` Alexandre Courbot
2026-06-02 3:21 ` [PATCH v12 21/22] gpu: nova-core: add non-sec2 unload path John Hubbard
2026-06-02 3:21 ` [PATCH v12 22/22] gpu: nova-core: gsp: enable FSP boot path John Hubbard
2026-06-02 3:38 ` sashiko-bot
2026-06-02 12:38 ` [PATCH v12 00/22] gpu: nova-core: firmware: Hopper/Blackwell support Danilo Krummrich
2026-06-02 13:37 ` 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=DIYK5AGFFHSP.3PVP7YX854KWN@nvidia.com \
--to=ecourtney@nvidia.com \
--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=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.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=ojeda@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.