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@xxxxxxxxx> > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > Signed-off-by: José Roberto de Souza <jose.souza@xxxxxxxxx> > --- > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
