Bug 101815 - [IGT][SKL] Failed to enable DP link training on resume when testing with Chamelium
Summary: [IGT][SKL] Failed to enable DP link training on resume when testing with Cham...
Status: CLOSED NOTABUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-17 08:34 UTC by Paul Kocialkowski
Modified: 2017-07-21 16:48 UTC (History)
1 user (show)

See Also:
i915 platform: SKL
i915 features: display/DP


Attachments
dmesg from 20170717 drm-tip (201.44 KB, text/plain)
2017-07-17 08:34 UTC, Paul Kocialkowski
no flags Details

Description Paul Kocialkowski 2017-07-17 08:34:52 UTC
Created attachment 132728 [details]
dmesg from 20170717 drm-tip

i915 fails to perform link training on resume with a Chamelium attached to the DP connector. This is triggered by launching one of the DP suspend/resume IGT chamelium tests such as dp-hpd-after-suspend or dp-edid-change-during-suspend.

The error appears to be: dp_aux_ch timeout status 0x7d4003ff (full dmesg from today's drm-tip is attached).

Information about the setup:
* Kernel: drm-tip 0ea81ff8a340aa1f2bc863f4c8e631542e47c98e
* Distro: Arch Linux (NOT using the distro's kernel)
* CPU: i5-6600K

Ironically, it makes the IGT test pass because a hotplug uevent is generated because of link training failure.
Comment 1 Martin Peres 2017-07-17 08:39:57 UTC
Updating some fields.
Comment 2 Paul Kocialkowski 2017-07-17 13:55:11 UTC
This issue is actually not related to the DP connector that is connected to the Chamelium but to another DP connector that has a DP-VGA bridge attached. The bridge is taking a while to get back up after resume and thus causes the AUX channel timeouts. After a while (a second or two), it gets back up and i915 properly handles it, so I don't think there's an issue here.

The reason why I reported this was that the link training failure generates a uevent that is mistakenly taken as the one resulting from the thing we want to test (either hpd or edid change). There's no problem affecting end users aside of that.

However, I noticed that the connector name is not printed on the link-training-failure-related messages, so I will craft a simple patch adding the connector name to the messages, to avoid similar confusion in the future.

Closing the issue for now since the issue is on the bridge's side and i915 already handles it like a champ'.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.