All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 0/4] FIFO underrun reporting v2
Date: Mon, 25 Feb 2013 14:14:56 +0200	[thread overview]
Message-ID: <20130225121456.GR4469@intel.com> (raw)
In-Reply-To: <1361563531-4653-1-git-send-email-przanoni@gmail.com>

On Fri, Feb 22, 2013 at 05:05:27PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> Hi
> 
> Here's a new series that tries to report FIFO underruns. The new implementation
> is completely different from the old one, due to the reviews I received. Now we
> don't just "ignore" the FIFO underrun interrupts when we receive them, we
> effectively disable the interrupts (the downsides of this approach are
> documented in the commit message of patch 2).
> 
> We will still see at most one of each error FIFO underrun message per mode set,
> so this is not really going to flood dmesg. I tested this series on ILK, SNB and
> HSW, and I am only seeing FIFO underruns on ILK when using 2 monitors
> (LVDS+HDMI). I'll work on a patch to fix this message later (at least now we
> know we have problems!).

If you want another way to get FIFO underruns, take an IVB machine, grab
my plane clipping patches and my glplane app, run the app w/ something
like 1080p resolution and hit 't'. When the sprite is at a magic
position on the screen and the downscaling ratio is at the maximum you
should see underruns.

I'm not sure if we're misprogramming the watermarks or something. I know
we're not checking the display core clock against the pixel rate
limitations, but I did a quick manual calculation and it gave me a
limit of ~152 MHz for 2x downscaled 32bpp sprite. The pixel clock of the
mode I'm using is 148.5 MHz, so in theory it should be safe.

At first I was only seeing pipe underruns, but now I'm also getting PCH
underruns. Not sure why the PCH underruns didn't get triggered
initially.

BTW I noticed that with your patches the ERR_INT triggers twice on underrun,
but the first time disables the underrun reporting so nothing gets printed
for the second occurance. I didn't read your patches with enough detail
yet to know if that's expected or not. I suppose one spurious triggering
of ERR_INT is not a big deal.

-- 
Ville Syrjälä
Intel OTC

      parent reply	other threads:[~2013-02-25 12:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-22 20:05 [PATCH 0/4] FIFO underrun reporting v2 Paulo Zanoni
2013-02-22 20:05 ` [PATCH 1/4] drm/i915: also disable south interrupts when handling them Paulo Zanoni
2013-03-05 19:08   ` Daniel Vetter
2014-05-23  8:13     ` Daniel Vetter
2014-05-23 11:25       ` Paulo Zanoni
2014-05-23 11:43         ` Daniel Vetter
2013-02-22 20:05 ` [PATCH 2/4] drm/i915: report Gen5+ CPU and PCH FIFO underruns Paulo Zanoni
2013-03-28 13:24   ` Daniel Vetter
2013-04-12 20:05     ` Paulo Zanoni
2013-03-28 13:26   ` Daniel Vetter
2013-02-22 20:05 ` [PATCH 3/4] drm/i915: print Gen5+ CPU/PCH poison interrupts Paulo Zanoni
2013-03-28 13:25   ` Daniel Vetter
2013-02-22 20:05 ` [PATCH 4/4] drm/i915: remove "inline" keyword from ironlake_disable_display_irq Paulo Zanoni
2013-03-28 12:55   ` Daniel Vetter
2013-02-25 12:14 ` Ville Syrjälä [this message]

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=20130225121456.GR4469@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=przanoni@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.