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
