On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote:
> > Older specs claimed this was bit 11, but newer specs and the actual
> > simulator code say it was bit 12.  Regardless, we don't use MI_FLUSH,
> > or try to enable it any more.
> > 
> > Signed-off-by: Eric Anholt <e...@anholt.net>
> 
> I'd like to amend this with the following (on this patch instead of the
> other, so that ppl actually can find it with git blame):
> 
> "Furthermore actually setting bit12 results in gpu hangs both on snb and
> ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11
> must be set, but that doesn't help either. And last but not least,
> MI_FLUSH seems to work regardless of the setting of these bits."

I haven't seen bit12 hanging snb/ivb -- I only knew of it hanging ilk
(since it doesn't exist there).  On my snb, running xvideo so that
MI_FLUSHes are generated by the userland (I think -- I haven't caught
them in cat i915_batchbuffers | intel_dump_decode -), with
intel_reg_read 0x209c saying 0x1240, things are going fine.  Also with
0x209c saying 0x240 (the result of this patch).

That 2008 PPT mentioned also said "the bit" and "bit 12", and only in
one cut-and-paste of a command line did I see it say two bits should be
set.  I would trust the actual code more than a ppt.

But basically, whatever we do to make this broken code go away, I'm fine
with.

Attachment: pgpRDclBJAiUF.pgp
Description: PGP signature

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to