i915_init takes a full second of kernel init time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 13 Dec 2011 13:34:38 -0800
Scott James Remnant <keybuk at google.com> wrote:

> On Tue, Dec 13, 2011 at 12:02 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > On Tue, 13 Dec 2011 11:55:06 -0800
> > Scott James Remnant <keybuk at google.com> wrote:
> >
> >> I've been investigating Chrome OS boot time and noticed the anomaly
> >> where i915_init takes up a considerable amount of kernel startup time,
> >> one second in fact. I've attached a full dmesg with drm.debug=0xff for
> >> analysis at Daniel's suggestion.
> >
> > I'm not surprised... we haven't optimized init time in awhile and lots
> > of delays have crept in.
> >
> > What kind of panel does this laptop have? ?Can you enable drm debugging
> > (drm.debug=1 on the boot line) and see where the big delays are in
> > modesetting?
> >
> Is this different to drm.debug=0xff ?

Should be the same... and now I look again and see you already attached
it, doh!

Looks like there are a couple of big jumps:

[    0.899057] [drm:intel_crtc_init], swapping pipes & planes for FBC
[    0.952613] [drm:drm_sysfs_connector_add], adding "LVDS-1" to sysfs

Between these two calls, we do the output setup stuff in i915.  There
are likely some delays there due to trying to fetch the EDID.

[    0.952846] [drm:intel_panel_set_backlight], set backlight PWM = 0
[    1.206060] [drm:i915_get_vblank_counter], trying to get vblank count for disabled pipe A

Not sure where this is coming from offhand...

[    1.206153] [drm:pineview_update_wm], Self-refresh is disabled
[    1.214189] [drm:init_status_page], render ring hws offset: 0x00000000

This looks like a mode set or CRTC disable happened before we
initialized the status page.

[    1.239347] [drm:drm_mode_debug_printmodeline], Modeline 8:"1280x800" 60 70700 1280 1296 1344 1440 800 801 804 818 0x48 0xa
[    1.273051] [drm:i9xx_update_plane], Writing base 00030000 00000000 0 0 5120

Looks like a mode set occurred, that'll also take awhile.

[    1.273758] [drm:intel_lvds_enable], applying panel-fitter: 8, 0
[    1.673051] [drm:intel_panel_set_backlight], set backlight PWM = 13046

So it's an LVDS machine... this is probably part of the LVDS mode set.

We had some async code to take all of this out of the boot time
critical path at least...  I thought Chris merged them long ago but I
guess they were dropped.  Chris?

In general, we can put a lot of the stuff we do into delayed work
handlers; e.g. when we shut things off we're often supposed to wait for
a full frame (i.e. the next vblank) before doing anything else.  This
could be done with a semaphore and delayed work though to keep things
snappy.

-- 
Jesse Barnes, Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20111213/1538fe07/attachment.pgp>


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux