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
> + goto fail;
> + }
> +
> ret = drm_atomic_helper_check_modeset(dev, state);
> if (ret) {
> drm_dbg_atomic(dev, "drm_atomic_helper_check_modeset()
> failed\n");
