All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: Simplify ilk-ivb underrun suppression
Date: Fri, 25 May 2018 22:23:47 +0300	[thread overview]
Message-ID: <20180525192347.GJ23723@intel.com> (raw)
In-Reply-To: <152726373601.4081.7861432797466581848@mail.alporthouse.com>

On Fri, May 25, 2018 at 04:55:36PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-05-25 16:43:42)
> > On Fri, May 25, 2018 at 04:20:07PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2018-05-24 20:04:06)
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Let's suppress the underruns around every modeset sequence instead
> > > > of trying to avoid it. Planes are disabled at this point anyway so
> > > > we don't really gain anything from keeping the underrun reporting
> > > > enabled. Also for PCH ports we already suppress all underruns here
> > > > anyway so trying avoid it for the CPU eDP doesn't seem all that
> > > > important.
> > > > 
> > > > Maybe this gets rid of some lingering spurious underruns?
> > > 
> > > I'll bite. Isn't the reason for enabling underrung report for the
> > > modeset itself to detect errors in our sequence?
> > 
> > In theory CPU FIFO underruns shouldn't happen until we have some planes
> > enabled. Otherwise we have no data going through the FIFOs and thus
> > reporting an underrun isn't particularly sane. That doesn't stop gen2
> > from doing it though, but gen3+ seem to follow the more reasonable
> > interpretation of what a FIFO underrun means.
> 
> Makes sense.
>  
> > I suppose PCH FIFO underruns are a bit different as there is data flowing
> > as soon as the CPU pipe starts running, whether or not any planes have
> > been enabled. So those could certainly indicate some kind of programming
> > sequence error. Or it could just be totally expected that we start the
> > PCH side of the pipe first and there's a small bit of time when the CPU
> > pipe isn't yet pushing out pixels, and that's when the PCH side reports
> > the underrun.
> > 
> > > 
> > > How certain are we that these are hw limitations vs sw bugs?
> > 
> > To the best of my knowledge we are reasonably close to the sequence
> > listed in bspec. And while it's at least theoretically possible that
> > there's some change we could make to eliminate the underruns I don't
> > suppose anyone has the time or energy to try out all possible
> > variations.
> > 
> > And as long as the underrun (even if it's real) has vanished by the
> > time we enable the planes I think we are reasonably safe wrt. getting
> > the correct looking output to the user's display.
> 
> Also makes sense. And if glitches during modesetting itself, we hope
> nobody complains ;)
> 
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks. Pushed.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-25 19:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24 19:04 [PATCH 1/2] drm/i915: Try to suppress more spurious PCH underruns on ILK-IVB Ville Syrjala
2018-05-24 19:04 ` [PATCH 2/2] drm/i915: Simplify ilk-ivb underrun suppression Ville Syrjala
2018-05-25 15:20   ` Chris Wilson
2018-05-25 15:43     ` Ville Syrjälä
2018-05-25 15:55       ` Chris Wilson
2018-05-25 19:23         ` Ville Syrjälä [this message]
2018-05-24 19:50 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Try to suppress more spurious PCH underruns on ILK-IVB Patchwork
2018-05-24 20:14 ` [PATCH 1/2] " Chris Wilson
2018-05-24 20:15   ` Chris Wilson
2018-05-24 20:31     ` Ville Syrjälä
2018-05-24 21:19 ` Chris Wilson
2018-05-25 15:02   ` Ville Syrjälä
2018-05-25 15:19     ` Jani Nikula
2018-05-25 15:49       ` Ville Syrjälä
2018-05-25  2:00 ` ✓ Fi.CI.IGT: success for series starting with [1/2] " 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=20180525192347.GJ23723@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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.