All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Disable C3 when enabling vblank interrupts on i945gm
Date: Mon, 25 Mar 2019 09:03:56 +0200	[thread overview]
Message-ID: <20190325070356.GP3888@intel.com> (raw)
In-Reply-To: <20190322235534.GM3888@intel.com>

On Sat, Mar 23, 2019 at 01:55:34AM +0200, Ville Syrjälä wrote:
> On Fri, Mar 22, 2019 at 09:08:35PM +0000, Chris Wilson wrote:
> > Quoting Ville Syrjala (2019-03-22 18:08:03)
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > The AGPBUSY thing doesn't work on i945gm anymore. This means
> > > the gmch is incapable of waking the CPU from C3 when an interrupt
> > > is generated. The interrupts just get postponed indefinitely until
> > > something wakes up the CPU. This is rather annoying for vblank
> > > interrupts as we are unable to maintain a steady framerate
> > > unless the machine is sufficiently loaded to stay out of C3.
> > > 
> > > To combat this let's use pm_qos to prevent C3 whenever vblank
> > > interrupts are enabled. To maintain reasonable amount of powersaving
> > > we will attempt to limit this to C3 only while leaving C1 and C2
> > > enabled.
> > 
> > Interesting compromise. Frankly, I had considered pm_qos in an
> > all-or-nothing approach, partly because finding the C transitions is a
> > bit opaque.
> >  
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30364
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h |  8 +++
> > >  drivers/gpu/drm/i915/i915_irq.c | 88 +++++++++++++++++++++++++++++++++
> > >  2 files changed, 96 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > > index f723b15527f8..0c736f8ca1b2 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2042,6 +2042,14 @@ struct drm_i915_private {
> > >                 struct i915_vma *scratch;
> > >         } gt;
> > >  
> > > +       /* For i945gm vblank irq vs. C3 workaround */
> > > +       struct {
> > > +               struct work_struct work;
> > > +               struct pm_qos_request pm_qos;
> > > +               u8 c3_disable_latency;
> > 
> > Ok, looks a bit tight, but checks out.
> > 
> > > +               u8 enabled;
> > > +       } i945gm_vblank;
> > > +
> > >         /* perform PHY state sanity checks? */
> > >         bool chv_phy_assert[2];
> > >  
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > > index 2f788291cfe0..33386f0acab3 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -30,6 +30,7 @@
> > >  
> > >  #include <linux/sysrq.h>
> > >  #include <linux/slab.h>
> > > +#include <linux/cpuidle.h>
> > >  #include <linux/circ_buf.h>
> > >  #include <drm/drm_irq.h>
> > >  #include <drm/drm_drv.h>
> > > @@ -3131,6 +3132,16 @@ static int i8xx_enable_vblank(struct drm_device *dev, unsigned int pipe)
> > >         return 0;
> > >  }
> > >  
> > > +static int i945gm_enable_vblank(struct drm_device *dev, unsigned int pipe)
> > > +{
> > > +       struct drm_i915_private *dev_priv = to_i915(dev);
> > > +
> > > +       if (dev_priv->i945gm_vblank.enabled++ == 0)
> > > +               schedule_work(&dev_priv->i945gm_vblank.work);
> > 
> > I was thinking u8, isn't that a bit dangerous. But the max counter here
> > should be num_pipes. Hmm, is the vblank spinlock local to a pipe? Nope,
> > dev->vbl_lock.
> > 
> > > +
> > > +       return i8xx_enable_vblank(dev, pipe);
> > > +}
> > > +
> > >  static int i965_enable_vblank(struct drm_device *dev, unsigned int pipe)
> > >  {
> > >         struct drm_i915_private *dev_priv = to_i915(dev);
> > > @@ -3195,6 +3206,16 @@ static void i8xx_disable_vblank(struct drm_device *dev, unsigned int pipe)
> > >         spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> > >  }
> > >  
> > > +static void i945gm_disable_vblank(struct drm_device *dev, unsigned int pipe)
> > > +{
> > > +       struct drm_i915_private *dev_priv = to_i915(dev);
> > > +
> > > +       i8xx_disable_vblank(dev, pipe);
> > > +
> > > +       if (--dev_priv->i945gm_vblank.enabled == 0)
> > > +               schedule_work(&dev_priv->i945gm_vblank.work);
> > > +}
> > > +
> > >  static void i965_disable_vblank(struct drm_device *dev, unsigned int pipe)
> > >  {
> > >         struct drm_i915_private *dev_priv = to_i915(dev);
> > > @@ -3228,6 +3249,60 @@ static void gen8_disable_vblank(struct drm_device *dev, unsigned int pipe)
> > >         spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> > >  }
> > >  
> > > +static void i945gm_vblank_work_func(struct work_struct *work)
> > > +{
> > > +       struct drm_i915_private *dev_priv =
> > > +               container_of(work, struct drm_i915_private, i945gm_vblank.work);
> > > +
> > > +       /*
> > > +        * Vblank interrupts fail to wake up the device from C3,
> > > +        * hence we want to prevent C3 usage while vblank interrupts
> > > +        * are enabled.
> > > +        */
> > > +       pm_qos_update_request(&dev_priv->i945gm_vblank.pm_qos,
> > > +                             dev_priv->i945gm_vblank.enabled ?
> > > +                             dev_priv->i945gm_vblank.c3_disable_latency :
> > > +                             PM_QOS_DEFAULT_VALUE);
> > 
> > Worker is required as the update may block.
> > 
> > I'd prefer that as READ_ONCE(dev_priv->i945gm_vblank.enabled)
> 
> Yeah, that does seem appropriate.

Pushed with that before I have chance to regret the 0.7W.
Thanks for the review.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-03-25  7:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22 18:08 [PATCH 1/2] drm/i915: Disable C3 when enabling vblank interrupts on i945gm Ville Syrjala
2019-03-22 18:08 ` [PATCH 2/2] drm/i915: Use vblank_disable_immediate on gen2 Ville Syrjala
2019-03-22 21:09   ` Chris Wilson
2019-03-22 19:53 ` ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Disable C3 when enabling vblank interrupts on i945gm Patchwork
2019-03-22 20:15 ` ✓ Fi.CI.BAT: success " Patchwork
2019-03-22 21:08 ` [PATCH 1/2] " Chris Wilson
2019-03-22 23:55   ` Ville Syrjälä
2019-03-25  7:03     ` Ville Syrjälä [this message]
2019-03-23 23:03 ` ✓ Fi.CI.IGT: success for series starting with [1/2] " 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=20190325070356.GP3888@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.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.