On Wed, May 18, 2016 at 06:47:11PM +0200, Daniel Vetter wrote:
> Oops. Hw default for programming these fields to 0 is "skip link
> training". Display won't take that too well usually.

s/skip/500 usec/

> 
> v2: Unbotch the math a bit.
> 
> v3: Drop debug hunk.
> 
> Tested-by: Lyude <cp...@redhat.com>
> Cc: Lyude <cp...@redhat.com>
> Cc: sta...@vger.kernel.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Cc: Sonika Jindal <sonika.jin...@intel.com>
> Cc: Durgadoss R <durgados...@intel.com>
> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandi...@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@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;

The current vbt spec is confusing. But after some head scratching this
does look correct.

Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>

> +
> +     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)
> -- 
> 2.8.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to