[Intel-gfx] Async eDP init

[Jesse Barnes]

On 03/19/2015 11:00 AM, Jesse Barnes wrote:
> On 03/19/2015 10:42 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...
>>
>> Imo the real issue is that we register a connector and then throw it away
>> again. Not that big a problem any more since mst dp happened meanwhile but
>> still might result in confusion.
>>
>> I think we should try to at least get the "is this an edp or not" question
>> right, and only postpone the other init steps. So maybe start with making
>> that edp failed to init issue really loud and then rip it out?
>>
>> Postponing all the other init work would be comparitively a lot easier I
>> think.
> 
> I didn't view that as a big issue, but it should be easy to solve.  I
> think the synchronization problems are still just as thorny though, even
> with the question of is_edp() solved early.  The eDP init is kind of
> like a boot time mode set, but one that needs to complete before any
> activity on the port.
> 
> I'll check those init paths; hopefully answering is_edp() won't have a
> bunch of delay in itself.

So the answer is unfortunately no.  The DPCD read we do at the top of
the eDP init function is the one we use to check whether the port should
exist, and it's the function that takes a long time (~700ms on this
machine).

Jesse