From: John Hubbard <jhubbard@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>, Alistair Popple <apopple@nvidia.com>
Cc: nova-gpu@lists.linux.dev, Alice Ryhl <aliceryhl@google.com>,
David Airlie <airlied@gmail.com>,
Alexandre Courbot <acourbot@nvidia.com>,
Benno Lossin <lossin@kernel.org>, Gary Guo <gary@garyguo.net>,
Eliot Courtney <ecourtney@nvidia.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v3 3/7] drm: nova: Add chipid enum to nova-drm UAPI
Date: Tue, 28 Jul 2026 14:49:54 -0700 [thread overview]
Message-ID: <57e2b956-89fd-43e8-8cb3-a15aee272660@nvidia.com> (raw)
In-Reply-To: <DKAIVPSA45O9.1NZES5S3BII10@kernel.org>
On 7/28/26 2:29 PM, Danilo Krummrich wrote:
> On Tue Jul 28, 2026 at 10:00 AM CEST, Alistair Popple wrote:
>> On 2026-07-26 at 01:23 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
>>> On Thu Jul 23, 2026 at 8:30 AM CEST, Alistair Popple wrote:
...
>>> For instance, what's valid for userspace to extract from this? Given chipid is a
>>> composed value, is userspace e.g. allowed to make assumptions on extracting the
>>> architecture? Or is this something we want to expose separately and tell
>>> userspace that the chipid is an opaque value identifying a specific chip only?
>>
>> I _think_ it makes sense for this to just be an opaque value, but it's a good
>> question that I should probably try and get some internal feedback on as well.
>> Reading the arch would then be a separate parameter.
>
> I'd prefer exposing it as an opaque value and provide other information
> separately; the kernel already does the work anyway, so why duplicate it in
> userspace. It would also remain much cleaner if encoding details ever change.
>
Just to orient myself, I'm assuming that by "opaque values", you mean using
something that just counts up from, say, 1, instead of using real boot42
values below, right?
That seems like a good approach to me, too. Because I can't imagine anything
particularly good coming from providing unnecessary details to user space
here. :)
>>>> + /* Turing */
>>>> + NOVA_DRM_CHIPID_TU102 = 0x162,
>>>> + NOVA_DRM_CHIPID_TU104 = 0x164,
>>>> + NOVA_DRM_CHIPID_TU106 = 0x166,
>>>> + NOVA_DRM_CHIPID_TU117 = 0x167,
>>>> + NOVA_DRM_CHIPID_TU116 = 0x168,
>>>> + /* Ampere */
>>>> + NOVA_DRM_CHIPID_GA100 = 0x170,
>>>> + NOVA_DRM_CHIPID_GA102 = 0x172,
>>>> + NOVA_DRM_CHIPID_GA103 = 0x173,
>>>> + NOVA_DRM_CHIPID_GA104 = 0x174,
>>>> + NOVA_DRM_CHIPID_GA106 = 0x176,
>>>> + NOVA_DRM_CHIPID_GA107 = 0x177,
>>>> + /* Hopper */
>>>> + NOVA_DRM_CHIPID_GH100 = 0x180,
>>>> + /* Ada */
>>>> + NOVA_DRM_CHIPID_AD102 = 0x192,
>>>> + NOVA_DRM_CHIPID_AD103 = 0x193,
>>>> + NOVA_DRM_CHIPID_AD104 = 0x194,
>>>> + NOVA_DRM_CHIPID_AD106 = 0x196,
>>>> + NOVA_DRM_CHIPID_AD107 = 0x197,
>>>> + /* Blackwell GB10x */
>>>> + NOVA_DRM_CHIPID_GB100 = 0x1a0,
>>>> + NOVA_DRM_CHIPID_GB102 = 0x1a2,
>>>> + /* Blackwell GB20x */
>>>> + NOVA_DRM_CHIPID_GB202 = 0x1b2,
>>>> + NOVA_DRM_CHIPID_GB203 = 0x1b3,
>>>> + NOVA_DRM_CHIPID_GB205 = 0x1b5,
>>>> + NOVA_DRM_CHIPID_GB206 = 0x1b6,
>>>> + NOVA_DRM_CHIPID_GB207 = 0x1b7,
>>>> +};
>
thanks,
--
John Hubbard
next prev parent reply other threads:[~2026-07-28 21:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 6:30 [PATCH v3 0/7] gpu: nova: Export parameters from nova-core to nova-drm Alistair Popple
2026-07-23 6:30 ` [PATCH v3 1/7] gpu: nova-core: Add public driver API to nova-core Alistair Popple
2026-07-25 15:23 ` Danilo Krummrich
2026-07-23 6:30 ` [PATCH v3 2/7] drm: nova: Add DRM registration data Alistair Popple
2026-07-25 15:23 ` Danilo Krummrich
2026-07-23 6:30 ` [PATCH v3 3/7] drm: nova: Add chipid enum to nova-drm UAPI Alistair Popple
2026-07-25 15:23 ` Danilo Krummrich
2026-07-28 8:00 ` Alistair Popple
2026-07-28 21:29 ` Danilo Krummrich
2026-07-28 21:49 ` John Hubbard [this message]
2026-07-28 22:57 ` Danilo Krummrich
2026-07-29 8:24 ` Alistair Popple
2026-07-23 6:30 ` [PATCH v3 4/7] drm: nova: Add GETPARAM parameter to read the GPU chipid Alistair Popple
2026-07-25 15:23 ` Danilo Krummrich
2026-07-23 6:30 ` [PATCH v3 5/7] drm: nova: Add GETPARAM parameter to read usable VRAM size Alistair Popple
2026-07-23 6:30 ` [PATCH v3 6/7] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter Alistair Popple
2026-07-23 6:30 ` [PATCH v3 7/7] drm: nova: Expose a render node Alistair Popple
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=57e2b956-89fd-43e8-8cb3-a15aee272660@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=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=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
/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