[PATCH v2] drm/i915/psr: Disable eDP Panel Replay on XPS 16 DA16260 (LG 0x07C5)

[Thierry Cantin-Demers <thierrycantindemers@gmail.com>]

The Dell XPS 16 DA16260 ships in more than one panel variant. The existing
quirk that disables Panel Replay on this laptop (added to fix the low
refresh rate / stutter in issue #7682) only matches the LG Display panel
with DPCD sink OUI 00:22:b9.

Another unit of the same laptop (subsystem 1028:0dba) uses an LG Display
0x07C5 panel with sink OUI 00:aa:01. It shows the identical symptom: the
internal eDP panel updates at only ~5 fps while external displays stay
smooth, with Panel Replay Selective Update stuck (i915_psr_status cycling
SLEEP/SU_STANDBY, no error). Because the OUI differs the existing quirk
does not match and Panel Replay stays enabled.

Add a quirk entry for OUI 00:aa:01 so this variant also gets eDP Panel
Replay disabled. Confirmed xe.enable_panel_replay=0 and a kernel with
this quirk both resolve the stutter.

Fixes: cb8d155b0806 ("drm/i915/psr: Disable Panel Replay on Dell XPS 16 DA16260 as a quirk")
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7682
Signed-off-by: Thierry Cantin-Demers <thierrycantindemers@gmail.com>
Tested-by: Thierry Cantin-Demers <thierrycantindemers@gmail.com>
---
Hi Jouni,

Thanks for looking. After capturing full drm.debug=0xe logs I should
correct my original description: this does not appear to be a Link CRC
error. That was a one-off reading I have not been able to reproduce.

With Panel Replay enabled and the panel stuck at ~5 fps, i915_psr_status
just cycles SLEEP / SU_STANDBY with no error, and a full drm.debug dmesg
shows nothing. It really seems to be the same low refresh rate / stutter
you already handled in issue #7682:

  https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7682

My machine is the same laptop (XPS 16 DA16260, subsystem 1028:0dba) and
seems to reproduce in the same way, including with no external display
attached: applying a gamma LUT via wlr-gamma-control (I use gammad) early
in the session is enough to leave the panel stuck. The main difference
from #7682 is the panel: mine is an LG Display 0x07C5 with DPCD sink OUI
00:aa:01, so the quirk from cb8d155b0806 (which matches 00:22:b9) does not
cover it and Panel Replay stays enabled.

xe.enable_panel_replay=0 resolves it, and a kernel with the quirk
extended to 00:aa:01 does too. This v2 drops the CRC wording and
references #7682. Happy to test any alternative you prefer.

Rather than open a new ticket right away, I went back and captured proper
logs, and once the CRC description turned out to be wrong it looked like
the same problem as #7682 rather than a new one, so a one-line quirk
extension seemed like the least noisy way to handle it. If after this you
still think it is something different, just let me know and I will gladly
file a fresh gitlab ticket with the full logs.

Thanks a lot for your time,
Thierry

v1 -> v2:
 - Reword: describe as the #7682 low-refresh-rate stutter, not a CRC error
 - Add Link: to issue #7682

 drivers/gpu/drm/i915/display/intel_quirks.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c b/drivers/gpu/drm/i915/display/intel_quirks.c
index 33245f44c0d5..e452235832fe 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -286,6 +286,14 @@ static const struct intel_dpcd_quirk intel_dpcd_quirks[] = {
 		.sink_oui = SINK_OUI(0x00, 0x22, 0xb9),
 		.hook = quirk_disable_edp_panel_replay,
 	},
+	/* Dell XPS 16 DA16260 (LG Display 0x07C5, OUI 00:aa:01) */
+	{
+		.device = DEVICE_ID_ANY,
+		.subsystem_vendor = 0x1028,
+		.subsystem_device = 0x0dba,
+		.sink_oui = SINK_OUI(0x00, 0xaa, 0x01),
+		.hook = quirk_disable_edp_panel_replay,
+	},
 };
 
 void intel_init_quirks(struct intel_display *display)
-- 
2.55.0