[Bug 94722] [SKL/KBL] Init time is high

[bugzilla-daemon at freedesktop.org]

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

--- Comment #19 from David Weinehall <david.weinehall at intel.com> ---
Measurements using SuspendResume on a KBL-Y yields roughly these numbers:

suspend: 320ms -- out of this 300ms is spent turning off panel + backlight; the
delays here cannot be optimised away, so at most we can shave off a few
milliseconds. This values will vary greatly depending on the panel used.

resume: 470ms -- out of this 30ms is spent in restore_gtt, 230ms is spent
turning on panel + backlight, 170ms on probing for new displays, and 30ms in
one of the opregion-related calls.

The probing for new displays can be parallelised once the atomic modeset code
is finalised. There are various other things that can be optimised here too, as
the numbers probably show, but -- and here's the important part, for resume we
are not blocking the critical path. There are several components that take
longer to resume, and they are resuming in parallel to our driver.

Finally, for init, after consultation with Daniel Vetter it seems unlikely that
the init-time target is realistic. According to him none of our earlier
platforms have been able to meet this target, and the basis for the requirement
isn't fully understood. It should, however, be noted that on startup all
modules load in parallel, so we're not actually blocking anything.

Conclusion -- the situation is much better than the initial bug report
indicates.
A lot of the time spent during init/suspend/resume is spent in delays that are
specified by hardware (enabling/disabling/probing) and thus not amenable to
optimisation. The main remaining area is likely to see improvements once the
atomic modeset is finalised.

-- 
You are receiving this mail because:
You are the QA Contact 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/20160503/d292c38b/attachment.html>