[Intel-gfx] [PATCH 6/7] drm/i915/psr: Use ->get_aux_send_ctl functions
Ville Syrjälä
ville.syrjala at linux.intel.com
Wed May 18 18:09:01 UTC 2016
On Wed, May 18, 2016 at 06:47:15PM +0200, Daniel Vetter wrote:
> I just wanted to get rid of the rmw cycle for gen9, but this also
> fixes some bugs we haven't carried over, like using recommended
> precharge and timeout values.
>
> Also I noticed that we don't set the fastwake sync length on skl, and
> that's used by PSR2 selective updates. Fix that.
>
> 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_dp.c | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 25 ++++---------------------
> 2 files changed, 5 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 36330026ceff..cccf9bc7c7d6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -770,6 +770,7 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp *intel_dp,
> DP_AUX_CH_CTL_TIME_OUT_1600us |
> DP_AUX_CH_CTL_RECEIVE_ERROR |
> (send_bytes << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
> + DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(32) |
> DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> index 87805078c8a3..f9ce47135bb4 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -176,7 +176,6 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint32_t aux_clock_divider;
> i915_reg_t aux_ctl_reg;
> - int precharge = 0x3;
> static const uint8_t aux_msg[] = {
> [0] = DP_AUX_NATIVE_WRITE << 4,
> [1] = DP_SET_POWER >> 8,
> @@ -185,6 +184,7 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
> [4] = DP_SET_POWER_D0,
> };
> enum port port = dig_port->port;
> + u32 aux_ctl;
> int i;
>
> BUILD_BUG_ON(sizeof(aux_msg) > 20);
> @@ -211,26 +211,9 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
> I915_WRITE(psr_aux_data_reg(dev_priv, port, i >> 2),
> intel_dp_pack_aux(&aux_msg[i], sizeof(aux_msg) - i));
>
> - if (INTEL_INFO(dev)->gen >= 9) {
> - uint32_t val;
> -
> - val = I915_READ(aux_ctl_reg);
> - val &= ~DP_AUX_CH_CTL_TIME_OUT_MASK;
> - val |= DP_AUX_CH_CTL_TIME_OUT_1600us;
> - val &= ~DP_AUX_CH_CTL_MESSAGE_SIZE_MASK;
> - val |= (sizeof(aux_msg) << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT);
> - /* Use hardcoded data values for PSR, frame sync and GTC */
> - val &= ~DP_AUX_CH_CTL_PSR_DATA_AUX_REG_SKL;
> - val &= ~DP_AUX_CH_CTL_FS_DATA_AUX_REG_SKL;
> - val &= ~DP_AUX_CH_CTL_GTC_DATA_AUX_REG_SKL;
> - I915_WRITE(aux_ctl_reg, val);
> - } else {
> - I915_WRITE(aux_ctl_reg,
> - DP_AUX_CH_CTL_TIME_OUT_400us |
> - (sizeof(aux_msg) << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) |
> - (precharge << DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) |
> - (aux_clock_divider << DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
> - }
> + aux_ctl = intel_dp->get_aux_send_ctl(intel_dp, 0, sizeof(aux_msg),
> + aux_clock_divider);
> + I915_WRITE(aux_ctl_reg, aux_ctl);
The HSW/BDW EDP specific register doesn't have quite all the bits, but
looks like those bits are RO in the PSR register, so no harm in writing
1 to them.
The one difference I noticed was there's an "interrupt on error" bit
(bit 11) in the PSR register that doesn't exist in the normal register.
But we're not setting that bit here, so not a problem.
For SKL+ this makes a ton of sense to me.
Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
PS. perhaps someone should look into those interrupt bits a bit more?
> }
>
> static void vlv_psr_enable_source(struct intel_dp *intel_dp)
> --
> 2.8.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
More information about the Intel-gfx
mailing list