On Mon, Nov 23, 2015 at 04:55:17PM +0200, Ville Syrjälä wrote: > On Mon, Nov 23, 2015 at 02:28:29PM +0000, Chris Wilson wrote: > > On Mon, Nov 23, 2015 at 04:22:08PM +0200, Ville Syrjälä wrote: > > > On Sat, Nov 21, 2015 at 10:51:50AM +0000, Chris Wilson wrote: > > > > On Fri, Nov 20, 2015 at 10:09:18PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > We still get spurious pipe underruns on ILK/SNB/IVB under two > > > > > circumstances when dealing with PCH ports: > > > > > * When the pipe has been disabled, but FDI RX/TX is still enabled > > > > > * During FDI link training > > > > > > > > > > Both cases seem to happen at least when we do VGA+HDMI cloning > > > > > from the same pipe. I don't think I've seen them when not cloning, > > > > > but can't be 100% sure. > > > > > > > > > > Disable underrun reporting around those places to eliminate the > > > > > dmesg errors. > > > > > > > > > > Testcase: igt/kms_setmode/basic-clone-single-crtc > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > Acked-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > > > > > I wondered if logging the suppressed errors would be of any use? > > > > > > Hmm. Maybe just to confirm that they still happen, and thus suppressing > > > is still neded. > > > > > > > Does > > > > the check_cpu_fifo work if the reporting is disabled? Could we do a > > > > manual check and DRM_DEBUG_KMS() if the enable did generate a failure. > > > > If the check_cpu_fifo does work, won't we still get the error from the > > > > added check in atomic_commit()? > > > > > > The check only looks at pipes that have underrun reporting enabled. I > > > suppose it might be possible to have it check all the pipes. At the > > > point where we call it no explicit suppression should be happening, so > > > the only reason why underrun reporting would be disabled on any pipe is > > > due to detecting a previous underrun via the interrupt. > > > > Does the hw flag the underrun even if the interrupt is disabled? > > (Playing games with PIPESTAT_IER?) Could we then report (debug) that an > > underrun happened before we re-enable reporting? > > Hmm. We use the IMR to disable this stuff on many platforms, so we > do lose the IIR. So we'd need to frob IER instead to make this work > universally. Currently it would only work for GMCH, IVB/HSW, > CPT/PPT/LPT/WPT since PIPESTAT/ERR_INT/SERR_INT don't have IMR. Feels a bit too risky imo, changing all that code. Also, even in tests where underruns reproduce readily it's not 100%, so the occasional debug message won't be solid enough evidence. For me I think as long as we hide underruns only while doing modesets (where there's some expectation of them happening) we should be perfectly fine wrt test coverage. The real benefit is when enabling/disabling planes, fbc and all that stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
