On Sun, Jan 20, 2013 at 04:33:32PM +0000, Chris Wilson wrote: > On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1, > the hardware can not program the scanline values. Those scanline values > then control when the signal is sent from the display engine to the render > ring for MI_WAIT_FOR_EVENTs. Note setting this bit means that TLB > invalidations must be performed explicitly through the appropriate bits > being set in PIPE_CONTROL. > > References: https://bugzilla.kernel.org/show_bug.cgi?id=52311 > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> > Cc: stable at vger.kernel.org This all sounds a bit hand-wavy to me. First, it's not clear from the commit message if this actually fixes anything. Is that connection between bit 13 of GFX_MODE and the scanline updates documented, or was it just "found." If it was found we should get a doc update, or clarification, because I can't find that in the docs, and perhaps more importantly, I can't even come up with a theory why the TLB would have any effect on the problem. OTOH, I've always disliked that this bit wasn't explicitly set. As a note there, we have a context workaround you could update as a result of this patch. My only real concern is over old userspace with this patch. Were there any released ddx, or mesa which didn't set the bit on the PIPE_CONTROL? Does anyone care? It'd be nice if we had some way to observe the TLBs weren't being invalidated as needed. If you can address my concerns over breaking old userspace, and don't feel like addressing my other comments, it is (and the next patch): Reviewed-by: Ben Widawsky <ben at bwidawsk.net> -- Ben Widawsky, Intel Open Source Technology Center
