[Intel-gfx] [PATCH 2/7] drm/i915/psr: Try to program link training times correctly

Jindal, Sonika sonika.jindal at intel.com
Thu May 19 10:50:02 UTC 2016



On 5/18/2016 10:17 PM, Daniel Vetter wrote:
> Oops. Hw default for programming these fields to 0 is "skip link
> training". Display won't take that too well usually.
But we were defaulting it to value 0, which means 500us for both TP1 and 
TP2 or TP3 time.
I dont think it means skip link training. This is just to set the time 
for the patterns.
Skip aux handshake can happen if bit 12 of SRD_CTL is set.

Does this solution help in fixing the bug mentioned here?

>
> v2: Unbotch the math a bit.
>
> v3: Drop debug hunk.
>
> Tested-by: Lyude <cpaul at redhat.com>
> Cc: Lyude <cpaul at redhat.com>
> Cc: stable at vger.kernel.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176
> Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> Cc: Sonika Jindal <sonika.jindal at intel.com>
> Cc: Durgadoss R <durgadoss.r at intel.com>
> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan at intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> ---
>   drivers/gpu/drm/i915/intel_psr.c | 55 ++++++++++++++++++++++++++++++++++------
>   1 file changed, 47 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> index c3abae4bc596..a788d1e9589b 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -280,7 +280,10 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp)
>   	 * with the 5 or 6 idle patterns.
>   	 */
>   	uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> -	uint32_t val = 0x0;
> +	uint32_t val = EDP_PSR_ENABLE;
> +
> +	val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> +	val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>   
>   	if (IS_HASWELL(dev))
>   		val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> @@ -288,14 +291,50 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp)
>   	if (dev_priv->psr.link_standby)
>   		val |= EDP_PSR_LINK_STANDBY;
>   
> -	I915_WRITE(EDP_PSR_CTL, val |
> -		   max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |
> -		   idle_frames << EDP_PSR_IDLE_FRAME_SHIFT |
> -		   EDP_PSR_ENABLE);
> +	if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
> +		val |= EDP_PSR_TP1_TIME_2500us;
> +	else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
> +		val |= EDP_PSR_TP1_TIME_500us;
> +	else if (dev_priv->vbt.psr.tp1_wakeup_time > 0)
> +		val |= EDP_PSR_TP1_TIME_100us;
> +	else
> +		val |= EDP_PSR_TP1_TIME_0us;
> +
> +	if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> +		val |= EDP_PSR_TP2_TP3_TIME_2500us;
> +	else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
> +		val |= EDP_PSR_TP2_TP3_TIME_500us;
> +	else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 0)
> +		val |= EDP_PSR_TP2_TP3_TIME_100us;
> +	else
> +		val |= EDP_PSR_TP2_TP3_TIME_0us;
> +
> +	if (intel_dp_source_supports_hbr2(intel_dp) &&
> +	    drm_dp_tps3_supported(intel_dp->dpcd))
> +		val |= EDP_PSR_TP1_TP3_SEL;
> +	else
> +		val |= EDP_PSR_TP1_TP2_SEL;
> +
> +	I915_WRITE(EDP_PSR_CTL, val);
> +
> +	if (!dev_priv->psr.psr2_support)
> +		return;
> +
> +	/* FIXME: selective update is probably totally broken because it doesn't
> +	 * mesh at all with our frontbuffer tracking. And the hw alone isn't
> +	 * good enough. */
> +	val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> +
> +	if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> +		val |= EDP_PSR2_TP2_TIME_2500;
> +	else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
> +		val |= EDP_PSR2_TP2_TIME_500;
> +	else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 0)
> +		val |= EDP_PSR2_TP2_TIME_100;
> +	else
> +		val |= EDP_PSR2_TP2_TIME_50;
>   
> -	if (dev_priv->psr.psr2_support)
> -		I915_WRITE(EDP_PSR2_CTL, EDP_PSR2_ENABLE |
> -				EDP_SU_TRACK_ENABLE | EDP_PSR2_TP2_TIME_100);
> +	I915_WRITE(EDP_PSR2_CTL, val);
>   }
>   
>   static bool intel_psr_match_conditions(struct intel_dp *intel_dp)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20160519/ac882f1d/attachment-0001.html>


More information about the Intel-gfx mailing list