kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c, branch v6.6.150

drm/amdgpu: fix division by zero with invalid uvd dimensions

2026-08-03T09:15:32+00:00

commit 0c01c811be47e6b146552dd59bfedbea8f09b8f4 upstream. When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. Signed-off-by: Boyuan Zhang Reviewed-by: Leo Liu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older

2026-08-03T09:15:23+00:00

commit 8002b744ad70055ef11ff7d0a7d685bfe8ffe6e4 upstream. These UVD versions don't fully support GPUVM and are only validated to work when their VCPU BO is placed in VRAM. Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 01b8dfc0660db5d6cdd62c22dc20f774a26ce853) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't at 0 (v2)

2026-08-03T09:15:23+00:00

commit 32bd35f068a3507a1b3922cd12ea2985fc58c85b upstream. UVD 4.x and older can only access MSG, FEEDBACK buffers from a specific 256M VRAM segment that the VCPU BO is also located in. We already modify all placements of the given BO to ensure the BO is placed within this segment. Previously, it always assumed that the VCPU segment is the first 256M of VRAM, even though under some conditions the VCPU BO could be allocated outside this segment, which made UVD non-functional as the BOs were not inside the same segment as the UVD VCPU BO. Solve that by using the segment where the VCPU BO actually is. This fixes an issue with UVD failing to initialize on SI/CIK when resizable BAR is enabled and the VCPU BO is allocated in a different segment. v2: - For other BOs, keep using the same UVD segment as before. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3851 Reviewed-by: Christian König Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit cbfd4d3fc2061a1ec8e9d36e65973ac3e813358a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amd/amdgpu: Fix errors & warnings in amdgpu _uvd, _vce.c

2023-06-09T14:38:22+00:00

Fix below checkpatch errors & warnings: In amdgpu_uvd.c: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Prefer 'unsigned int *' to bare use of 'unsigned *' WARNING: Missing a blank line after declarations WARNING: %Lx is non-standard C, use %llx ERROR: space required before the open parenthesis '(' ERROR: space required before the open brace '{' WARNING: %LX is non-standard C, use %llX WARNING: Block comments use * on subsequent lines +/* multiple fence commands without any stream commands in between can + crash the vcpu so just try to emmit a dummy create/destroy msg to WARNING: Block comments use a trailing */ on a separate line + avoid this */ WARNING: braces {} are not necessary for single statement blocks + for (j = 0; j < adev->uvd.num_enc_rings; ++j) { + fences += amdgpu_fence_count_emitted(&adev->uvd.inst[i].ring_enc[j]); + } In amdgpu_vce.c: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Missing a blank line after declarations WARNING: %Lx is non-standard C, use %llx WARNING: Possible repeated word: 'we' ERROR: space required before the open parenthesis '(' Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Acked-by: Luben Tuikov Signed-off-by: Alex Deucher

drm/amdgpu: simplify amdgpu_uvd_send_msg

2023-03-07T19:21:57+00:00

We only need one offset and not an array of it. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amdgpu: stop waiting in amdgpu_uvd_send_msg

2023-03-06T20:27:22+00:00

We have a wait in the amdgpu_bo_kmap() code for quite a while now, so waiting here isn't needed any more. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher

drm/amd: Use `amdgpu_ucode_*` helpers for UVD

2023-01-10T19:32:58+00:00

The `amdgpu_ucode_request` helper will ensure that the return code for missing firmware is -ENODEV so that early_init can fail. The `amdgpu_ucode_release` helper is for symmetry on unloading. Reviewed-by: Alex Deucher Reviewed-by: Lijo Lazar Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher

drm/amdgpu: use VRAM|GTT for a bunch of kernel allocations

2023-01-03T21:49:54+00:00

Technically all of those can use GTT as well, no need to force things into VRAM. Signed-off-by: Christian König Signed-off-by: Luben Tuikov Acked-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdgpu: use scheduler dependencies for UVD msgs

2022-11-03T11:45:20+00:00

Instead of putting that into the job sync object. Signed-off-by: Christian König Reviewed-by: Luben Tuikov Link: https://patchwork.freedesktop.org/patch/msgid/20221014084641.128280-10-christian.koenig@amd.com

drm/amdgpu: cleanup scheduler job initialization v2

2022-11-03T11:45:20+00:00

Init the DRM scheduler base class while allocating the job. This makes the whole handling much more cleaner. v2: fix coding style Signed-off-by: Christian König Reviewed-by: Luben Tuikov Link: https://patchwork.freedesktop.org/patch/msgid/20221014084641.128280-7-christian.koenig@amd.com