mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Joel Fernandes" <joelagnelf@nvidia.com>,
	<linux-kernel@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>, <dakr@kernel.org>,
	<acourbot@nvidia.com>
Cc: "Alistair Popple" <apopple@nvidia.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>, <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>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>, <joel@joelfernandes.org>,
	<nouveau@lists.freedesktop.org>,
	"Nouveau" <nouveau-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v2 07/12] nova-core: Implement the GSP sequencer
Date: Mon, 10 Nov 2025 22:43:36 +0900	[thread overview]
Message-ID: <DE5256UCJHXU.27RS8A445Z1XN@nvidia.com> (raw)
In-Reply-To: <20251102235920.3784592-8-joelagnelf@nvidia.com>

Hi Joel,

I guess you will want to rebase the series on top of the GSP boot v9,
for fixing the conflicts with the imports, squash patch 13 where it
should belong, and also because it adds a few things that should
simplify this patch.

As a general comment, the structures and their members could benefit
from short doccomments (thankfully after this review there should be a
few less :)).

On Mon Nov 3, 2025 at 8:59 AM JST, Joel Fernandes wrote:
<snip>
> diff --git a/drivers/gpu/nova-core/gsp/sequencer.rs b/drivers/gpu/nova-core/gsp/sequencer.rs
> new file mode 100644
> index 000000000000..48c40140876b
> --- /dev/null
> +++ b/drivers/gpu/nova-core/gsp/sequencer.rs
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! GSP Sequencer implementation for Pre-hopper GSP boot sequence.
> +
> +use core::mem::size_of;
> +use kernel::alloc::flags::GFP_KERNEL;
> +use kernel::device;
> +use kernel::prelude::*;
> +use kernel::time::Delta;
> +use kernel::transmute::FromBytes;
> +
> +use crate::driver::Bar0;
> +use crate::falcon::{
> +    gsp::Gsp,
> +    sec2::Sec2,
> +    Falcon, //
> +};
> +use crate::firmware::gsp::GspFirmware;
> +use crate::gsp::cmdq::{
> +    Cmdq,
> +    MessageFromGsp, //
> +};
> +use crate::gsp::fw;
> +
> +use kernel::{
> +    dev_dbg,
> +    dev_err, //
> +};
> +
> +impl MessageFromGsp for fw::rpc_run_cpu_sequencer_v17_00 {
> +    const FUNCTION: fw::MsgFunction = fw::MsgFunction::GspRunCpuSequencer;
> +}
> +
> +const CMD_SIZE: usize = size_of::<fw::GSP_SEQUENCER_BUFFER_CMD>();
> +
> +struct GspSequencerInfo<'a> {
> +    info: &'a fw::rpc_run_cpu_sequencer_v17_00,
> +    cmd_data: KVec<u8>,
> +}
> +
> +/// GSP Sequencer Command types with payload data.
> +/// Commands have an opcode and a opcode-dependent struct.
> +#[allow(dead_code)]
> +pub(crate) enum GspSeqCmd {}
> +
> +impl GspSeqCmd {
> +    /// Creates a new GspSeqCmd from a firmware GSP_SEQUENCER_BUFFER_CMD.
> +    pub(crate) fn from_fw_cmd(_cmd: &fw::GSP_SEQUENCER_BUFFER_CMD) -> Result<Self> {
> +        Err(EINVAL)
> +    }
> +
> +    pub(crate) fn new(data: &[u8], dev: &device::Device<device::Bound>) -> Result<Self> {
> +        let fw_cmd = fw::GSP_SEQUENCER_BUFFER_CMD::from_bytes(data).ok_or(EINVAL)?;
> +        let cmd = Self::from_fw_cmd(fw_cmd)?;
> +
> +        if data.len() < cmd.size_bytes() {
> +            dev_err!(dev, "data is not enough for command.\n");
> +            return Err(EINVAL);
> +        }
> +
> +        Ok(cmd)
> +    }
> +
> +    /// Get the size of this command in bytes, the command consists of
> +    /// a 4-byte opcode, and a variable-sized payload.
> +    pub(crate) fn size_bytes(&self) -> usize {
> +        0
> +    }

Instead of having this (which involves another dedicated match
statement), how about having the `new` method return the size in bytes
that are read, that the caller can add to its cursor?

> +}
> +
> +#[expect(dead_code)]
> +pub(crate) struct GspSequencer<'a> {
> +    seq_info: GspSequencerInfo<'a>,
> +    bar: &'a Bar0,
> +    sec2_falcon: &'a Falcon<Sec2>,
> +    gsp_falcon: &'a Falcon<Gsp>,
> +    libos_dma_handle: u64,
> +    gsp_fw: &'a GspFirmware,

`gsp_fw` seems to be only needed to obtain the bootloader app version -
let's store that information directly instead a reference to a whole
structure we don't need.

> +    dev: &'a device::Device<device::Bound>,

Since this is only used for logging purposes, we don't need a bound
device. This can be an `ARef<device::Device>`, which removes a
reference.

> +}
> +
> +pub(crate) trait GspSeqCmdRunner {
> +    fn run(&self, sequencer: &GspSequencer<'_>) -> Result;
> +}
> +
> +impl GspSeqCmdRunner for GspSeqCmd {
> +    fn run(&self, _seq: &GspSequencer<'_>) -> Result {
> +        Ok(())
> +    }
> +}
> +
> +pub(crate) struct GspSeqIter<'a> {
> +    cmd_data: &'a [u8],
> +    current_offset: usize, // Tracking the current position.
> +    total_cmds: u32,
> +    cmds_processed: u32,
> +    dev: &'a device::Device<device::Bound>,
> +}
> +
> +impl<'a> Iterator for GspSeqIter<'a> {
> +    type Item = Result<GspSeqCmd>;
> +
> +    fn next(&mut self) -> Option<Self::Item> {
> +        // Stop if we've processed all commands or reached the end of data.
> +        if self.cmds_processed >= self.total_cmds || self.current_offset >= self.cmd_data.len() {
> +            return None;
> +        }
> +
> +        // Check if we have enough data for opcode.
> +        let opcode_size = size_of::<fw::GSP_SEQ_BUF_OPCODE>();
> +        if self.current_offset + opcode_size > self.cmd_data.len() {

`opcode_size` looks superfluous as it is only used once.

> +            return Some(Err(EINVAL));

Should probably be `EIO` as the data is not the expected size.

> +        }
> +
> +        let offset = self.current_offset;
> +
> +        // Handle command creation based on available data,
> +        // zero-pad if necessary (since last command may not be full size).
> +        let mut buffer = [0u8; CMD_SIZE];
> +        let copy_len = if offset + CMD_SIZE <= self.cmd_data.len() {
> +            CMD_SIZE
> +        } else {
> +            self.cmd_data.len() - offset
> +        };
> +        buffer[..copy_len].copy_from_slice(&self.cmd_data[offset..offset + copy_len]);
> +        let cmd_result = GspSeqCmd::new(&buffer, self.dev);
> +
> +        cmd_result.map_or_else(
> +            |_err| {
> +                dev_err!(self.dev, "Error parsing command at offset {}", offset);
> +                None
> +            },

This looks a bit redundant: we are processing errors here, but then we
also have another error handler in the caller (the one that says "Error
running command..."). I'm pretty sure there is room for simplification
here.

> +            |cmd| {
> +                self.current_offset += cmd.size_bytes();
> +                self.cmds_processed += 1;
> +                Some(Ok(cmd))
> +            },
> +        )
> +    }
> +}
> +
> +impl<'a, 'b> IntoIterator for &'b GspSequencer<'a> {
> +    type Item = Result<GspSeqCmd>;
> +    type IntoIter = GspSeqIter<'b>;
> +
> +    fn into_iter(self) -> Self::IntoIter {
> +        let cmd_data = &self.seq_info.cmd_data[..];
> +
> +        GspSeqIter {
> +            cmd_data,
> +            current_offset: 0,
> +            total_cmds: self.seq_info.info.cmdIndex,
> +            cmds_processed: 0,
> +            dev: self.dev,
> +        }
> +    }
> +}

You can do without this implementation by just having an `iter` method
returning the iterator where appropriate (in the current version this
would be `GspSequencer`, but I suggest moving that to the
`GspSequencerInfo/GspSequence`).


  reply	other threads:[~2025-11-10 13:43 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02 23:59 [PATCH v2 00/12] nova-core: Complete GSP boot and begin RPC communication Joel Fernandes
2025-11-02 23:59 ` [PATCH v2 01/12] nova-core: falcon: Move waiting until halted to a helper Joel Fernandes
2025-11-05 23:12   ` Lyude Paul
2025-11-02 23:59 ` [PATCH v2 02/12] nova-core: falcon: Move start functionality into separate helper Joel Fernandes
2025-11-05 23:13   ` Lyude Paul
2025-11-02 23:59 ` [PATCH v2 03/12] nova-core: falcon: Move mbox functionalities into helper Joel Fernandes
2025-11-05 23:16   ` Lyude Paul
2025-11-02 23:59 ` [PATCH v2 04/12] nova-core: falcon: Move dma_reset functionality " Joel Fernandes
2025-11-05 23:16   ` Lyude Paul
2025-11-02 23:59 ` [PATCH v2 05/12] nova-core: gsp: Add support for checking if GSP reloaded Joel Fernandes
2025-11-05 23:18   ` Lyude Paul
2025-11-05 23:29     ` John Hubbard
2025-11-06  0:26     ` Alexandre Courbot
2025-11-02 23:59 ` [PATCH v2 06/12] nova-core: Add bindings required by GSP sequencer Joel Fernandes
2025-11-05 23:23   ` Lyude Paul
2025-11-10 13:39   ` Alexandre Courbot
2025-11-11 22:06     ` Joel Fernandes
2025-11-12  1:12       ` Alexandre Courbot
2025-11-12  2:53         ` Joel Fernandes
2025-11-02 23:59 ` [PATCH v2 07/12] nova-core: Implement the " Joel Fernandes
2025-11-10 13:43   ` Alexandre Courbot [this message]
2025-11-11 22:51     ` Joel Fernandes
2025-11-11 23:02     ` Joel Fernandes
2025-11-12  0:42       ` Alexandre Courbot
2025-11-12  2:57         ` Joel Fernandes
2025-11-02 23:59 ` [PATCH v2 08/12] nova-core: sequencer: Add register opcodes Joel Fernandes
2025-11-05  2:50   ` John Hubbard
2025-11-05  3:45     ` Joel Fernandes
2025-11-05 16:30       ` Timur Tabi
2025-11-05 21:55         ` John Hubbard
2025-11-05 23:19           ` Timur Tabi
2025-11-05 23:27             ` John Hubbard
2025-11-10 15:16             ` Joel Fernandes
2025-11-10 15:16               ` Joel Fernandes
2025-11-10 16:59                 ` Steven Rostedt
2025-11-10 17:09                   ` Joel Fernandes
2025-11-11 18:42               ` Lyude Paul
2025-11-12  0:45                 ` Alexandre Courbot
2025-11-10 13:50   ` Alexandre Courbot
2025-11-11 23:39     ` Joel Fernandes
2025-11-02 23:59 ` [PATCH v2 09/12] nova-core: sequencer: Add delay opcode support Joel Fernandes
2025-11-10 13:51   ` Alexandre Courbot
2025-11-02 23:59 ` [PATCH v2 10/12] nova-core: sequencer: Implement basic core operations Joel Fernandes
2025-11-11 19:04   ` Lyude Paul
2025-11-02 23:59 ` [PATCH v2 11/12] nova-core: sequencer: Implement core resume operation Joel Fernandes
2025-11-02 23:59 ` [PATCH v2 12/12] gpu: nova-core: gsp: Wait for gsp initialization to complete Joel Fernandes
2025-11-10 13:51   ` Alexandre Courbot
2025-11-03 19:12 ` [PATCH v2 00/12] nova-core: Complete GSP boot and begin RPC communication Timur Tabi
2025-11-03 19:35   ` Joel Fernandes
2025-11-03 19:54     ` Timur Tabi
2025-11-04 23:26   ` [PATCH v2 13/12] nova-core: sequencer: Refactor run() to handle unknown messages Joel Fernandes
2025-11-10 13:52     ` Alexandre Courbot
2025-11-06 23:11   ` [PATCH v3 00/14] nova-core: Complete GSP boot and begin RPC communication Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 01/14] gpu: nova-core: falcon: Move waiting until halted to a helper Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 02/14] gpu: nova-core: falcon: Move start functionality into separate helper Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 03/14] gpu: nova-core: falcon: Move mbox functionalities into helper Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 04/14] gpu: nova-core: falcon: Move dma_reset functionality " Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 05/14] gpu: nova-core: gsp: Add support for checking if GSP reloaded Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 06/14] gpu: nova-core: Add bindings required by GSP sequencer Joel Fernandes
2025-11-11 21:43       ` Lyude Paul
2025-11-13  0:48         ` Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 07/14] gpu: nova-core: Implement the " Joel Fernandes
2025-11-11 20:57       ` Lyude Paul
2025-11-13  1:24         ` Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 08/14] gpu: nova-core: sequencer: Add register opcodes Joel Fernandes
2025-11-11 21:09       ` Lyude Paul
2025-11-06 23:11     ` [PATCH v3 09/14] gpu: nova-core: sequencer: Add delay opcode support Joel Fernandes
2025-11-11 21:11       ` Lyude Paul
2025-11-06 23:11     ` [PATCH v3 10/14] gpu: nova-core: sequencer: Implement basic core operations Joel Fernandes
2025-11-11 21:12       ` Lyude Paul
2025-11-13  0:49         ` Joel Fernandes
2025-11-06 23:11     ` [PATCH v3 11/14] gpu: nova-core: sequencer: Implement core resume operation Joel Fernandes
2025-11-11 21:44       ` Lyude Paul
2025-11-06 23:11     ` [PATCH v3 12/14] gpu: nova-core: gsp: Wait for gsp initialization to complete Joel Fernandes
2025-11-11 21:47       ` Lyude Paul
2025-11-06 23:11     ` [PATCH v3 13/14] gpu: nova-core: sequencer: Refactor run() to handle unknown messages Joel Fernandes
2025-11-11 21:49       ` Lyude Paul
2025-11-06 23:11     ` [PATCH v3 14/14] gpu: nova-core: gsp: Retrieve GSP static info to gather GPU information Joel Fernandes
2025-11-11 22:02       ` Lyude Paul
2025-11-12 20:22         ` Joel Fernandes
2025-11-12 20:35           ` Joel Fernandes
2025-11-06  2:06 ` [PATCH v2 00/12] nova-core: Complete GSP boot and begin RPC communication John Hubbard
2025-11-11 20:24 ` Lyude Paul

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=DE5256UCJHXU.27RS8A445Z1XN@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=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joel@joelfernandes.org \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau-bounces@lists.freedesktop.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    /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

all inboxes | Powered by JetHome®