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

[John Hubbard]

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.

The register layouts for Tegra iGPUs vs dGPUs have been similar
(remember that similar doesn't mean "the same") since the Kepler GPUs.

thanks,
-- 
John Hubbard

> 
> (I will prepare a patch to address this for the existing codebase.)