On Sun, Jan 20, 2013 at 07:36:39PM -0800, Ben Widawsky wrote: > 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> Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
