All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/i915: reference counted forcewake
Date: Mon, 18 Apr 2011 10:31:43 -0700	[thread overview]
Message-ID: <20110418173143.GA10406@bwgnt.jf.intel.com> (raw)
In-Reply-To: <0d30dc$ls6j08@orsmga001.jf.intel.com>

On Sat, Apr 16, 2011 at 07:52:44AM +0100, Chris Wilson wrote:
> On Thu, 14 Apr 2011 11:13:46 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> > Provide a reference count to track the forcewake state of the GPU. The
> > savings is up to 1 UC read if the unit is already awake, but the main
> > goal is to give userspace some mechanism to wake the GPU.
> > 
> > v2:
> > Added a spin_lock for synchronizing access to forcewake. The lock
> > should not be heavily contested because any caller will either have
> > struct_mutex or config.mutex, and those locks should be much more
> > serializing than this. In terms of locking order:
> > 
> > 1.[config.mutex]
> > 2.	[struct_mutex]
> > 3.		forcewake_lock
> > 
> > By default i915_read[bwlq] functions now acquire forcewake_lock. Added a new
> > _locked version of the read function for callers wishing to prevent the
> > GT from possibly going to sleep in between reads. (We could also use
> > these functions to try to get system state if the lock somehow becomes
> > stuck).
> 
> This patch needs to be split again. I want the update to the existing
> interface and users to be separate from the introduction of a new
> interface. (This means that should we ever regret that interface we can
> rip it out without undoing the fixes.)
> 
> Replacing the get()...long sequence of read/writes...put() did make me cry
> a little, but it is indeed safer to move the check into the individual
> reads (though there is nothing to prevent the rc6-window from closing
> during the middle of that sequence... we need to check that is ok) and too
> ugly to special case those rare times when we do modify 20 regs at once
> (or maybe we have to?).

In case you didn't notice, there is a new interface
i915_read##x##_awake. This should serve that need. In other words:
gen6_gt_force_wake_get()
while(foo)
	i915_read32_awake()
gen6_gt_force_wake_put()

I'll split the patches. I can also use the awake() variant for the
existing users, if you're okay with the awake() function (I was actually
expecting a comment from you on that). For the relevant functions, it
should be as simple as:
s/I915_READ32/i915_read32_awake
s/__gen6_gt_force_wake_/gen6_gt_force_wake_/

Jesse has started the email to verify IIR is in fact a problem for us.
So I'll postpone resubmitting the patches until that's confirmed.

> 
> Again, let's change the macro without removing the existing get()...put()
> users and then remove those as a patch+review on a per-case basis.
> 
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -2025,6 +2025,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
> >  
> >  	spin_lock_init(&dev_priv->irq_lock);
> >  	spin_lock_init(&dev_priv->error_lock);
> > +	if (IS_GEN6(dev))
> > +		spin_lock_init(&dev_priv->forcewake_lock);
> 
> Just do it.

Once again, I went back and forth and picked the one I thought you would
like. I'm learning...

> -Chris

  reply	other threads:[~2011-04-18 17:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-14 18:13 forcewake v4 (now with spinlock) Ben Widawsky
2011-04-14 18:13 ` (no subject) Ben Widawsky
2011-04-14 18:13 ` [PATCH 1/3] drm/i915: proper use of forcewake Ben Widawsky
2011-04-14 18:13 ` [PATCH 2/3] drm/i915: reference counted forcewake Ben Widawsky
2011-04-14 19:12   ` Ben Widawsky
2011-04-16  6:52   ` Chris Wilson
2011-04-18 17:31     ` Ben Widawsky [this message]
2011-04-19  5:48       ` Chris Wilson
2011-04-19 15:12       ` Keith Packard
2011-04-14 18:13 ` [PATCH 3/3] drm/i915: userspace interface to the forcewake Ben Widawsky
2011-04-14 19:13   ` Ben Widawsky
2011-04-14 19:56   ` Paul Menzel
2011-04-16  7:05     ` Chris Wilson
2011-04-17 16:55       ` Ben Widawsky

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=20110418173143.GA10406@bwgnt.jf.intel.com \
    --to=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.