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
