From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/i915: properly lock gt_fifo_count
Date: Sun, 6 Nov 2011 11:46:44 +0100 [thread overview]
Message-ID: <20111106104644.GA2940@phenom.ffwll.local> (raw)
In-Reply-To: <d08817$23njts@azsmga001.ch.intel.com>
On Sun, Nov 06, 2011 at 08:39:46AM +0000, Chris Wilson wrote:
> On Sun, 6 Nov 2011 01:41:35 +0100, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Use a combination of atomic_t and a spinlocked slow-path to make most
> > writes fast.
>
> What happened to the rule that this was protected by struct_mutex?
> Did you find a violation? Or is this step 1 in the hundred step plan to
> clarify and fix the locking around register access?
The real problem is the read side, which isn't really protected by
struct_mutex everywhere. And we can't change that because we want to
capture the error_state without taking struct_mutex. Somehow I've gotten a
bit overenthusiastic about all this and decided to start with that 5 year
plan to clean up our locking around register access.
After some more thinking this morning I've noticed that my trick is
fundamentally racy. Before I embarass myself even more I'll drop this
patch and just resend the read side locking fix so that the hangcheck
won't kill my machine anymore.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2011-11-06 10:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-06 0:31 [PATCH 1/2] drm/i915: properly lock gt_fifo_count Daniel Vetter
2011-11-06 0:31 ` [PATCH 2/2] drm/i915: protect force_wake_(get|put) with the gt_lock Daniel Vetter
2011-11-06 0:41 ` [PATCH 1/2] drm/i915: properly lock gt_fifo_count Daniel Vetter
2011-11-06 8:39 ` Chris Wilson
2011-11-06 10:46 ` Daniel Vetter [this message]
2011-11-06 11:31 ` [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock Daniel Vetter
2011-11-06 11:57 ` Chris Wilson
2011-11-06 12:35 ` Daniel Vetter
2011-11-06 21:01 ` Chris Wilson
2011-11-06 22:06 ` 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=20111106104644.GA2940@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--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.