Created attachment 85690 [details] dmesg: 3 response time Environment: -------------------- Kernel: (drm-intel-next-queued)6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Sep 10 14:54:42 2013 -0700 drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT lspci: -------------------- 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0a) Description: -------------------- On Baytrail, 3 response time of i915 init,suspend and resume are quite larger than expected. I list the result below: Acquire initcall time: 1661.503 msecs Acquire suspend time: 831.419 msecs Acquire resume time: 9375.159 msecs Another IVB mobile(Apple MacBook Pro) 3 response time of eDP: Acquire initcall time: 2465.873 msecs Acquire suspend time: 1304.496 msecs Acquire resume time: 1036.836 msecs Steps: -------------------- 1. booting with kernel command: "initcall_debug drm.debug=0xe" 2. dmesg | grep -i -e "i915_init|PM:.*complete|00:02.0+" 3. calculate related times
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.