Hi all,
tl;dr: I've discovered what appears to be some kind of timing issue with DP link training on new hardware. I applied a hacky fix locally, but I need help with coming up with a real fix that we can actually use.
I recently got a new laptop, a Thinkpad X1 Extreme Gen 3, with an OLED display. I've been trying to debug inconsistent behavior during resume where the display would not power on the majority of the time.
This is all the first time I've ever worked with this stuff, so I have no idea what I'm really doing and so anything I say here might be wrong. When comparing logs between a good and bad resume, I noticed the following:
* Failed resumes would result in "Max Voltage Swing reached", and "Link Training failed".
* Successful and failed resumes would have the exact same behavior regarding link training in the logs, right up until the end, where for a bad resume. we'd read the following register state:
[drm:drm_dp_dpcd_read [drm_kms_helper]] AUX A/DDI A/PHY A: 0x00202 AUX -> (ret= 6) 00 00 00 00 22 22
and a good resume:
[drm:drm_dp_dpcd_read [drm_kms_helper]] AUX A/DDI A/PHY A: 0x00202 AUX -> (ret= 6) 77 77 81 01 22 22
This led me to think that there's some kind of timing issue here where we're reading the register before it's fully populated. To test that, I added an additional 20ms sleep to intel_dp_link_training_clock_recovery right after the call to intel_dp_link_training_clock_recovery_delay. I attached the hack patch to the issue I filed tracking this: https://gitlab.freedesktop.org/drm/intel/-/issues/3173
Since applying that patch, everything has been working perfectly. So now I'd love to figure out how to get this into a real fix, but I don't really know what to propose beyond my current hack of "wait longer".
Thanks in advance for any assistance!
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
