[Intel-gfx] [PATCH 0/4] FIFO underrun reporting v2

[Ville Syrjälä]

On Fri, Feb 22, 2013 at 05:05:27PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni at 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