From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH 19/24] drm/i915: don't enable PM_VEBOX_CS_ERROR_INTERRUPT Date: Fri, 28 Jun 2013 10:25:57 -0700 Message-ID: <20130628172556.GC20241@bwidawsk.net> References: <1371037046-3732-1-git-send-email-daniel.vetter@ffwll.ch> <1371037046-3732-20-git-send-email-daniel.vetter@ffwll.ch> <20130612171340.GA15749@bwidawsk.net> <20130612171838.GF22870@phenom.ffwll.local> <20130612181940.GA16571@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from shiva.localdomain (unknown [209.20.75.48]) by gabe.freedesktop.org (Postfix) with ESMTP id 85877E670F for ; Fri, 28 Jun 2013 10:22:46 -0700 (PDT) Content-Disposition: inline In-Reply-To: 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: Intel Graphics Development List-Id: intel-gfx@lists.freedesktop.org On Wed, Jun 12, 2013 at 08:32:44PM +0200, Daniel Vetter wrote: > On Wed, Jun 12, 2013 at 8:19 PM, Ben Widawsky wrote: > > On Wed, Jun 12, 2013 at 07:18:38PM +0200, Daniel Vetter wrote: > >> On Wed, Jun 12, 2013 at 10:13:41AM -0700, Ben Widawsky wrote: > >> > On Wed, Jun 12, 2013 at 01:37:21PM +0200, Daniel Vetter wrote: > >> > > The code to handle it is broken - there's simply no code to clear CS > >> > > parser errors on gen5+. And behold, for all the other rings we also > >> > > don't enable it! > >> > > > >> > > Leave the handling code itself in place just to be consistent with the > >> > > existing mess though. And in case someone feels like fixing it all up. > >> > > > >> > > This has been errornously enabled in > >> > > > >> > > commit 12638c57f31952127c734c26315e1348fa1334c2 > >> > > Author: Ben Widawsky > >> > > Date: Tue May 28 19:22:31 2013 -0700 > >> > > > >> > > drm/i915: Enable vebox interrupts > >> > > > >> > > Cc: Damien Lespiau > >> > > Cc: Ben Widawsky > >> > > Signed-off-by: Daniel Vetter > >> > > > >> > Why not fix the problem instead of just disabling the interrupt? Then > >> > the "existing mess" is justified. It really shouldn't be terribly > >> > difficult to fix it. > >> > >> Haven't seen it proven useful, and I don't want to blow through time just > >> for fun on it. Hangcheck seems to be able to deal with it just fine. > >> -Daniel > > I don't get it. Isn't it just clearing a bit in the handler, vs. > > clearing the flag here? > > On a quick Bspec read we'd need to set up per-ring error interrupt > registers, put them to sensible value in them, wire up the interrupt > handling for each ring since ilk+ and then also test it. I really > don't see the point in doing that. The only upshot of all that work is > that if there's an instruction error we'd get an interrupt instead of > waiting for the hangcheck to kick in. Hmm. I still think you're overthinking this. I don't think it requires so much work to get the parser interrupts, but I don't insist. Reviewed-by: Ben Widawsky > > If you insist I can follow-up with a patch to just rip out the > bare-bones handler we have now. Everything else really feels like > wasted effort to me. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center