All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"R, Durgadoss" <durgadoss.r@intel.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock
Date: Fri, 6 Apr 2018 15:18:16 -0700	[thread overview]
Message-ID: <20180406221816.GG8964@intel.com> (raw)
In-Reply-To: <7e7b4336aefd6e6cf993150c1a83d214c161a210.camel@intel.com>

On Fri, Apr 06, 2018 at 11:12:27AM -0700, Souza, Jose wrote:
> On Thu, 2018-04-05 at 12:49 +0100, Chris Wilson wrote:
> > Inside the psr work function, we want to wait for PSR to idle first
> > and
> > wish to do so without blocking the normal modeset path, so we do so
> > without holding the PSR lock. However, we first have to find which
> > pipe
> > PSR was enabled on, which requires chasing into the PSR struct and
> > requires locking to prevent intel_psr_disable() from concurrently
> > setting our pointer to NULL.
> > 
> > Fixes: 995d30477496 ("drm/i915: VLV/CHV PSR Software timer mode")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Durgadoss R <durgadoss.r@intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: <stable@vger.kernel.org> # v4.0+
> 
> Feel free to add:
> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
> 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 82 +++++++++++++++++++++---------
> > ----------
> >  1 file changed, 44 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2d53f7398a6d..69a5b276f4d8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -775,53 +775,59 @@ void intel_psr_disable(struct intel_dp
> > *intel_dp,
> >  	cancel_delayed_work_sync(&dev_priv->psr.work);
> >  }
> >  
> > -static void intel_psr_work(struct work_struct *work)
> > +static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
> >  {
> > -	struct drm_i915_private *dev_priv =
> > -		container_of(work, typeof(*dev_priv),
> > psr.work.work);
> > -	struct intel_dp *intel_dp = dev_priv->psr.enabled;
> > -	struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-
> > >base.base.crtc;
> > -	enum pipe pipe = to_intel_crtc(crtc)->pipe;
> > +	struct intel_dp *intel_dp;
> 
> nitpick: Why not already set it?
> struct intel_dp *intel_dp = dev_priv->psr.enabled;
> 
> 
> > +	i915_reg_t reg;
> > +	u32 mask;
> > +	int err;
> > +
> > +	intel_dp = dev_priv->psr.enabled;
> > +	if (!intel_dp)
> > +		return false;
> >  
> > -	/* We have to make sure PSR is ready for re-enable
> > -	 * otherwise it keeps disabled until next full
> > enable/disable cycle.
> > -	 * PSR might take some time to get fully disabled
> > -	 * and be ready for re-enable.
> > -	 */
> >  	if (HAS_DDI(dev_priv)) {
> 
> 
> nitpick: While on that you could replace this for:
> 
> if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))) {
> 
> >  		if (dev_priv->psr.psr2_enabled) {
> > -			if (intel_wait_for_register(dev_priv,
> > -						    EDP_PSR2_STATUS,
> > -						    EDP_PSR2_STATUS_
> > STATE_MASK,
> > -						    0,
> > -						    50)) {
> > -				DRM_ERROR("Timed out waiting for
> > PSR2 Idle for re-enable\n");
> > -				return;
> > -			}
> > +			reg = EDP_PSR2_STATUS;
> > +			mask = EDP_PSR2_STATUS_STATE_MASK;
> >  		} else {
> > -			if (intel_wait_for_register(dev_priv,
> > -						    EDP_PSR_STATUS,
> > -						    EDP_PSR_STATUS_S
> > TATE_MASK,
> > -						    0,
> > -						    50)) {
> > -				DRM_ERROR("Timed out waiting for PSR
> > Idle for re-enable\n");
> > -				return;
> > -			}
> > +			reg = EDP_PSR_STATUS;
> > +			mask = EDP_PSR_STATUS_STATE_MASK;
> >  		}
> >  	} else {
> > -		if (intel_wait_for_register(dev_priv,
> > -					    VLV_PSRSTAT(pipe),
> > -					    VLV_EDP_PSR_IN_TRANS,
> > -					    0,
> > -					    1)) {
> > -			DRM_ERROR("Timed out waiting for PSR Idle
> > for re-enable\n");
> > -			return;
> > -		}
> > +		struct drm_crtc *crtc =
> > +			dp_to_dig_port(intel_dp)->base.base.crtc;

I'm afraid that the issue is this pointer here. So this will only mask
the issue.

Should we maybe stash the pipe? :/

> > +		enum pipe pipe = to_intel_crtc(crtc)->pipe;
> > +
> > +		reg = VLV_PSRSTAT(pipe);
> > +		mask = VLV_EDP_PSR_IN_TRANS;
> >  	}
> > +
> > +	mutex_unlock(&dev_priv->psr.lock);
> > +
> > +	err = intel_wait_for_register(dev_priv, reg, mask, 0, 50);
> > +	if (err)
> > +		DRM_ERROR("Timed out waiting for PSR Idle for re-
> > enable\n");
> > +
> > +	/* After the unlocked wait, verify that PSR is still wanted!
> > */
> >  	mutex_lock(&dev_priv->psr.lock);
> > -	intel_dp = dev_priv->psr.enabled;
> > +	return err == 0 && dev_priv->psr.enabled;
> > +}
> >  
> > -	if (!intel_dp)
> > +static void intel_psr_work(struct work_struct *work)
> > +{
> > +	struct drm_i915_private *dev_priv =
> > +		container_of(work, typeof(*dev_priv),
> > psr.work.work);
> > +
> > +	mutex_lock(&dev_priv->psr.lock);
> > +
> > +	/*
> > +	 * We have to make sure PSR is ready for re-enable
> > +	 * otherwise it keeps disabled until next full
> > enable/disable cycle.
> > +	 * PSR might take some time to get fully disabled
> > +	 * and be ready for re-enable.
> > +	 */
> > +	if (!psr_wait_for_idle(dev_priv))
> >  		goto unlock;
> >  
> >  	/*
> > @@ -832,7 +838,7 @@ static void intel_psr_work(struct work_struct
> > *work)
> >  	if (dev_priv->psr.busy_frontbuffer_bits)
> >  		goto unlock;
> >  
> > -	intel_psr_activate(intel_dp);
> > +	intel_psr_activate(dev_priv->psr.enabled);
> >  unlock:
> >  	mutex_unlock(&dev_priv->psr.lock);
> >  }
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"chris@chris-wilson.co.uk" <chris@chris-wilson.co.uk>,
	"R, Durgadoss" <durgadoss.r@intel.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock
Date: Fri, 6 Apr 2018 15:18:16 -0700	[thread overview]
Message-ID: <20180406221816.GG8964@intel.com> (raw)
In-Reply-To: <7e7b4336aefd6e6cf993150c1a83d214c161a210.camel@intel.com>

On Fri, Apr 06, 2018 at 11:12:27AM -0700, Souza, Jose wrote:
> On Thu, 2018-04-05 at 12:49 +0100, Chris Wilson wrote:
> > Inside the psr work function, we want to wait for PSR to idle first
> > and
> > wish to do so without blocking the normal modeset path, so we do so
> > without holding the PSR lock. However, we first have to find which
> > pipe
> > PSR was enabled on, which requires chasing into the PSR struct and
> > requires locking to prevent intel_psr_disable() from concurrently
> > setting our pointer to NULL.
> > 
> > Fixes: 995d30477496 ("drm/i915: VLV/CHV PSR Software timer mode")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Durgadoss R <durgadoss.r@intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: <stable@vger.kernel.org> # v4.0+
> 
> Feel free to add:
> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
> 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 82 +++++++++++++++++++++---------
> > ----------
> >  1 file changed, 44 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2d53f7398a6d..69a5b276f4d8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -775,53 +775,59 @@ void intel_psr_disable(struct intel_dp
> > *intel_dp,
> >  	cancel_delayed_work_sync(&dev_priv->psr.work);
> >  }
> >  
> > -static void intel_psr_work(struct work_struct *work)
> > +static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
> >  {
> > -	struct drm_i915_private *dev_priv =
> > -		container_of(work, typeof(*dev_priv),
> > psr.work.work);
> > -	struct intel_dp *intel_dp = dev_priv->psr.enabled;
> > -	struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-
> > >base.base.crtc;
> > -	enum pipe pipe = to_intel_crtc(crtc)->pipe;
> > +	struct intel_dp *intel_dp;
> 
> nitpick: Why not already set it?
> struct intel_dp *intel_dp = dev_priv->psr.enabled;
> 
> 
> > +	i915_reg_t reg;
> > +	u32 mask;
> > +	int err;
> > +
> > +	intel_dp = dev_priv->psr.enabled;
> > +	if (!intel_dp)
> > +		return false;
> >  
> > -	/* We have to make sure PSR is ready for re-enable
> > -	 * otherwise it keeps disabled until next full
> > enable/disable cycle.
> > -	 * PSR might take some time to get fully disabled
> > -	 * and be ready for re-enable.
> > -	 */
> >  	if (HAS_DDI(dev_priv)) {
> 
> 
> nitpick: While on that you could replace this for:
> 
> if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))) {
> 
> >  		if (dev_priv->psr.psr2_enabled) {
> > -			if (intel_wait_for_register(dev_priv,
> > -						    EDP_PSR2_STATUS,
> > -						    EDP_PSR2_STATUS_
> > STATE_MASK,
> > -						    0,
> > -						    50)) {
> > -				DRM_ERROR("Timed out waiting for
> > PSR2 Idle for re-enable\n");
> > -				return;
> > -			}
> > +			reg = EDP_PSR2_STATUS;
> > +			mask = EDP_PSR2_STATUS_STATE_MASK;
> >  		} else {
> > -			if (intel_wait_for_register(dev_priv,
> > -						    EDP_PSR_STATUS,
> > -						    EDP_PSR_STATUS_S
> > TATE_MASK,
> > -						    0,
> > -						    50)) {
> > -				DRM_ERROR("Timed out waiting for PSR
> > Idle for re-enable\n");
> > -				return;
> > -			}
> > +			reg = EDP_PSR_STATUS;
> > +			mask = EDP_PSR_STATUS_STATE_MASK;
> >  		}
> >  	} else {
> > -		if (intel_wait_for_register(dev_priv,
> > -					    VLV_PSRSTAT(pipe),
> > -					    VLV_EDP_PSR_IN_TRANS,
> > -					    0,
> > -					    1)) {
> > -			DRM_ERROR("Timed out waiting for PSR Idle
> > for re-enable\n");
> > -			return;
> > -		}
> > +		struct drm_crtc *crtc =
> > +			dp_to_dig_port(intel_dp)->base.base.crtc;

I'm afraid that the issue is this pointer here. So this will only mask
the issue.

Should we maybe stash the pipe? :/

> > +		enum pipe pipe = to_intel_crtc(crtc)->pipe;
> > +
> > +		reg = VLV_PSRSTAT(pipe);
> > +		mask = VLV_EDP_PSR_IN_TRANS;
> >  	}
> > +
> > +	mutex_unlock(&dev_priv->psr.lock);
> > +
> > +	err = intel_wait_for_register(dev_priv, reg, mask, 0, 50);
> > +	if (err)
> > +		DRM_ERROR("Timed out waiting for PSR Idle for re-
> > enable\n");
> > +
> > +	/* After the unlocked wait, verify that PSR is still wanted!
> > */
> >  	mutex_lock(&dev_priv->psr.lock);
> > -	intel_dp = dev_priv->psr.enabled;
> > +	return err == 0 && dev_priv->psr.enabled;
> > +}
> >  
> > -	if (!intel_dp)
> > +static void intel_psr_work(struct work_struct *work)
> > +{
> > +	struct drm_i915_private *dev_priv =
> > +		container_of(work, typeof(*dev_priv),
> > psr.work.work);
> > +
> > +	mutex_lock(&dev_priv->psr.lock);
> > +
> > +	/*
> > +	 * We have to make sure PSR is ready for re-enable
> > +	 * otherwise it keeps disabled until next full
> > enable/disable cycle.
> > +	 * PSR might take some time to get fully disabled
> > +	 * and be ready for re-enable.
> > +	 */
> > +	if (!psr_wait_for_idle(dev_priv))
> >  		goto unlock;
> >  
> >  	/*
> > @@ -832,7 +838,7 @@ static void intel_psr_work(struct work_struct
> > *work)
> >  	if (dev_priv->psr.busy_frontbuffer_bits)
> >  		goto unlock;
> >  
> > -	intel_psr_activate(intel_dp);
> > +	intel_psr_activate(dev_priv->psr.enabled);
> >  unlock:
> >  	mutex_unlock(&dev_priv->psr.lock);
> >  }

  reply	other threads:[~2018-04-06 22:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 11:49 [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock Chris Wilson
2018-04-05 12:25 ` ✗ Fi.CI.BAT: failure for " Patchwork
2018-04-05 13:06 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-05 14:54 ` ✓ Fi.CI.IGT: " Patchwork
2018-04-06 18:12 ` [Intel-gfx] [PATCH] " Souza, Jose
2018-04-06 22:18   ` Rodrigo Vivi [this message]
2018-04-06 22:18     ` Rodrigo Vivi
2018-04-07  9:05     ` Chris Wilson
2018-04-09 19:14       ` Rodrigo Vivi
2018-04-09 19:14         ` [Intel-gfx] " Rodrigo Vivi
2018-04-10 11:00         ` Chris Wilson
2018-04-10 18:02           ` [Intel-gfx] " Rodrigo Vivi
2018-04-10 10:30   ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180406221816.GG8964@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=durgadoss.r@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jose.souza@intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.