Fix the inconsistent indenting warning for mes_userq_map().

Fixes: d0827dda8fa7 ("drm/amdgpu/mes: refactor the amdgpu_mes_alloc/free_proc|gang()")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202608190252.8XCa0HqR-lkp@intel.com/
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

- Unify amdgpu_mes_alloc/free_proc|gang_ctx_index to provide
  centralized RS64mem bitmap management for both KGD and KFD.
- Retrieve the bitmap bit for userq contex index based on a
  per process granularity.

Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Michael Chen <michael.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

mes_userq_reset() unmaps the queue via the low-level mes_userq_unmap()
(REMOVE_QUEUE) but does not update queue->state, so the queue still looks
MAPPED. The destroy path then issues a second, redundant REMOVE_QUEUE for
the already-removed queue; for gfx that unmap waits on an EOP that never
arrives, times out (-110) and escalates to a full GPU reset.

Mark the queue UNMAPPED on a successful reset-path unmap so destroy skips
the redundant REMOVE_QUEUE.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Instead of pinning the wptr bo attach the eviction fence to
the bo to make sure it remains valid all the time.

Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

We need to increment the reset counter, force fence completion,
and set the wedged event when a user queue is reset, but only
for the guilty queue.  We don't want additional events for
collateral damage.

Only increment the reset counter and set the wedged event
in the top level userq reset callers (both KGD and KFD).
This aligns with how this is managed for kernel queue resets.

v2: fix task info refcount handling, align with
    kfd error reporting.
v3: check for has_reset_queue in KFD path (Prike)

Cc: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Cc: Prike Liang <Prike.Liang@amd.com>
Cc: Sunil Khatri <sunil.khatri@amd.com>
Cc: Lazar, Lijo <lijo.lazar@amd.com>
Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Prike Liang <Prike.Liang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Implement the MES gang contex alloc and free heplers.

Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Michael Chen <michael.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Those helpers allocates/frees slots from bitmaps for
process_context_array_index processed by MES firmware.

Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Michael Chen <michael.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Move struct amdgpu_wb and helpers out of the monolithic header amdgpu.h
into its own dedicated header amdgpu_wb.h.

Add amdgpu_wb_init() and amdgpu_wb_fini() into amdgpu_wb.h.

Move functions amdgpu_device_wb_get(), amdgpu_device_wb_free(),
amdgpu_device_wb_init(), and amdgpu_device_wb_fini() out of
amdgpu_device.c into new dedicated amdgpu_wb.c file.

Removed static from functions amdgpu_device_wb_init() and amdgpu_device_wb_fini().

Rename functions amdgpu_device_wb_get(), amdgpu_device_wb_free(),
amdgpu_device_wb_init(), and amdgpu_device_wb_fini() into
amdgpu_wb_get(), amdgpu_wb_free(), amdgpu_wb_init(), and amdgpu_wb_fini().

Update amdgpu/Makefile to build amdgpu_wb.o.

This is part of the ongoing effort to reduce the size of amdgpu.h into
their own respective separate headers.

Signed-off-by: Shahyan Soltani <shahyan.soltani@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

MES ADD_QUEUE programs the firmware with the queue type from the driver
input, but MES REMOVE_QUEUE leaves queue_type at the zero-initialized
value.  Zero decodes as GFX in the MES REMOVE_QUEUE packet.

That means removing a KFD compute queue can be submitted to MES as a GFX
queue.  In a debug-trap suspend/remove sequence this can leave MES
looking for the doorbell in the wrong queue class and the REMOVE_QUEUE
command may never complete.  The observed failing packet removed
doorbell 0x1002 with queue_type=GFX even though the corresponding
ADD_QUEUE for the same doorbell was queue_type=COMPUTE.

Populate REMOVE_QUEUE.queue_type the same way ADD_QUEUE does.

Signed-off-by: Geoffrey McRae <geoffrey.mcrae@amd.com>
Reviewed-by: Sunil Khatri <sunil.khatri@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

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 <lingshan.zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>