| Summary: | [Baytrail-M edp] link training failures on resume | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | shui yangwei <yangweix.shui> | ||||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
| Severity: | major | ||||||||||
| Priority: | medium | CC: | intel-gfx-bugs | ||||||||
| Version: | unspecified | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
|
Description
shui yangwei
2013-09-12 05:44:08 UTC
Those times are consistent with the panel delays specified by the manufacturer of the panel. There are a few silly timeouts, but they are tiny compared to the panel waits. We might get away with not waiting on power down for suspend. (In reply to comment #1) > Those times are consistent with the panel delays specified by the > manufacturer of the panel. There are a few silly timeouts, but they are tiny > compared to the panel waits. We might get away with not waiting on power > down for suspend. Now, kernels can't resume from S3, so this bug is blocked by : Bug 67731 - [Baytrail-M] system can't resume from S3/S4 There's another S3 bug you can track too: Bug 69166 - [Baytrail-M] Monitor can't light up after resuming from S3 Sorry, our platform is unstable, today S3 is able to resume again. And I tested 3 response time again. Test results listed below: With eDP panel: ------------------------ Acquire initcall time: 1613.640 msecs Acquire suspend time: 841.988 msecs Acquire resume time: 10057.757 msecs Non-eDP (disable eDP panel): ------------------------ Acquire initcall time: 131.216 msecs Acquire suspend time: 10.115 msecs Acquire resume time: 1973.709 msecs So might be the eDP panel cause quite longer response time. Looks to be much faster on mine: [ 23.184985] call 0000:00:02.0+ returned 0 after 804979 usecs so I'd say this is probably panel specific. We may be able to make the panel resume more asynchronous, but ultimately the user experience will be gated on the panel, so it wouldn't do much good. So I'd say we can close this one if/until we get a platform where we're not meeting a specific resume time target even though the platform supports it. Created attachment 87313 [details]
dmesg: HSW Desktop 3 response time.
HSW Desktop with the same eDP panel of Baytrail:
------------------------
Acquire initcall time:
1599.312 msecs (Baytrail: 1613.640 msecs)
Acquire suspend time:
1018.271 msecs (Baytrail: 841.988 msecs)
Acquire resume time:
576.649 msecs (Baytrail: 10057.757 msecs)
Using the same eDP panel to test the response time on HSW Desktop, the resume time isn't that large even though we also have a bug to track it. Can you help me to analyse the data and tell me what should I do. I append the dmesg on HSW Desktop, and hope it's useful for you.
The original BYT dmesg is filled with display port link training issues. It's obvious the resume time goes ballistic if we keep retrying the link training. Also note that we get the panel power sequencing timings from VBT, so the panel enable time even with the same panel is going to be different between HSW and BYT. I've fixed a number of DP link training issues lately. Please try the latest drm-intel-nightly on BYT, and see if that helps. Attach dmesg with debugs enabled if it still fails. Thanks. Created attachment 87365 [details] dmesg: with new CPU and updated BIOS (In reply to comment #6) > The original BYT dmesg is filled with display port link training issues. > It's obvious the resume time goes ballistic if we keep retrying the link > training. > > Also note that we get the panel power sequencing timings from VBT, so the > panel enable time even with the same panel is going to be different between > HSW and BYT. > > I've fixed a number of DP link training issues lately. Please try the latest > drm-intel-nightly on BYT, and see if that helps. Attach dmesg with debugs > enabled if it still fails. Thanks. We updated our cpu to "VGA Gen 7 id=0f31", and BIOS updated to "v61.R22 X64", then I use latest -nightly and find eDP resume time is similar with HSW Desktop now. Acquire initcall time: 1386.488 msecs (HSW Desktop: 1599.312 msecs) Acquire suspend time: 825.701 msecs (HSW Desktop: 1018.271 msecs) Acquire resume time: 767.916 msecs (HSW Desktop: 576.649 msecs) Resolving fixed, although we don't really know which change (in kernel or in your platform) fixed it. Presuming there are no link training erros in dmesg now. Please reopen if those pop up. There seems to have been a regression of response time on BYT machine with eDP. I reported a new bug(Bug 72210). Closing old verified. |
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.