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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).