Re: Tegra notes for Nova: [PATCH v4 18/33] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure

[Alexandre Courbot]

On Sat Feb 21, 2026 at 7:05 AM JST, John Hubbard wrote:
> On 2/17/26 8:28 AM, Danilo Krummrich wrote:
>> On Tue Feb 10, 2026 at 3:45 AM CET, John Hubbard wrote:
>>> +    pub(crate) fn poll_msgq(&self, bar: &Bar0) -> u32 {
>>> +    pub(crate) fn send_msg(&self, bar: &Bar0, packet: &[u8]) -> Result {
>>> +    pub(crate) fn recv_msg(&self, bar: &Bar0, buffer: &mut [u8], size: usize) -> Result<usize> {
>> 
>> Just a quick note, since I just reminded myself on this: We should keep in mind
>> that at some point we have to replace most (if not all) &Bar0 usages with
>> &Mmio<SIZE> as nova-core will also support platform devices.
>> 
>> I think Tegra chips with GSP-based GPU IPs have a compatible register layout,
>> right?
>
> Well...I'd characterize it a little differently. Here are some notes
> from a recent discussion with Tegra, to help shed some light on that:
>
> (+Cc: Vikram Sethi, to keep things accurate.)
>
> Some Tegra chips have a Blackwell iGPU that looks like a PCIe device and
> acts like a PCIe device, and has GSP, just like a dGPU (discrete GPU).
>
> iGPUs don’t have FSP, nor a separate VBIOS, nor even vidmem. So the boot
> sequence for them is different, but only from the first couple of steps
> where SoC root of trust does the work of FSP, and boot skips any vidmem
> related code.
>
> Tegra display is sufficiently different (with several quirky variations
> too) from dGPU that it's an open question whether Nova is even the right
> driver to use for that aspect.

Back in the day (T124/T210), Nouveau was only providing a render node,
with a completely different driver (tegra_drm) driving the display.
Unless the display IP has aligned with that of dGPUs there seems to be
little reason to change that.

Regarding the initial discussion: for layers where the `Bar0`
characterization is not needed, I agree it makes sense to use the lowest
`Io` denominator. We could even consider making that code generic
against `Io`, as it would open the door to things like e.g. emulating
the behavior of some registers for tests that don't require hardware.
Not sure whether we want to go down that path though... :)