From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] [RFC] drm/i915: Warning when reads or writes are dropped Date: Tue, 17 Jan 2012 11:26:01 +0000 Message-ID: References: <1320451434-16655-1-git-send-email-ben@bwidawsk.net> <20120117110857.GJ4093@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id CA3BC9E761 for ; Tue, 17 Jan 2012 03:26:11 -0800 (PST) In-Reply-To: <20120117110857.GJ4093@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 , Ben Widawsky Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, 17 Jan 2012 12:08:57 +0100, Daniel Vetter wrote: > On Fri, Nov 04, 2011 at 05:03:54PM -0700, Ben Widawsky wrote: > > The GTFIFODBG register gives us 3 error types when the fifo is accessed > > and full. Whenever we do a forcewake_put we can check this register to > > see if any of the CPU related errors occurred. > > > > Of more interest is perhaps the bit I am not checking which tells when > > some other part of the chip makes a request and the FIFO is full. I > > couldn't really decide on a good place to put that check. > > > > This patch seems to have value to me, but I'm not sure it's worth the > > cost of the extra MMIO read`. (I've yet to see this occur, but I haven't > > actually been running with it for very long). > > > > This looks like a nice little patch here. Care to update it for > spinlocked and multithreaded forcewake and maybe also check the other > errors? And also add it to the error_state output (just base it on top of > danvet/my-next to avoid conflicts with the oustanding error_state > cleanup). The advantage of placing the warning in _put is that we could identify the sequence of register writes that trigger the error, so a stack trace would be more useful i.e. a WARN instead. -Chris -- Chris Wilson, Intel Open Source Technology Centre