All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Rodrigo Vivi <rodrigo.vivi@gmail.com>,
	Ben Widawsky <benjamin.widawsky@intel.com>,
	Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Fix some NUM_RING iterators
Date: Sat, 28 Jun 2014 08:26:15 -0700	[thread overview]
Message-ID: <20140628152615.GC17803@bwidawsk.net> (raw)
In-Reply-To: <20140628062038.GA25660@nuc-i3427.alporthouse.com>

On Sat, Jun 28, 2014 at 07:20:38AM +0100, Chris Wilson wrote:
> On Fri, Jun 27, 2014 at 03:21:20PM -0700, Rodrigo Vivi wrote:
> >    Reviewed-by: Rodrigo Vivi <[1]rodrigo.vivi@intel.com>
> > 
> >    On Fri, Jun 27, 2014 at 3:09 PM, Ben Widawsky
> >    <[2]benjamin.widawsky@intel.com> wrote:
> > 
> >      There are some cases in the code where we need to know how many rings to
> >      iterate over, but cannot use for_each_ring(). These are always error
> >      cases
> >      which happen either before ring setup, or after ring teardown (or
> >      reset).
> > 
> >      Note, a NUM_RINGS issue exists in semaphores, but this is fixed by the
> >      remaining semaphore patches which Rodrigo will resubmit shortly. I'd
> >      rather see those patches for fixing the problem than fix it here.
> > 
> >      I found this initially for the BSD2 case where on the same platform we
> >      can have differing rings. AFAICT however this effects many platforms.
> > 
> >      I'd CC stable on this, except I think all the issues have been around
> >      for multiple releases without bug reports.
> > 
> >      Compile tested only for now.
> > 
> >      Signed-off-by: Ben Widawsky <[3]ben@bwidawsk.net>
> >      ---
> >       drivers/gpu/drm/i915/i915_gem_context.c | 6 +++---
> >       drivers/gpu/drm/i915/i915_gpu_error.c   | 2 +-
> >       drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
> >       3 files changed, 6 insertions(+), 4 deletions(-)
> > 
> >      diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> >      b/drivers/gpu/drm/i915/i915_gem_context.c
> >      index b9bac25..0c044a9 100644
> >      --- a/drivers/gpu/drm/i915/i915_gem_context.c
> >      +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >      @@ -403,7 +403,7 @@ void i915_gem_context_reset(struct drm_device *dev)
> > 
> >              /* Prevent the hardware from restoring the last context (which
> >      hung) on
> >               * the next switch */
> >      -       for (i = 0; i < I915_NUM_RINGS; i++) {
> >      +       for (i = 0; i < I915_ACTIVE_RINGS(dev); i++) {
> >                      struct intel_engine_cs *ring = &dev_priv->ring[i];
> >                      struct intel_context *dctx = ring->default_context;
> > 
> >      @@ -456,7 +456,7 @@ int i915_gem_context_init(struct drm_device *dev)
> >              }
> > 
> >              /* NB: RCS will hold a ref for all rings */
> >      -       for (i = 0; i < I915_NUM_RINGS; i++)
> >      +       for (i = 0; i < I915_ACTIVE_RINGS(dev); i++)
> >                      dev_priv->ring[i].default_context = ctx;
> > 
> >              DRM_DEBUG_DRIVER("%s context support initialized\n",
> >      dev_priv->hw_context_size ? "HW" : "fake");
> >      @@ -493,7 +493,7 @@ void i915_gem_context_fini(struct drm_device *dev)
> >                      i915_gem_object_ggtt_unpin(dctx->obj);
> >              }
> > 
> >      -       for (i = 0; i < I915_NUM_RINGS; i++) {
> >      +       for (i = 0; i < I915_ACTIVE_RINGS(dev); i++) {
> >                      struct intel_engine_cs *ring = &dev_priv->ring[i];
> > 
> >                      if (ring->last_context)
> >      diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> >      b/drivers/gpu/drm/i915/i915_gpu_error.c
> >      index 86362de..6e5250d 100644
> >      --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> >      +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> >      @@ -848,7 +848,7 @@ static uint32_t i915_error_generate_code(struct
> >      drm_i915_private *dev_priv,
> >               * synchronization commands which almost always appear in the
> >      case
> >               * strictly a client bug. Use instdone to differentiate those
> >      some.
> >               */
> >      -       for (i = 0; i < I915_NUM_RINGS; i++) {
> >      +       for (i = 0; i < I915_ACTIVE_RINGS(dev_priv->dev); i++) {
> >                      if (error->ring[i].hangcheck_action == HANGCHECK_HUNG) {
> >                              if (ring_id)
> >                                      *ring_id = i;
> >      diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> >      b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >      index e72017b..67e2919 100644
> >      --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> >      +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >      @@ -90,6 +90,8 @@ struct  intel_engine_cs {
> >              } id;
> >       #define I915_NUM_RINGS 5
> >       #define LAST_USER_RING (VECS + 1)
> >      +#define I915_ACTIVE_RINGS(dev) hweight8(INTEL_INFO(dev)->ring_mask)
> 
> What does the popcount of the mask have to do with the validity of the
> arrays being iterated over in this patch?
> -Chris

The popcount of the mask represents the number of rings available on the
specific SKU, as opposed to the total number of rings on any SKU ever.
It is not always correct to iterate on all rings in the system. Please
note, the patch is incomplete. I have a couple of other, perhaps more
interesting, cases which I've missed.

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-06-28 15:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 22:09 [PATCH] drm/i915: Fix some NUM_RING iterators Ben Widawsky
2014-06-27 22:21 ` Rodrigo Vivi
2014-06-28  4:45   ` Ben Widawsky
2014-06-28  6:20   ` Chris Wilson
2014-06-28 15:26     ` Ben Widawsky [this message]
2014-06-28 19:28       ` Chris Wilson
2014-06-28 21:55         ` Ben Widawsky
2014-06-30 11:27           ` Mateo Lozano, Oscar
2014-07-07 19:37             ` 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=20140628152615.GC17803@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=benjamin.widawsky@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@gmail.com \
    /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.