> -----Original Message----- > From: Metrical revel <[email protected]> > Sent: Thursday, September 10, 2026 10:13 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, > > 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). > Thanks for the test results.
> 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 Regarding the Sashiko comment, Will replace write with mask/write. > 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 DP2.1 Spec, Section 2.3.1.2 says if the sink is in sleep > for panels that actually need the D3_AUX_ON state. > As per the spec if the sink is in sleep, exit from sleep will happened within 1ms, so trying to wake it after 1ms again. D3_AUX_ON will keep AUX_ON, and D0 will wake take it to normal operation mode. The code path succeeding this will be link training so hence keeping it on D0. Thanks and Regards, Arun R Murthy ------------------- > 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
