From patchwork Tue Apr 5 22:00:46 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Wilson X-Patchwork-Id: 688931 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p35M2iKE020617 for ; Tue, 5 Apr 2011 22:03:05 GMT Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E7ACE9E8AB for ; Tue, 5 Apr 2011 15:02:44 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from fireflyinternet.com (server109-228-6-236.live-servers.net [109.228.6.236]) by gabe.freedesktop.org (Postfix) with ESMTP id 05CA89E81A for ; Tue, 5 Apr 2011 15:00:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.66.37; Received: from arrandale.alporthouse.com (unverified [78.156.66.37]) by fireflyinternet.com (Firefly Internet SMTP) with ESMTP id 31217091-1500050 for multiple; Tue, 05 Apr 2011 23:00:47 +0100 From: Chris Wilson To: intel-gfx@lists.freedesktop.org Date: Tue, 5 Apr 2011 23:00:46 +0100 Message-Id: <1302040846-18447-1-git-send-email-chris@chris-wilson.co.uk> X-Mailer: git-send-email 1.7.4.1 X-Originating-IP: 78.156.66.37 Subject: [Intel-gfx] [PATCH] drm/i915: Clear any errors recorded before i915.ko is loaded X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Tue, 05 Apr 2011 22:03:05 +0000 (UTC) This looks like it fixes two bugs: 1) What if there is an error recorded before we start and so we immediately service an IIR/EIR upon intalling the IRQ. Did we generate that error during initialisation or was that SEP? Now we do stuff before we even install the IRQ so there is a possibility that we zap one of our own. 2) When re-enabling the interrupt (gpu reset) we need to preserve any masking of stuck EIR. I guess this is easiest to test by generating an EIR, then reloading the module? Does EIR even persist between phases to cause these issues in the first place? Something to think about... --- drivers/gpu/drm/i915/i915_irq.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 46ccfc8..bb1a624 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1650,11 +1650,24 @@ static int ironlake_irq_postinstall(struct drm_device *dev) return 0; } +static void i915_irq_clear_errors(struct drm_device *dev) +{ + struct drm_i915_private *dev_priv = dev->dev_private; + u32 eir = I915_READ(EIR); + if (eir) { + I915_WRITE(EIR, eir); + POSTING_READ(EIR); + } +} + void i915_driver_irq_preinstall(struct drm_device * dev) { drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private; int pipe; + /* Clear any errors recorded before we begin. */ + i915_irq_clear_errors(dev); + atomic_set(&dev_priv->irq_received, 0); INIT_WORK(&dev_priv->hotplug_work, i915_hotplug_work_func); @@ -1719,7 +1732,8 @@ int i915_driver_irq_postinstall(struct drm_device *dev) error_mask = ~(I915_ERROR_PAGE_TABLE | I915_ERROR_MEMORY_REFRESH); } - I915_WRITE(EMR, error_mask); + /* Some pre-existing errors might have become stuck, mask them. */ + I915_WRITE(EMR, error_mask | I915_READ(EIR)); I915_WRITE(IMR, dev_priv->irq_mask); I915_WRITE(IER, enable_mask);