linux-next.git/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h, branch master

drm/amdgpu/userq: add reset helper and identify guilty user queue

2026-07-01T15:15:36+00:00

If we get an interrupt for a bad user queue (bad opcode, etc.), add a helper to handle the reset for user queues. v2: squash in fixes v3: - schedule the reset via amdgpu_userq_start_hang_detect_work() instead of open-coding mod_delayed_work() - drop the per-queue guilty flag; always reset the queue the hang detect work belongs to, matching the non-compute reset path Co-developed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Jesse Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: implement per-process MES context

2026-06-17T20:20:37+00:00

MES process context is a process-level page where process specific context is saved for MES scheduler. However, current user-queue code path assigns fw_obj of a queue to MES process_context_addr when adding the queue to MES. This means every new queue from the same process would replace the previous process context address with that queue's fw_obj address. What's worse is, when user space frees a queue, its fw_obj will be freed as well, causing MES working on a NULL page pointer. This issue leads to inconsistency and crash in the scheduler. This commit allocates a process-level page for MES process contexts for a process other than queue-level Signed-off-by: Zhu Lingshan Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu/userq: drop detect_and_reset callback

2026-06-17T19:51:34+00:00

No longer needed. Reviewed-by: Jesse Zhang Reviewed-by: Prike Liang Signed-off-by: Alex Deucher

drm/amdgpu/userq: add per queue reset callback

2026-06-17T19:51:34+00:00

Add a per queue reset callback. Reviewed-by: Jesse Zhang Reviewed-by: Prike Liang Signed-off-by: Alex Deucher

drm/amdgpu/userq: remove the vital queue unmap logging

2026-06-03T17:55:33+00:00

Mesa userqueues free does not wait for the free to complete and go ahead in unmapping the vital bos while kernel is still in queue free and corresponding cleanup. So ideally we don't need the logging for that and hence remove the warn message as this is expected behaviour and functionally, we are making sure to wait for the required fences before unmap. Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu/userq: use array instead of list for userq_vas

2026-05-27T14:50:02+00:00

Use arrays instead of list for userq_vas since we have fixed no of bos. Also, we dont have to worry to free that memory later since this array would be free along with queue only. Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu/userq: remove amdgpu_userq_create/destroy_object wrapper

2026-05-27T14:48:34+00:00

Remove the amdgpu_userq_create/destroy_object wrappers and use directly the kernel bo allocation function which does all the things which are done in wrapper. Signed-off-by: Sunil Khatri Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: simplify return value in amdgpu_userq_get_doorbell_index

2026-05-27T14:39:07+00:00

amdgpu_userq_get_doorbell_index returns a uint64 type index as well as a int type failure values. Simplifying this and using a int type return value and getting the index in input pointer of type uint64 type. Also since it's used at once place making it static would be better. Signed-off-by: Sunil Khatri Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: rework userq reset work handling

2026-05-18T22:07:26+00:00

It is illegal to schedule reset work from another reset work! Fix this by scheduling the userq reset work directly on the work queue of the reset domain. Not fully tested, I leave that to the IGT test cases. Signed-off-by: Christian König Reviewed-by: Prike Liang Reviewed-by: Sunil Khatri Signed-off-by: Alex Deucher

drm/amdgpu: fix userq hang detection and reset

2026-05-11T20:08:42+00:00

Fix lock inversions pointed out by Prike and Sunil. The hang detection timeout *CAN'T* grab locks under which we wait for fences, especially not the userq_mutex lock. Then instead of this completely broken handling with the hang_detect_fence just cancel the work when fences are processed and re-start if necessary. Signed-off-by: Christian König Reviewed-by: Sunil Khatri Signed-off-by: Alex Deucher