On Thu, Mar 19, 2015 at 11:06:14AM -0700, Jesse Barnes wrote: > 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. Hm I just read up on that patch again and noticed that the module load code has an async_synchronize_full. Is there some magic I'm missing to not make this synchronize with the fbdev stuff? > 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! Proper userspace forks one thread per module to load, so returning to userspace fast isn't useful really. I'd really like to see some numbers that this indeed makes boot-up faster before we add all the complexity needed for it. -Danel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
