[Intel-gfx] [PATCH 10/12] drm/i915: TLB invalidation with MI_FLUSH_SW requires a post-sync op

Jesse Barnes jbarnes at virtuousgeek.org
Thu Oct 4 16:39:31 CEST 2012


On Thu, 4 Oct 2012 10:32:13 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Wed, Oct 03, 2012 at 09:20:20AM +0200, Daniel Vetter wrote:
> > On Tue, Oct 02, 2012 at 05:14:53PM -0700, Ben Widawsky wrote:
> > > s/MI_FLUSH_SW/MI_FLUSH_DW/
> > 
> > Applied, with spelling fixed. Thanks for patch&review.
> 
> This hard-hangs my snb here when X starts (so probably on the very first
> batch). Impressive!
> 
> I've dropped this one from -fixes. And since no one piped up that the
> other w/a patches fix anything, I've moved those two I've merged already
> to dinq.

Yeah not -fixes material.  But it fixes i-g-t on VLV and *should* fix
issues we may not have seen yet on IVB, so we need to figure this one
out.

> Totally unrelated, I think I'll instate harsher rules for w/a patches:
> 1. w/a patches only go in through -fixes if they indeed fix an issue we
> (or a bug reporter) can reproduce.

Yeah, that's fine.

> 2. w/a patches need testcases, too. Either a register check added to i-g-t
> or if it's a runtime thing, a runtime assert at a nice place (where
> feasible, ofc).

A register check isn't that useful imo.  A real test case would be
ideal, but given how hard some of these issues are to hit, it's
unrealistic to spend weeks writing a test case for a workaround that's
already been documented to fix a specific issue.

> 3. I'll randomly stall patches to bring 2. up to par for existing
> workarounds.

Btw if you want to take this to its logical conclusion, we also
shouldn't be "fixing" issues that are obvious from code review but
people haven't hit in practice (this goes for a good chunk of the code
churn in our driver involving cleanups and fixes for potential
non-issues).  And that's not even including test case development for
any patch claiming it fixes anything.

That said, I definitely agree we want to add more test cases.  Just
don't block applying known workaround fixes or other stuff on those
test cases.

Jesse



More information about the Intel-gfx mailing list