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);
}
...
Do you not see that on your machine?
Jesse
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
