[Intel-gfx] Async eDP init

[Ville Syrjälä]

On Thu, Mar 19, 2015 at 11:40:15AM -0700, Jesse Barnes wrote:
> 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).

Why is it taking that long? Even with an external display connected my
BSW boots with VDD forced on, so in theory it should just go read the
DPCD without any power sequencing needed, unless the delayed vdd off
work somehow manages to execute between the intel_edp_panel_vdd_sanitize()
call and intel_dp_get_dpcd() call...

-- 
Ville Syrjälä
Intel OTC