Re: [PATCH v3 10/33] gpu: nova-core: add GMC send path

[Alexandre Courbot]

On Fri Sep 18, 2026 at 10:06 AM JST, John Hubbard wrote:
> The r000 boot protocol has the driver send GSP_INIT, the request that
> carries the driver's configuration to GSP-RM, as a GMC command. GMC and
> RPC commands share the command queue and the RPC sequence counter, and
> a GMC element, unlike an RPC element, carries no checksum.
>
> Nova-core's send path filled in RPC elements only, so there was no way
> to send a GMC command.
>
> Add a send path for GMC commands. It has no caller yet. A following
> patch adds the GSP_INIT sender.
>
> Assisted-by: LLM
> Reviewed-by: Timur Tabi <ttabi@xxxxxxxxxx>
> Reviewed-by: Zhi Wang <zhiw@xxxxxxxxxx>
> Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx>
> ---
>  drivers/gpu/nova-core/gsp/cmdq.rs | 43 +++++++++++++++++++++++++++++++
>  drivers/gpu/nova-core/gsp/fw.rs   |  1 -
>  2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs b/drivers/gpu/nova-core/gsp/cmdq.rs
> index a1c9b7cce255..c0c3d8596b30 100644
> --- a/drivers/gpu/nova-core/gsp/cmdq.rs
> +++ b/drivers/gpu/nova-core/gsp/cmdq.rs
> @@ -54,6 +54,7 @@
>      driver::Bar0,
>      gsp::{
>          fw::{
> +            GspGmcMsgElement,
>              GspMsgElement,
>              MsgFunction,
>              MsgqRxHeader,
> @@ -749,6 +750,48 @@ fn poison(&self, reason: fmt::Arguments<'_>) -> Error {
>          EIO
>      }
>  
> +    /// Sends a GMC API request to the GSP.
> +    ///
> +    /// `payload` follows the GMC API header in the element, and `max_response_size` is the largest
> +    /// response that the caller accepts. The request carries the next sequence number, which GSP-RM
> +    /// copies into its response. The number is consumed even if the send fails.
> +    ///
> +    /// # Errors
> +    ///
> +    /// Errors from [`DmaGspMem::allocate_command`] are propagated as-is.
> +    #[expect(dead_code)]
> +    fn send_gmc(&mut self, command_id: u32, payload: &[u8], max_response_size: u32) -> Result {

This is basically a mirror of `send_command` for GMC commands (or rather
`send_single_command` since GMC appears to not have split commands).

Only it's not quite as good: `send_command` is generic over its
`command` using the `CommandToGsp` trait, which is nice as it
establishes a relationship between commands and their expected
responses. The GMC counterparts completely dismantle that and work with
raw `u32`s, even though it would benefit even more from having
structure, as I see later that each command (hard to tell though since
we only have one at the moment) seems to have their own maximum response
size, which could be an associated constant.

Looking down the series at `gsp_init`, it passes both the expected
command ID and a function to decode the response to `await_gmc_response`
from a dedicated helper, whereas RPCs just need to call `send_command*`
and know whether to wait for a response, and how to decode it just
through their type. That GMC is unable to function similarly is a
serious step back.

I also want to understand whether we need to keep using RPC alongside
GMC, because by the end of this series RPC is still there as dead code
(except maybe for GSP events?) and if this code is here to stay then we
need to factor out the send paths a bit more than that, and separate the
two mechanisms more clearly.

Because right now both `cmdq.rs` and `fw.rs` have types and methods for
handling both mixed together and that's quite messy. So if both are to
coexist we should have `gmc` and `rpc` sub-modules to keep them properly
separated.