From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
Date: Sun, 06 Nov 2011 21:01:44 +0000 [thread overview]
Message-ID: <c55c5d$1097gk@AZSMGA002.ch.intel.com> (raw)
In-Reply-To: <1320582922-5618-1-git-send-email-daniel.vetter@ffwll.ch>
On Sun, 6 Nov 2011 13:35:22 +0100, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> The problem this patch solves is that the forcewake accounting
> necessary for register reads is protected by dev->struct_mutex. But the
> hangcheck and error_capture code need to access registers without
> grabbing this mutex because we hold it while waiting for the gpu.
> So a new lock is required. Because currently the error_state capture
> is called from the error irq handler and the hangcheck code runs from
> a timer, it needs to be an irqsafe spinlock (note that the registers
> used by the irq handler (neglecting the error handling part) only uses
> registers that don't need the forcewake dance).
>
> We could tune this down to a normal spinlock when we rework the
> error_state capture and hangcheck code to run from a workqueue. But
> we don't have any read in a fastpath that needs forcewake, so I've
> decided to not care much about overhead.
>
> This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
> snb on recent kernels - something must have slightly changed the
> timings. On previous kernels it only trigger a WARN about the broken
> locking.
>
> v2: Drop the previous patch for the register writes.
>
> v3: Improve the commit message per Chris Wilson's suggestions.
>
> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
One minor oddity left ;-)
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 8 ++++++--
> drivers/gpu/drm/i915/i915_dma.c | 1 +
> drivers/gpu/drm/i915/i915_drv.c | 19 +++++++++++++------
> drivers/gpu/drm/i915/i915_drv.h | 10 +++++++---
> 4 files changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5ba63ad..51b21eb 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1320,9 +1320,13 @@ static int i915_gen6_forcewake_count_info(struct seq_file *m, void *data)
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> struct drm_device *dev = node->minor->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + unsigned forcewake_count;
>
> - seq_printf(m, "forcewake count = %d\n",
> - atomic_read(&dev_priv->forcewake_count));
> + spin_lock_irq(&dev_priv->gt_lock);
> + forcewake_count = dev_priv->forcewake_count;
> + spin_unlock_irq(&dev_priv->gt_lock);
> +
> + seq_printf(m, "forcewake count = %d\n", forcewake_count);
Is it signed or unsigned? Who cares? ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2011-11-06 21:01 UTC|newest]
Thread overview: 21+ 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
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 [this message]
2011-11-06 22:06 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2011-11-06 17:42 Nicolas Kalkhof
2011-11-06 17:46 ` Daniel Vetter
2011-11-07 13:52 Nicolas Kalkhof
2011-11-07 16:05 ` Daniel Vetter
2011-11-07 16:39 Nicolas Kalkhof
2011-11-07 16:56 ` Daniel Vetter
2011-11-07 17:31 Nicolas Kalkhof
2011-11-07 18:14 Nicolas Kalkhof
2011-11-07 18:36 ` Daniel Vetter
2011-11-09 16:22 Nicolas Kalkhof
2011-11-09 16:28 ` 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='c55c5d$1097gk@AZSMGA002.ch.intel.com' \
--to=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.