All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tarun Vyas <tarun.vyas@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org,
	dhinakaran.pandiyan@intel.com, rodrigo.vivi@intel.com
Subject: Re: [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused.
Date: Mon, 14 May 2018 15:00:15 -0700	[thread overview]
Message-ID: <20180514220015.GA194720@otc-chromeosbuild-5> (raw)
In-Reply-To: <152633251911.18532.12845710278597901479@mail.alporthouse.com>

On Mon, May 14, 2018 at 10:15:19PM +0100, Chris Wilson wrote:
> Quoting Tarun Vyas (2018-05-14 21:49:20)
> > intel_pipe_update_start also needs to wait for PSR to idle
> > out. Need some minor modifications in psr_wait_for_idle in
> > order to reuse it.
> > 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Tarun Vyas <tarun.vyas@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 29 ++++++++++++++++++-----------
> >  1 file changed, 18 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
> > index db27f2faa1de..40aafc0f4513 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -889,11 +889,15 @@ static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
> >         i915_reg_t reg;
> >         u32 mask;
> >         int err;
> > +       bool wait = false;
> > +
> > +       mutex_lock(&dev_priv->psr.lock);
> >  
> >         intel_dp = dev_priv->psr.enabled;
> >         if (!intel_dp)
> > -               return false;
> > +               goto unlock;
> >  
> > +       wait = true;
> >         if (HAS_DDI(dev_priv)) {
> >                 if (dev_priv->psr.psr2_enabled) {
> >                         reg = EDP_PSR2_STATUS;
> > @@ -911,15 +915,18 @@ static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
> >                 mask = VLV_EDP_PSR_IN_TRANS;
> >         }
> >  
> > +unlock:
> >         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");
> > +       if(wait) {
> > +               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");
> > +                       wait = false;
> > +               }
> > +       }
> >  
> > -       /* After the unlocked wait, verify that PSR is still wanted! */
> > -       mutex_lock(&dev_priv->psr.lock);
> > -       return err == 0 && dev_priv->psr.enabled;
> > +       return wait;
I wanted to avoid taking this additional lock b/c all we need inside intel_pipe_update_start is for PSR to go idle. So can we retain moving it to intel_psr_work ?
> >  }
> >  
> >  static void intel_psr_work(struct work_struct *work)
> > @@ -927,7 +934,6 @@ 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
> > @@ -936,14 +942,15 @@ static void intel_psr_work(struct work_struct *work)
> >          * and be ready for re-enable.
> >          */
> >         if (!psr_wait_for_idle(dev_priv))
> > -               goto unlock;
> > +               return;
> >  
> > -       /*
> > +       /* After the unlocked wait, verify that PSR is still wanted!
> >          * The delayed work can race with an invalidate hence we need to
> >          * recheck. Since psr_flush first clears this and then reschedules we
> >          * won't ever miss a flush when bailing out here.
> >          */
> > -       if (dev_priv->psr.busy_frontbuffer_bits)
> > +       mutex_lock(&dev_priv->psr.lock);
> > +       if (dev_priv->psr.enabled && dev_priv->psr.busy_frontbuffer_bits)
> >                 goto unlock;
> 
> I'm not sold on the locking dropping here, doing so inside the wait is
> bad enough. (And do we need to there anyway?)
> 
Thanks for the comments Chris.
In that case, as suggested by Rodrigo, can we assert that the lock is held, inside psr_wait_for_idle() ?
> Since you need to introduce intel_psr_wait_for_idle() anyway, how about
> 
> void intel_psr_wait_for_idle(...)
> {
> 	mutex_lock(&i915->psr.lock);
> 	psr_wait_for_idle();
> 	mutex_unlock(&i915->psr.lock);
> }
> -Chris
>>        /* After the unlocked wait, verify that PSR is still wanted! */
>>	mutex_lock(&dev_priv->psr.lock); 
>>	return err == 0 && dev_priv->psr.enabled; 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-14 22:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 20:49 [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused Tarun Vyas
2018-05-14 20:49 ` [PATCH 2/2] drm/i915: Un-statify psr_wait_for_idle Tarun Vyas
2018-05-14 20:49 ` [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion Tarun Vyas
2018-05-14 21:16   ` Chris Wilson
2018-05-15 19:38     ` Tarun Vyas
2018-05-15  3:16   ` kbuild test robot
2018-06-19 21:27   ` Dhinakaran Pandiyan
2018-06-19 21:54     ` Dhinakaran Pandiyan
2018-06-19 21:59       ` Tarun Vyas
2018-06-19 23:11         ` Dhinakaran Pandiyan
2018-06-21 22:43         ` Tarun Vyas
2018-05-14 21:15 ` [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused Chris Wilson
2018-05-14 22:00   ` Tarun Vyas [this message]
2018-05-17 20:35     ` Tarun Vyas
2018-05-14 21:35 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2] drm/i915: Wait for PSR exit before checking for vblank evasion (rev2) Patchwork
2018-05-14 21:36 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-05-14 21:53 ` ✗ Fi.CI.BAT: failure " Patchwork

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=20180514220015.GA194720@otc-chromeosbuild-5 \
    --to=tarun.vyas@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=rodrigo.vivi@intel.com \
    /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.