stable.vger.kernel.org archive mirror
 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>,
	"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: 7+ 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-06 18:12 ` [Intel-gfx] " Souza, Jose
2018-04-06 22:18   ` Rodrigo Vivi [this message]
2018-04-07  9:05     ` Chris Wilson
2018-04-09 19:14       ` Rodrigo Vivi
     [not found]         ` <152335802656.3167.11689504042884395588@mail.alporthouse.com>
2018-04-10 18:02           ` 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=chris@chris-wilson.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).