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, Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH] drm/i915: Convert the forcewake worker into a timer func
Date: Fri, 28 Feb 2014 11:16:33 +0200	[thread overview]
Message-ID: <20140228091633.GO3852@intel.com> (raw)
In-Reply-To: <1393578158-2112-1-git-send-email-chris@chris-wilson.co.uk>

On Fri, Feb 28, 2014 at 09:02:38AM +0000, Chris Wilson wrote:
> We don't want to suffer scheduling delay when turning off the GPU after
> waking it up to touch registers. Ideally, we only want to keep the GPU
> awake for the register access sequence, with a single forcewake dance on
> the first access and release immediately after the last. We set a timer
> on the first access so that we only dance once and on the next scheduler
> tick, we drop the forcewake again.
> 
> This moves the cleanup routine from the common i915 workqueue to a timer
> func so that we don't anger powertop, and drop the forcewake again
> quicker.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Ben Widawsky <ben@bwidawsk.net>
> ---
>  drivers/gpu/drm/i915/i915_drv.h     |    2 +-
>  drivers/gpu/drm/i915/intel_uncore.c |   15 ++++++---------
>  2 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index eb31c45..9416b03 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -508,7 +508,7 @@ struct intel_uncore {
>  	unsigned fw_rendercount;
>  	unsigned fw_mediacount;
>  
> -	struct delayed_work force_wake_work;
> +	struct timer_list force_wake_timer;
>  };
>  
>  #define DEV_INFO_FOR_EACH_FLAG(func, sep) \
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index c628414..140a9f0 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -289,10 +289,8 @@ void vlv_force_wake_put(struct drm_i915_private *dev_priv,
>  	spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
>  }
>  
> -static void gen6_force_wake_work(struct work_struct *work)
> +static void gen6_force_wake_timer(struct drm_i915_private *dev_priv)
>  {
> -	struct drm_i915_private *dev_priv =
> -		container_of(work, typeof(*dev_priv), uncore.force_wake_work.work);
>  	unsigned long irqflags;
>  
>  	spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> @@ -405,9 +403,8 @@ void gen6_gt_force_wake_put(struct drm_i915_private *dev_priv, int fw_engine)
>  	spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
>  	if (--dev_priv->uncore.forcewake_count == 0) {
>  		dev_priv->uncore.forcewake_count++;
> -		mod_delayed_work(dev_priv->wq,
> -				 &dev_priv->uncore.force_wake_work,
> -				 1);
> +		mod_timer_pinned(&dev_priv->uncore.force_wake_timer,
> +				 jiffies + 1);
>  	}
>  	spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);

Should we use the timer to delay the forcewake release from register
read/write functions too? Or maybe do it only for register
read/write since gen6_gt_force_wake_get/put are rather rare and I
wouldn't expect significant forcewake ping-pong after the put.

>  
> @@ -681,8 +678,8 @@ void intel_uncore_init(struct drm_device *dev)
>  {
>  	struct drm_i915_private *dev_priv = dev->dev_private;
>  
> -	INIT_DELAYED_WORK(&dev_priv->uncore.force_wake_work,
> -			  gen6_force_wake_work);
> +	setup_timer(&dev_priv->uncore.force_wake_timer,
> +		    gen6_force_wake_timer, (unsigned long)dev_priv);
>  
>  	if (IS_VALLEYVIEW(dev)) {
>  		dev_priv->uncore.funcs.force_wake_get = __vlv_force_wake_get;
> @@ -794,7 +791,7 @@ void intel_uncore_fini(struct drm_device *dev)
>  {
>  	struct drm_i915_private *dev_priv = dev->dev_private;
>  
> -	flush_delayed_work(&dev_priv->uncore.force_wake_work);
> +	del_timer_sync(&dev_priv->uncore.force_wake_timer);
>  
>  	/* Paranoia: make sure we have disabled everything before we exit. */
>  	intel_uncore_sanitize(dev);
> -- 
> 1.7.9.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-02-28  9:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-26 11:06 [PATCH] drm/i915: Delay the relase of the forcewake by a jiffie Chris Wilson
2013-08-26 11:49 ` Ville Syrjälä
2014-02-23 20:12 ` Ben Widawsky
2014-02-24  8:30   ` Chris Wilson
2014-02-24 20:31     ` Ben Widawsky
2014-02-28  9:02       ` [PATCH] drm/i915: Convert the forcewake worker into a timer func Chris Wilson
2014-02-28  9:16         ` Ville Syrjälä [this message]
2014-02-28 16:38           ` Chris Wilson
2014-02-28 18:44           ` Chris Wilson
2014-03-03  1:01             ` Ben Widawsky
2014-03-03  7:05               ` Chris Wilson
2014-03-03 14:46             ` Ville Syrjälä
2014-03-03 14:55               ` Chris Wilson
2014-03-05 12:00               ` Chris Wilson
2014-03-05 12:21                 ` Ville Syrjälä
2014-03-05 12:50                   ` Daniel Vetter

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=20140228091633.GO3852@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=ben@bwidawsk.net \
    --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.