[Bug 99627] Improve resume time

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99627

David Weinehall <david.weinehall at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|NEW                         |RESOLVED

--- Comment #9 from David Weinehall <david.weinehall at intel.com> ---
One more thing that would be helpful is the output of:

cat /sys/kernel/debug/dri/0/eDP-1/i915_panel_timings

Looking at the suspend/resume log I make the following observations:

intel_edp_backlight_off() takes 238ms
intel_edp_panel_off() takes 52ms

332ms - 238ms - 52ms = 52ms, which is a totally reasonable suspend time.
(It should be noted here, and for the corresponding panel on/backlight on
timeouts, that due to the potentially long waits we're doing ranged sleeps, not
precise sleeps, meaning that these delays vary in length).

The 22ms in resume_noirq() is mostly spent in pci_power_up(), which is outside
our control (it's part of the PCI subsystem; I'm no expert here, but I find it
likely that the delays imposed here are mandated by specs).

The majority of the time spent in resume_early() is spent in
intel_csr_load_program() loading the DMC firmware (necessary for deeper display
power management). I should probably add some bad news here; it's likely that
if you enable GuC submissions and also provide the HuC firmware you'll see
further slowdowns, since those firmwares will also need loading.

I'm currently investigating the feasibility of loading these firmwares
asynchronously, but that will only happen if we can guarantee that it doesn't
introduce race conditions or unduly complicates the driver.

As for the intel_opregion_setup(), it seems that your BIOS is really slow.
We're requesting BIOS data and polling for the data. On the test systems here
the BIOS returns the relevant data within 1ms; on your machine it takes 18ms.
I'd posit that this is a hardware issue, not a software issue.

intel_edp_panel_on() takes 201ms

This leaves us with:

274ms - 201ms - (18 - 1)ms = 57ms, which again is a perfectly cromulent figure.

So, nothing here stands out apart from the suspected BIOS read slowdown.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170227/5a4c8f49/attachment-0001.html>