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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox