linux-toradex.git/drivers/gpu/drm/panthor, branch v6.17

drm/panthor: Defer scheduler entitiy destruction to queue release

2025-09-25T08:52:03+00:00

Commit de8548813824 ("drm/panthor: Add the scheduler logical block")
handled destruction of a group's queues' drm scheduler entities early
into the group destruction procedure.

However, that races with the group submit ioctl, because by the time
entities are destroyed (through the group destroy ioctl), the submission
procedure might've already obtained a group handle, and therefore the
ability to push jobs into entities. This is met with a DRM error message
within the drm scheduler core as a situation that should never occur.

Fix by deferring drm scheduler entity destruction to queue release time.

Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
Signed-off-by: Adrián Larumbe 
Reviewed-by: Steven Price 
Reviewed-by: Boris Brezillon 
Signed-off-by: Steven Price 
Link: https://lore.kernel.org/r/20250919164436.531930-1-adrian.larumbe@collabora.com

drm/panthor: validate group queue count

2025-09-04T14:59:23+00:00

A panthor group can have at most MAX_CS_PER_CSG panthor queues.

Fixes: 4bdca11507928 ("drm/panthor: Add the driver frontend block")
Signed-off-by: Chia-I Wu 
Reviewed-by: Boris Brezillon  # v1
Reviewed-by: Steven Price 
Signed-off-by: Steven Price 
Link: https://lore.kernel.org/r/20250903192133.288477-1-olvaffe@gmail.com

drm/sched: Rename DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESET

2025-07-15T11:27:00+00:00

Among the scheduler's statuses, the only one that indicates an error is
DRM_GPU_SCHED_STAT_ENODEV. Any status other than DRM_GPU_SCHED_STAT_ENODEV
signifies that the operation succeeded and the GPU is in a nominal state.

However, to provide more information about the GPU's status, it is needed
to convey more information than just "OK".

Therefore, rename DRM_GPU_SCHED_STAT_NOMINAL to
DRM_GPU_SCHED_STAT_RESET, which better communicates the meaning of this
status. The status DRM_GPU_SCHED_STAT_RESET indicates that the GPU has
hung, but it has been successfully reset and is now in a nominal state
again.

Reviewed-by: Philipp Stanner 
Link: https://lore.kernel.org/r/20250714-sched-skip-reset-v6-1-5c5ba4f55039@igalia.com
Signed-off-by: Maíra Canal

drm/panthor: Remove dead VM flushing code

2025-07-14T15:59:21+00:00

Commit ec62d37d2c0d("drm/panthor: Fix the fast-reset logic") did away
with the only reference to panthor_vm_flush_all(), so let's get rid
of the orphaned definition.

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

drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs code

2025-07-10T09:16:50+00:00

The object is potentially already gone after the drm_gem_object_put().
In general the object should be fully constructed before calling
drm_gem_handle_create(), except the debugfs tracking uses a separate
lock and list and separate flag to denotate whether the object is
actually initialized.

Since I'm touching this all anyway simplify this by only adding the
object to the debugfs when it's ready for that, which allows us to
delete that separate flag. panthor_gem_debugfs_bo_rm() already checks
whether we've actually been added to the list or this is some error
path cleanup.

v2: Fix build issues for !CONFIG_DEBUGFS (Adrián)

v3: Add linebreak and remove outdated comment (Liviu)

Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS")
Cc: Adrián Larumbe 
Cc: Boris Brezillon 
Cc: Steven Price 
Cc: Liviu Dudau 
Reviewed-by: Liviu Dudau 
Signed-off-by: Simona Vetter 
Signed-off-by: Simona Vetter 
Reviewed-by: Steven Price 
Signed-off-by: Steven Price 
Link: https://lore.kernel.org/r/20250709135220.1428931-1-simona.vetter@ffwll.ch

drm/panthor: Wait for _READY register when powering on

2025-06-30T15:57:24+00:00

panthor_gpu_block_power_on() takes a register offset (rdy_reg) for the
purpose of waiting for the power transition to complete. However, a
copy/paste error converting to use the new 64 register functions
switched it to using the pwrtrans_reg register instead. Fix the function
to use the correct register.

Fixes: 4d230aa209ed ("drm/panthor: Add 64-bit and poll register accessors")
Signed-off-by: Steven Price 
Reviewed-by: Liviu Dudau 
Reviewed-by: Boris Brezillon 
Link: https://lore.kernel.org/r/20250630140704.432409-1-steven.price@arm.com

drm/panthor: Clean up 64-bit register definitions

2025-06-06T10:44:41+00:00

With the introduction of 64-bit register accessors, the separate *_HI
definitions are no longer necessary. This change removes them and
renames the corresponding *_LO entries for cleaner and more consistent
register definitions.

Reviewed-by: Liviu Dudau 
Reviewed-by: Steven Price 
Reviewed-by: Boris Brezillon 
Suggested-by: Boris Brezillon 
Signed-off-by: Karunika Choo 
Link: https://lore.kernel.org/r/20250606101835.41840-3-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon

drm/panthor: Add 64-bit and poll register accessors

2025-06-06T10:44:41+00:00

This patch adds 64-bit register accessors to simplify register access in
Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout.

This patch also updates Panthor to use the new 64-bit accessors and poll
functions.

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

drm/panthor: Fix the user MMIO offset logic for emulators

2025-06-06T09:36:08+00:00

Currently, we pick the MMIO offset based on the size of the pgoff_t
type seen by the process that manipulates the FD, such that a 32-bit
process can always map the user MMIO ranges. But this approach doesn't
work well for emulators like FEX, where the emulator is a 64-bit binary
which might be executing 32-bit code. In that case, the kernel thinks
it's the 64-bit process and assumes DRM_PANTHOR_USER_MMIO_OFFSET_64BIT
is in use, but the UMD library expects DRM_PANTHOR_USER_MMIO_OFFSET_32BIT,
because it can't mmap() anything above the pgoff_t size.

In order to solve that, we need a way to explicitly set the user MMIO
offset from the UMD, such that the kernel doesn't have to guess it
from the TIF_32BIT flag set on user thread. We keep the old behavior
if DRM_PANTHOR_SET_USER_MMIO_OFFSET is never called.

Changes in v2:
- Drop the lock/immutable fields and allow SET_USER_MMIO_OFFSET
  requests to race with mmap() requests
- Don't do the is_user_mmio_offset test twice in panthor_mmap()
- Improve the uAPI docs

Changes in v3:
- Bump to version 1.5 instead of 1.4 after rebasing
- Add R-bs
- Fix/rephrase comment as suggested by Liviu

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

drm/sched: Store the drm client_id in drm_sched_fence

2025-05-28T14:15:58+00:00

This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.

This requires changing all the users of drm_sched_job_init to
add an extra parameter.

The newly added drm_client_id field in the drm_sched_fence is a bit
of a duplicate of the owner one. One suggestion I received was to
merge those 2 fields - this can't be done right now as amdgpu uses
some special values (AMDGPU_FENCE_OWNER_*) that can't really be
translated into a client id. Christian is working on getting rid of
those; when it's done we should be able to squash owner/drm_client_id
together.

Reviewed-by: Christian König 
Signed-off-by: Pierre-Eric Pelloux-Prayer 
Signed-off-by: Philipp Stanner 
Link: https://lore.kernel.org/r/20250526125505.2360-3-pierre-eric.pelloux-prayer@amd.com