[Intel-gfx] Async eDP init

[Jesse Barnes]

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