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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #24 from David Weinehall <david.weinehall at intel.com> ---
Measurement on KBL-Y with my patch applied:

Total suspend: 308ms

200ms is spent waiting for the backlight to disable (timing from VBT).
16ms is spent disabling the pipe.
60ms is spent waiting for the panel to disable (timing from VBT).
12ms is spent in late suspend.
20ms is spent doing various other things (reading from/writing to hardware,
ACPI, etc.)

The late suspend is for disabling power domains and setting the PCI state to
D3_hot.

So, after subtracting the 260ms from panel/backlight timings, we actually meet
the expected result for suspend (it's reasonable to assume that such values
would be the outcome if we were to measure without a display connected via
eDP).


For the resume case:

Total resume: 460ms

13.5ms in resume noirq (PCI powerup and state restore)
13ms in resume early (init powerdomains)
40ms setting up + initialising opregions
3ms to restore gtt mappings
200ms to enable the panel (timing from VBT) + 4ms linktraining
2 * 88ms for HDMI detect (2 ports)
10.5ms doing other things

Reasonably the HDMI detection should be possible to parallelise (either only
with each other, thus saving us 88ms, or with the eDP, thus saving us 176ms on
platforms that uses eDP, and 88ms on platforms that don't).

The opregion setup looks like a target we could optimise (possibly even
postpone).

If we subtract the 200ms panel timing, we still have 260ms left (of which 176ms
is HDMI detect), so clearly there's some room for improvement, but also the
targets might need readjusting (if the total time allotment for suspend +
resume is 187.5ms and suspend takes ~43ms, we've got 144.5ms to resume. The PCI
powerup/restore/powerdomain bits are non-negotiable (to my understanding), so
that's 26.5ms we cannot shave off. At the very least the device is bound to be
connected to one display, so we'll have at least either 88ms or 200ms to
contend with. Link training is also unavoidable, as well as restoring gtt
mappings. The "doing other things" bit is quite likely to contain mostly
necessary things too.

Thus, unless we can optimise away some bits of the opregion setup cost, the
target needs adjusting (also, I think it makes sense to split the target into
separate suspend & resume values).

Preliminary suggestions for targets would 50ms for suspend (might need
adjusting for hardware) on a non-eDP device, and maybe something like 150ms for
resume. But this assumes that it is feasible to optimise things, obviously.

-- 
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/20160518/1611e0fa/attachment.html>