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,
	Paul Menzel <paulepanter@users.sourceforge.net>
Subject: Re: [PATCH 3/3] drm/i915: userspace interface to the forcewake
Date: Sun, 17 Apr 2011 09:55:12 -0700	[thread overview]
Message-ID: <20110417165512.GA21592@lundgren.kumite> (raw)
In-Reply-To: <1bdc18$k8bua6@fmsmga002.fm.intel.com>

On Sat, Apr 16, 2011 at 08:05:42AM +0100, Chris Wilson wrote:
> On Thu, 14 Apr 2011 21:56:02 +0200, Paul Menzel <paulepanter@users.sourceforge.net> wrote:

> But Ben... I seemed to have missed the real reason why we need the
> spinlock. You have to remind me or else I will keep whining on like a
> broken record. ;-)
> -Chris
> 

The reason rests on 1 major conclusion, we must make sure FORCEAWAKE
(FORCEWAKE_ACK in the code) is set prior to reading any register in the
range 0-0x3ffff. If I've misunderstood the way this works, and that is
not correct, then you can stop reading now.

The simplest case which shows why we need a spinlock is in reading IIR
(as discussed previously, including my theory why we probably don't
actually have an issue today) in the interrupt handler. We can't get
struct_mutex there, so we're forced to either bump up struct_mutex to a
spinlock, or introduce a new one.

There were one or two cases which got uncovered with the warning, which
I can't find from code inspection right now, where we write to these
registers with just config.mutex. In those cases, we could just acquire
struct_mutex after config.mutex, and that should fix those problems.

Now assuming access is synchronized, here is how I believe it should
work:

/*
 * Sorry for using the register names from the doc, which differ from
 * our code, but I'm writing this while reading the docs, not our code.
 */
u32 reg = IIR; // As an example
if (reg < 0x40000) {
	while(!I915_READ(GTFORCEAWAKE)) {
		I915_WRITE(FORCEWAKE, FWAKE2)
		I915_POSTING_READ(FORCEWAKE);
		gen6_gt_drain_write_fifo(); // ;)
	}
}

I would honestly prefer being wrong about this :-)
Ben

      reply	other threads:[~2011-04-17 16:55 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
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 [this message]

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=20110417165512.GA21592@lundgren.kumite \
    --to=ben@bwidawsk.net \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulepanter@users.sourceforge.net \
    /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.