linux.git/drivers/gpu/drm/panthor, branch v6.16

drm/panthor: Fix build warning when DEBUG_FS is disabled

2025-04-29T16:12:23+00:00

Commit a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM
objects over DebugFS") causes a build warning and linking error when
built without support for DebugFS, because of a non-inline non-static
function declaration in a header file.

On top of that, the function is only being used inside a single
compilation unit, so there is no point in exposing it as a global
symbol.

This is a follow-up from Arnd Bergmann's first fix.
Also move panthor_gem_debugfs_set_usage_flags() into panthor_gem.c and
declare it static.

Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS")
Reported-by: Arnd Bergmann 
Closes: https://lore.kernel.org/dri-devel/20250424142419.47b9d457@collabora.com/T/#t
Signed-off-by: Adrián Larumbe 
Reviewed-by: Steven Price 
Reviewed-by: Liviu Dudau 
Link: https://lore.kernel.org/r/20250424184041.356191-1-adrian.larumbe@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: show device-wide list of DRM GEM objects over DebugFS

2025-04-23T08:35:36+00:00

Add a device DebugFS file that displays a complete list of all the DRM
GEM objects that are exposed to UM through a DRM handle.

Since leaking object identifiers that might belong to a different NS is
inadmissible, this functionality is only made available in debug builds
with DEBUGFS support enabled.

File format is that of a table, with each entry displaying a variety of
fields with information about each GEM object.

Each GEM object entry in the file displays the following information
fields: Client PID, BO's global name, reference count, BO virtual size,
BO resize size, VM address in its DRM-managed range, BO label and a GEM
state flags.

There's also a usage flags field for the type of BO, which tells us
whether it's a kernel BO and/or mapped onto the FW's address space.

GEM state and usage flag meanings are printed in the file prelude, so
that UM parsing tools can interpret the numerical values in the table.

Signed-off-by: Adrián Larumbe 
Reviewed-by: Liviu Dudau 
Reviewed-by: Boris Brezillon 
Reviewed-by: Steven Price 
Link: https://lore.kernel.org/r/20250423021238.1639175-5-adrian.larumbe@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Label all kernel BO's

2025-04-23T08:35:35+00:00

Kernel BO's aren't exposed to UM, so labelling them is the responsibility
of the driver itself. This kind of tagging will prove useful in further
commits when want to expose these objects through DebugFS.

Expand panthor_kernel_bo_create() interface to take a NUL-terminated
string. No bounds checking is done because all label strings are given
as statically-allocated literals, but if a more complex kernel BO naming
scheme with explicit memory allocation and formatting was desired in the
future, this would have to change.

Signed-off-by: Adrián Larumbe 
Reviewed-by: Boris Brezillon 
Reviewed-by: Liviu Dudau 
Reviewed-by: Steven Price 
Link: https://lore.kernel.org/r/20250423021238.1639175-4-adrian.larumbe@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Add driver IOCTL for setting BO labels

2025-04-23T08:35:35+00:00

Allow UM to label a BO for which it possesses a DRM handle.

Signed-off-by: Adrián Larumbe 
Reviewed-by: Liviu Dudau 
Reviewed-by: Boris Brezillon 
Reviewed-by: Steven Price 
Link: https://lore.kernel.org/r/20250423021238.1639175-3-adrian.larumbe@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Introduce BO labeling

2025-04-23T08:35:35+00:00

Add a new character string Panthor BO field, and a function that allows
setting it from within the driver.

Driver takes care of freeing the string when it's replaced or no longer
needed at object destruction time, but allocating it is the responsibility
of callers.

Signed-off-by: Adrián Larumbe 
Reviewed-by: Boris Brezillon 
Reviewed-by: Liviu Dudau 
Reviewed-by: Steven Price 
Link: https://lore.kernel.org/r/20250423021238.1639175-2-adrian.larumbe@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Don't create a file offset for NO_MMAP BOs

2025-04-22T08:56:03+00:00

Right now the DRM_PANTHOR_BO_NO_MMAP flag is ignored by
panthor_ioctl_bo_mmap_offset(), meaning BOs with this flag set can
have a file offset but can't be mapped anyway, because
panthor_gem_mmap() will filter them out.

If we error out at mmap_offset creation time, we can get rid of
panthor_gem_mmap() and call drm_gem_shmem_object_mmap directly, and
we get rid of this inconsistency of having an mmap offset for a
BO that can never be mmap-ed.

Changes in v2:
- Get rid of panthor_gem_mmap()
- Get rid of the Fixes tag and adjust the commit message accordingly
- Return ENOPERM instead of EINVAL

Changes in v3:
- Don't leak the BO ref
- Add R-bs

Reviewed-by: Steven Price 
Reviewed-by: Liviu Dudau 
Reviewed-by: Adrián Larumbe 
Link: https://lore.kernel.org/r/20250417121942.3574111-1-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Fix the panthor_gpu_coherency_init() error path

2025-04-17T09:29:49+00:00

The panthor_gpu_coherency_init() call has been moved around, but the
error path hasn't been adjusted accordingly. Make sure we undo what
has been done before this call in case of failure.

Fixes: 7d5a3b22f5b5 ("drm/panthor: Call panthor_gpu_coherency_init() after PM resume()")
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/dri-devel/4da470aa-4f84-460e-aff8-dabc8cc4da15@stanley.mountain/T/#t
Reviewed-by: Steven Price 
Reviewed-by: Liviu Dudau 
Link: https://lore.kernel.org/r/20250414130120.581274-1-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Test for imported buffers with drm_gem_is_imported()

2025-04-14T08:53:11+00:00

Instead of testing import_attach for imported GEM buffers, invoke
drm_gem_is_imported() to do the test. The helper tests the dma_buf
itself while import_attach is just an artifact of the import. Prepares
to make import_attach optional.

Signed-off-by: Thomas Zimmermann 
Cc: Boris Brezillon 
Cc: Steven Price 
Cc: Liviu Dudau 
Reviewed-by: Liviu Dudau 
Reviewed-by: Steven Price 
Link: https://lore.kernel.org/r/20250317131923.238374-10-tzimmermann@suse.de

drm/panthor: Don't update MMU_INT_MASK in panthor_mmu_irq_handler()

2025-04-10T13:00:11+00:00

Interrupts are automatically unmasked in
panthor_mmu_irq_threaded_handler() when the handler returns. Unmasking
prematurely might generate spurious interrupts if the IRQ line is
shared.

Changes in v2:
- New patch

Changes in v3:
- Add R-bs

Reviewed-by: Liviu Dudau 
Reviewed-by: Steven Price 
Link: https://lore.kernel.org/r/20250404080933.2912674-6-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Let IRQ handlers clear the interrupts themselves

2025-04-10T13:00:11+00:00

MMU handler needs to be in control of the job interrupt clears because
clearing the interrupt also unblocks the writer/reader that triggered
the fault, and we don't want it to be unblocked until we've had a chance
to process the IRQ.

Since clearing the clearing is just one line, let's make it explicit
instead of doing it in the generic code path.

Note that this commit changes the existing behavior in that the MMU
COMPLETED irqs are no longer cleared, which is fine because they are
masked, so we're not risking an interrupt flood.

Changes in v3:
- Mention the fact we no longer clear MMU COMPLETED irqs
- Add Liviu's R-b

Changes in v2:
- Move the MMU_INT_CLEAR around

Reviewed-by: Liviu Dudau 
Reviewed-by: Steven Price 
Link: https://lore.kernel.org/r/20250404080933.2912674-5-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon