On Fri, May 23, 2014 at 10:11 AM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: >> For enabled->enabled I think that can happen in crtc_enable - we >> unconditionally enable underrun reporting againg to clear out old fail (or >> firmware setups). But we don't always disable it when disabling the crtc >> since some platforms/ports don't underrun when disabled. > > Hmm. Actually since we don't necessarily notice the underruns with the > shared error interrupt, maybe we need to also throw an explicit underrun > check at the end of crtc_disable. That would mean we'd catch the underrun > at the very latest there, and crtc_enable can then clear the bit without > worrying about losing valid underrun reports. > > So, I think this patch looks OK. But we will need to keep this issue in > mind if we add the underrun report re-enable timer, or something like it. > Since my quick hack for that just blindly walks the crtcs and > (re)enables the underrun reporting for everything. Hm yeah, we might want a fifo underrun check like on gmch platforms. Otoh if we disable the shared error interrupt things are already rather bad, and the problem on the first pipe should have accurate irq-based reporting. The 2nd pipe is hidden, but should show up as soon as the first issue is addressed. So I don't think we really should worry about this. Maybe more intersting would be to check the _other_ pipes when we re-enable fifo underruns. At least some of the reports we've seen suggest that modesets on the pch influence each another ... -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
