Hi Arun,
Tested v6 on my HP Victus 15 (Raptor Lake-P), compiled against
linux-zen v7.2.2 with the v6 patch applied.
Ran multiple suspend/resume cycles (both `systemctl suspend` and lid
close) with drm.debug=0x1e:
journalctl -k -b 0 | grep -c "Failed to enable link training"
0
Display resumed instantly in every cycle, ~2s to fully exit deep
suspend. No trace of the eDP link-training failure that was
consistently reproducible before this patch (or on unpatched
7.2.2).
Also checked i915.CI.Full for v6 -- only 2 flagged regressions, both
unrelated HDMI cursor tests (kms_cursor_edge_walk, pipe-d-hdmi-a-4),
nothing on eDP this time. Looks like the read_byte/timeout issue
from v5 is resolved.
One thing worth flagging alongside Sashiko's bitmask comment before
this lands: the wake sequence writes DP_SET_POWER_D0 twice --
drm_dp_dpcd_write_byte(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
fsleep(1000);
drm_dp_dpcd_write_byte(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
The comment right above it still says "wake it up to D3_AUX_ON", and
earlier revisions (v3/v4) wrote D3_AUX_ON on the second call per
DP2.1 sec 2.3.1.2. Looks like it may have been dropped during the v5
simplification. It didn't stop the fix from working for my case, but
might matter for panels that actually need the D3_AUX_ON state.
Tested-by: Mathias Sebastián Vargas Silva <[email protected]>
Thanks,
Mathias
El lun, 7 sept 2026 a la(s) 10:20 p.m., Murthy, Arun R
([email protected]) escribió:
>
> Mathias,
> There seems to a bug in the poll with the replacement of readb with read_byte
> related to timeout. I will have to fix that and also received few comments as
> well. Let me fix those and will post a new version which you can use for
> testing.
>
> Thanks and Regards,
> Arun R Murthy
> --------------------
>
> > -----Original Message-----
> > From: Metrical revel <[email protected]>
> > Sent: Tuesday, September 8, 2026 2:23 AM
> > To: Murthy, Arun R <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [PATCHv4] drm/i915/dp: On DPCD init wake the DPRx for eDP
> >
> > Hi Arun,
> >
> > (Replying by email since patchwork doesn't support direct comments —
> > apologies if this duplicates my GitLab note.)
> >
> > Noticed v5's i915.CI.BAT is passing now — good sign the build issue is
> > resolved.
> >
> > Before I compile and test v5 on my hardware for a Tested-by, I wanted to
> > flag
> > something from i915.CI.Full that looks a bit more specific than the usual
> > noise
> > we saw on v1/v3:
> >
> > igt@kms_cursor_crc@cursor-rapid-movement-128x128@pipe-a-edp-1:
> > shard-mtlp: PASS -> ABORT +1 other test abort
> >
> > igt@kms_cursor_crc@cursor-rapid-movement-128x128@pipe-d-edp-1:
> > shard-mtlp: PASS -> DMESG-WARN
> >
> > Unlike the earlier CI flags (which were all in unrelated subsystems like
> > gem_ccs/kms_plane_lowres), these two are both on eDP-1 specifically, same
> > shard, same test family, both regressing from PASS. Is this known/expected
> > noise on shard-mtlp, or worth digging into given it touches the exact
> > connector
> > this patch modifies?
> >
> > Happy to go ahead and test v5 on my hardware for a Tested-by either way —
> > just didn't want to give a Tested-by without flagging this first.
> >
> > Thanks,
> > Mathias
