From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paulo Zanoni Subject: [PATCH 2/4] drm/i915: don't disable ERR_INT on the IRQ handler Date: Thu, 19 Sep 2013 17:00:36 -0300 Message-ID: <1379620838-1491-3-git-send-email-przanoni@gmail.com> References: <1379620838-1491-1-git-send-email-przanoni@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by gabe.freedesktop.org (Postfix) with ESMTP id F0401E6C66 for ; Thu, 19 Sep 2013 13:00:59 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id ld13so4698477vcb.11 for ; Thu, 19 Sep 2013 13:00:59 -0700 (PDT) In-Reply-To: <1379620838-1491-1-git-send-email-przanoni@gmail.com> 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: intel-gfx@lists.freedesktop.org Cc: Paulo Zanoni List-Id: intel-gfx@lists.freedesktop.org From: Paulo Zanoni We currently disable the ERR_INT interrupts while running the IRQ handler because we fear that if we do an unclaimed register access from inside the IRQ handler we'll keep triggering the IRQ handler forever. The problem is that since we always disable the ERR_INT interrupts at the IRQ handler, when we get a FIFO underrun we'll always print both messages: - "uncleared fifo underrun on pipe A" - "Pipe A FIFO underrun" Because the "was_enabled" variable from ivybridge_set_fifo_underrun_reporting will always be false (since we disable ERR int at the IRQ handler!). Instead of actually fixing ivybridge_set_fifo_underrun_reporting, let's just remove the "disable ERR_INT during the IRQ handler" code. As far as we know we shouldn't really be triggering ERR_INT interrupts from the IRQ handler, so if we ever get stuck in the endless loop of interrupts we can git-bisect and revert (and we can even bisect and revert this patch in case I'm just wrong). As a bonus, our IRQ handler is now simpler and a few nanoseconds faster. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_irq.c | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 9ecc9d9..e9f6bc3 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1394,7 +1394,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void *arg) drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private; u32 de_iir, gt_iir, de_ier, sde_ier = 0; irqreturn_t ret = IRQ_NONE; - bool err_int_reenable = false; atomic_inc(&dev_priv->irq_received); @@ -1418,17 +1417,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void *arg) POSTING_READ(SDEIER); } - /* On Haswell, also mask ERR_INT because we don't want to risk - * generating "unclaimed register" interrupts from inside the interrupt - * handler. */ - if (IS_HASWELL(dev)) { - spin_lock(&dev_priv->irq_lock); - err_int_reenable = ~dev_priv->irq_mask & DE_ERR_INT_IVB; - if (err_int_reenable) - ironlake_disable_display_irq(dev_priv, DE_ERR_INT_IVB); - spin_unlock(&dev_priv->irq_lock); - } - gt_iir = I915_READ(GTIIR); if (gt_iir) { if (INTEL_INFO(dev)->gen >= 6) @@ -1458,13 +1446,6 @@ static irqreturn_t ironlake_irq_handler(int irq, void *arg) } } - if (err_int_reenable) { - spin_lock(&dev_priv->irq_lock); - if (ivb_can_enable_err_int(dev)) - ironlake_enable_display_irq(dev_priv, DE_ERR_INT_IVB); - spin_unlock(&dev_priv->irq_lock); - } - I915_WRITE(DEIER, de_ier); POSTING_READ(DEIER); if (!HAS_PCH_NOP(dev)) { -- 1.8.3.1