On Thu, Mar 19, 2015 at 12:13:24PM -0700, Jesse Barnes wrote:
> On 03/19/2015 11:53 AM, Ville Syrjälä wrote:
> > 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...
>
> Yeah, in my config somehow the DPCD read does end up incurring the cost
> of the PPS. The panel is on when the kernel loads too. It seems
> unlikely that the vdd_sanitize runs first, but I suppose it's possible
> if the delay is 0? Hm no that doesn't seem to be happening here.
>
> Looks like we're doing the panel power sequence delays due to the panel
> not being on:
>
> ... if (!edp_have_panel_power(intel_dp))
> wait_panel_power_cycle(intel_dp);
> ...
> if (!edp_have_panel_power(intel_dp)) {
> DRM_DEBUG_KMS("eDP port %c panel power wasn't enabled\n",
> port_name(intel_dig_port->port));
> msleep(intel_dp->panel_power_up_delay);
> }
> ...
Hmm. The edp_have_panel_vdd() check should have returned already earlier
assuming VDD is still on at this point.
> Do you not see that on your machine?
Not sure. Imre borrowed my machine to fix some bugs while I'm busy with
other stuff so can't check now. But I can check tomorrow.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
