All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 3/4] drm/i915: Move underrun work from fbc to fifo_underrun.
Date: Mon, 26 Feb 2018 14:23:29 -0800	[thread overview]
Message-ID: <20180226222329.GB24704@intel.com> (raw)
In-Reply-To: <151967885050.14388.3364410613556862500@mail.alporthouse.com>

On Mon, Feb 26, 2018 at 09:00:50PM +0000, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-02-26 20:53:08)
> > -void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
> > -{
> > -       struct intel_fbc *fbc = &dev_priv->fbc;
> > -
> > -       if (!fbc_supported(dev_priv))
> > -               return;
> > -
> > -       /* There's no guarantee that underrun_detected won't be set to true
> > -        * right after this check and before the work is scheduled, but that's
> > -        * not a problem since we'll check it again under the work function
> > -        * while FBC is locked. This check here is just to prevent us from
> > -        * unnecessarily scheduling the work, and it relies on the fact that we
> > -        * never switch underrun_detect back to false after it's true. */
> > -       if (READ_ONCE(fbc->underrun_detected))
> > -               return;
> > -
> > -       schedule_work(&fbc->underrun_work);
> > -}
> 
> > +static void intel_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
> > +{
> > +       if (!HAS_FBC(dev_priv))
> > +               return;
> > +
> > +       spin_lock(&dev_priv->underrun.lock);
> > +
> > +       if (dev_priv->underrun.detected)
> > +               goto out;
> > +       dev_priv->underrun.detected = true;
> > +
> > +       schedule_work(&dev_priv->underrun.work);
> > +out:
> > +       spin_unlock(&dev_priv->underrun.lock);
> 
> This locking (or bool) isn't required by the following patch either. But
> I presume the boolean is printed at some point, although that's probably
> less useful than whatever FBC/SAGV would say about being disabled.

I honestly didn't fully followed the initial goal of checking the detection
before scheduling the work.... So I assumed it was some underrun storm
and a mechanism to avoid multiple calls to fbc disable...

But yeap... I think we could live without it if no storm is possible
or if internal sagv and fbc are already handling those properly.

> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-02-26 22:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 20:53 [PATCH 1/4] drm/i915: Don't propagate SAGV errnos in vain Rodrigo Vivi
2018-02-26 20:53 ` [PATCH 2/4] drm/i915: Introduce SAGV mutex Rodrigo Vivi
2018-02-26 21:21   ` Chris Wilson
2018-02-26 22:20     ` Rodrigo Vivi
2018-02-26 20:53 ` [PATCH 3/4] drm/i915: Move underrun work from fbc to fifo_underrun Rodrigo Vivi
2018-02-26 21:00   ` Chris Wilson
2018-02-26 22:23     ` Rodrigo Vivi [this message]
2018-02-26 20:53 ` [PATCH 4/4] drm/i915: Also disable SAGV on fifo underrun Rodrigo Vivi
2018-02-26 21:25 ` ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Don't propagate SAGV errnos in vain Patchwork

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=20180226222329.GB24704@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.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.