All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jakob Linke" <jakob@linke.cx>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu/soc24: reset dGPU if suspend got aborted
Date: Wed, 17 Jun 2026 06:45:02 +0000	[thread overview]
Message-ID: <20260617064503.3BF2D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260617062415.19898-1-jakob@linke.cx>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Unconditional 100ms delay added to all normal S3 resumes due to a missing suspend-abort check.
- [Medium] Flawed condition or contradictory documentation for detecting suspend abort.
--

commit f65d16d9bd092a9093fda22e85afb7762ebbe6a5
Author: Jakob Linke <jakob@linke.cx>

drm/amdgpu/soc24: reset dGPU if suspend got aborted

For SOC24 ASICs (RDNA4 / Navi 4x dGPUs) re-enabling PM features fails if an
S3 suspend got aborted. Apply the same workaround as soc15 and soc21 to
detect the aborted-suspend state and reset the device before re-init.

> diff --git a/drivers/gpu/drm/amd/amdgpu/soc24.c b/drivers/gpu/drm/amd/amdgpu/soc24.c
> index 265db9331d0bb..9dce30d2bb8d3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/soc24.c
> +++ b/drivers/gpu/drm/amd/amdgpu/soc24.c
[ ... ]
> @@ -496,8 +496,36 @@ static int soc24_common_suspend(struct amdgpu_ip_block *ip_block)
>  	return soc24_common_hw_fini(ip_block);
>  }
>  
> +static bool soc24_need_reset_on_resume(struct amdgpu_device *adev)
> +{
> +	u32 sol_reg1, sol_reg2;
> +
> +	/* Will reset for the following suspend abort cases.
> +	 * 1) Only reset dGPU side.
> +	 * 2) S3 suspend got aborted and TOS is active.
> +	 *    As for dGPU suspend abort cases the SOL value
> +	 *    will be kept as zero at this resume point.
> +	 */
> +	if (!(adev->flags & AMD_IS_APU) && adev->in_s3) {
> +		sol_reg1 = RREG32_SOC15(MP0, 0, regMPASP_SMN_C2PMSG_81);
> +		msleep(100);

[Severity: Medium]
Does this add an unconditional 100ms delay to all S3 resumes?

Since adev->in_s3 is true during all S3 resumes, not just aborted ones, this
path seems to execute and sleep every time the system normally wakes up.

Could this use a fast-path check, like skipping the sleep if sol_reg1 is
non-zero, or perhaps checking !pm_resume_via_firmware() similar to what the
soc15 workaround does?

> +		sol_reg2 = RREG32_SOC15(MP0, 0, regMPASP_SMN_C2PMSG_81);
> +
> +		return (sol_reg1 != sol_reg2);

[Severity: Medium]
Is the block comment above accurate about the SOL value behavior?

The comment states that for dGPU suspend abort cases, the SOL value will be
kept as zero at this resume point. If both sol_reg1 and sol_reg2 read as zero,
the condition (0 != 0) will evaluate to false, and the reset will not be
triggered.

If the SOL registers stay zero during an abort, does this logic actually fail
to detect the abort case entirely?

> +	}
> +
> +	return false;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617062415.19898-1-jakob@linke.cx?part=1

      reply	other threads:[~2026-06-17  6:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17  6:24 [PATCH] drm/amdgpu/soc24: reset dGPU if suspend got aborted Jakob Linke
2026-06-17  6:45 ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260617064503.3BF2D1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jakob@linke.cx \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.