All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Polack <spolack+git@mailbox.org>
To: Harry Wentland <harry.wentland@amd.com>, Leo Li <sunpeng.li@amd.com>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Rodrigo Siqueira" <siqueira@igalia.com>,
	"Ray Wu" <ray.wu@amd.com>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/amd/display: Fix stale replay_events after mod_power stream removal
Date: Thu, 17 Sep 2026 12:42:34 +0200	[thread overview]
Message-ID: <20260917104234.18858-1-spolack+git@mailbox.org> (raw)

[Why]
mod_power_remove_stream() shifts the remaining power_entity slots down
but does not move replay_events, and mod_power_add_stream() does not
initialize it. replay_events therefore stay bound to the map slot
instead of the stream.

When several streams are disabled in one atomic commit,
amdgpu_dm_mod_power_update_streams() removes them one after another.
The eDP stream can then be looked up in a slot whose stale
replay_events already have replay_event_hw_programming set, so
amdgpu_dm_replay_set_event() returns early ("already in desired state")
without calling mod_power_set_replay_event(). Replay is not disabled
before the eDP panel is powered off. After DPMS on, the sink reports
neither replay state nor frame lock (DPCD 0x378 = 0x00, no error bits),
so the HPD IRQ recovery does not trigger and the panel stays black
until a full modeset.

Seen with an eDP panel using FreeSync Replay plus two DP-MST displays:
DPMS off/on of all outputs leaves eDP black, while DPMS of eDP alone
works. Doing an eDP-only DPMS first makes the next all-output DPMS
fail reliably.

[How]
Shift replay_events together with the PSR cached fields in
mod_power_remove_stream() and initialize it to replay_event_vsync in
mod_power_add_stream(), matching the psr_event_vsync initial value used
for PSR (both vsync events are driven together by
amdgpu_dm_crtc_set_static_screen_optimze()).

Tested on 7.3.0-rc3 (238650ef6c7c): the reproducer above now recovers
reliably, and Replay still engages when the screen is idle.

The issue was debugged with help from an AI assistant (Claude), which
analysed ftrace/kprobe traces and the driver source, pointed to the
missing replay_events handling and suggested this change. I collected
the traces and built and tested the fix on the affected hardware.

Fixes: 4cef2ac4c795 ("drm/amd/display: Introduce power module on Linux")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
---
Based on v7.3-rc3 (238650ef6c7c), where it was tested; also applies to
amd-staging-drm-next.

This does not address why stale replay_events can reach the eDP slot
with replay_event_hw_programming already set in the first place; with
per-stream bookkeeping that state is consistent again. Traces
(kprobes/fprobes on the Replay path, eDP-only vs. all-output DPMS) and
DPCD dumps are available on request.

 drivers/gpu/drm/amd/display/modules/power/power.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/modules/power/power.c b/drivers/gpu/drm/amd/display/modules/power/power.c
index 2f9690e65ca9..d900be8cb5fc 100644
--- a/drivers/gpu/drm/amd/display/modules/power/power.c
+++ b/drivers/gpu/drm/amd/display/modules/power/power.c
@@ -328,6 +328,7 @@ bool mod_power_add_stream(struct mod_power *mod_power,
 		core_power->map[core_power->num_entities].psr_enabled = 0;
 		core_power->map[core_power->num_entities].psr_events = psr_event_vsync;
 		core_power->map[core_power->num_entities].psr_power_opt = 0;
+		core_power->map[core_power->num_entities].replay_events = replay_event_vsync;
 		core_power->num_entities++;
 		return true;
 	}
@@ -387,6 +388,7 @@ bool mod_power_remove_stream(struct mod_power *mod_power,
 		core_power->map[i].psr_enabled = core_power->map[i + 1].psr_enabled;
 		core_power->map[i].psr_events = core_power->map[i + 1].psr_events;
 		core_power->map[i].psr_power_opt = core_power->map[i + 1].psr_power_opt;
+		core_power->map[i].replay_events = core_power->map[i + 1].replay_events;
 
 		memcpy(core_power->map[i].psr_context, core_power->map[i + 1].psr_context, sizeof(struct mod_power_psr_context));
 		memset(core_power->map[i + 1].psr_context, 0, sizeof(struct mod_power_psr_context));

base-commit: 238650ef6c7c7cca08e032527329424c9fbd70e5
-- 
2.55.0


             reply	other threads:[~2026-09-18  7:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 10:42 Simon Polack [this message]
2026-09-24 17:25 ` [PATCH] drm/amd/display: Fix stale replay_events after mod_power stream removal Leo Li
2026-10-01 11:12   ` Simon Polack
2026-10-01 21:25     ` Alex Deucher

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=20260917104234.18858-1-spolack+git@mailbox.org \
    --to=spolack+git@mailbox.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=ray.wu@amd.com \
    --cc=siqueira@igalia.com \
    --cc=sunpeng.li@amd.com \
    /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.