| Age | Commit message (Collapse) | Author |
|
bar1_size() reports the length of PCI resource 1 as the size of BAR1.
That is only correct when BAR0 is a 32-bit BAR. On Blackwell, and on some
Ampere GA100 and Hopper SKUs, BAR0 is 64-bit and takes resource slots 0
and 1, pushing BAR1 to slot 2. Slot 1 is then the upper half of BAR0
rather than a BAR of its own, so NOVA_GETPARAM_VRAM_BAR_SIZE reports the
wrong size on those GPUs.
Probe handles this with the new bar1_resource_index(), which it uses to
map BAR1, so use the same lookup here.
Fixes: 7edc491f6fca ("drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter")
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20261001005615.77130-1-apopple@nvidia.com
[ Import the driver module. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently nova-drm reads the VRAM BAR size directly from the PCIe device
which requires trying to cast the parent device into a PCIe device. This
obviously requires the parent device to actually be a PCIe bus device.
Whilst that is true today it may not always be the case, and there
is no reason to make this assumption now that NovaCoreApi can hold a
reference to the bound PCIe device.
So convert nova-drm to using nova-core to obtain the VRAM_BAR_SIZE
parameter.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-10-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a field to the GPU info structure containing the total usable
framebuffer size. The usable framebuffer excludes GSP carveouts and
other protected regions, so it may differ from the BAR size and total
physical VRAM.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-9-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add an extensible info ioctl and use it to report basic GPU information.
One of the first things userspace needs to know about a GPU is its
architecture and which chip it is, so add those as the first fields in
the GPU info result. The chip identifier is opaque to userspace and is
only meaningful when compared against the values of enum
drm_nova_chipid.
The ioctl selects an information type by ID and writes the result through
a sized userspace buffer. The kernel truncates results to the supplied
size, allowing information structures to grow and new logical information
groups to be added without introducing new ioctls. Passing a NULL data
pointer returns the size of the requested information structure instead.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-8-apopple@nvidia.com
[ Avoid 'as' casts (add From<Chipset> for u32, From<Architecture> for
u32 and use IntoSafeCast, IntoSafeCastArch); improve / simplify a few
comments. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Nova core will be used to export core functionality to other drivers
which will bind to it via auxiliary bus devices. Add a NovaCoreApi type
which drivers can use to call nova-core methods.
Auxiliary bus drivers obtain a NovaCoreApiHandle for a particular GPU
using NovaCoreApi::of(). This takes a reference to a bound auxiliary bus
device and checks that its registration data is a NovaCoreApi. The
NovaCoreApi itself is then accessed by passing a closure to
NovaCoreApiHandle::with().
Closure based access is used because NovaCoreApi cannot be assumed to be
covariant over its lifetime. It references the Gpu, which will carry
locks around types holding device resources, making it invariant.
Covariant sub-fields can still be returned directly from the closure
thanks to the lifetime bound on registration_data_with().
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-3-apopple@nvidia.com
[ Rebase and use pin_chain() for Gpu::run_selftests(). - Danilo ]
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|