Re: [PATCH] drm/i915/psr: Get pipe id following atomic guidelines

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Tue, Nov 27, 2018 at 11:28:38PM -0800, José Roberto de Souza wrote:
> As stated in struct drm_encoder, crtc field should only be used
> by non-atomic drivers.
> 
> So here caching the pipe id in intel_psr_enable() what is way more
> simple and efficient than at every call to
> intel_psr_flush()/invalidate() get the
> drm.mode_config.connection_mutex lock to safely be able to get the
> pipe id by reading drm_connector_state.crtc.
> 
> This should fix the null pointer dereference crash below as the
> previous way to get the pipe id was prone to race conditions.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105959
> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 19 ++++---------------
>  2 files changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f763b30f98d9..9ea39b82836f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -494,6 +494,7 @@ struct i915_psr {
>  	bool sink_support;
>  	bool prepared, enabled;
>  	struct intel_dp *dp;
> +	enum pipe pipe;
>  	bool active;
>  	struct work_struct work;
>  	unsigned busy_frontbuffer_bits;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> index 572e626eadff..11a520074f06 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -705,6 +705,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>  	dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
>  	dev_priv->psr.busy_frontbuffer_bits = 0;
>  	dev_priv->psr.prepared = true;
> +	dev_priv->psr.pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
>  
>  	if (psr_global_enabled(dev_priv->psr.debug))
>  		intel_psr_enable_locked(dev_priv, crtc_state);
> @@ -1012,9 +1013,6 @@ static void intel_psr_work(struct work_struct *work)
>  void intel_psr_invalidate(struct drm_i915_private *dev_priv,
>  			  unsigned frontbuffer_bits, enum fb_op_origin origin)
>  {
> -	struct drm_crtc *crtc;
> -	enum pipe pipe;
> -
>  	if (!CAN_PSR(dev_priv))
>  		return;
>  
> @@ -1027,10 +1025,7 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv,
>  		return;
>  	}
>  
> -	crtc = dp_to_dig_port(dev_priv->psr.dp)->base.base.crtc;
> -	pipe = to_intel_crtc(crtc)->pipe;
> -
> -	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> +	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(dev_priv->psr.pipe);
>  	dev_priv->psr.busy_frontbuffer_bits |= frontbuffer_bits;
>  
>  	if (frontbuffer_bits)
> @@ -1055,9 +1050,6 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv,
>  void intel_psr_flush(struct drm_i915_private *dev_priv,
>  		     unsigned frontbuffer_bits, enum fb_op_origin origin)
>  {
> -	struct drm_crtc *crtc;
> -	enum pipe pipe;
> -
>  	if (!CAN_PSR(dev_priv))
>  		return;
>  
> @@ -1070,10 +1062,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>  		return;
>  	}
>  
> -	crtc = dp_to_dig_port(dev_priv->psr.dp)->base.base.crtc;
> -	pipe = to_intel_crtc(crtc)->pipe;
> -
> -	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> +	frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(dev_priv->psr.pipe);

This approach will introduce another bug.

Any frontbuffer tracking from any connector on another pipe will trigger
psr actions on eDP.

>  	dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
>  
>  	/* By definition flush = invalidate + flush */
> @@ -1087,7 +1076,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>  		 * but it makes more sense write to the current active
>  		 * pipe.
>  		 */
> -		I915_WRITE(CURSURFLIVE(pipe), 0);
> +		I915_WRITE(CURSURFLIVE(dev_priv->psr.pipe), 0);
>  	}
>  
>  	if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> -- 
> 2.19.2
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx