linux.git/drivers/gpu/drm/amd, branch v6.18-rc2

drm/amdkfd: fix suspend/resume all calls in mes based eviction path

2025-10-13T18:14:28+00:00

Suspend/resume all gangs should be done with the device lock is held.

Signed-off-by: Jonathan Kim 
Acked-by: Alex Deucher 
Reviewed-by: Harish Kasiviswanathan 
Signed-off-by: Alex Deucher

drm/amdgpu: enable suspend/resume all for gfx 12

2025-10-13T18:14:28+00:00

Suspend/resume all gangs has been available for GFX12 for a while now
so enable it.

Signed-off-by: Jonathan Kim 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: fix hung reset queue array memory allocation

2025-10-13T18:14:28+00:00

By design the MES will return an array result that is twice the number
of hung doorbells it can report.

i.e. if up k reported doorbells are supported, then the
second half of the array, also of length k, holds the HQD information
(type/queue/pipe) where queue 1 corresponds to index 0 and k,
queue 2 corresponds to index 1 and k + 1 etc ...

The driver will use the HDQ info to target queue/pipe reset for
hardware scheduled user compute queues.

Signed-off-by: Jonathan Kim 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: fix initialization of doorbell array for detect and hang

2025-10-13T18:14:28+00:00

Initialized doorbells should be set to invalid rather than 0 to prevent
driver from over counting hung doorbells since it checks against the
invalid value to begin with.

Signed-off-by: Jonathan Kim 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: fix gfx12 mes packet status return check

2025-10-13T18:14:16+00:00

GFX12 MES uses low 32 bits of status return for success (1 or 0)
and high bits for debug information if low bits are 0.

GFX11 MES doesn't do this so checking full 64-bit status return
for 1 or 0 is still valid.

Signed-off-by: Jonathan Kim 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices

2025-10-13T18:14:15+00:00

Previously, APU platforms (and other scenarios with uninitialized VRAM managers)
triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root
cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,
but that `man->bdev` (the backing device pointer within the manager) remains
uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully
set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to
acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to
a kernel OOPS.

1. **amdgpu_cs.c**: Extend the existing bandwidth control check in
   `amdgpu_cs_get_threshold_for_moves()` to include a check for
   `ttm_resource_manager_used()`. If the manager is not used (uninitialized
   `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific
   logic that would trigger the NULL dereference.

2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info
   reporting to use a conditional: if the manager is used, return the real VRAM
   usage; otherwise, return 0. This avoids accessing `man->bdev` when it is
   NULL.

3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function)
   data write path. Use `ttm_resource_manager_used()` to check validity: if the
   manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set
   `fb_usage` to 0 (APUs have no discrete framebuffer to report).

This approach is more robust than APU-specific checks because it:
- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),
- Aligns with TTM's design by using its native helper function,
- Preserves correct behavior for discrete GPUs (which have fully initialized
  `man->bdev` and pass the `ttm_resource_manager_used()` check).

v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)

Reviewed-by: Christian König 
Suggested-by: Lijo Lazar 
Signed-off-by: Jesse Zhang 
Signed-off-by: Alex Deucher

drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM

2025-10-13T18:14:15+00:00

Otherwise accessing them can cause a crash.

Signed-off-by: Christian König 
Tested-by: Mangesh Gadre 
Acked-by: Alex Deucher 
Reviewed-by: Arunpravin Paneer Selvam 
Signed-off-by: Alex Deucher

drm/amdgpu: fix bit shift logic

2025-10-13T18:14:15+00:00

BIT_ULL(n) sets nth bit, remove explicit shift and set the position

Fixes: a7a411e24626 ("drm/amdgpu: fix shift-out-of-bounds in amdgpu_debugfs_jpeg_sched_mask_set")
Signed-off-by: Sathishkumar S 
Reviewed-by: Leo Liu 
Signed-off-by: Alex Deucher

drm/amd/powerplay: Fix CIK shutdown temperature

2025-10-13T18:14:15+00:00

Remove extra multiplication.

CIK GPUs such as Hawaii appear to use PP_TABLE_V0 in which case
the shutdown temperature is hardcoded in smu7_init_dpm_defaults
and is already multiplied by 1000. The value was mistakenly
multiplied another time by smu7_get_thermal_temperature_range.

Fixes: 4ba082572a42 ("drm/amd/powerplay: export the thermal ranges of VI asics (V2)")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1676
Reviewed-by: Alex Deucher 
Signed-off-by: Timur Kristóf 
Signed-off-by: Alex Deucher

drm/amdgpu: use atomic functions with memory barriers for vm fault info

2025-10-13T18:14:15+00:00

The atomic variable vm_fault_info_updated is used to synchronize access to
adev->gmc.vm_fault_info between the interrupt handler and
get_vm_fault_info().

The default atomic functions like atomic_set() and atomic_read() do not
provide memory barriers. This allows for CPU instruction reordering,
meaning the memory accesses to vm_fault_info and the vm_fault_info_updated
flag are not guaranteed to occur in the intended order. This creates a
race condition that can lead to inconsistent or stale data being used.

The previous implementation, which used an explicit mb(), was incomplete
and inefficient. It failed to account for all potential CPU reorderings,
such as the access of vm_fault_info being reordered before the atomic_read
of the flag. This approach is also more verbose and less performant than
using the proper atomic functions with acquire/release semantics.

Fix this by switching to atomic_set_release() and atomic_read_acquire().
These functions provide the necessary acquire and release semantics,
which act as memory barriers to ensure the correct order of operations.
It is also more efficient and idiomatic than using explicit full memory
barriers.

Fixes: b97dfa27ef3a ("drm/amdgpu: save vm fault information for amdkfd")
Cc: stable@vger.kernel.org
Signed-off-by: Gui-Dong Han 
Signed-off-by: Felix Kuehling 
Reviewed-by: Felix Kuehling 
Signed-off-by: Alex Deucher