On Thu, Jan 16, 2014 at 3:11 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Thu, Jan 16, 2014 at 03:00:26PM +0100, Daniel Vetter wrote: >> On Thu, Jan 16, 2014 at 2:28 PM, Ville Syrjälä >> <ville.syrjala@xxxxxxxxxxxxxxx> wrote: >> > On Thu, Jan 16, 2014 at 01:41:32PM +0100, Dragos Carp wrote: >> >> Hi Jani, >> >> >> >> thank you for your response. >> >> Attached is the dmesg output trimmed of more thousand lines like: >> >> [drm:i915_irq_handler], pipe B underrun >> > >> > That's a bit weird. We're supposed to disable the underrun reporting >> > after the first error. I guess the pipe state gets stuck somehow and >> > it just keeps reporting the same error all the time... >> >> Only on pch platforms, but not on gmch stuff. Those still lack a bit >> of work to make them fit into the underrun reporting framework. And we >> need to enable those underruns to be much louder ... > > Oh right. Somehow I remembered that it was universal. But now that > re-think things PIPESTAT doesn't even have an enable bit for underruns. > So I guess an underrun won't itself generate an interrupt on gmch > platforms, but instead you need some other interrupt to fire to detect > it. That means we should just have some flag/bool to shut up the debug > message and the rest of the code is fine as is. We also need to make sure we clear the PIPESTAT bit when disabling the reporting. Otherwise we might leak it. But yeah, a simple flag should be good enough for gmch underrun reporting. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
