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