wireguard-linux/drivers/gpu/drm/radeon, branch stable

drm/radeon: fix autosuspend cleanup during teardown

2026-08-12T13:39:44Z

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 Signed-off-by: Alex Deucher

drm/radeon: restore hardware polling in fence_is_signaled to fix performance regression

2026-08-06T16:50:02Z

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(&rdev->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 Signed-off-by: Wang Jiang Signed-off-by: Alex Deucher

drm/radeon: Only define radeon_acpi_vfct_match when actually used

2026-07-16T22:27:48Z

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 Signed-off-by: Alex Deucher

drm/radeon: Validate VBIOS signature in VFCT path

2026-07-15T13:15:41Z

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 Link: https://patch.msgid.link/20260708193518.702584-6-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher

drm/radeon: Fix VFCT bus number matching with soft filter

2026-07-15T13:15:41Z

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 Link: https://patch.msgid.link/20260708193518.702584-5-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher

drm/radeon: Modernize VFCT error handling

2026-07-15T13:15:41Z

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 Link: https://patch.msgid.link/20260708193518.702584-4-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher

drm/radeon: avoid double free in r600 DPM cleanup

2026-06-17T20:23:16Z

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 Signed-off-by: Alex Deucher

drm/radeon: fix r100_copy_blit for large BOs

2026-06-17T20:22:25Z

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 Signed-off-by: Pavel Ondračka Signed-off-by: Alex Deucher

drm/radeon/radeon_connectors: remove radeon_connector_free_edid

2026-05-27T14:51:19Z

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 Signed-off-by: Alex Deucher

drm/radeon/radeon_connectors: use struct drm_edid instead of struct edid

2026-05-27T14:51:15Z

This was done with amdgpu, just bringing the same patch to radeon. The goal of this is to stop using the deprecated edid functions, specifically drm_connector_update_edid_property. Switch to struct drm_edid and the appropriate function replacements for the new type. Also, for audio, use the raw edid for SADB allocations and for equivalent drm_edid_is_digital expressions. Signed-off-by: Joshua Peisach Signed-off-by: Alex Deucher