From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: "gary@garyguo.net" <gary@garyguo.net>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"dakr@kernel.org" <dakr@kernel.org>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"John Hubbard" <jhubbard@nvidia.com>,
"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v5 4/6] gpu: nova-core: add FbHal::frts_size() for GA100 support
Date: Tue, 21 Apr 2026 10:22:34 +0900 [thread overview]
Message-ID: <DHYFU2313OZG.3RBEJ64S9R2OC@nvidia.com> (raw)
In-Reply-To: <a6bdeca9dd144a50cb59169f20833c1dc70ea700.camel@nvidia.com>
On Tue Apr 21, 2026 at 6:15 AM JST, Timur Tabi wrote:
> On Mon, 2026-04-20 at 21:27 +0100, Gary Guo wrote:
>>
>> Ah, I see, so this is what the "supports_display" refers to in the commit
>> message?
>
> Kinda. It refers to this FbHal function:
>
> /// Returns `true` is display is supported.
> fn supports_display(&self, bar: &Bar0) -> bool;
>
> It reads an arch-specific register to determine whether display is "supported". There is no
> register that tells us "needs FRTS", and so that's why frts_size() exists.
>
>> > So I guess what I'm really trying to say is that I've done a lot of research into how this code
>> > works, and it's written the way I wrote it for a reason.
>> >
>> > As for using a Trait to define a default value that is just overridden by GA100, that would be
>> > okay,
>> > but it wouldn't be any clearer or more accurate.
>> >
>> > I personally don't like `super::tu102::frts_size_tu102()` and I think both tu102::frts_size()
>> > and
>> > ga102::frts_size() should just return u64::SZ_1M, but I don't care enough to make a stink about
>> > it.
>>
>> Thanks, that's a very good explanation how the reason the code is written as is.
>> With the information above, I'm happy with current approach.
>>
>> Acked-by: Gary Guo <gary@garyguo.net>
>
> Thanks.
>
>> I think it's important to note that not all of us have knowledge (or even
>> access) to some of the context that you have, so something that may seem obvious
>> to you could require some additional background or reasons to be added in commit
>> message or comment.
>
> Unfortunately, the process to boot GSP-RM is so convoluted that it's not really possible to document
> everything publicly. A lot of it just porting OpenRM (and to some degree Nouveau) to Rust and
> saying "Well, this is how it is". In fact, it's much easier to mimic OpenRM than it is to actually
> read the internal documentation to figure out what to do.
>
>> Also, in the commit message you mentioned
>>
>> > Introduce FbHal method frts_size() to return the size of the FRTS
>> > window. GA100 is a special case in that there is no FRTS, and so
>> > the size must be set to 0.
>>
>> and this probably should be corrected.
>
> Ugh, I thought I caught all of these.
>
> Alex, if you wouldn't mind, change that last sentence to:
>
> "GA100 is a special case in that although there is an FRTS, its size must arbitrarily be set to 0."
Sure, I've fixed it on my staging branch.
With this last point cleared, you can consider this series merged as I
will push it as soon as drm-rust-next reopens. It also makes the
Blackwell series a bit smoother, so I'm happy we can push it first!
>
>
> If you update to the latest git, you can use the new "git history" command:
> https://github.blog/open-source/git/highlights-from-git-2-54/
Thanks for the pointer, I do commit log edits *a lot* and this is
definitely going to help!
next prev parent reply other threads:[~2026-04-21 1:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 19:13 [PATCH v5 0/6] gpu: nova-core: add GA100 support Timur Tabi
2026-04-17 19:13 ` [PATCH v5 1/6] gpu: nova-core: use correct fwsignature for GA100 Timur Tabi
2026-04-19 19:34 ` Gary Guo
2026-04-17 19:13 ` [PATCH v5 2/6] gpu: nova-core: do not consider 0xBB77 as a valid PCI ROM header signature Timur Tabi
2026-04-19 19:36 ` Gary Guo
2026-04-17 19:13 ` [PATCH v5 3/6] gpu: nova-core: only boot FRTS if its region is allocated Timur Tabi
2026-04-19 19:36 ` Gary Guo
2026-04-17 19:13 ` [PATCH v5 4/6] gpu: nova-core: add FbHal::frts_size() for GA100 support Timur Tabi
2026-04-19 19:47 ` Gary Guo
2026-04-20 1:28 ` Alexandre Courbot
2026-04-20 10:23 ` Gary Guo
2026-04-20 12:50 ` Alexandre Courbot
2026-04-20 17:51 ` Timur Tabi
2026-04-20 20:27 ` Gary Guo
2026-04-20 21:15 ` Timur Tabi
2026-04-21 1:22 ` Alexandre Courbot [this message]
2026-04-17 19:13 ` [PATCH v5 5/6] gpu: nova-core: skip the IFR header if present Timur Tabi
2026-04-20 6:37 ` Eliot Courtney
2026-04-17 19:13 ` [PATCH v5 6/6] gpu: nova-core: enable GA100 Timur Tabi
2026-04-19 19:36 ` Gary Guo
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=DHYFU2313OZG.3RBEJ64S9R2OC@nvidia.com \
--to=acourbot@nvidia.com \
--cc=dakr@kernel.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=ttabi@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