Re: [PATCH v6 00/15] gpu: nova-core: gsp: prepare the command queue for r000 dual-message types

[Alexandre Courbot]

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@xxxxxxxxxx/
>> 
>> Signed-off-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
>> ---
>> 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@xxxxxxxxxx
>
> 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.