[Bug 99650] Suspend and resume take long time on Dell XPS 13 9360 (Kaby Lake)

[bugzilla-daemon at freedesktop.org]

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

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

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

--- Comment #11 from David Weinehall <david.weinehall at intel.com> ---
(In reply to Paul Menzel from comment #9)
> (In reply to David Weinehall from comment #7)
> > Something seems to be really wrong with that graph you posted (suspend only
> > taking 0.011ms)--or did you filter these figures to only contain resume time?
> 
> Indeed. Something seems off. I didn’t do anything besides running the
> script. It looks like there is a bug.
> 
> > Anyhow, let's start with the low-hanging fruit:
> > 
> > The 206ms spent in skl_update_crtcs() is the VBT-mandated panel on-timeout
> > (200ms) + DP link training. There's also cdclk programming which takes a few
> > milliseconds. This covers intel_display_resume(), which is the biggest
> > "culprit".
> 
> Indeed. What are the options to improve that? My first naive and ignorant
> thought would be, on a laptop, and even desktop systems, the display doesn’t
> change during suspend/resume. So can this be cached, and those values tried
> first?
> 
> […]

Sadly the news about the VESA timeouts are rather bad; according to spec it's
not permitted to run the timeouts in parallel, nor can they be skipped. The
link training can possibly be cached, but for eDP this is just a short pulse
anyway, so the time saving would be fairly minimal.

Looking at complete suspend/resume logs (without other drivers filtered out)
from other machines it seems that the i915 driver is the blocking factor on
suspend, but not on resume; other drivers (notably the USB subsystem) take far
longer to resume; since driver suspend, and driver resume, happens in parallel
between most drivers, we don't benefit all that much at the moment from trying
to "cheat" by making the i915 resume asynchronously; no matter if we resume in
the normal way or if we do it asynchronously it'll still take as long to get to
a point where the system can use the driver again.

As I analysed in another bug, slowdowns in intel_opregion_setup() seem to be
caused by slow replies from the BIOS when reading the GBDA.

All in all we're looking at:

322ms - 206ms (panel timeout) - (64 - 6)ms (opregion adjusted for a "normally
slow" read) = 58ms.

This is a perfectly reasonable resume time, well on par with what is to be
expected.

To shorten the panel timeout delay you'll need a different panel (or the VBT
timings adjusted for the panel you have; don't go around overriding these
timeouts without full knowledge of what the specs of the panel is though). To
fix the opregion slowdown you'll most likely either need another BIOS (and I
mean another; it's unlikely that slow reads from BIOS is something that a
typical BIOS upgrade would fix) or other hardware (depending on where the
slowdown is).

If you aren't worried about runtime power consumption (but since this is a
laptop you probably are) you could try removing/renaming the DMC firmware,
which will save you the 4.5ms it takes to load that firmware).

Finally you should be aware that as soon as the HuC firmware is available on
your system the driver will load it, which means that you'll see another
slowdown on the order of 30ms or so; if you do not need hardware optimisation
for HEVC you might want to remove/rename that file too.

Long story short: nothing in this log seems to indicate that we're spending too
much time resuming in our driver. Believe me, I'd love to find things that
could improve the suspend/resume times.

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