From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "John Hubbard" <jhubbard@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"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>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, <nova-gpu@lists.linux.dev>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v6 00/15] gpu: nova-core: gsp: prepare the command queue for r000 dual-message types
Date: Wed, 28 Oct 2026 21:28:28 +0900 [thread overview]
Message-ID: <DMGGZF1N5CM8.38XZQHRGOG7UE@nvidia.com> (raw)
In-Reply-To: <c9e88fe3-24da-48bf-8a84-1afe22949021@nvidia.com>
On Wed Oct 28, 2026 at 11:31 AM JST, John Hubbard wrote:
> On 10/27/26 12:35 AM, Alexandre Courbot wrote:
>> The upcoming r000 firmware support [1] introduces a new type of command
>> named GMC alongside the existing and already supported RPC command type.
>>
>> Since RPC was the only command type supported so far, it was embedded
>> into the lowest command queue level: the message header actually
>> includes the RPC header and the code considers them as one.
>>
>> This makes the r000/GMC support difficult to land without a refactor,
>> with the result of transport layer code being duplicated between the two
>> message types, and no clear separation between the RPC and GMC code
>> which are mixed together in the command queue. Merging the code that way
>> would introduce quite some technical debt.
>>
>> Thus, this series prepares a proper landing ground for a new message
>> type by extracting all the RPC layer code and moving it into its own
>> sub-modules, making the `cmdq` module completely agnostic of the type of
>> message it transports.
>>
>> With the transport and message layers properly separated, support for
>> GMC can be added into sibling modules of `rpc`, and the transport layer
>> can be converted once when doing the switch to r000.
>>
>> This moves quite a bit of code around, but most of it is moved verbatim.
>> No significant functional change is intended.
>>
>> For the r000 series, this essentially means the following:
>>
>> - Its patch 7 making `allocate_command` generic can be dropped as the
>> transport layer makes no assumption about the message type.
>> - Patches adding GMC support will do it in dedicated `gmc` sub-modules,
>> following the model set by RPC. These `gmc` sub-modules will start as
>> `dead_code` as they are being built.
>> - The "switch to r000" patch will essentially operate on the transport
>> layer level, i.e. `cmdq.rs`.
>> - There should be no need for extra post-switch RPC fixing, as the
>> transport layer code will already be shared with GMC.
>>
>> Overall, this should make the r000 series much easier to review and
>> eventually land, while not creating new technical debt.
>>
>> This revision fixes the latest nits while addressing a couple more
>> issues found by Sashiko.
>>
>> This series is based on `drm-rust-next`.
>>
>> [1] https://lore.kernel.org/all/20260918010719.1176945-1-jhubbard@nvidia.com/
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> Changes in v6:
>> - Add comment to `consume_element`'s documentation to disambiguate it.
>> (Eliot)
>> - Add a patch to avoid sleeping in `drain` when reaching the end of the
>> queue. (Sashiko)
>> - Fix badly-formatted import block. (Sashiko)
>> - Link to v5: https://patch.msgid.link/20261020-cmdq-rpc-v5-0-dceeb8f360ec@nvidia.com
>
> Hi Alex, looks like it is converging, are you planning to merge soon?
> Or do you need more reviewers to weigh in?
I was planning to give this (hopefully final) a couple days on the list
to check that the r000 rebase on it is viable (which it seems to be!),
so unless someone screams I will merge it very soon.
prev parent reply other threads:[~2026-10-28 12:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 7:35 [PATCH v6 00/15] gpu: nova-core: gsp: prepare the command queue for r000 dual-message types Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 01/15] gpu: nova-core: gsp: cmdq: remove stale comment Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 02/15] gpu: nova-core: gsp: cmdq: simplify framing error description Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 03/15] gpu: nova-core: gsp: cmdq: validate checksum earlier on receive Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 04/15] gpu: nova-core: gsp: introduce and use proper RpcMessageHeader type Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 05/15] gpu: nova-core: gsp: cmdq: group the RPC-specific part of send_single_command Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 06/15] gpu: nova-core: gsp: cmdq: split the transport part of the send path Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 07/15] gpu: nova-core: gsp: cmdq: split RPC parsing part of the receive path Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 08/15] gpu: nova-core: gsp: cmdq: move RPC message logging to RpcMessage Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 09/15] gpu: nova-core: gsp: cmdq: split the transport part of the receive path Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 10/15] gpu: nova-core: gsp: cmdq: extract await_msg_with from await_msg Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 11/15] gpu: nova-core: gsp: cmdq: do not sleep when waiting for a message with timeout 0 Alexandre Courbot
2026-10-27 8:01 ` Eliot Courtney
2026-10-27 7:35 ` [PATCH v6 12/15] gpu: nova-core: gsp: cmdq: use consume_element to implement drain Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 13/15] gpu: nova-core: gsp: cmdq: move the RPC code into a sub-module Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 14/15] gpu: nova-core: gsp: move the RPC commands " Alexandre Courbot
2026-10-27 7:35 ` [PATCH v6 15/15] gpu: nova-core: gsp: add `rpc` to RPC message send/receive methods Alexandre Courbot
2026-10-28 2:31 ` [PATCH v6 00/15] gpu: nova-core: gsp: prepare the command queue for r000 dual-message types John Hubbard
2026-10-28 12:28 ` Alexandre Courbot [this message]
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=DMGGZF1N5CM8.38XZQHRGOG7UE@nvidia.com \
--to=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=ecourtney@nvidia.com \
--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 \
--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.