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 08/12] nova-core: sequencer: Add register opcodes
Date: Mon, 10 Nov 2025 22:50:49 +0900 [thread overview]
Message-ID: <DE52APJTD9NN.A41RA78NMNIE@nvidia.com> (raw)
In-Reply-To: <20251102235920.3784592-9-joelagnelf@nvidia.com>
On Mon Nov 3, 2025 at 8:59 AM JST, Joel Fernandes wrote:
> These opcodes are used for register write, modify, poll and store (save)
> sequencer operations.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/gsp/sequencer.rs | 138 +++++++++++++++++++++++--
> 1 file changed, 131 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gsp/sequencer.rs b/drivers/gpu/nova-core/gsp/sequencer.rs
> index 48c40140876b..f429fee01f86 100644
> --- a/drivers/gpu/nova-core/gsp/sequencer.rs
> +++ b/drivers/gpu/nova-core/gsp/sequencer.rs
> @@ -5,6 +5,7 @@
> use core::mem::size_of;
> use kernel::alloc::flags::GFP_KERNEL;
> use kernel::device;
> +use kernel::io::poll::read_poll_timeout;
> use kernel::prelude::*;
> use kernel::time::Delta;
> use kernel::transmute::FromBytes;
> @@ -40,13 +41,36 @@ struct GspSequencerInfo<'a> {
>
> /// GSP Sequencer Command types with payload data.
> /// Commands have an opcode and a opcode-dependent struct.
> -#[allow(dead_code)]
> -pub(crate) enum GspSeqCmd {}
> +#[allow(clippy::enum_variant_names)]
> +pub(crate) enum GspSeqCmd {
> + RegWrite(fw::GSP_SEQ_BUF_PAYLOAD_REG_WRITE),
> + RegModify(fw::GSP_SEQ_BUF_PAYLOAD_REG_MODIFY),
> + RegPoll(fw::GSP_SEQ_BUF_PAYLOAD_REG_POLL),
> + RegStore(fw::GSP_SEQ_BUF_PAYLOAD_REG_STORE),
> +}
>
> 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 from_fw_cmd(cmd: &fw::GSP_SEQUENCER_BUFFER_CMD) -> Result<Self> {
> + match cmd.opCode {
> + fw::GSP_SEQ_BUF_OPCODE_GSP_SEQ_BUF_OPCODE_REG_WRITE => {
> + // SAFETY: We're using the union field that corresponds to the opCode.
> + Ok(GspSeqCmd::RegWrite(unsafe { cmd.payload.regWrite }))
> + }
> + fw::GSP_SEQ_BUF_OPCODE_GSP_SEQ_BUF_OPCODE_REG_MODIFY => {
> + // SAFETY: We're using the union field that corresponds to the opCode.
> + Ok(GspSeqCmd::RegModify(unsafe { cmd.payload.regModify }))
> + }
> + fw::GSP_SEQ_BUF_OPCODE_GSP_SEQ_BUF_OPCODE_REG_POLL => {
> + // SAFETY: We're using the union field that corresponds to the opCode.
> + Ok(GspSeqCmd::RegPoll(unsafe { cmd.payload.regPoll }))
> + }
> + fw::GSP_SEQ_BUF_OPCODE_GSP_SEQ_BUF_OPCODE_REG_STORE => {
> + // SAFETY: We're using the union field that corresponds to the opCode.
> + Ok(GspSeqCmd::RegStore(unsafe { cmd.payload.regStore }))
> + }
I'd rather have these `unsafe` statements in the `fw` module - guess
that's all he more reason to add an abstraction layer there.
> + _ => Err(EINVAL),
> + }
> }
>
> pub(crate) fn new(data: &[u8], dev: &device::Device<device::Bound>) -> Result<Self> {
> @@ -64,7 +88,16 @@ pub(crate) fn new(data: &[u8], dev: &device::Device<device::Bound>) -> Result<Se
> /// 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
> + let opcode_size = size_of::<fw::GSP_SEQ_BUF_OPCODE>();
> + match self {
> + // For commands with payloads, add the payload size in bytes.
> + GspSeqCmd::RegWrite(_) => opcode_size + size_of::<fw::GSP_SEQ_BUF_PAYLOAD_REG_WRITE>(),
> + GspSeqCmd::RegModify(_) => {
> + opcode_size + size_of::<fw::GSP_SEQ_BUF_PAYLOAD_REG_MODIFY>()
> + }
> + GspSeqCmd::RegPoll(_) => opcode_size + size_of::<fw::GSP_SEQ_BUF_PAYLOAD_REG_POLL>(),
> + GspSeqCmd::RegStore(_) => opcode_size + size_of::<fw::GSP_SEQ_BUF_PAYLOAD_REG_STORE>(),
> + }
> }
> }
>
> @@ -83,12 +116,103 @@ pub(crate) trait GspSeqCmdRunner {
> fn run(&self, sequencer: &GspSequencer<'_>) -> Result;
> }
>
> -impl GspSeqCmdRunner for GspSeqCmd {
> - fn run(&self, _seq: &GspSequencer<'_>) -> Result {
> +impl GspSeqCmdRunner for fw::GSP_SEQ_BUF_PAYLOAD_REG_WRITE {
> + fn run(&self, sequencer: &GspSequencer<'_>) -> Result {
> + dev_dbg!(
> + sequencer.dev,
> + "RegWrite: addr=0x{:x}, val=0x{:x}\n",
> + self.addr,
> + self.val
> + );
Per the other feedback I believe you are going to remove these `dev_dbg`
anyway, but since the opcodes derive a `Debug` implementation, you could
have just printed that from the caller for a similar result and no extra
code.
> + let addr = self.addr as usize;
> + let val = self.val;
> + let _ = sequencer.bar.try_write32(val, addr);
> + Ok(())
> + }
> +}
> +
> +impl GspSeqCmdRunner for fw::GSP_SEQ_BUF_PAYLOAD_REG_MODIFY {
> + fn run(&self, sequencer: &GspSequencer<'_>) -> Result {
> + dev_dbg!(
> + sequencer.dev,
> + "RegModify: addr=0x{:x}, mask=0x{:x}, val=0x{:x}\n",
> + self.addr,
> + self.mask,
> + self.val
> + );
> +
> + let addr = self.addr as usize;
> + if let Ok(temp) = sequencer.bar.try_read32(addr) {
> + let _ = sequencer
> + .bar
> + .try_write32((temp & !self.mask) | self.val, addr);
> + }
> Ok(())
> }
> }
>
> +impl GspSeqCmdRunner for fw::GSP_SEQ_BUF_PAYLOAD_REG_POLL {
> + fn run(&self, sequencer: &GspSequencer<'_>) -> Result {
> + dev_dbg!(
> + sequencer.dev,
> + "RegPoll: addr=0x{:x}, mask=0x{:x}, val=0x{:x}, timeout=0x{:x}, error=0x{:x}\n",
> + self.addr,
> + self.mask,
> + self.val,
> + self.timeout,
> + self.error
> + );
> +
> + let addr = self.addr as usize;
> + let mut timeout_us = i64::from(self.timeout);
> +
> + // Default timeout to 4 seconds.
> + timeout_us = if timeout_us == 0 { 4000000 } else { timeout_us };
`let timeout_us = if self.timeout == 0 { 4_000_000 } else {
i64::from(self.timeout)`
(removes the `mut` on `timeout_us`)
> +
> + // First read.
> + sequencer.bar.try_read32(addr)?;
> +
> + // Poll the requested register with requested timeout.
> + read_poll_timeout(
> + || sequencer.bar.try_read32(addr),
> + |current| (current & self.mask) == self.val,
> + Delta::ZERO,
> + Delta::from_micros(timeout_us),
> + )
> + .map(|_| ())
> + }
> +}
> +
> +impl GspSeqCmdRunner for fw::GSP_SEQ_BUF_PAYLOAD_REG_STORE {
> + fn run(&self, sequencer: &GspSequencer<'_>) -> Result {
> + let addr = self.addr as usize;
> + let _index = self.index;
> +
> + let val = sequencer.bar.try_read32(addr)?;
> +
> + dev_dbg!(
> + sequencer.dev,
> + "RegStore: addr=0x{:x}, index=0x{:x}, value={:?}\n",
> + self.addr,
> + self.index,
> + val
> + );
> +
> + Ok(())
> + }
> +}
> +
> +impl GspSeqCmdRunner for GspSeqCmd {
> + fn run(&self, seq: &GspSequencer<'_>) -> Result {
> + match self {
> + GspSeqCmd::RegWrite(cmd) => cmd.run(seq),
> + GspSeqCmd::RegModify(cmd) => cmd.run(seq),
> + GspSeqCmd::RegPoll(cmd) => cmd.run(seq),
> + GspSeqCmd::RegStore(cmd) => cmd.run(seq),
> + }
> + }
> +}
This makes me wonder: do we need to store the deserialized version of
these operands, and make a second `match` on them? How about passing the
`bar` to the deserialization command and have it run the operand
immediately?
next prev parent reply other threads:[~2025-11-10 13:50 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
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 [this message]
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=DE52APJTD9NN.A41RA78NMNIE@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 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.