==System Environment== -------------------------- platforms: skylake-y cpu: C0 stepping pch: B0 stepping BIOS: V84 ==kernel== -------------------------- Ubuntu 14.04 LTS 64 bits mainline 4.1-rc6 ==Bug detailed description== ----------------------------- suspend/resume time for 0000:00:02.0+ is 200ms+, $ lspci 00:02.0 VGA compatible controller: Intel Corporation Device 191e (rev 02) log: [ 746.760346] call 0000:00:02.0+ returned 0 after 280934 usecs ... [ 747.309040] PM: suspend of devices complete after 845.974 msecs ... [ 747.391298] PM: noirq suspend of devices complete after 61.672 msecs [ 747.391306] PM: suspend-to-idle [ 754.542631] PM: resume from suspend-to-idle ... [ 754.912154] call 0000:00:02.0+ returned 0 after 261735 usecs ... [ 759.737839] PM: resume of devices complete after 5092.997 msecs [ 759.743245] PM: Finishing wakeup. [ 759.743248] Restarting tasks ... done. ==Reproduce steps== ---------------------------- 1. echo mem > /sys/power/state 2. Resume by pressing power button or rtcwake I also used the opensource tool SuspendResume to capture the time during suspend/resume, and please find attached the ftrace/dmesg together with a graphic view for these drivers. ==Expect result== suspend/resume time drops to less than 50ms, or is this normal to cost 200ms on SKLAKE-Y? Thanks Best Regards, Yu
Created attachment 116347 [details] dmesg during suspend/resume from freeze
Please try drm-intel-nightly, add drm.debug=14 module parameter and attach dmesg all the way from boot to the suspend/resume cycle. Add log_buf_len=4M or similar to capture everything.
OK, I'll update later. thanks Regards, Yu
Tested with Kernel : drm-intel-nightly c1380a01867fd3cc7922a5152186e1aac7118b35 4.2.0-rc3 from git://anongit.freedesktop.org/drm-intel i915 init: 304.054 ms suspend to ram: 300.768 ms resume: 546.279 ms Assigned to me, I will provide logs with drm.debug=14 and log_buf_len=4M.
(In reply to Jani Nikula from comment #2) > Please try drm-intel-nightly, add drm.debug=14 module parameter and attach > dmesg all the way from boot to the suspend/resume cycle. Add log_buf_len=4M > or similar to capture everything. Hi Jani, Nikula I've tested s3 on SKL-Y under the following configuration, attached dmesg.log with drm.debug=14 and log_buf_len=4M Kernel : latest drm-intel-testing (4.3.0-rc6-testing) commit 87074657f22e38163e712ca417e1a398d00096b6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 11:56:52 2015 +0200 Software configuration : -------------------------------- Ubuntu 14.04.03 x86_64 Xserver : 1.17.4 (commit : 2c7fa2a) libdrm : 2.4.65 (commit :c349616) Xf86-video-intel : 2.99.917 (commit : baec802) Mesa : 11.0.4 (commit : 31bf247) Libva : 1.6.1 (commit : 613eb96) Intel-driver : 1.6.1 (commit : 35858c6) Cairo : 1.14.4 (commit : 0317ee7) --- Hardware information --- CPU information : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz GPU Card : Intel Corporation Device 191e (rev 07) (prog-if 00 [VGA controller]) Bios : 102.0 KSC : 1.15 Memory ram : 4 GB this is part of dmesg [ 92.760478] call 0000:00:02.0+ returned 0 after 262133 usecs [ 93.788900] call 0000:00:02.0+ returned 0 after 999283 usecs [ 93.796837] call 0000:00:02.0+ returned 0 after 0 usecs [ 94.090103] call 0000:00:02.0+ returned 0 after 14944 usecs [ 94.097125] call 0000:00:02.0+ returned 0 after 2789 usecs [ 94.413966] call 0000:00:02.0+ returned 0 after 267411 usecs [ 126.657504] call 0000:00:02.0+ returned 0 after 269764 usecs [ 127.721857] call 0000:00:02.0+ returned 0 after 998288 usecs [ 127.728879] call 0000:00:02.0+ returned 0 after 0 usecs [ 128.027012] call 0000:00:02.0+ returned 0 after 13414 usecs [ 128.033913] call 0000:00:02.0+ returned 0 after 2743 usecs [ 128.328738] call 0000:00:02.0+ returned 0 after 245876 usecs [ 235.339245] call 0000:00:02.0+ returned 0 after 282050 usecs [ 236.411420] call 0000:00:02.0+ returned 0 after 997115 usecs [ 236.418517] call 0000:00:02.0+ returned 0 after 0 usecs [ 236.700661] call 0000:00:02.0+ returned 0 after 14283 usecs [ 236.707655] call 0000:00:02.0+ returned 0 after 2778 usecs [ 237.002294] call 0000:00:02.0+ returned 0 after 247000 usecs [ 638.176926] call 0000:00:02.0+ returned 0 after 270062 usecs [ 639.205327] call 0000:00:02.0+ returned 0 after 1000015 usecs [ 639.211750] call 0000:00:02.0+ returned 0 after 0 usecs [ 639.490584] call 0000:00:02.0+ returned 0 after 14984 usecs [ 639.491842] call 0000:00:02.0+ returned 0 after 984 usecs [ 639.800207] call 0000:00:02.0+ returned 0 after 258558 usecs [ 92.760669] PM: suspend of devices complete after 275.643 msecs [ 126.657570] PM: suspend of devices complete after 283.799 msecs [ 235.339370] PM: suspend of devices complete after 296.023 msecs [ 638.177062] PM: suspend of devices complete after 283.487 msecs
Created attachment 119611 [details] dmesg.log
(In reply to yu.c.chen@intel.com from comment #0) > ==Expect result== > suspend/resume time drops to less than 50ms, or is this normal to cost 200ms > on SKLAKE-Y? With eDP panels? I don't think that ever happened on i915.ko. What exactly is your target? With which outputs connected? I would suggest to close this bug as NOTABUG and treat it as a feature request, through the appropriate channels, or at least drop the high/major priority.
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.