Bug 90892

Summary: [skl] suspend/resume time from suspend-to-freeze/mem is high for i915
Product: DRI Reporter: yu.c.chen <yu.c.chen>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED INVALID QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: high CC: dblack, intel-gfx-bugs, przanoni, yu.c.chen
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: SKL i915 features: power/suspend-resume
Attachments:
Description Flags
dmesg during suspend/resume from freeze
none
dmesg.log none

Description yu.c.chen@intel.com 2015-06-08 04:55:43 UTC 
==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
Comment 1 yu.c.chen@intel.com 2015-06-08 04:56:58 UTC 
Created attachment 116347 [details]
dmesg during suspend/resume from freeze
Comment 2 Jani Nikula 2015-06-08 08:06:30 UTC 
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.
Comment 3 yu.c.chen@intel.com 2015-06-08 08:08:28 UTC 
OK, I'll update later. thanks

Regards,
Yu
Comment 4 cprigent 2015-08-03 21:10:55 UTC 
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.
Comment 5 Humberto Israel Perez Rodriguez 2015-11-12 22:24:07 UTC 
(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
Comment 6 Humberto Israel Perez Rodriguez 2015-11-12 22:24:26 UTC 
Created attachment 119611 [details]
dmesg.log
Comment 7 Paulo Zanoni 2016-08-09 19:33:53 UTC 
(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.