<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c, branch v7.2-rc1</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc1</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc1'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-17T22:30:52+00:00</updated>
<entry>
<title>drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't at 0 (v2)</title>
<updated>2026-06-17T22:30:52+00:00</updated>
<author>
<name>Timur Kristóf</name>
<email>timur.kristof@gmail.com</email>
</author>
<published>2026-05-25T11:33:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32bd35f068a3507a1b3922cd12ea2985fc58c85b'/>
<id>urn:sha1:32bd35f068a3507a1b3922cd12ea2985fc58c85b</id>
<content type='text'>
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 &lt;christian.koenig@amd.com&gt;
Signed-off-by: Timur Kristóf &lt;timur.kristof@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit cbfd4d3fc2061a1ec8e9d36e65973ac3e813358a)
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older</title>
<updated>2026-06-17T22:29:52+00:00</updated>
<author>
<name>Timur Kristóf</name>
<email>timur.kristof@gmail.com</email>
</author>
<published>2026-05-25T11:33:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8002b744ad70055ef11ff7d0a7d685bfe8ffe6e4'/>
<id>urn:sha1:8002b744ad70055ef11ff7d0a7d685bfe8ffe6e4</id>
<content type='text'>
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 &lt;timur.kristof@gmail.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit 01b8dfc0660db5d6cdd62c22dc20f774a26ce853)
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/amdgpu: plumb timedout fence through to force completion</title>
<updated>2026-05-11T20:15:31+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2026-01-01T22:20:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c184df870db1e328691ea0fbb7d0e59efd9d3f9f'/>
<id>urn:sha1:c184df870db1e328691ea0fbb7d0e59efd9d3f9f</id>
<content type='text'>
When we do a full adapter reset, if we know the timedout fence
mark the fence with -ETIME rather than -ECANCELED so it
gets properly handled by userspace.

v2: rebase

Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd: Convert DRM_*() to drm_*()</title>
<updated>2026-01-05T21:59:55+00:00</updated>
<author>
<name>Mario Limonciello (AMD)</name>
<email>superm1@kernel.org</email>
</author>
<published>2025-12-15T01:12:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e291729873095262697758c389c8d7affa81bdcc'/>
<id>urn:sha1:e291729873095262697758c389c8d7affa81bdcc</id>
<content type='text'>
The drm_*() macros include the device which is helpful for debugging
issues in multi-GPU systems.

Signed-off-by: Mario Limonciello (AMD) &lt;superm1@kernel.org&gt;
Reviewed-by: Aurabindo Pillai &lt;aurabindo.pillai@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: give each kernel job a unique id</title>
<updated>2025-09-01T05:19:31+00:00</updated>
<author>
<name>Pierre-Eric Pelloux-Prayer</name>
<email>pierre-eric.pelloux-prayer@amd.com</email>
</author>
<published>2025-06-04T12:28:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=256576ed6895b81290690ae3e2b9f62eb7c642fc'/>
<id>urn:sha1:256576ed6895b81290690ae3e2b9f62eb7c642fc</id>
<content type='text'>
Userspace jobs have drm_file.client_id as a unique identifier
as job's owners. For kernel jobs, we can allocate arbitrary
values - the risk of overlap with userspace ids is small (given
that it's a u64 value).
In the unlikely case the overlap happens, it'll only impact
trace events.

Since this ID is traced in the gpu_scheduler trace events, this
allows to determine the source of each job sent to the hardware.

To make grepping easier, the IDs are defined as they will appear
in the trace output.

Signed-off-by: Pierre-Eric Pelloux-Prayer &lt;pierre-eric.pelloux-prayer@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Arunpravin Paneer Selvam &lt;Arunpravin.PaneerSelvam@amd.com&gt;
Link: https://lore.kernel.org/r/20250604122827.2191-1-pierre-eric.pelloux-prayer@amd.com
</content>
</entry>
<entry>
<title>drm/amd: Add the capability to mark certain firmware as "required"</title>
<updated>2024-12-10T15:26:51+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2024-12-03T17:28:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ea5d49349894a7a74ce8dba242e3a487d24b6c0e'/>
<id>urn:sha1:ea5d49349894a7a74ce8dba242e3a487d24b6c0e</id>
<content type='text'>
Some of the firmware that is loaded by amdgpu is not actually required.
For example the ISP firmware on some SoCs is optional, and if it's not
present the ISP IP block just won't be initialized.

The firmware loader core however will show a warning when this happens
like this:
```
Direct firmware load for amdgpu/isp_4_1_0.bin failed with error -2
```

To avoid confusion for non-required firmware, adjust the amd-ucode helper
to take an extra argument indicating if the firmware is required or
optional.

On optional firmware use firmware_request_nowarn() instead of
request_firmware() to avoid the warnings.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://lore.kernel.org/amd-gfx/df71d375-7abd-4b32-97ce-15e57846eed8@amd.com/T/#t
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: fix UVD contiguous CS mapping problem</title>
<updated>2024-12-05T19:14:53+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2024-11-29T13:19:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=12f325bcd2411e571dbb500bf6862c812c479735'/>
<id>urn:sha1:12f325bcd2411e571dbb500bf6862c812c479735</id>
<content type='text'>
When starting the mpv player, Radeon R9 users are observing
the below error in dmesg.

[drm:amdgpu_uvd_cs_pass2 [amdgpu]]
*ERROR* msg/fb buffer ff00f7c000-ff00f7e000 out of 256MB segment!

The patch tries to set the TTM_PL_FLAG_CONTIGUOUS for both user
flag(AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS) set and not set cases.

v2: Make the TTM_PL_FLAG_CONTIGUOUS mandatory for user BO's.
v3: revert back to v1, but fix the check instead (chk).

Closes:https://gitlab.freedesktop.org/drm/amd/-/issues/3599
Closes:https://gitlab.freedesktop.org/drm/amd/-/issues/3501
Signed-off-by: Arunpravin Paneer Selvam &lt;Arunpravin.PaneerSelvam@amd.com&gt;
Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Arunpravin Paneer Selvam &lt;Arunpravin.PaneerSelvam@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org # 6.10+
</content>
</entry>
<entry>
<title>drm/amd/amdgpu: cleanup parse_cs callbacks</title>
<updated>2024-08-13T16:13:03+00:00</updated>
<author>
<name>David (Ming Qiang) Wu</name>
<email>David.Wu3@amd.com</email>
</author>
<published>2024-08-02T18:29:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a28a072d90e4543b5e07a904e3a6afad0117e26'/>
<id>urn:sha1:6a28a072d90e4543b5e07a904e3a6afad0117e26</id>
<content type='text'>
Because gpu_addr is updated in the calling routine
(amdgpu_cs_patch_ibs()),it is removed in the callback.

Use .patch_cs_in_place instead of .parse_cs for
amdgpu_vce_ring_parse_cs_vm() as there is no need for keeping
a temporary IB, therefore ib-&gt;sa_bo is NULL and amdgpu_ib_free()
is removed.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: David (Ming Qiang) Wu &lt;David.Wu3@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amd: Use a constant format string for amdgpu_ucode_request</title>
<updated>2024-08-13T14:27:03+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-07-19T10:08:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=020620424b27bababf7f53d00692ab919c357a3f'/>
<id>urn:sha1:020620424b27bababf7f53d00692ab919c357a3f</id>
<content type='text'>
Multiple files in amdgpu call amdgpu_ucode_request() with a fw_name
variable that the compiler cannot check for being a valid format string,
as seen by enabling the (default-disabled) -Wformat-security option:

drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c: In function 'amdgpu_mes_init_microcode':
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c:1517:61: error: format not a string literal and no format arguments [-Werror=format-security]
 1517 |         r = amdgpu_ucode_request(adev, &amp;adev-&gt;mes.fw[pipe], fw_name);
      |                                                             ^~~~~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c: In function 'amdgpu_uvd_sw_init':
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:263:9: error: format not a string literal and no format arguments [-Werror=format-security]
  263 |         r = amdgpu_ucode_request(adev, &amp;adev-&gt;uvd.fw, fw_name);
      |         ^
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c: In function 'amdgpu_vce_sw_init':
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:161:9: error: format not a string literal and no format arguments [-Werror=format-security]
  161 |         r = amdgpu_ucode_request(adev, &amp;adev-&gt;vce.fw, fw_name);
      |         ^
drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c: In function 'amdgpu_umsch_mm_init_microcode':
drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c:590:9: error: format not a string literal and no format arguments [-Werror=format-security]
  590 |         r = amdgpu_ucode_request(adev, &amp;adev-&gt;umsch_mm.fw, fw_name);
      |         ^
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c: In function 'amdgpu_cgs_get_firmware_info':
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:417:72: error: format not a string literal and no format arguments [-Werror=format-security]
  417 |                         err = amdgpu_ucode_request(adev, &amp;adev-&gt;pm.fw, fw_name);
      |                                                                        ^~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 'load_dmcu_fw':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2221:9: error: format not a string literal and no format arguments [-Werror=format-security]
 2221 |         r = amdgpu_ucode_request(adev, &amp;adev-&gt;dm.fw_dmcu, fw_name_dmcu);
      |         ^
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function 'dm_init_microcode':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5147:9: error: format not a string literal and no format arguments [-Werror=format-security]
 5147 |         r = amdgpu_ucode_request(adev, &amp;adev-&gt;dm.dmub_fw, fw_name_dmub);
      |         ^

Change these all to use a "%s" format with the actual name as an argument,
to let the compiler prove this to be correct.

Fixes: e5a7d047f41b ("drm/amd: Use `amdgpu_ucode_*` helpers for CGS")
Fixes: 52215e2a5d4a ("drm/amd: Use `amdgpu_ucode_*` helpers for VCE")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: Address member 'ring' not described in 'amdgpu_ vce, uvd_entity_init()'</title>
<updated>2023-11-17T05:47:14+00:00</updated>
<author>
<name>Srinivasan Shanmugam</name>
<email>srinivasan.shanmugam@amd.com</email>
</author>
<published>2023-11-12T04:21:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8a0173cd90984835645022bf1997abd1bcd81aae'/>
<id>urn:sha1:8a0173cd90984835645022bf1997abd1bcd81aae</id>
<content type='text'>
Fixes the following:

drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:237: warning: Function parameter or member 'ring' not described in 'amdgpu_vce_entity_init'
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:405: warning: Function parameter or member 'ring' not described in 'amdgpu_uvd_entity_init'

Cc: Christian König &lt;christian.koenig@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: "Pan, Xinhui" &lt;Xinhui.Pan@amd.com&gt;
Signed-off-by: Srinivasan Shanmugam &lt;srinivasan.shanmugam@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
</entry>
</feed>
