Intel-GFX Archive on 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox