From patchwork Wed Mar 20 23:14:22 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiri Kosina X-Patchwork-Id: 2310451 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 308F5DF24C for ; Wed, 20 Mar 2013 23:14:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751891Ab3CTXOf (ORCPT ); Wed, 20 Mar 2013 19:14:35 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33809 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751696Ab3CTXOd (ORCPT ); Wed, 20 Mar 2013 19:14:33 -0400 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EBDD5A398E; Thu, 21 Mar 2013 00:14:28 +0100 (CET) Date: Thu, 21 Mar 2013 00:14:22 +0100 (CET) From: Jiri Kosina To: Yinghai Lu Cc: Daniel Vetter , Alan Stern , Chris Wilson , Greg KH , Harald Arnesen , Kernel development list , "Rafael J. Wysocki" , Peter Hurley , Thomas Meyer , Shawn Starr , USB list , linux-acpi@vger.kernel.org, Bjorn Helgaas , linux-pci@vger.kernel.org, Imre Deak , Daniel Kurtz , dri-devel@lists.freedesktop.org, Thomas Gleixner , "H. Peter Anvin" , x86@kernel.org, Arkadiusz Miskiewicz Subject: Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Tue, 19 Mar 2013, Yinghai Lu wrote: > > I guess I should have phrased it more precisely, but that's exactly > > what I expect is happening on my machine: I don't have anything on > > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence > > the irq is completely disabled. Which obviously makes it impossible > > for me to reproduce the issue. To test that theory, is there a quick > > way to force-enable a given interrupt, short of just hacking up a 2nd > > dummy irq handler in my driver? > > You may try to add another request_irq() > after i915_load_modeset_init==>drm_irq_install. > That could install one dummy action for ioapic irq for i915. > > Also you may need to add one quirk that does not disable intx during > msi enabling like: > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, > 0x2e22, > quirk_msi_intx_disable_bug); > This seemed to be really promising idea to me, as the DisINTx+ vs INTx+ discrepancy is very good hint, but unfortunately, after applying this: --- drivers/pci/quirks.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) The problem is still there ... so the inconsistency between DisINTx+ and INTx+ is unfortunately not the whole story. diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 0369fb6..8508e24 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2643,6 +2643,9 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1073, quirk_msi_intx_disable_bug); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1083, quirk_msi_intx_disable_bug); + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2a42, + quirk_msi_intx_disable_bug); #endif /* CONFIG_PCI_MSI */ /* Allow manual resource allocation for PCI hotplug bridges