linux-stable.git/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c, branch linux-5.15.y

Revert "drm/amd: flush any delayed gfxoff on suspend entry"

2024-02-23T07:55:05+00:00

commit 916361685319098f696b798ef1560f69ed96e934 upstream.

commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring
callbacks") caused GFXOFF control to be used more heavily and the
codepath that was removed from commit 0dee72639533 ("drm/amd: flush any
delayed gfxoff on suspend entry") now can be exercised at suspend again.

Users report that by using GNOME to suspend the lockscreen trigger will
cause SDMA traffic and the system can deadlock.

This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.

Acked-by: Alex Deucher 
Fixes: ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks")
Signed-off-by: Mario Limonciello 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd: flush any delayed gfxoff on suspend entry

2023-08-26T12:23:37+00:00

commit a7b7d9e8aee4f71b4c7151702fd74237b8cef989 upstream.

DCN 3.1.4 is reported to hang on s2idle entry if graphics activity
is happening during entry.  This is because GFXOFF was scheduled as
delayed but RLC gets disabled in s2idle entry sequence which will
hang GFX IP if not already in GFXOFF.

To help this problem, flush any delayed work for GFXOFF early in
s2idle entry sequence to ensure that it's off when RLC is changed.

commit 4b31b92b143f ("drm/amdgpu: complete gfxoff allow signal during
suspend without delay") modified power gating flow so that if called
in s0ix that it ensured that GFXOFF wasn't put in work queue but
instead processed immediately.

This is dead code due to commit 10cb67eb8a1b ("drm/amdgpu: skip
CG/PG for gfx during S0ix") because GFXOFF will now not be explicitly
called as part of the suspend entry code.  Remove that dead code.

Signed-off-by: Mario Limonciello 
Signed-off-by: Tim Huang 
Reviewed-by: Lijo Lazar 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: complete gfxoff allow signal during suspend without delay

2023-02-01T07:27:22+00:00

commit 4b31b92b143f7d209f3d494c56d4c4673e9fc53d upstream.

change guarantees that gfxoff is allowed before moving further in
s2idle sequence to add more reliablity about gfxoff in amdgpu IP's
suspend flow

Signed-off-by: Harsh Jain 
Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Cc: "Limonciello, Mario" 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix off by one in amdgpu_gfx_kiq_acquire()

2022-04-13T18:59:14+00:00

[ Upstream commit 1647b54ed55d4d48c7199d439f8834626576cbe9 ]

This post-op should be a pre-op so that we do not pass -1 as the bit
number to test_bit().  The current code will loop downwards from 63 to
-1.  After changing to a pre-op, it loops from 63 to 0.

Fixes: 71c37505e7ea ("drm/amdgpu/gfx: move more common KIQ code to amdgpu_gfx.c")
Signed-off-by: Dan Carpenter 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: During s0ix don't wait to signal GFXOFF

2021-10-05T14:55:07+00:00

In the rare event when GFX IP suspend coincides with a s0ix entry, don't
schedule a delayed work, instead signal PMFW immediately to allow GFXOFF
entry. GFXOFF is a prerequisite for s0ix entry. PMFW needs to be
signaled about GFXOFF status before amd-pmc module passes OS HINT
to PMFW telling that everything is ready for a safe s0ix entry.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1712

Signed-off-by: Lijo Lazar 
Reviewed-by: Alex Deucher 
Reviewed-by: Mario Limonciello 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org

drm/amdgpu: Cancel delayed work when GFXOFF is disabled

2021-08-20T16:09:44+00:00

schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-enabled again during those 100 ms.

This resulted in frame drops / stutter with the upcoming mutter 41
release on Navi 14, due to constantly enabling GFXOFF in the HW and
disabling it again (for getting the GPU clock counter).

To fix this, call cancel_delayed_work_sync when the disable count
transitions from 0 to 1, and only schedule the delayed work on the
reverse transition, not if the disable count was already 0. This makes
sure the delayed work doesn't run at unexpected times, and allows it to
be lock-free.

v2:
* Use cancel_delayed_work_sync & mutex_trylock instead of
  mod_delayed_work.
v3:
* Make amdgpu_device_delay_enable_gfx_off lock-free (Christian König)
v4:
* Fix race condition between amdgpu_gfx_off_ctrl incrementing
  adev->gfx.gfx_off_req_count and amdgpu_device_delay_enable_gfx_off
  checking for it to be 0 (Evan Quan)

Cc: stable@vger.kernel.org
Reviewed-by: Evan Quan 
Reviewed-by: Lijo Lazar  # v3
Acked-by: Christian König  # v3
Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher

drm/amd/amdgpu: remove unnecessary RAS context field

2021-08-16T19:35:55+00:00

Delete ras_if->name in the RAS ctx structure and remove related lines.

Signed-off-by: Candice Li 
Reviewed-by: John Clements 
Signed-off-by: Alex Deucher

drm/amdgpu: Conditionally reset RAS counters on boot

2021-05-20T02:38:11+00:00

Only clear RAS error counters if perestent EDC harvesting is not supported

Reviewed-by: Hawking Zhang 
Signed-off-by: John Clements 
Signed-off-by: Alex Deucher

drm/amdgpu: split gfx callbacks into ras and non-ras ones

2021-04-09T20:51:22+00:00

gfx ras is only available in cerntain ip generations.

Signed-off-by: Hawking Zhang 
Reviewed-by: Dennis Li 
Reviewed-by: John Clements 
Signed-off-by: Alex Deucher

drm/amd/pm: unify the interface for gfx state setting

2021-04-09T20:46:51+00:00

No need to have special handling for swSMU supported ASICs.

Signed-off-by: Evan Quan 
Reviewed-by: Lijo Lazar 
Signed-off-by: Alex Deucher