[Intel-gfx] [PATCH] drm/i915: eDP HPD connected check to reduce T3 time

[Clint Taylor]

On 09/22/2015 10:27 AM, Ville Syrjälä wrote:
> On Tue, Sep 22, 2015 at 10:09:39AM -0700, clinton.a.taylor at intel.com wrote:
>> From: Clint Taylor <clinton.a.taylor at intel.com>
>>
>> To reduce eDP T3 time check for digital port connected instead of
>> msleep. Maintain VBT time if HPD is not asserted on the port.
>>
>> Current eDP T3 time is an msleep for the panel_power_up time specified
>> in VBT. The eDP specification allows maximum T3 time of 200ms.
>> Typically panels raise HPD from 70ms-105ms and are ready for AUX traffic
>>   and training. Reading HPD will reduce power-on and resume times by over
>> 100ms on systems with eDP HPD connected.
>>
>> Signed-off-by: Clint Taylor <clinton.a.taylor at intel.com>
>> ---
>>   drivers/gpu/drm/i915/intel_dp.c |   13 ++++++++++++-
>>   1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 77e4115..7caf3ab 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -129,6 +129,8 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync);
>>   static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
>>   static void vlv_steal_power_sequencer(struct drm_device *dev,
>>   				      enum pipe pipe);
>> +static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
>> +					 struct intel_digital_port *port);
>>
>>   static unsigned int intel_dp_unused_lane_mask(int lane_count)
>>   {
>> @@ -1772,6 +1774,7 @@ static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
>>   	u32 pp;
>>   	u32 pp_stat_reg, pp_ctrl_reg;
>>   	bool need_to_disable = !intel_dp->want_panel_vdd;
>> +	int i, step = 0;
>>
>>   	lockdep_assert_held(&dev_priv->pps_mutex);
>>
>> @@ -1809,7 +1812,15 @@ static bool edp_panel_vdd_on(struct intel_dp *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);
>> +		step = intel_dp->panel_power_up_delay / 10;
>> +		for (i=0; i < intel_dp->panel_power_up_delay; i+=step) {
>> +			if (intel_digital_port_connected(dev_priv, intel_dig_port)) {
>> +				DRM_DEBUG_KMS("Port %c HPD detected\n",
>> +					      port_name(intel_dig_port->port));
>> +				break;
>> +			}
>> +			msleep(10);
>> +		}
>
> We have the HPD irq wired up for all ports now, so we could even do
> this without polling.

I thought about using the HPD irq though I really didn't want to get 
into full HPD handling of the eDP port since only the rise of HPD is of 
interest.

>
> There is a slight concern that what if the HPD line is noisy (happened
> on BSW RVP due wrong pullup settings at least) we could start link
> training before the panel is powered up. But I have no good solution for
> that, other than maybe blacklisting bad machines, which would require
> that we detect them somehow in the first place. Maybe we should have
> some kind of check in case the HPD is raised suspiciously soon, we would
> fall back to the full msleep method?
>

If for some reason the HPD line asserts early we could always retry AUX 
transactions until we get a good ACK before starting link training. VBT 
has a field for "T3 optimization" that when enabled just polls the AUX 
until the panel becomes ready instead of waiting for T3 time. retrying 
AUX on a spurious HPD would be the equivalent. We would need a sane way 
to give up after the expected T3 time.


> Another thing I didn't think about fully is how the power sequencer fits
> into this sort of thing. It seems we always enable the vdd force override
> before starting the panel on sequence, so i suppose we should be able
> to program the panel power on delay to 0 (or whatever the min is), and
> just rely on the driver to do the delays?
>
The power panel sequencer is actually causing additional delays during 
coldboot and resume. The current optimization in the driver for 
power_panel_cycle T12 delay is not being realized as we still wait for 
the panel power sequencer to complete its cycle before training the 
panel. That is my next level of optimization that I was going to work on 
next. My initial prototypes are causing spikes in the output voltage 
which could damage the panel. If the power on delays were 0 that may 
help. Thanks for the idea.

>
>>   	}
>>
>>   	return need_to_disable;
>> --
>> 1.7.9.5
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>