On Tue, Oct 14, 2025 at 3:46 PM Mario Limonciello <[email protected]> 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.
Is there any way to prevent this altogether? This seems like a recipe for trouble for any driver. Alex > > [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]> > --- > Cc: Harry Wentland <[email protected]> > v2: > * Return -EBUSY instead (Harry) > --- > 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 6446ec6c21d4..f5cd9982af99 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -12010,6 +12010,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 = -EBUSY; > + goto fail; > + } > + > ret = drm_atomic_helper_check_modeset(dev, state); > if (ret) { > drm_dbg_atomic(dev, "drm_atomic_helper_check_modeset() > failed\n"); > -- > 2.49.0 >
