<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/gpu/drm/radeon, branch master</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>drm/radeon: fix internal display on iMac11, 1 (RV770/DCE3.1)</title>
<updated>2026-08-19T14:12:25+00:00</updated>
<author>
<name>Gilles Risch</name>
<email>gilles.risch@gmail.com</email>
</author>
<published>2026-08-17T00:43:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=275c3332585bbabcefad109a6978cc0cbecf2008'/>
<id>275c3332585bbabcefad109a6978cc0cbecf2008</id>
<content type='text'>
The Apple iMac11,1 (27-inch, Late 2009) uses a Mobility Radeon HD 4850
(RV770/DCE3.1) with a 2560x1440 internal panel on an internal
DisplayPort path. Without this fix the display stays dark under KMS.

This machine suffers from the same issue as iMac10,1 and iMac11,2:
Apple routes the internal display through Link B of the DIG encoder
instead of Link A. Add iMac11,1 to the existing DMI quirk and move
the Apple-specific encoder assignment into its own block, independent
of the DCE version check.

Additionally, the 2560x1440 panel requires RADEON_PLL_USE_FRAC_FB_DIV
and ATOM_ENCODER_CMD_DP_VIDEO_ON, limited to iMac11,1 via dmi_match()
to avoid affecting other boards.

Reviewed-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Gilles Risch &lt;gilles.risch@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Apple iMac11,1 (27-inch, Late 2009) uses a Mobility Radeon HD 4850
(RV770/DCE3.1) with a 2560x1440 internal panel on an internal
DisplayPort path. Without this fix the display stays dark under KMS.

This machine suffers from the same issue as iMac10,1 and iMac11,2:
Apple routes the internal display through Link B of the DIG encoder
instead of Link A. Add iMac11,1 to the existing DMI quirk and move
the Apple-specific encoder assignment into its own block, independent
of the DCE version check.

Additionally, the 2560x1440 panel requires RADEON_PLL_USE_FRAC_FB_DIV
and ATOM_ENCODER_CMD_DP_VIDEO_ON, limited to iMac11,1 via dmi_match()
to avoid affecting other boards.

Reviewed-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Gilles Risch &lt;gilles.risch@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix autosuspend cleanup during teardown</title>
<updated>2026-08-12T13:39:44+00:00</updated>
<author>
<name>Guangshuo Li</name>
<email>lgs201920130244@gmail.com</email>
</author>
<published>2026-08-08T13:59:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0fdc1ff82ea14844c22795e9e0813c3ca03235e1'/>
<id>0fdc1ff82ea14844c22795e9e0813c3ca03235e1</id>
<content type='text'>
radeon_driver_load_kms() calls pm_runtime_use_autosuspend() for PX
devices, but radeon_driver_unload_kms() does not call the matching
pm_runtime_dont_use_autosuspend() during teardown.

If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped.

The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().

Add the missing pm_runtime_dont_use_autosuspend() call to the driver
unload path.

This issue was found by manual code inspection.

Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)")
Signed-off-by: Guangshuo Li &lt;lgs201920130244@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
radeon_driver_load_kms() calls pm_runtime_use_autosuspend() for PX
devices, but radeon_driver_unload_kms() does not call the matching
pm_runtime_dont_use_autosuspend() during teardown.

If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped.

The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().

Add the missing pm_runtime_dont_use_autosuspend() call to the driver
unload path.

This issue was found by manual code inspection.

Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)")
Signed-off-by: Guangshuo Li &lt;lgs201920130244@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: restore hardware polling in fence_is_signaled to fix performance regression</title>
<updated>2026-08-06T16:50:02+00:00</updated>
<author>
<name>Wang Jiang</name>
<email>jiangwang@kylinos.cn</email>
</author>
<published>2026-07-29T10:26:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f59ad4cca219c7fdf934f712c5860ec5f5900fd7'/>
<id>f59ad4cca219c7fdf934f712c5860ec5f5900fd7</id>
<content type='text'>
Commit 527ba26e50ec ("drm/radeon: delete radeon_fence_process in
is_signaled, no deadlock") removed the hardware polling from
radeon_fence_is_signaled() to fix a self-deadlock caused by
wake_up_all(&amp;rdev-&gt;fence_queue) being called with the fence queue
lock held.

However, removing the polling entirely causes significant performance
regression (e.g. glxgears FPS drop) because the fence signaled check
becomes purely passive — it only reads the cached last_seq without
probing the GPU, so completed GPU work is not detected in time,
causing unnecessary CPU stalls in sync-heavy workloads.

Fix this by calling radeon_fence_activity() directly instead of
radeon_fence_process(). radeon_fence_activity() reads the hardware
fence counter and updates last_seq via atomic ops without calling
wake_up_all(), thus avoiding the deadlock while restoring timely
fence detection.

Fixes: 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock")
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Wang Jiang &lt;jiangwang@kylinos.cn&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 527ba26e50ec ("drm/radeon: delete radeon_fence_process in
is_signaled, no deadlock") removed the hardware polling from
radeon_fence_is_signaled() to fix a self-deadlock caused by
wake_up_all(&amp;rdev-&gt;fence_queue) being called with the fence queue
lock held.

However, removing the polling entirely causes significant performance
regression (e.g. glxgears FPS drop) because the fence signaled check
becomes purely passive — it only reads the cached last_seq without
probing the GPU, so completed GPU work is not detected in time,
causing unnecessary CPU stalls in sync-heavy workloads.

Fix this by calling radeon_fence_activity() directly instead of
radeon_fence_process(). radeon_fence_activity() reads the hardware
fence counter and updates last_seq via atomic ops without calling
wake_up_all(), thus avoiding the deadlock while restoring timely
fence detection.

Fixes: 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock")
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Wang Jiang &lt;jiangwang@kylinos.cn&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: Only define radeon_acpi_vfct_match when actually used</title>
<updated>2026-07-16T22:27:48+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2026-07-16T12:36:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8e1f8214cbba2ccda3f3c625df0a67dcfd9b1356'/>
<id>8e1f8214cbba2ccda3f3c625df0a67dcfd9b1356</id>
<content type='text'>
This fixes the build failure

drivers/gpu/drm/radeon/radeon_bios.c:614:12: error: ‘radeon_acpi_vfct_match’ defined but not used [-Werror=unused-function]
  614 | static int radeon_acpi_vfct_match(struct radeon_device *rdev,
      |            ^~~~~~~~~~~~~~~~~~~~~~

for builds with CONFIG_ACPI unset.

Fixes: 4059e2f02c8a ("drm/radeon: Fix VFCT bus number matching with soft filter")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes the build failure

drivers/gpu/drm/radeon/radeon_bios.c:614:12: error: ‘radeon_acpi_vfct_match’ defined but not used [-Werror=unused-function]
  614 | static int radeon_acpi_vfct_match(struct radeon_device *rdev,
      |            ^~~~~~~~~~~~~~~~~~~~~~

for builds with CONFIG_ACPI unset.

Fixes: 4059e2f02c8a ("drm/radeon: Fix VFCT bus number matching with soft filter")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@baylibre.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: Validate VBIOS signature in VFCT path</title>
<updated>2026-07-15T13:15:41+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2026-07-08T19:35:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a9c196b3f135fe9b165c5e75b3a24eadcc22fd6a'/>
<id>a9c196b3f135fe9b165c5e75b3a24eadcc22fd6a</id>
<content type='text'>
The VFCT path accepted whatever kmemdup() returned without checking
that the copied image is a valid VBIOS. Every other radeon BIOS
fetch path verifies the 0x55 0xaa signature before trusting the
image; the VFCT path is the odd one out.

Check the signature after copying the image and reject it (freeing
the buffer) if it does not match, matching the amdgpu VFCT path
which validates via check_atom_bios().

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patch.msgid.link/20260708193518.702584-6-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The VFCT path accepted whatever kmemdup() returned without checking
that the copied image is a valid VBIOS. Every other radeon BIOS
fetch path verifies the 0x55 0xaa signature before trusting the
image; the VFCT path is the odd one out.

Check the signature after copying the image and reject it (freeing
the buffer) if it does not match, matching the amdgpu VFCT path
which validates via check_atom_bios().

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patch.msgid.link/20260708193518.702584-6-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: Fix VFCT bus number matching with soft filter</title>
<updated>2026-07-15T13:15:41+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2026-07-08T19:35:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4059e2f02c8a2a51ba78860775877d721df6a055'/>
<id>4059e2f02c8a2a51ba78860775877d721df6a055</id>
<content type='text'>
On systems where PCI bus renumbering occurs (e.g. pci=realloc,
resource conflicts), the runtime bus number may differ from the
BIOS POST bus number recorded in the VFCT table. This causes
radeon_acpi_vfct_bios() to fail finding the VBIOS even though
the correct device entry exists.

Introduce radeon_acpi_vfct_match() which treats the bus number
as a soft filter: vendor/device/function identity is the hard
requirement, while exact bus match is the preferred path. When
bus numbers disagree but device identity matches, accept the
VFCT entry and log a dev_notice for diagnostics. This mirrors the
equivalent amdgpu change.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patch.msgid.link/20260708193518.702584-5-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On systems where PCI bus renumbering occurs (e.g. pci=realloc,
resource conflicts), the runtime bus number may differ from the
BIOS POST bus number recorded in the VFCT table. This causes
radeon_acpi_vfct_bios() to fail finding the VBIOS even though
the correct device entry exists.

Introduce radeon_acpi_vfct_match() which treats the bus number
as a soft filter: vendor/device/function identity is the hard
requirement, while exact bus match is the preferred path. When
bus numbers disagree but device identity matches, accept the
VFCT entry and log a dev_notice for diagnostics. This mirrors the
equivalent amdgpu change.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patch.msgid.link/20260708193518.702584-5-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: Modernize VFCT error handling</title>
<updated>2026-07-15T13:15:41+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2026-07-08T19:35:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=24071402a41a56dba3e215ca89c6b5d855c678ea'/>
<id>24071402a41a56dba3e215ca89c6b5d855c678ea</id>
<content type='text'>
Clean up radeon_acpi_vfct_bios() logging:

- Replace DRM_ERROR with dev_warn tied to the PCI device
- Use unsigned int rather than bare unsigned for the offset

A malformed or missing VFCT table is not fatal: radeon falls back
to the other BIOS fetch methods, so warn rather than error on these
paths.

The goto out label is retained: acpi_get_table() takes a reference on
the table (incrementing its validation_count and mapping it), which
must be released with a paired acpi_put_table() on every exit path.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patch.msgid.link/20260708193518.702584-4-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Clean up radeon_acpi_vfct_bios() logging:

- Replace DRM_ERROR with dev_warn tied to the PCI device
- Use unsigned int rather than bare unsigned for the offset

A malformed or missing VFCT table is not fatal: radeon falls back
to the other BIOS fetch methods, so warn rather than error on these
paths.

The goto out label is retained: acpi_get_table() takes a reference on
the table (incrementing its validation_count and mapping it), which
must be released with a paired acpi_put_table() on every exit path.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patch.msgid.link/20260708193518.702584-4-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: avoid double free in r600 DPM cleanup</title>
<updated>2026-06-17T20:23:16+00:00</updated>
<author>
<name>Ruoyu Wang</name>
<email>ruoyuw560@gmail.com</email>
</author>
<published>2026-06-08T06:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d3f30034f861a585f8e487ae1555d9f288a96f87'/>
<id>d3f30034f861a585f8e487ae1555d9f288a96f87</id>
<content type='text'>
r600_parse_extended_power_table() uses manual kfree() calls for some
early allocation failures, but the freed pointers are left in the
dynamic power-management state. If device teardown later calls
r600_free_extended_power_table(), those stale pointers can be freed
again.

Use the common extended power table cleanup helper for those early
failure paths as well, and clear each pointer after freeing it so
repeated cleanup stays safe.

Signed-off-by: Ruoyu Wang &lt;ruoyuw560@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r600_parse_extended_power_table() uses manual kfree() calls for some
early allocation failures, but the freed pointers are left in the
dynamic power-management state. If device teardown later calls
r600_free_extended_power_table(), those stale pointers can be freed
again.

Use the common extended power table cleanup helper for those early
failure paths as well, and clear each pointer after freeing it so
repeated cleanup stays safe.

Signed-off-by: Ruoyu Wang &lt;ruoyuw560@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon: fix r100_copy_blit for large BOs</title>
<updated>2026-06-17T20:22:25+00:00</updated>
<author>
<name>Pavel Ondračka</name>
<email>pavel.ondracka@gmail.com</email>
</author>
<published>2026-06-10T08:32:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=87be26aee76239c6da03e599f238a426897f78ad'/>
<id>87be26aee76239c6da03e599f238a426897f78ad</id>
<content type='text'>
r100_copy_blit() copies BOs as 1024-pixel-wide ARGB8888 blits, so one
GPU page becomes one blit row. Large copies are split into chunks of at
most 8191 rows.

The kernel register header names the packet coordinate dwords SRC_Y_X
and DST_Y_X. In the BITBLT_MULTI description in
R5xx_Acceleration_v1.5.pdf docs, these correspond to [SRC_X1 | SRC_Y1]
and [DST_X1 | DST_Y1], which are signed 13-bit coordinates in the
-8192..8191 range. The old code kept SRC/DST_PITCH_OFFSET at the BO base
and used SRC_Y_X/DST_Y_X as the chunk address, so large BO moves could
exceed that coordinate range.

Compute per-chunk SRC/DST_PITCH_OFFSET bases and emit zero source and
destination coordinates. r100_copy_blit() already packs
SRC/DST_PITCH_OFFSET as pitch plus base offset, so large chunk addresses
belong there rather than in the coordinate fields.

This fixes Prison Architect corruption with 4096x4096 mipped textures
after they are evicted to GTT under memory pressure on RV530.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/6716
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Pavel Ondračka &lt;pavel.ondracka@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r100_copy_blit() copies BOs as 1024-pixel-wide ARGB8888 blits, so one
GPU page becomes one blit row. Large copies are split into chunks of at
most 8191 rows.

The kernel register header names the packet coordinate dwords SRC_Y_X
and DST_Y_X. In the BITBLT_MULTI description in
R5xx_Acceleration_v1.5.pdf docs, these correspond to [SRC_X1 | SRC_Y1]
and [DST_X1 | DST_Y1], which are signed 13-bit coordinates in the
-8192..8191 range. The old code kept SRC/DST_PITCH_OFFSET at the BO base
and used SRC_Y_X/DST_Y_X as the chunk address, so large BO moves could
exceed that coordinate range.

Compute per-chunk SRC/DST_PITCH_OFFSET bases and emit zero source and
destination coordinates. r100_copy_blit() already packs
SRC/DST_PITCH_OFFSET as pitch plus base offset, so large chunk addresses
belong there rather than in the coordinate fields.

This fixes Prison Architect corruption with 4096x4096 mipped textures
after they are evicted to GTT under memory pressure on RV530.

Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/6716
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Pavel Ondračka &lt;pavel.ondracka@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/radeon/radeon_connectors: remove radeon_connector_free_edid</title>
<updated>2026-05-27T14:51:19+00:00</updated>
<author>
<name>Joshua Peisach</name>
<email>jpeisach@ubuntu.com</email>
</author>
<published>2026-05-23T14:27:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c9b2ad100b10dabe0bea691001b0808b4f0fcc55'/>
<id>c9b2ad100b10dabe0bea691001b0808b4f0fcc55</id>
<content type='text'>
Since we are using struct drm_edid, we can call drm_edid_free directly.
Also make sure to set the pointer to NULL afterwards.

Signed-off-by: Joshua Peisach &lt;jpeisach@ubuntu.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since we are using struct drm_edid, we can call drm_edid_free directly.
Also make sure to set the pointer to NULL afterwards.

Signed-off-by: Joshua Peisach &lt;jpeisach@ubuntu.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
