From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932879AbbI3Moj (ORCPT <rfc822;w@1wt.eu>);
	Wed, 30 Sep 2015 08:44:39 -0400
Received: from 8bytes.org ([81.169.241.247]:39434 "EHLO theia.8bytes.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932553AbbI3Moe (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 30 Sep 2015 08:44:34 -0400
Date: Wed, 30 Sep 2015 14:44:32 +0200
From: Joerg Roedel <joro@8bytes.org>
To: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>, Daniel Vetter <daniel@ffwll.ch>,
        Thomas Gleixner <tglx@linutronix.de>,
        Bjorn Helgaas <bhelgaas@google.com>,
        Alex Deucher <alexdeucher@gmail.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        Christian =?iso-8859-1?Q?K=F6nig?= <christian.koenig@amd.com>,
        Maling list - DRI developers 
	<dri-devel@lists.freedesktop.org>,
        lkml <linux-kernel@vger.kernel.org>
Subject: Re: WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577
 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized
Message-ID: <20150930124432.GS3036@8bytes.org>
References: <CADnq5_NSM3r+=B5DEru_=o0pBTFPwysnXHGPUu=A_H5LQ+oogg@mail.gmail.com>
 <20150923072523.GB3383@phenom.ffwll.local>
 <20150923085950.GA3440@pd.tnic>
 <20150923144450.GD3383@phenom.ffwll.local>
 <20150923160621.GA3446@pd.tnic>
 <20150923161839.GB3446@pd.tnic>
 <20150926164651.GA3640@pd.tnic>
 <560A50DC.1040505@linux.intel.com>
 <20150929105138.GA12037@nazgul.tnic>
 <560B9323.6000309@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <560B9323.6000309@linux.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Sep 30, 2015 at 03:45:39PM +0800, Jiang Liu wrote:
> So we need to figure out why we got irq number 0 after enabling
> MSI for AMD IOMMU device. The only hint I got is that iommu driver just
> grabbing the PCI device without providing a PCI device driver for IOMMU
> PCI device, we have solved a similar case for eata driver. So could you
> please help to apply this debug patch to gather more info and send me
> /proc/interrupts?

I think I have an idea on how dev->irq got 0 after pci_enable_msi(). The
PCI probe code calls pcibios_alloc_irq() and after a failed probe it calls
pcibios_free_irq(), which sets dev->irq to 0.
The AMD IOMMU driver does not register a pci_driver for itself, it just
doesn't make sense for it. But the PCI device containing the IOMMU gets
probed later, which fails because there is no driver for it. So the
following call to pcibios_free_irq() clears dev->irq, so that it is 0 on
the next resume. Does that make sense?


	Joerg