[Intel-gfx] [PATCH] drm/i915/psr: Get pipe id following atomic guidelines

[Rodrigo Vivi]

On Wed, Nov 28, 2018 at 10:21:05AM -0800, Souza, Jose wrote:
> On Wed, 2018-11-28 at 08:55 -0800, Rodrigo Vivi wrote:
> > 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 at intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > > Signed-off-by: José Roberto de Souza <jose.souza at 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.
> 
> Why that would happen? dev_priv->psr.pipe will be set with the pipe id
> that is used by the eDP panel so INTEL_FRONTBUFFER_ALL_MASK() will
> return only the frontbuffer bits of that pipe.

Oh... nevermind... and I saw that we were already getting from psr.dp
anyway...


Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>



> 
> > 
> > >  	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 at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx