On 03/20/2015 03:16 AM, Daniel Vetter wrote: > 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? Maybe? I'm not using async domains at all for this, so it doesn't sync with anything until we get a call into the DP code. So if fbcon comes first and tries to set a mode, it'll end up in get_dpcd or some other function which will flush the edp init work. >> 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. As Chris said, modules aren't always in use. And I'd like to flip this around too; you need to justify why spending over 1s in module init is ok, modules or no. Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
