[Intel-gfx] [PATCH 2/2] drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.

[Daniel Vetter]

On Tue, Jan 24, 2012 at 08:22:57PM -0800, Ben Widawsky wrote:
> On 01/24/12 18:55, Eric Anholt wrote:
> >On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetter<daniel at 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<eric at 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).
> 
> Daniel has a failing test on IVB. I haven't tried hard enough to
> make it fail on SNB, so I cannot speak to that.

Could be some other crash and I've just had an unlucky day and it died
much earlier than usual. Anyway, with things tested I'm happy with these 2
patches and queued them for -next.

> >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.
> 
> I'm in the same boat. I think trying to figure out which source to
> trust is a losing game for all, and our best bet is to find out what
> the Windows driver does, and presumably that cut-and-paste is not
> from the Windows driver.

I've added a small comment to patch 2 to urge people to get a clue before
trying to use this bit ;-)

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48