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>
