From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 10/12] drm/i915: TLB invalidation with MI_FLUSH_SW requires a post-sync op Date: Thu, 4 Oct 2012 09:39:31 -0500 Message-ID: <20121004093931.73bdac1a@jbarnes-t420> References: <1349217826-2538-1-git-send-email-jbarnes@virtuousgeek.org> <1349217826-2538-11-git-send-email-jbarnes@virtuousgeek.org> <20121002171453.3a201ac1@bwidawsk.net> <20121003072020.GB5329@phenom.ffwll.local> <20121004083213.GB5661@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by gabe.freedesktop.org (Postfix) with SMTP id 17F7CA0F9F for ; Thu, 4 Oct 2012 07:39:42 -0700 (PDT) In-Reply-To: <20121004083213.GB5661@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: Ben Widawsky , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Thu, 4 Oct 2012 10:32:13 +0200 Daniel Vetter 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