Re: [PATCH] drm/amdgpu: use dirty framebuffer helper
From: root
Date: Sun Sep 18 2022 - 08:14:45 EST
Hi, I recently experienced lock-ups that only responded to magic sysreq
reboots when the amdgpu module was loading on my pc (Athlon II X4 640 CPU,
with Radeon R7 250 - Cape Verde).
.config has:
CONFIG_DRM_AMDGPU=m
CONFIG_DRM_AMDGPU_SI=y
# CONFIG_DRM_AMDGPU_CIK is not set
# CONFIG_DRM_AMDGPU_USERPTR is not set
kernel command line has:
amdgpu.audio=1 amdgpu.si_support=1 radeon.si_support=0 page_owner=on \
amdgpu.gpu_recovery=1
Bisecting lead to:
commit 66f99628eb24409cb8feb5061f78283c8b65f820
Author: Hamza Mahfooz <hamza.mahfooz@xxxxxxx>
Date: Tue Sep 6 15:01:49 2022 -0400
drm/amdgpu: use dirty framebuffer helper
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@xxxxxxx>
Acked-by: Alex Deucher <alexander.deucher@xxxxxxx>
Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index c20922a5af9f..5b09c8f4fe95 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,7 @@
#include <linux/pci.h>
#include <linux/pm_runtime.h>
#include <drm/drm_crtc_helper.h>
+#include <drm/drm_damage_helper.h>
#include <drm/drm_edid.h>
#include <drm/drm_gem_framebuffer_helper.h>
#include <drm/drm_fb_helper.h>
@@ -496,6 +497,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector *amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
After doing a git bisect reset, git pull and reverting the patch above, I
rebuilt the kernel and am successfully running with the amdgpu module loaded
and using the Radeon R7 250 GPU.
I am happy to supply any further configuration details.
Arthur Marsh.