On 10/14/2025 1:20 PM, Harry Wentland wrote:
On 2025-10-09 16:55, Mario Limonciello wrote:
[Why]
If userspace hasn't frozen user processes (like systemd does with
user.slice) then an aborted hibernate could give control back to
userspace before display hardware is resumed. IoW an atomic commit could
be done while the hardware is in D3, which could hang a system.
[How]
Add a check whether the IP block hardware is ready to the atomic check
handler and return a failure. Userspace shouldn't do an atomic commit if
the atomic check fails.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4627
Signed-off-by: Mario Limonciello <[email protected]>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6f5be090b744..5a189deac631 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -12014,6 +12014,11 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
trace_amdgpu_dm_atomic_check_begin(state);
+ if (WARN_ON(unlikely(!amdgpu_device_ip_is_hw(adev, AMD_IP_BLOCK_TYPE_DCE)))) {
+ ret = -ENXIO;
ENXIO means no such device or address. Wouldn't that
potentially confuse userspace when they debug issues
where we return ENXIO? My understanding is that this is
a transient error, so maybe an -EBUSY might be better?
Harry
Thanks, that makes a lot of sense. I'll update and resend.
+ goto fail;
+ }
+
ret = drm_atomic_helper_check_modeset(dev, state);
if (ret) {
drm_dbg_atomic(dev, "drm_atomic_helper_check_modeset()
failed\n");
