kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c, branch v6.12.80

drm/amdgpu: remove all KFD fences from the BO on release

2025-05-29T09:02:41+00:00

[ Upstream commit cb0de06d1b0afb2d0c600ad748069f5ce27730ec ] Remove all KFD BOs from the private dma_resv object. This prevents the KFD from being evict unecessarily when an exported BO is released. Signed-off-by: Christian König Signed-off-by: James Zhu Reviewed-by: Felix Kuehling Reviewed-and-tested-by: James Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amdgpu: immediately use GTT for new allocations

2025-04-25T08:48:01+00:00

commit a755906fb2b8370c43e91ba437ae1b3e228e8b02 upstream. Only use GTT as a fallback if we already have a backing store. This prevents evictions when an application constantly allocates and frees new memory. Partially fixes https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2833985. Signed-off-by: Christian König Fixes: 216c1282dde3 ("drm/amdgpu: use GTT only as fallback for VRAM|GTT") Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: enable GTT fallback handling for dGPUs only

2024-11-12T22:37:38+00:00

That is just a waste of time on APUs. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3704 Fixes: 216c1282dde3 ("drm/amdgpu: use GTT only as fallback for VRAM|GTT") Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit e8fc090d322346e5ce4c4cfe03a8100e31f61c3c) Cc: stable@vger.kernel.org

drm/amdgpu: use GEM references instead of TTMs v2

2024-09-18T20:15:13+00:00

Instead of a TTM reference grab a GEM reference whenever necessary. v2: fix typo in amdgpu_bo_unref pointed out by Vitaly, initialize the GEM funcs for kernel allocations as well. Signed-off-by: Christian König Reviewed-by: Daniel Vetter (v1) Signed-off-by: Alex Deucher

drm/amdgpu: remove amdgpu_pin_restricted()

2024-09-18T20:15:09+00:00

We haven't used the functionality to pin BOs in a certain range at all while the driver existed. Just nuke it. Signed-off-by: Christian König Acked-by: Lijo Lazar Signed-off-by: Alex Deucher

drm/amdgpu: explicitely set the AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS flag

2024-09-18T20:15:09+00:00

Instead of having that in the amdgpu_bo_pin() function applied for all pinned BOs. Signed-off-by: Christian König Acked-by: Lijo Lazar Signed-off-by: Alex Deucher

drm/amdgpu: nuke the VM PD/PT shadow handling

2024-09-18T20:15:06+00:00

This was only used as workaround for recovering the page tables after VRAM was lost and is no longer necessary after the function amdgpu_vm_bo_reset_state_machine() started to do the same. Compute never used shadows either, so the only proplematic case left is SVM and that is most likely not recoverable in any way when VRAM is lost. Signed-off-by: Christian König Acked-by: Lijo Lazar Signed-off-by: Alex Deucher

Merge tag 'amd-drm-next-6.11-2024-06-28' of https://gitlab.freedesktop.org/agd5f/linux into drm-next

2024-07-05T09:39:23+00:00

amd-drm-next-6.11-2024-06-28: amdgpu: - JPEG 5.x fixes - More FW loading cleanups - Misc code cleanups - GC 12.x fixes - ASPM fix - DCN 4.0.1 updates - SR-IOV fixes - HDCP fix - USB4 fixes - Silence UBSAN warnings - MES submission fixes - Update documentation for new products - DCC updates - Initial ISP 4.x plumbing - RAS fixes - Misc small fixes amdkfd: - Fix missing unlock in error path for adding queues Signed-off-by: Daniel Vetter From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20240628213135.427214-1-alexander.deucher@amd.com

Merge v6.10-rc6 into drm-next

2024-07-05T08:47:28+00:00

The exynos-next pull is based on a newer -rc than drm-next. hence backmerge first to make sure the unrelated conflicts we accumulated don't end up randomly in the exynos merge pull, but are separated out. Conflicts are all benign: Adjacent changes in amdgpu and fbdev-dma code, and cherry-pick conflict in xe. Signed-off-by: Daniel Vetter

amdgpu: don't dereference a NULL resource in sysfs code

2024-06-27T21:09:46+00:00

dma_resv_trylock being successful doesn't guarantee that bo->tbo.base.resv is not NULL, so check its validity before using it. Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher