On 03/19/2015 10:44 AM, Daniel Vetter wrote: > On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote: >> This updates my old patch for this, but w/o fixing the locking issue >> Ville mentioned. In looking at it, it seems like the sync point should >> be at a higher level, maybe at the level of the atomic mode setting async >> serialization points? Another possibility would be to make it a lazy >> init type function, sprinkled about but only running once when we first >> need it. >> >> Any thoughts from anyone? I don't think I can just do a lock drop here, >> since other threads may jump in and mess with underlying state. That >> shouldn't affect the eDP state we fill out, but may affect the state the >> caller depended on in the first place... > > Also, has boot-time actually increased or did we simply push it somewhere > we don't measure the delay anymore? After all right afterwards we'll do > the fbcon setup, and that will synchronize everything again. fbcon setup is pushed off to a work queue already. This problem has been around since before I posted the initial eDP work queue patch, and is related to a few things: fetching the DPCD, EDID, and initializing the panel power sequencer. I think these days we actually do a PPS cycle in eDP init too, which really increased the init time. On one of my test systems here, module init time is about 1s. With this patch it drops to less than 300ms (most of that other time is spent in power well functions; I still have to debug that). > And on modern systems without fbcon I expect userspace to go around and do > a probe, which again would force synchronization pretty quickly ... Right, but the whole point is to get to userspace as soon as we can so they'll at least have the option of poking us right away! Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
