From: John Hubbard <jhubbard@nvidia.com>
To: Joel Fernandes <joelagnelf@nvidia.com>,
Eliot Courtney <ecourtney@nvidia.com>
Cc: Danilo Krummrich <dakr@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Alexandre Courbot <acourbot@nvidia.com>,
Simona Vetter <simona@ffwll.ch>,
rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/9] gpu: nova-core: gsp: expose GSP-RM internal client and subdevice handles
Date: Mon, 9 Mar 2026 17:06:38 -0700 [thread overview]
Message-ID: <288fc58b-657c-4e8c-b6bc-d07afe14bb97@nvidia.com> (raw)
In-Reply-To: <2A3368BE-26A8-4F8D-A0F0-F078FCC06CB3@nvidia.com>
On 3/9/26 4:41 PM, Joel Fernandes wrote:
>> On Mar 9, 2026, at 5:22 PM, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>> On Fri, Feb 27, 2026 at 09:32:08PM +0900, Eliot Courtney wrote:
>>> Expose the `hInternalClient` and `hInternalSubdevice` handles. These are
>>> needed for RM control calls.
>>>
>>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>>> ---
>>> drivers/gpu/nova-core/gsp/commands.rs | 16 ++++++++++++++++
>>> drivers/gpu/nova-core/gsp/fw/commands.rs | 10 ++++++++++
>>> 2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/gpu/nova-core/gsp/commands.rs b/drivers/gpu/nova-core/gsp/commands.rs
>>> index 4740cda0b51c..2cadfcaf9a8a 100644
>>> --- a/drivers/gpu/nova-core/gsp/commands.rs
>>> +++ b/drivers/gpu/nova-core/gsp/commands.rs
>>> @@ -197,6 +197,8 @@ fn init(&self) -> impl Init<Self::Command, Self::InitError> {
>>> /// The reply from the GSP to the [`GetGspInfo`] command.
>>> pub(crate) struct GetGspStaticInfoReply {
>>> gpu_name: [u8; 64],
>>> + h_client: u32,
>>> + h_subdevice: u32,
>>
>> I would rather have more descriptive names please. 'client_handle',
Maybe it's better to mirror the Open RM names, which are ancient and
well known in those circles. Changing them at this point is probably
going to result in a slightly worse situation, because there are
probably millions of lines of code out there that use the existing
nomenclature.
However...
>> 'subdevice_handle'. Also some explanation of what a client and a sub-device
>> mean somewhere in the comments or documentation would be nice.
Yes, although I expect you can simply refer to some well known pre-
existing documentation from NVIDAI for that!
>
> Also just checking if we can have repr wrappers around the u32 for clients /
> handles. These concepts are quite common in Nvidia drivers so we should
> probably create new types for them.
>
> And if we can please document the terminology, device, subset, clients handles
> etc. and add new Documentation/ entries even.
>
> Thoughts?
>
This has already been done countless times by countless people I
think, and so we don't need to do it again. Just refer to existing
docs.
btw, as an aside:
I'm checking with our GSP firmware team to be sure, but my
understanding is that much of this is actually very temporary. Because
the GSP team does not want to continue on with this model in which
GSP has to maintain that kind of state: an internal hierarchy of
objects. Instead, they are hoping to move to an API in which nova
would directly refer to each object/item in GSP. And subdevice, in
particular, is an old SLI term that no one wants to keep around
either. It was an ugly hack in Open RM that took more than a decade
to recover from, by moving the SLI concept out to user space.
So even though we should document what we're doing now, I would like
to also note that we suspect a certain amount of this will
disappear, to be replaced with a somewhat simpler API, in the
somewhat near future.
thanks,
--
John Hubbard
next prev parent reply other threads:[~2026-03-10 0:06 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 12:32 [PATCH 0/9] gpu: nova-core: gsp: add RM control command infrastructure Eliot Courtney
2026-02-27 12:32 ` [PATCH 1/9] gpu: nova-core: gsp: add NV_STATUS error code bindings Eliot Courtney
2026-02-27 12:32 ` [PATCH 2/9] gpu: nova-core: gsp: add NvStatus enum for RM control errors Eliot Courtney
2026-02-27 12:32 ` [PATCH 3/9] gpu: nova-core: gsp: expose GSP-RM internal client and subdevice handles Eliot Courtney
2026-03-09 21:22 ` Joel Fernandes
2026-03-09 23:41 ` Joel Fernandes
2026-03-10 0:06 ` John Hubbard [this message]
2026-03-10 2:17 ` Joel Fernandes
2026-03-10 2:29 ` John Hubbard
2026-03-10 18:48 ` Joel Fernandes
2026-03-10 2:36 ` Alexandre Courbot
2026-03-10 4:02 ` Eliot Courtney
2026-03-10 10:35 ` Danilo Krummrich
2026-02-27 12:32 ` [PATCH 4/9] gpu: nova-core: gsp: add RM control RPC structure binding Eliot Courtney
2026-02-27 12:32 ` [PATCH 5/9] gpu: nova-core: gsp: add types for RM control RPCs Eliot Courtney
2026-03-09 21:45 ` Joel Fernandes
2026-03-16 11:42 ` Eliot Courtney
2026-02-27 12:32 ` [PATCH 6/9] gpu: nova-core: generalize `flush_into_kvec` to `flush_into_vec` Eliot Courtney
2026-03-09 21:53 ` Joel Fernandes
2026-03-09 21:57 ` Danilo Krummrich
2026-03-09 22:01 ` Danilo Krummrich
2026-03-16 11:44 ` Eliot Courtney
2026-03-16 12:21 ` Danilo Krummrich
2026-03-17 1:55 ` Alexandre Courbot
2026-03-17 10:49 ` Danilo Krummrich
2026-03-17 13:41 ` Alexandre Courbot
2026-03-17 14:12 ` Danilo Krummrich
2026-03-18 1:52 ` Alexandre Courbot
2026-02-27 12:32 ` [PATCH 7/9] gpu: nova-core: gsp: add RM control command infrastructure Eliot Courtney
2026-03-02 8:00 ` Zhi Wang
2026-03-09 22:08 ` Joel Fernandes
2026-03-13 15:40 ` Danilo Krummrich
2026-03-16 12:06 ` Eliot Courtney
2026-02-27 12:32 ` [PATCH 8/9] gpu: nova-core: gsp: add CE fault method buffer size bindings Eliot Courtney
2026-03-09 22:08 ` Joel Fernandes
2026-02-27 12:32 ` [PATCH 9/9] gpu: nova-core: gsp: add CeGetFaultMethodBufferSize RM control command Eliot Courtney
2026-03-09 22:23 ` Joel Fernandes
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=288fc58b-657c-4e8c-b6bc-d07afe14bb97@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
/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