kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/gpu/nova-core/fb.rs

272 lines
8.2 KiB
Raw Normal View History

gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: apply the one "use" item per line policy As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>
2025-11-06 18:10:06 -08:00
gpu: nova-core: fb: use dma::CoherentHandle Replace the nova-core local `DmaObject` with a `CoherentHandle` that can fulfill the same role. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-5-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-27 00:22:11 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: convert PDISP registers to kernel register macro Convert all PDISP registers to use the kernel's register macro and update the code accordingly. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260325-b4-nova-register-v4-7-bdf172f0f6ca@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-25 11:46:20 +09:00
gpu: nova-core: apply the one "use" item per line policy As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>
2025-11-06 18:10:06 -08:00
gpu: nova-core: replace ARef<Device> with &'bound Device in SysmemFlush Now that SysmemFlush is lifetime-parameterized, the ARef<Device> is unnecessary -- a plain &'bound Device reference suffices. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:31 +02:00
gpu: nova-core: apply the one "use" item per line policy As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>
2025-11-06 18:10:06 -08:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: apply the one "use" item per line policy As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>
2025-11-06 18:10:06 -08:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: apply the one "use" item per line policy As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>
2025-11-06 18:10:06 -08:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: use SizeConstants trait for u64 size constants Replace manual usize-to-u64 conversions of SZ_* constants with the SizeConstants trait's associated constants on u64. With the SizeConstants trait in scope, u64::SZ_1M replaces usize_as_u64(SZ_1M) and similar. This removes several now-unused imports: usize_as_u64, FromSafeCast, and individual SZ_* type-level constants. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260411024118.471294-2-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-10 19:41:17 -07:00
gpu: nova-core: apply the one "use" item per line policy As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.com>
2025-11-06 18:10:06 -08:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: Clarify sysmembar operations sysmembar is a critical operation that the GSP falcon needs to perform in the reset sequence. Add some code comments to clarify. [acourbot@nvdidia.com: move relevant documentation to SysmemFlush type] Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250708-nova-docs-v4-2-9d188772c4c7@nvidia.com [ Minor grammar fix in the PFB register documentation. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-07-08 15:49:42 +09:00
gpu: nova-core: unregister sysmem flush page from Drop Now that SysmemFlush can borrow the Bar via HRT lifetime, store a &'bound Bar0 reference and implement Drop to automatically unregister the sysmem flush page. This removes the need for manual unregister() calls and the Gpu::unbind() method. Reported-by: Eliot Courtney <ecourtney@nvidia.com> Closes: https://lore.kernel.org/all/20260409-fix-systemflush-v1-1-a1d6c968f17c@nvidia.com/ Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page") Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:30 +02:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: replace ARef<Device> with &'bound Device in SysmemFlush Now that SysmemFlush is lifetime-parameterized, the ARef<Device> is unnecessary -- a plain &'bound Device reference suffices. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:31 +02:00
gpu: nova-core: move lifetime to `Bar0` Currently Nova code uses `&'a Bar0` a lot. This is `&'a Mmio`, where `Mmio` represents an owned MMIO region; this type only exists as a target for `Deref` so `Bar` and `IoMem` can share code and should be avoided to be named directly. The upcoming I/O projection series would make `Io` trait much simpler to implement, and thus the owned MMIO type would be removed in favour of direct `Io` implementation on `Bar` and `IoMem`. Add lifetime parameter to `Bar0<'a>` and change it to be alias of `&'a pci::Bar<'a, ..>`. This also prepares Nova core so that when I/O projection series land, this could be changed to using a MMIO view type directly which avoids double indirection. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602170416.2268531-1-gary@kernel.org [ Rebase onto latest drm-rust-next (Blackwell enablement). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-02 18:04:07 +01:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: fb: use dma::CoherentHandle Replace the nova-core local `DmaObject` with a `CoherentHandle` that can fulfill the same role. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-5-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-27 00:22:11 +09:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: unregister sysmem flush page from Drop Now that SysmemFlush can borrow the Bar via HRT lifetime, store a &'bound Bar0 reference and implement Drop to automatically unregister the sysmem flush page. This removes the need for manual unregister() calls and the Gpu::unbind() method. Reported-by: Eliot Courtney <ecourtney@nvidia.com> Closes: https://lore.kernel.org/all/20260409-fix-systemflush-v1-1-a1d6c968f17c@nvidia.com/ Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page") Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:30 +02:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: replace ARef<Device> with &'bound Device in SysmemFlush Now that SysmemFlush is lifetime-parameterized, the ARef<Device> is unnecessary -- a plain &'bound Device reference suffices. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:31 +02:00
gpu: nova-core: move lifetime to `Bar0` Currently Nova code uses `&'a Bar0` a lot. This is `&'a Mmio`, where `Mmio` represents an owned MMIO region; this type only exists as a target for `Deref` so `Bar` and `IoMem` can share code and should be avoided to be named directly. The upcoming I/O projection series would make `Io` trait much simpler to implement, and thus the owned MMIO type would be removed in favour of direct `Io` implementation on `Bar` and `IoMem`. Add lifetime parameter to `Bar0<'a>` and change it to be alias of `&'a pci::Bar<'a, ..>`. This also prepares Nova core so that when I/O projection series land, this could be changed to using a MMIO view type directly which avoids double indirection. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602170416.2268531-1-gary@kernel.org [ Rebase onto latest drm-rust-next (Blackwell enablement). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-02 18:04:07 +01:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: fb: use dma::CoherentHandle Replace the nova-core local `DmaObject` with a `CoherentHandle` that can fulfill the same role. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-5-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-27 00:22:11 +09:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: replace ARef<Device> with &'bound Device in SysmemFlush Now that SysmemFlush is lifetime-parameterized, the ARef<Device> is unnecessary -- a plain &'bound Device reference suffices. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:31 +02:00
gpu: nova-core: unregister sysmem flush page from Drop Now that SysmemFlush can borrow the Bar via HRT lifetime, store a &'bound Bar0 reference and implement Drop to automatically unregister the sysmem flush page. This removes the need for manual unregister() calls and the Gpu::unbind() method. Reported-by: Eliot Courtney <ecourtney@nvidia.com> Closes: https://lore.kernel.org/all/20260409-fix-systemflush-v1-1-a1d6c968f17c@nvidia.com/ Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page") Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:30 +02:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: unregister sysmem flush page from Drop Now that SysmemFlush can borrow the Bar via HRT lifetime, store a &'bound Bar0 reference and implement Drop to automatically unregister the sysmem flush page. This removes the need for manual unregister() calls and the Gpu::unbind() method. Reported-by: Eliot Courtney <ecourtney@nvidia.com> Closes: https://lore.kernel.org/all/20260409-fix-systemflush-v1-1-a1d6c968f17c@nvidia.com/ Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page") Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:30 +02:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: unregister sysmem flush page from Drop Now that SysmemFlush can borrow the Bar via HRT lifetime, store a &'bound Bar0 reference and implement Drop to automatically unregister the sysmem flush page. This removes the need for manual unregister() calls and the Gpu::unbind() method. Reported-by: Eliot Courtney <ecourtney@nvidia.com> Closes: https://lore.kernel.org/all/20260409-fix-systemflush-v1-1-a1d6c968f17c@nvidia.com/ Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page") Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:30 +02:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: unregister sysmem flush page from Drop Now that SysmemFlush can borrow the Bar via HRT lifetime, store a &'bound Bar0 reference and implement Drop to automatically unregister the sysmem flush page. This removes the need for manual unregister() calls and the Gpu::unbind() method. Reported-by: Eliot Courtney <ecourtney@nvidia.com> Closes: https://lore.kernel.org/all/20260409-fix-systemflush-v1-1-a1d6c968f17c@nvidia.com/ Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page") Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260525225838.276108-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-26 00:58:30 +02:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: add missing newlines to several print strings Although the dev_xx!() macro calls do not technically require terminating newlines for the format strings, they should be added anyway to maintain consistency, both within Rust code and with the C versions. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260107201647.2490140-2-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-07 14:16:47 -06:00
gpu: nova-core: register sysmem flush page Reserve a page of system memory so sysmembar can perform a read on it if a system write occurred since the last flush. Do this early as it can be required to e.g. reset the GPU falcons. Chipsets capabilities differ in that respect, so this commit also introduces the FB HAL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-14-ecf41ef99252@nvidia.com [ * Use kernel::page::PAGE_SIZE instead of kernel::bindings::PAGE_SIZE. * Get rid of the Option for SysmemFlush. * Slightly reword SysmemFlush doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:23:58 +09:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: add FbRange.len() and use it in boot.rs A tiny simplification: now that FbLayout uses its own specific FbRange type, add an FbRange.len() method, and use that to (very slightly) simplify the calculation of Frts::frts_size initialization. Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-3-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:52 -07:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: add FbRange.len() and use it in boot.rs A tiny simplification: now that FbLayout uses its own specific FbRange type, add an FbRange.len() method, and use that to (very slightly) simplify the calculation of Frts::frts_size initialization. Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-3-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:52 -07:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: use SizeConstants trait for u64 size constants Replace manual usize-to-u64 conversions of SZ_* constants with the SizeConstants trait's associated constants on u64. With the SizeConstants trait in scope, u64::SZ_1M replaces usize_as_u64(SZ_1M) and similar. This removes several now-unused imports: usize_as_u64, FromSafeCast, and individual SZ_* type-level constants. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260411024118.471294-2-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-10 19:41:17 -07:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: use SizeConstants trait for u64 size constants Replace manual usize-to-u64 conversions of SZ_* constants with the SizeConstants trait's associated constants on u64. With the SizeConstants trait in scope, u64::SZ_1M replaces usize_as_u64(SZ_1M) and similar. This removes several now-unused imports: usize_as_u64, FromSafeCast, and individual SZ_* type-level constants. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260411024118.471294-2-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-10 19:41:17 -07:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: Blackwell: compute PMU-reserved framebuffer size GSP boot needs to know how much framebuffer memory is reserved for the PMU. Compute it per architecture: Blackwell dGPUs reserve a non-zero amount, earlier architectures leave it at zero, matching Open RM behavior. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-4-jhubbard@nvidia.com Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-01 20:20:51 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: move lifetime to `Bar0` Currently Nova code uses `&'a Bar0` a lot. This is `&'a Mmio`, where `Mmio` represents an owned MMIO region; this type only exists as a target for `Deref` so `Bar` and `IoMem` can share code and should be avoided to be named directly. The upcoming I/O projection series would make `Io` trait much simpler to implement, and thus the owned MMIO type would be removed in favour of direct `Io` implementation on `Bar` and `IoMem`. Add lifetime parameter to `Bar0<'a>` and change it to be alias of `&'a pci::Bar<'a, ..>`. This also prepares Nova core so that when I/O projection series land, this could be changed to using a MMIO view type directly which avoids double indirection. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602170416.2268531-1-gary@kernel.org [ Rebase onto latest drm-rust-next (Blackwell enablement). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-02 18:04:07 +01:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: use SizeConstants trait for u64 size constants Replace manual usize-to-u64 conversions of SZ_* constants with the SizeConstants trait's associated constants on u64. With the SizeConstants trait in scope, u64::SZ_1M replaces usize_as_u64(SZ_1M) and similar. This removes several now-unused imports: usize_as_u64, FromSafeCast, and individual SZ_* type-level constants. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260411024118.471294-2-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-10 19:41:17 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: convert PDISP registers to kernel register macro Convert all PDISP registers to use the kernel's register macro and update the code accordingly. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260325-b4-nova-register-v4-7-bdf172f0f6ca@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-25 11:46:20 +09:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: use SizeConstants trait for u64 size constants Replace manual usize-to-u64 conversions of SZ_* constants with the SizeConstants trait's associated constants on u64. With the SizeConstants trait in scope, u64::SZ_1M replaces usize_as_u64(SZ_1M) and similar. This removes several now-unused imports: usize_as_u64, FromSafeCast, and individual SZ_* type-level constants. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260411024118.471294-2-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-10 19:41:17 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: use Alignment for alignment-related operations Make use of the newly-available `Alignment` type and remove the corresponding TODO item. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-08 22:25:55 +09:00
gpu: nova-core: add FbHal::frts_size() for GA100 support Introduce FbHal method frts_size() to return the size of the FRTS window. GA100 is a special case in that although there is an FRTS, its size must arbitrarily be set to 0. Note that we cannot use supports_display() to determine the FRTS size because there are other GPUs (e.g. GA102GL) that have display disabled (and so supports_display() returns False), but the FRTS window size still needs to be 1MB. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260417191359.1307434-5-ttabi@nvidia.com [acourbot: apply requested fix to commit message.] [acourbot: fix minor conflict.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-04-17 14:13:57 -05:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: add FbHal::frts_size() for GA100 support Introduce FbHal method frts_size() to return the size of the FRTS window. GA100 is a special case in that although there is an FRTS, its size must arbitrarily be set to 0. Note that we cannot use supports_display() to determine the FRTS size because there are other GPUs (e.g. GA102GL) that have display disabled (and so supports_display() returns False), but the FRTS window size still needs to be 1MB. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260417191359.1307434-5-ttabi@nvidia.com [acourbot: apply requested fix to commit message.] [acourbot: fix minor conflict.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-04-17 14:13:57 -05:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: make WPR heap sizing fallible Make management_overhead() fail on multiplication or alignment overflow instead of silently saturating. Propagate that failure through wpr_heap_size() and the framebuffer layout code that consumes it. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260326013902.588242-27-jhubbard@nvidia.com [acourbot: remove unrelated WPR2 mention from commit log.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-25 18:38:57 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: print FB sizes, along with ranges For convenience of the reader: now you can directly see the sizes of each range. It is surprising just how much this helps. Sample output (using an Ampere GA104): NovaCore 0000:e1:00.0: FbLayout { fb: 0x0..0x3ff800000 (16376 MiB), vga_workspace: 0x3ff700000..0x3ff800000 (1 MiB), frts: 0x3ff600000..0x3ff700000 (1 MiB), boot: 0x3ff5fa000..0x3ff600000 (24 KiB), elf: 0x3fb960000..0x3ff5f9000 (60 MiB), wpr2_heap: 0x3f3900000..0x3fb900000 (128 MiB), wpr2: 0x3f3800000..0x3ff700000 (191 MiB), heap: 0x3f3700000..0x3f3800000 (1 MiB), vf_partition_count: 0x0, } Cc: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260310021125.117855-2-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09 19:10:51 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: Hopper/Blackwell: larger non-WPR heap Hopper and Blackwell need a larger non-WPR heap than the 1 MiB that earlier architectures use. Hopper and Blackwell GB10x need 2 MiB, while Blackwell GB20x needs 2 MiB + 128 KiB. These sizes diverge by family, so give Hopper and each Blackwell family its own framebuffer HAL and select the non-WPR heap size per chipset family. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-5-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-01 20:20:52 -07:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00
gpu: nova-core: compute layout of more framebuffer regions required for GSP Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-10 22:34:09 +09:00
gpu: nova-core: Blackwell: compute PMU-reserved framebuffer size GSP boot needs to know how much framebuffer memory is reserved for the PMU. Compute it per architecture: Blackwell dGPUs reserve a non-zero amount, earlier architectures leave it at zero, matching Open RM behavior. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-4-jhubbard@nvidia.com Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-01 20:20:51 -07:00
gpu: nova-core: compute layout of the FRTS region FWSEC-FRTS is run with the desired address of the FRTS region as parameter, which we need to compute depending on some hardware parameters. Do this in a `FbLayout` structure, that will be later extended to describe more memory regions used to boot the GSP. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250619-nova-frts-v6-20-ecf41ef99252@nvidia.com [ In doc-comment of FbLayout s/bootup process/boot process/ - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-19 22:24:04 +09:00