From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161407AbcFHFL0 (ORCPT ); Wed, 8 Jun 2016 01:11:26 -0400 Received: from mail-db5eur01on0061.outbound.protection.outlook.com ([104.47.2.61]:22791 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1161354AbcFHFLY (ORCPT ); Wed, 8 Jun 2016 01:11:24 -0400 From: Po Liu To: Bjorn Helgaas CC: Murali Karicheri , Roy Zang , "Arnd Bergmann" , "devicetree@vger.kernel.org" , Marc Zyngier , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Stuart Yoder , Minghuan Lian , Mingkai Hu , Bjorn Helgaas , Yang-Leo Li , Shawn Guo , "linux-arm-kernel@lists.infradead.org" Subject: RE: [PATCH 2/2] aer: add support aer interrupt with none MSI/MSI-X/INTx mode Thread-Topic: [PATCH 2/2] aer: add support aer interrupt with none MSI/MSI-X/INTx mode Thread-Index: AQHRtxVFPugJa9Xwc0eoyVzTYuxTY5/VlRQAgAAOGZCAAJuUAIAAHGoAgADSOACAAN/jgIAArJQAgANT63CAAHv6AIAARZiAgADswYCAAPKfAIAAZPpQ Date: Wed, 8 Jun 2016 04:56:13 +0000 Message-ID: References: <20160602135546.GA8262@localhost> <575052B8.3090203@ti.com> <20160603040952.GA17904@localhost> <5751BEDF.3040300@ti.com> <20160604034852.GA15143@localhost> <57558248.4010502@ti.com> <20160606181049.GA15171@localhost> <20160607224634.GB2543@localhost> In-Reply-To: <20160607224634.GB2543@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=po.liu@nxp.com; x-originating-ip: [199.59.231.64] x-ms-office365-filtering-correlation-id: 0367dc7a-4a40-447c-e10e-08d38f5937ac x-microsoft-exchange-diagnostics: 1;VI1PR0401MB1712;5:54QmcbLuJJlMy6iDn18vIHlvTCdp1vgD+vOzbRGYAcPhzf6G0HLZp716lSRLHm/PETxF7bEi1xJqk9NXFjsnxrrnvB6ZF33I9qblX/v5Ie8K9qDtz/jaHUohMSteL9ptleCHqmhWiKsY6Xdu69JsAg==;24:S24b2ev53GIMaGAgn/ckcj0RJ+1wR6pwpBfN0EuwZfDLzSCpp4ti/GmPnBkBnEScfFPyM1ltQY70qZrY/LuGAIf8l52aFwGaBVREhE000U8=;7:sKYMngHjg+e1pgUHJkixvRjrEt5KWeXjmgrWv0+hJ0COzBX00Jw8U88s+WbQ6BkwkzWUrNi0FoL6ptSMmFDFA5i6TohUORtGrBbqvQg7U0d4M6BUOAcCVWcBUypDW3BeRS/laEADH/dNHLaH3cSHKxmCz/H0YD4wUvjqadXnDY+44VkMZnO6QmnRNrHjQpQmTyKmMUN7RwUTate5Ygr69E64yw128n0e+c0W/W0Ns3o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB1712; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(258649278758335)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:VI1PR0401MB1712;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB1712; x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(377454003)(13464003)(24454002)(51914003)(199003)(189002)(74316001)(4326007)(8936002)(106116001)(106356001)(105586002)(122556002)(10400500002)(5008740100001)(54356999)(76176999)(9686002)(50986999)(102836003)(6116002)(3846002)(66066001)(33656002)(101416001)(87936001)(92566002)(19580395003)(19580405001)(3280700002)(586003)(5002640100001)(97736004)(2950100001)(68736007)(3660700001)(2900100001)(5003600100002)(110136002)(77096005)(81156014)(8676002)(2906002)(81166006)(5004730100002)(86362001)(76576001)(189998001)(93886004);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0401MB1712;H:VI1PR0401MB1709.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2016 04:56:13.5653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB1712 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u585BWHm004289 Hi Bjorn, Thanks for the kindly reply. All these are helpful. > From: Bjorn Helgaas [mailto:helgaas@kernel.org] > On Wed, June 08, 2016 6:47 AM > > On Tue, Jun 07, 2016 at 10:07:40AM +0000, Po Liu wrote: > > Hi Bjorn, > > > > > -----Original Message----- > > > > > > On Mon, Jun 06, 2016 at 10:01:44AM -0400, Murali Karicheri wrote: > > > > On 06/06/2016 03:32 AM, Po Liu wrote: > > > > > Hi Bjorn, > > > > > I confirm we met same problem with KeyStone base on DesignWare > > > design. > > > > > > > > > > > > > > > Best regards, > > > > > Liu Po > > > > > > > > > >> -----Original Message----- > > > > >> From: Bjorn Helgaas [mailto:helgaas@kernel.org] > >> Sent: > > > Saturday, June 04, 2016 11:49 AM > >> To: Murali Karicheri > >> > > > Cc: Po Liu; linux-pci@vger.kernel.org; linux-arm- > >> > > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > >> > > > devicetree@vger.kernel.org; Arnd Bergmann; Roy Zang; Marc Zyngier; > > > > >> Stuart Yoder; Yang-Leo Li; Minghuan Lian; Bjorn Helgaas; Shawn > > > Guo; > >> Mingkai Hu; Rob Herring > >> Subject: Re: [PATCH 2/2] > > > aer: add support aer interrupt with none > >> MSI/MSI-X/INTx mode > > > > >> > >> On Fri, Jun 03, 2016 at 01:31:11PM -0400, Murali > > > Karicheri wrote: > > > > >> > Po, > > > > >> > > > > > >> > Sorry to hijack your discussion, but the problem seems to > > > be > >> same for > Keystone PCI controller which is also > > > designware (old > > > version) based. > > > > >> > > > > > >> > On 06/03/2016 12:09 AM, Bjorn Helgaas wrote: > > > > >> > > On Thu, Jun 02, 2016 at 11:37:28AM -0400, Murali > > > Karicheri > > > wrote: > > > > >> > >> On 06/02/2016 09:55 AM, Bjorn Helgaas wrote: > > > > >> > >>> On Thu, Jun 02, 2016 at 05:01:19AM +0000, Po Liu wrote: > > > > >> > >>>>> -----Original Message----- > >>>>> From: Bjorn > > > Helgaas > >> [mailto:helgaas@kernel.org] > >>>>> Sent: Thursday, > > > June 02, 2016 > >> 11:48 AM > >>>>> To: Po Liu > >>>>> Cc: > > > > >> linux-pci@vger.kernel.org; > >>>>> > >> > > > linux-arm-kernel@lists.infradead.org; > > > > >> > >>>>> linux-kernel@vger.kernel.org; > > > devicetree@vger.kernel.org; > >> Arnd > >>>>> Bergmann; Roy Zang; > > > Marc Zyngier; Stuart Yoder; > >> Yang-Leo Li; > >>>>> Minghuan > > > Lian; Bjorn Helgaas; Shawn Guo; > >> Mingkai Hu; Rob > >>>>> > > > Herring > >>>>> Subject: Re: [PATCH 2/2] > >> aer: add support > > > aer interrupt with > >>>>> none MSI/MSI-X/INTx > >> mode > >>>>> > > > > >>>>> [+cc Rob] > >>>>> > >>>>> Hi Po, > > >> >>>>> > >>>>> > > > On Thu, May 26, 2016 at 02:00:06PM +0800, Po Liu > >> wrote: > > > > >> > >>>>> > On some platforms, root port doesn't support > >> > > > MSI/MSI-X/INTx in RC mode. > > > > >> > >>>>> > When chip support the aer interrupt with none > > > > >> MSI/MSI-X/INTx > >>>>> mode, > maybe there is interrupt line > > > for > >> aer pme etc. Search > >>>>> the interrupt > number in > > > the fdt file. > > > > >> > >>>>> > > > > >> > >>>>> My understanding is that AER interrupt signaling can > > > be > >> done > >>>>> via INTx, MSI, or MSI-X (PCIe spec r3.0, sec > > > 6.2.4.1.2). > > > > >> > >>>>> Apparently your device doesn't support MSI or MSI-X. > > > Are > >> you > >>>>> saying it doesn't support INTx either? How > > > is the > >> interrupt you're requesting here different from INTx? > > > > >> > >>>> > > > > >> > >>>> Layerscape use none of MSI or MSI-X or INTx to > > > indicate the > >> > >>>> devices or root error in RC mode. But use > > > an independent SPI > >> > >>>> interrupt(arm interrupt controller) > line. > > > > >> > >>> > > > > >> > >>> The Root Port is a PCI device and should follow the > > > normal > >> PCI > >>> rules for interrupts. As far as I > > > understand, that > >> means it > >>> should use MSI, MSI-X, or > > > INTx. If your Root Port > >> doesn't use MSI > >>> or MSI-X, it > > > should use INTx, the > >> PCI_INTERRUPT_PIN register > >>> should > > > tell us which (INTA/ > >> INTB/etc.), and PCI_COMMAND_INTX_DISABLE > should work to disable it. > > > > >> > >>> That's all from the PCI point of view, of course. > > > > >> > >> > > > > >> > >> I am faced with the same issue on Keystone PCI hardware > > > and > >> it has > >> been on my TODO list for quite some time. > > > Keystone > >> PCI hardware > >> also doesn't use MSI or MSI-X or > > > INTx for > >> reporting errors received > >> at the root port, but > > > use a > >> platform interrupt instead (not > >> complaint to PCI > > > standard as > >> per PCI base spec). So I would need > >> similar > > > change to have > >> the error interrupt passed to the aer > >> > > > driver. So there are > >> hardware out there like Keystone which > > > requires to support this through platform IRQ. > > > > >> > > > > > > >> > > This is not a new area of the spec, and it's hard for me > > > to > >> believe > > that these two new PCIe controllers are both > > > broken > >> the same way > > (although I guess both are > > > DesignWare-based, so > >> maybe this is the > > same underlying > > > problem in both cases?). I > >> think it's more likely > > that > > > we just haven't figured out the > >> right way to describe this in > the DT. > > > > >> > > > > > >> > Keystone is using an older version of the designware IP and > > > it > >> > implements all of the interrupts in the application > > > register > >> space > unlike other newer version of the hardware. > > > So I assume, > >> the version > used on Layerscape is also an > > > older version and the > >> both have same > issue in terms of non > > > standard platform interrupt > >> used for error reporting. > > > > >> > > > > > >> > > I assume you have a Root Port with an AER capability, no > > > MSI > >> > > capability, and no MSI-X capability, right? > > > > >> > > > > > >> > Has AER capability and both MSI and INTx (legacy) > > > capability > > >> > > What does its Interrupt > > Pin register > > > contain? If it's > >> zero, it doesn't use INTx either, so > > > > > according to the spec it > >> should generate no interrupts. > > > > >> > > > > > > >> > At address offset 0x3C by default has a value of 1, but it > > > is > >> writable > by software. So default is INTx A. > > > > >> > > > > >> 0x3c is the Interrupt *Line*, which is read/write. The > > > Interrupt > >> *Pin* is at 0x3d and should be read-only. > > > > >> > > > > > > > > You are right. But default is 1 at this address. > > > > > > > > >> Does your Keystone driver support MSI? If so, since your > > > Root > >> Port supports MSI, I would think we would use that by > > > default, and > >> the INTx stuff wouldn't even matter. > > > > > > > > > > Layerscape is also shows "Both message signaled interrupts > > > (MSI) and legacy INTx are supported." > > > > > But both of them not work for AER interrupt when devices or > > > root port report aer error. > > > > > But another GIC interrupt line do. > > > > > > > > Same with Keystone. Even though both MSI and INTx are supported > > > error > interrupt at root port is reported on a different interrupt > > > line than > MSI/INTx. So for Power Management event interrupt is > > > also different > line. > > > > > > I'm looking at the "Error Message Controls" diagram in the PCIe > > > spec r3.0, sec 6.2.6. Does this hardware fit into the > > > platform-specific "System Error" case there? Do the Root Control > > > enable bits (in the PCIe > > > Capability) control this interrupt? If so, maybe this makes more > > > sense than I thought. > > > > It supposedly not the "System Error" case. But "the Error Interrupt" > case. > > Which means " Root Error Command register " could control the > > interrupt line we have now. (refer PCIe spec r3.0, sec 6.2.6) > > Did you actually try this out and verify that the PCIe Root Control > enable bits have no effect and the AER Root Error Command bits do > control it? The names are very similar, so there's lots of room for > misunderstanding here :) Yes, all these result were tested before reply. > > If the AER Root Error Command does control this interrupt, I think the > PCI_COMMAND_INTX_DISABLE bit in the PCI Command register should also > control it (per sec 6.2.4.1.2). Yes, I am sure the PCI_COMMAND_INTX_DISABLE bit can also control this interrupt. > > > May this kind of hardware design route broken the spec? > > If the Reporting Enable bits in the Root Port's AER Root Error Command > register control the interrupt, but the interrupt is not delivered via > the Root Port's INTx or MSI/MSI-X, I think the design is not following > the spec. > > All the information needed by the AER driver should be communicated via > the config space mechanisms described in the spec (AER capability, > MSI/MSI-X capabilities, Interrupt Pin, etc.) That way the driver works > without change on future spec-compliant hardware. > > > PME also like the AER. Hotplug is not supported. Others not known. > > Po Liu > > Per sec 6.1.6, I think PME *should* be signaled by the Root Port's INTx > or MSI/MSI-X. > > In particular, it says "Note that all other interrupt sources within the > same Function will assert the same virtual INTx wire when requesting > service." To me, that means that if we're using INTx, it will be the > same INTx for AER, PME, hotplug, etc., and it should be the one > indicated by the Interrupt Pin register. > > But I think on your Root Port: > > - There is an MSI capability, but MSI doesn't actually work at all > - Interrupt Pin contains 1, indicating INTA, which is routed to IRQ X > - AER interrupts are routed to some different IRQ Y > - PME interrupts are routed to a third IRQ Z > The descriptions are all right. > So how should we work around this? I think you should be able to get > partway there with a quirk that sets: > > dev->no_msi = 1; > dev->irq = Y; > > for this device. That should make AER work, but of course PME would not > work. > > Is there a way to set up your interrupt controller so these three > interrupts (X, Y, Z above) all map to the same Linux IRQ? If you can do > that, you could set up INTA, the AER interrupt, and the PME interrupt to > all be on the same IRQ and everything should work. > > Bjorn We'll think about all the ways. It is really helpful, thanks! From mboxrd@z Thu Jan 1 00:00:00 1970 From: Po Liu Subject: RE: [PATCH 2/2] aer: add support aer interrupt with none MSI/MSI-X/INTx mode Date: Wed, 8 Jun 2016 04:56:13 +0000 Message-ID: References: <20160602135546.GA8262@localhost> <575052B8.3090203@ti.com> <20160603040952.GA17904@localhost> <5751BEDF.3040300@ti.com> <20160604034852.GA15143@localhost> <57558248.4010502@ti.com> <20160606181049.GA15171@localhost> <20160607224634.GB2543@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160607224634.GB2543@localhost> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Bjorn Helgaas Cc: Roy Zang , Arnd Bergmann , "devicetree@vger.kernel.org" , Marc Zyngier , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Stuart Yoder , Minghuan Lian , Murali Karicheri , "linux-arm-kernel@lists.infradead.org" , Bjorn Helgaas , Yang-Leo Li , Shawn Guo , Mingkai Hu List-Id: devicetree@vger.kernel.org Hi Bjorn, Thanks for the kindly reply. All these are helpful. > From: Bjorn Helgaas [mailto:helgaas@kernel.org] > On Wed, June 08, 2016 6:47 AM > > On Tue, Jun 07, 2016 at 10:07:40AM +0000, Po Liu wrote: > > Hi Bjorn, > > > > > -----Original Message----- > > > > > > On Mon, Jun 06, 2016 at 10:01:44AM -0400, Murali Karicheri wrote: > > > > On 06/06/2016 03:32 AM, Po Liu wrote: > > > > > Hi Bjorn, > > > > > I confirm we met same problem with KeyStone base on DesignWare > > > design. > > > > > > > > > > > > > > > Best regards, > > > > > Liu Po > > > > > > > > > >> -----Original Message----- > > > > >> From: Bjorn Helgaas [mailto:helgaas@kernel.org] > >> Sent: > > > Saturday, June 04, 2016 11:49 AM > >> To: Murali Karicheri > >> > > > Cc: Po Liu; linux-pci@vger.kernel.org; linux-arm- > >> > > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > >> > > > devicetree@vger.kernel.org; Arnd Bergmann; Roy Zang; Marc Zyngier; > > > > >> Stuart Yoder; Yang-Leo Li; Minghuan Lian; Bjorn Helgaas; Shawn > > > Guo; > >> Mingkai Hu; Rob Herring > >> Subject: Re: [PATCH 2/2] > > > aer: add support aer interrupt with none > >> MSI/MSI-X/INTx mode > > > > >> > >> On Fri, Jun 03, 2016 at 01:31:11PM -0400, Murali > > > Karicheri wrote: > > > > >> > Po, > > > > >> > > > > > >> > Sorry to hijack your discussion, but the problem seems to > > > be > >> same for > Keystone PCI controller which is also > > > designware (old > > > version) based. > > > > >> > > > > > >> > On 06/03/2016 12:09 AM, Bjorn Helgaas wrote: > > > > >> > > On Thu, Jun 02, 2016 at 11:37:28AM -0400, Murali > > > Karicheri > > > wrote: > > > > >> > >> On 06/02/2016 09:55 AM, Bjorn Helgaas wrote: > > > > >> > >>> On Thu, Jun 02, 2016 at 05:01:19AM +0000, Po Liu wrote: > > > > >> > >>>>> -----Original Message----- > >>>>> From: Bjorn > > > Helgaas > >> [mailto:helgaas@kernel.org] > >>>>> Sent: Thursday, > > > June 02, 2016 > >> 11:48 AM > >>>>> To: Po Liu > >>>>> Cc: > > > > >> linux-pci@vger.kernel.org; > >>>>> > >> > > > linux-arm-kernel@lists.infradead.org; > > > > >> > >>>>> linux-kernel@vger.kernel.org; > > > devicetree@vger.kernel.org; > >> Arnd > >>>>> Bergmann; Roy Zang; > > > Marc Zyngier; Stuart Yoder; > >> Yang-Leo Li; > >>>>> Minghuan > > > Lian; Bjorn Helgaas; Shawn Guo; > >> Mingkai Hu; Rob > >>>>> > > > Herring > >>>>> Subject: Re: [PATCH 2/2] > >> aer: add support > > > aer interrupt with > >>>>> none MSI/MSI-X/INTx > >> mode > >>>>> > > > > >>>>> [+cc Rob] > >>>>> > >>>>> Hi Po, > > >> >>>>> > >>>>> > > > On Thu, May 26, 2016 at 02:00:06PM +0800, Po Liu > >> wrote: > > > > >> > >>>>> > On some platforms, root port doesn't support > >> > > > MSI/MSI-X/INTx in RC mode. > > > > >> > >>>>> > When chip support the aer interrupt with none > > > > >> MSI/MSI-X/INTx > >>>>> mode, > maybe there is interrupt line > > > for > >> aer pme etc. Search > >>>>> the interrupt > number in > > > the fdt file. > > > > >> > >>>>> > > > > >> > >>>>> My understanding is that AER interrupt signaling can > > > be > >> done > >>>>> via INTx, MSI, or MSI-X (PCIe spec r3.0, sec > > > 6.2.4.1.2). > > > > >> > >>>>> Apparently your device doesn't support MSI or MSI-X. > > > Are > >> you > >>>>> saying it doesn't support INTx either? How > > > is the > >> interrupt you're requesting here different from INTx? > > > > >> > >>>> > > > > >> > >>>> Layerscape use none of MSI or MSI-X or INTx to > > > indicate the > >> > >>>> devices or root error in RC mode. But use > > > an independent SPI > >> > >>>> interrupt(arm interrupt controller) > line. > > > > >> > >>> > > > > >> > >>> The Root Port is a PCI device and should follow the > > > normal > >> PCI > >>> rules for interrupts. As far as I > > > understand, that > >> means it > >>> should use MSI, MSI-X, or > > > INTx. If your Root Port > >> doesn't use MSI > >>> or MSI-X, it > > > should use INTx, the > >> PCI_INTERRUPT_PIN register > >>> should > > > tell us which (INTA/ > >> INTB/etc.), and PCI_COMMAND_INTX_DISABLE > should work to disable it. > > > > >> > >>> That's all from the PCI point of view, of course. > > > > >> > >> > > > > >> > >> I am faced with the same issue on Keystone PCI hardware > > > and > >> it has > >> been on my TODO list for quite some time. > > > Keystone > >> PCI hardware > >> also doesn't use MSI or MSI-X or > > > INTx for > >> reporting errors received > >> at the root port, but > > > use a > >> platform interrupt instead (not > >> complaint to PCI > > > standard as > >> per PCI base spec). So I would need > >> similar > > > change to have > >> the error interrupt passed to the aer > >> > > > driver. So there are > >> hardware out there like Keystone which > > > requires to support this through platform IRQ. > > > > >> > > > > > > >> > > This is not a new area of the spec, and it's hard for me > > > to > >> believe > > that these two new PCIe controllers are both > > > broken > >> the same way > > (although I guess both are > > > DesignWare-based, so > >> maybe this is the > > same underlying > > > problem in both cases?). I > >> think it's more likely > > that > > > we just haven't figured out the > >> right way to describe this in > the DT. > > > > >> > > > > > >> > Keystone is using an older version of the designware IP and > > > it > >> > implements all of the interrupts in the application > > > register > >> space > unlike other newer version of the hardware. > > > So I assume, > >> the version > used on Layerscape is also an > > > older version and the > >> both have same > issue in terms of non > > > standard platform interrupt > >> used for error reporting. > > > > >> > > > > > >> > > I assume you have a Root Port with an AER capability, no > > > MSI > >> > > capability, and no MSI-X capability, right? > > > > >> > > > > > >> > Has AER capability and both MSI and INTx (legacy) > > > capability > > >> > > What does its Interrupt > > Pin register > > > contain? If it's > >> zero, it doesn't use INTx either, so > > > > > according to the spec it > >> should generate no interrupts. > > > > >> > > > > > > >> > At address offset 0x3C by default has a value of 1, but it > > > is > >> writable > by software. So default is INTx A. > > > > >> > > > > >> 0x3c is the Interrupt *Line*, which is read/write. The > > > Interrupt > >> *Pin* is at 0x3d and should be read-only. > > > > >> > > > > > > > > You are right. But default is 1 at this address. > > > > > > > > >> Does your Keystone driver support MSI? If so, since your > > > Root > >> Port supports MSI, I would think we would use that by > > > default, and > >> the INTx stuff wouldn't even matter. > > > > > > > > > > Layerscape is also shows "Both message signaled interrupts > > > (MSI) and legacy INTx are supported." > > > > > But both of them not work for AER interrupt when devices or > > > root port report aer error. > > > > > But another GIC interrupt line do. > > > > > > > > Same with Keystone. Even though both MSI and INTx are supported > > > error > interrupt at root port is reported on a different interrupt > > > line than > MSI/INTx. So for Power Management event interrupt is > > > also different > line. > > > > > > I'm looking at the "Error Message Controls" diagram in the PCIe > > > spec r3.0, sec 6.2.6. Does this hardware fit into the > > > platform-specific "System Error" case there? Do the Root Control > > > enable bits (in the PCIe > > > Capability) control this interrupt? If so, maybe this makes more > > > sense than I thought. > > > > It supposedly not the "System Error" case. But "the Error Interrupt" > case. > > Which means " Root Error Command register " could control the > > interrupt line we have now. (refer PCIe spec r3.0, sec 6.2.6) > > Did you actually try this out and verify that the PCIe Root Control > enable bits have no effect and the AER Root Error Command bits do > control it? The names are very similar, so there's lots of room for > misunderstanding here :) Yes, all these result were tested before reply. > > If the AER Root Error Command does control this interrupt, I think the > PCI_COMMAND_INTX_DISABLE bit in the PCI Command register should also > control it (per sec 6.2.4.1.2). Yes, I am sure the PCI_COMMAND_INTX_DISABLE bit can also control this interrupt. > > > May this kind of hardware design route broken the spec? > > If the Reporting Enable bits in the Root Port's AER Root Error Command > register control the interrupt, but the interrupt is not delivered via > the Root Port's INTx or MSI/MSI-X, I think the design is not following > the spec. > > All the information needed by the AER driver should be communicated via > the config space mechanisms described in the spec (AER capability, > MSI/MSI-X capabilities, Interrupt Pin, etc.) That way the driver works > without change on future spec-compliant hardware. > > > PME also like the AER. Hotplug is not supported. Others not known. > > Po Liu > > Per sec 6.1.6, I think PME *should* be signaled by the Root Port's INTx > or MSI/MSI-X. > > In particular, it says "Note that all other interrupt sources within the > same Function will assert the same virtual INTx wire when requesting > service." To me, that means that if we're using INTx, it will be the > same INTx for AER, PME, hotplug, etc., and it should be the one > indicated by the Interrupt Pin register. > > But I think on your Root Port: > > - There is an MSI capability, but MSI doesn't actually work at all > - Interrupt Pin contains 1, indicating INTA, which is routed to IRQ X > - AER interrupts are routed to some different IRQ Y > - PME interrupts are routed to a third IRQ Z > The descriptions are all right. > So how should we work around this? I think you should be able to get > partway there with a quirk that sets: > > dev->no_msi = 1; > dev->irq = Y; > > for this device. That should make AER work, but of course PME would not > work. > > Is there a way to set up your interrupt controller so these three > interrupts (X, Y, Z above) all map to the same Linux IRQ? If you can do > that, you could set up INTA, the AER interrupt, and the PME interrupt to > all be on the same IRQ and everything should work. > > Bjorn We'll think about all the ways. It is really helpful, thanks! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: From: Po Liu To: Bjorn Helgaas CC: Murali Karicheri , Roy Zang , "Arnd Bergmann" , "devicetree@vger.kernel.org" , Marc Zyngier , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Stuart Yoder , Minghuan Lian , Mingkai Hu , Bjorn Helgaas , Yang-Leo Li , Shawn Guo , "linux-arm-kernel@lists.infradead.org" Subject: RE: [PATCH 2/2] aer: add support aer interrupt with none MSI/MSI-X/INTx mode Date: Wed, 8 Jun 2016 04:56:13 +0000 Message-ID: References: <20160602135546.GA8262@localhost> <575052B8.3090203@ti.com> <20160603040952.GA17904@localhost> <5751BEDF.3040300@ti.com> <20160604034852.GA15143@localhost> <57558248.4010502@ti.com> <20160606181049.GA15171@localhost> <20160607224634.GB2543@localhost> In-Reply-To: <20160607224634.GB2543@localhost> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 List-ID: SGkgQmpvcm4sDQoNClRoYW5rcyBmb3IgdGhlIGtpbmRseSByZXBseS4gQWxsIHRoZXNlIGFyZSBo ZWxwZnVsLg0KDQo+ICBGcm9tOiBCam9ybiBIZWxnYWFzIFttYWlsdG86aGVsZ2Fhc0BrZXJuZWwu b3JnXQ0KPiAgT24gV2VkLCBKdW5lIDA4LCAyMDE2IDY6NDcgQU0NCj4gIA0KPiAgT24gVHVlLCBK dW4gMDcsIDIwMTYgYXQgMTA6MDc6NDBBTSArMDAwMCwgUG8gTGl1IHdyb3RlOg0KPiAgPiBIaSBC am9ybiwNCj4gID4NCj4gID4gPiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4gPg0K PiAgPiA+ICBPbiBNb24sIEp1biAwNiwgMjAxNiBhdCAxMDowMTo0NEFNIC0wNDAwLCBNdXJhbGkg S2FyaWNoZXJpIHdyb3RlOg0KPiAgPiA+ICA+IE9uIDA2LzA2LzIwMTYgMDM6MzIgQU0sIFBvIExp dSB3cm90ZToNCj4gID4gPiAgPiA+IEhpIEJqb3JuLA0KPiAgPiA+ICA+ID4gSSBjb25maXJtIHdl IG1ldCBzYW1lIHByb2JsZW0gd2l0aCBLZXlTdG9uZSBiYXNlIG9uIERlc2lnbldhcmUNCj4gID4g PiBkZXNpZ24uDQo+ICA+ID4gID4gPg0KPiAgPiA+ICA+ID4NCj4gID4gPiAgPiA+IEJlc3QgcmVn YXJkcywNCj4gID4gPiAgPiA+IExpdSBQbw0KPiAgPiA+ICA+ID4NCj4gID4gPiAgPiA+PiAgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4gPiAgPiA+PiAgRnJvbTogQmpvcm4gSGVsZ2Fh cyBbbWFpbHRvOmhlbGdhYXNAa2VybmVsLm9yZ10gID4gPj4gIFNlbnQ6DQo+ICA+ID4gU2F0dXJk YXksIEp1bmUgMDQsIDIwMTYgMTE6NDkgQU0gID4gPj4gIFRvOiBNdXJhbGkgS2FyaWNoZXJpICA+ ID4+DQo+ICA+ID4gQ2M6IFBvIExpdTsgbGludXgtcGNpQHZnZXIua2VybmVsLm9yZzsgbGludXgt YXJtLSAgPiA+Pg0KPiAgPiA+IGtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC1rZXJu ZWxAdmdlci5rZXJuZWwub3JnOyAgPiA+Pg0KPiAgPiA+IGRldmljZXRyZWVAdmdlci5rZXJuZWwu b3JnOyBBcm5kIEJlcmdtYW5uOyBSb3kgWmFuZzsgTWFyYyBaeW5naWVyOw0KPiAgPiA+ID4gPj4g U3R1YXJ0IFlvZGVyOyBZYW5nLUxlbyBMaTsgTWluZ2h1YW4gTGlhbjsgQmpvcm4gSGVsZ2Fhczsg U2hhd24NCj4gID4gPiBHdW87ICA+ID4+IE1pbmdrYWkgSHU7IFJvYiBIZXJyaW5nICA+ID4+ICBT dWJqZWN0OiBSZTogW1BBVENIIDIvMl0NCj4gID4gPiBhZXI6IGFkZCBzdXBwb3J0IGFlciBpbnRl cnJ1cHQgd2l0aCBub25lICA+ID4+IE1TSS9NU0ktWC9JTlR4IG1vZGUNCj4gID4gPiA+ID4+ICA+ ID4+ICBPbiBGcmksIEp1biAwMywgMjAxNiBhdCAwMTozMToxMVBNIC0wNDAwLCBNdXJhbGkNCj4g ID4gPiBLYXJpY2hlcmkgd3JvdGU6DQo+ICA+ID4gID4gPj4gID4gUG8sDQo+ICA+ID4gID4gPj4g ID4NCj4gID4gPiAgPiA+PiAgPiBTb3JyeSB0byBoaWphY2sgeW91ciBkaXNjdXNzaW9uLCBidXQg dGhlIHByb2JsZW0gc2VlbXMgdG8NCj4gID4gPiBiZSAgPiA+PiBzYW1lIGZvciAgPiBLZXlzdG9u ZSBQQ0kgY29udHJvbGxlciB3aGljaCBpcyBhbHNvDQo+ICA+ID4gZGVzaWdud2FyZSAob2xkDQo+ ICA+ID4gIHZlcnNpb24pIGJhc2VkLg0KPiAgPiA+ICA+ID4+ICA+DQo+ICA+ID4gID4gPj4gID4g T24gMDYvMDMvMjAxNiAxMjowOSBBTSwgQmpvcm4gSGVsZ2FhcyB3cm90ZToNCj4gID4gPiAgPiA+ PiAgPiA+IE9uIFRodSwgSnVuIDAyLCAyMDE2IGF0IDExOjM3OjI4QU0gLTA0MDAsIE11cmFsaQ0K PiAgPiA+IEthcmljaGVyaQ0KPiAgPiA+ICB3cm90ZToNCj4gID4gPiAgPiA+PiAgPiA+PiBPbiAw Ni8wMi8yMDE2IDA5OjU1IEFNLCBCam9ybiBIZWxnYWFzIHdyb3RlOg0KPiAgPiA+ICA+ID4+ICA+ ID4+PiBPbiBUaHUsIEp1biAwMiwgMjAxNiBhdCAwNTowMToxOUFNICswMDAwLCBQbyBMaXUgd3Jv dGU6DQo+ICA+ID4gID4gPj4gID4gPj4+Pj4gIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tICA+ ID4+Pj4+ICBGcm9tOiBCam9ybg0KPiAgPiA+IEhlbGdhYXMgID4gPj4gW21haWx0bzpoZWxnYWFz QGtlcm5lbC5vcmddICA+ID4+Pj4+ICBTZW50OiBUaHVyc2RheSwNCj4gID4gPiBKdW5lIDAyLCAy MDE2ICA+ID4+IDExOjQ4IEFNICA+ID4+Pj4+ICBUbzogUG8gTGl1ICA+ID4+Pj4+ICBDYzoNCj4g ID4gPiAgPiA+PiBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOyAgPiA+Pj4+PiAgPiA+Pg0KPiAg PiA+IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gID4gPiAgPiA+PiAg PiA+Pj4+PiAgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gID4gPiBkZXZpY2V0cmVl QHZnZXIua2VybmVsLm9yZzsgID4gPj4gQXJuZCAgPiA+Pj4+PiBCZXJnbWFubjsgIFJveSBaYW5n Ow0KPiAgPiA+IE1hcmMgWnluZ2llcjsgU3R1YXJ0IFlvZGVyOyAgPiA+PiBZYW5nLUxlbyBMaTsg ID4gPj4+Pj4gTWluZ2h1YW4NCj4gID4gPiBMaWFuOyBCam9ybiAgSGVsZ2FhczsgU2hhd24gR3Vv OyAgPiA+PiBNaW5na2FpIEh1OyBSb2IgID4gPj4+Pj4NCj4gID4gPiBIZXJyaW5nICA+ID4+Pj4+ ICBTdWJqZWN0OiBSZTogW1BBVENIIDIvMl0gID4gPj4gYWVyOiBhZGQgc3VwcG9ydA0KPiAgPiA+ IGFlciBpbnRlcnJ1cHQgd2l0aCAgPiA+Pj4+PiBub25lICBNU0kvTVNJLVgvSU5UeCAgPiA+PiBt b2RlICA+ID4+Pj4+DQo+ICA+ID4gPiA+Pj4+PiAgWytjYyBSb2JdICA+ID4+Pj4+ICA+ID4+Pj4+ ICBIaSBQbywgID4gID4gPj4gPj4+Pj4gID4gPj4+Pj4NCj4gID4gPiBPbiBUaHUsIE1heSAyNiwg MjAxNiBhdCAwMjowMDowNlBNICswODAwLCBQbyBMaXUgID4gPj4gd3JvdGU6DQo+ICA+ID4gID4g Pj4gID4gPj4+Pj4gID4gT24gc29tZSBwbGF0Zm9ybXMsIHJvb3QgcG9ydCBkb2Vzbid0IHN1cHBv cnQgID4gPj4NCj4gID4gPiBNU0kvTVNJLVgvSU5UeCAgaW4gUkMgbW9kZS4NCj4gID4gPiAgPiA+ PiAgPiA+Pj4+PiAgPiBXaGVuIGNoaXAgc3VwcG9ydCB0aGUgYWVyIGludGVycnVwdCB3aXRoIG5v bmUgID4NCj4gID4gPiA+PiBNU0kvTVNJLVgvSU5UeCAgPiA+Pj4+PiBtb2RlLCAgPiBtYXliZSB0 aGVyZSBpcyBpbnRlcnJ1cHQgbGluZQ0KPiAgPiA+IGZvciAgPiA+PiBhZXIgcG1lIGV0Yy4gU2Vh cmNoICA+ID4+Pj4+IHRoZSBpbnRlcnJ1cHQgID4gbnVtYmVyIGluDQo+ICA+ID4gdGhlIGZkdCAg ZmlsZS4NCj4gID4gPiAgPiA+PiAgPiA+Pj4+Pg0KPiAgPiA+ICA+ID4+ICA+ID4+Pj4+ICBNeSB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgQUVSIGludGVycnVwdCBzaWduYWxpbmcgY2FuDQo+ICA+ID4g YmUgID4gPj4gZG9uZSAgPiA+Pj4+PiB2aWEgSU5UeCwgIE1TSSwgb3IgTVNJLVggKFBDSWUgc3Bl YyByMy4wLCBzZWMNCj4gID4gPiA2LjIuNC4xLjIpLg0KPiAgPiA+ICA+ID4+ICA+ID4+Pj4+IEFw cGFyZW50bHkgeW91ciBkZXZpY2UgIGRvZXNuJ3Qgc3VwcG9ydCBNU0kgb3IgTVNJLVguDQo+ICA+ ID4gQXJlICA+ID4+IHlvdSAgPiA+Pj4+PiBzYXlpbmcgaXQgZG9lc24ndCBzdXBwb3J0IElOVHgg IGVpdGhlcj8gIEhvdw0KPiAgPiA+IGlzIHRoZSAgPiA+PiBpbnRlcnJ1cHQgIHlvdSdyZSByZXF1 ZXN0aW5nIGhlcmUgZGlmZmVyZW50IGZyb20gSU5UeD8NCj4gID4gPiAgPiA+PiAgPiA+Pj4+DQo+ ICA+ID4gID4gPj4gID4gPj4+PiBMYXllcnNjYXBlIHVzZSBub25lIG9mIE1TSSBvciBNU0ktWCBv ciBJTlR4IHRvDQo+ICA+ID4gaW5kaWNhdGUgdGhlICA+ID4+ID4gPj4+PiBkZXZpY2VzIG9yIHJv b3QgZXJyb3IgaW4gUkMgbW9kZS4gQnV0IHVzZQ0KPiAgPiA+IGFuIGluZGVwZW5kZW50IFNQSSAg PiA+PiA+ID4+Pj4gaW50ZXJydXB0KGFybSBpbnRlcnJ1cHQgY29udHJvbGxlcikNCj4gIGxpbmUu DQo+ICA+ID4gID4gPj4gID4gPj4+DQo+ICA+ID4gID4gPj4gID4gPj4+IFRoZSBSb290IFBvcnQg aXMgYSBQQ0kgZGV2aWNlIGFuZCBzaG91bGQgZm9sbG93IHRoZQ0KPiAgPiA+IG5vcm1hbCAgPiA+ PiBQQ0kgID4gPj4+IHJ1bGVzIGZvciBpbnRlcnJ1cHRzLiAgQXMgZmFyIGFzIEkNCj4gID4gPiB1 bmRlcnN0YW5kLCB0aGF0ICA+ID4+IG1lYW5zIGl0ICA+ID4+PiBzaG91bGQgdXNlIE1TSSwgTVNJ LVgsIG9yDQo+ICA+ID4gSU5UeC4gIElmIHlvdXIgUm9vdCBQb3J0ICA+ID4+IGRvZXNuJ3QgdXNl IE1TSSAgPiA+Pj4gb3IgTVNJLVgsIGl0DQo+ICA+ID4gc2hvdWxkIHVzZSBJTlR4LCB0aGUgID4g Pj4gUENJX0lOVEVSUlVQVF9QSU4gcmVnaXN0ZXIgID4gPj4+IHNob3VsZA0KPiAgPiA+IHRlbGwg dXMgd2hpY2ggKElOVEEvICA+ID4+IElOVEIvZXRjLiksIGFuZCAgUENJX0NPTU1BTkRfSU5UWF9E SVNBQkxFDQo+ICBzaG91bGQgd29yayB0byBkaXNhYmxlIGl0Lg0KPiAgPiA+ICA+ID4+ICA+ID4+ PiBUaGF0J3MgYWxsIGZyb20gdGhlIFBDSSBwb2ludCBvZiB2aWV3LCBvZiBjb3Vyc2UuDQo+ICA+ ID4gID4gPj4gID4gPj4NCj4gID4gPiAgPiA+PiAgPiA+PiBJIGFtIGZhY2VkIHdpdGggdGhlIHNh bWUgaXNzdWUgb24gS2V5c3RvbmUgUENJIGhhcmR3YXJlDQo+ICA+ID4gYW5kICA+ID4+IGl0IGhh cyAgPiA+PiBiZWVuIG9uIG15IFRPRE8gbGlzdCAgZm9yIHF1aXRlIHNvbWUgdGltZS4NCj4gID4g PiBLZXlzdG9uZSAgPiA+PiBQQ0kgaGFyZHdhcmUgID4gPj4gYWxzbyBkb2Vzbid0IHVzZSBNU0kg b3IgTVNJLVggb3INCj4gID4gPiBJTlR4IGZvciAgPiA+PiByZXBvcnRpbmcgZXJyb3JzIHJlY2Vp dmVkICA+ID4+IGF0IHRoZSByb290IHBvcnQsIGJ1dA0KPiAgPiA+IHVzZSBhICA+ID4+IHBsYXRm b3JtIGludGVycnVwdCBpbnN0ZWFkIChub3QgID4gPj4gY29tcGxhaW50IHRvIFBDSQ0KPiAgPiA+ IHN0YW5kYXJkIGFzICA+ID4+IHBlciBQQ0kgYmFzZSBzcGVjKS4gU28gSSB3b3VsZCBuZWVkICA+ ID4+IHNpbWlsYXINCj4gID4gPiBjaGFuZ2UgdG8gaGF2ZSAgPiA+PiB0aGUgZXJyb3IgaW50ZXJy dXB0IHBhc3NlZCB0byB0aGUgYWVyICA+ID4+DQo+ICA+ID4gZHJpdmVyLiBTbyB0aGVyZSBhcmUg ID4gPj4gaGFyZHdhcmUgb3V0IHRoZXJlIGxpa2UgS2V5c3RvbmUgd2hpY2gNCj4gID4gPiByZXF1 aXJlcyB0byBzdXBwb3J0IHRoaXMgIHRocm91Z2ggcGxhdGZvcm0gSVJRLg0KPiAgPiA+ICA+ID4+ ICA+ID4NCj4gID4gPiAgPiA+PiAgPiA+IFRoaXMgaXMgbm90IGEgbmV3IGFyZWEgb2YgdGhlIHNw ZWMsIGFuZCBpdCdzIGhhcmQgZm9yIG1lDQo+ICA+ID4gdG8gID4gPj4gYmVsaWV2ZSAgPiA+IHRo YXQgdGhlc2UgdHdvIG5ldyBQQ0llIGNvbnRyb2xsZXJzIGFyZSBib3RoDQo+ICA+ID4gYnJva2Vu ICA+ID4+IHRoZSBzYW1lIHdheSAgPiA+IChhbHRob3VnaCBJIGd1ZXNzIGJvdGggYXJlDQo+ICA+ ID4gRGVzaWduV2FyZS1iYXNlZCwgc28gID4gPj4gbWF5YmUgdGhpcyBpcyB0aGUgID4gPiBzYW1l IHVuZGVybHlpbmcNCj4gID4gPiBwcm9ibGVtIGluIGJvdGggY2FzZXM/KS4gIEkgID4gPj4gdGhp bmsgaXQncyBtb3JlIGxpa2VseSAgPiA+IHRoYXQNCj4gID4gPiB3ZSBqdXN0IGhhdmVuJ3QgZmln dXJlZCBvdXQgdGhlICA+ID4+IHJpZ2h0IHdheSB0byBkZXNjcmliZSB0aGlzIGluDQo+ICB0aGUg RFQuDQo+ICA+ID4gID4gPj4gID4NCj4gID4gPiAgPiA+PiAgPiBLZXlzdG9uZSBpcyB1c2luZyBh biBvbGRlciB2ZXJzaW9uIG9mIHRoZSBkZXNpZ253YXJlIElQIGFuZA0KPiAgPiA+IGl0ICA+ID4+ ID4gaW1wbGVtZW50cyBhbGwgb2YgdGhlIGludGVycnVwdHMgaW4gdGhlIGFwcGxpY2F0aW9uDQo+ ICA+ID4gcmVnaXN0ZXIgID4gPj4gc3BhY2UgID4gdW5saWtlIG90aGVyIG5ld2VyIHZlcnNpb24g b2YgdGhlIGhhcmR3YXJlLg0KPiAgPiA+IFNvIEkgYXNzdW1lLCAgPiA+PiB0aGUgdmVyc2lvbiAg PiB1c2VkIG9uIExheWVyc2NhcGUgaXMgYWxzbyBhbg0KPiAgPiA+IG9sZGVyIHZlcnNpb24gYW5k IHRoZSAgPiA+PiBib3RoIGhhdmUgc2FtZSAgPiBpc3N1ZSBpbiB0ZXJtcyBvZiBub24NCj4gID4g PiBzdGFuZGFyZCBwbGF0Zm9ybSBpbnRlcnJ1cHQgID4gPj4gdXNlZCBmb3IgZXJyb3IgIHJlcG9y dGluZy4NCj4gID4gPiAgPiA+PiAgPg0KPiAgPiA+ICA+ID4+ICA+ID4gSSBhc3N1bWUgeW91IGhh dmUgYSBSb290IFBvcnQgd2l0aCBhbiBBRVIgY2FwYWJpbGl0eSwgbm8NCj4gID4gPiBNU0kgID4g Pj4gPiA+IGNhcGFiaWxpdHksIGFuZCBubyBNU0ktWCBjYXBhYmlsaXR5LCByaWdodD8NCj4gID4g PiAgPiA+PiAgPg0KPiAgPiA+ICA+ID4+ICA+IEhhcyBBRVIgY2FwYWJpbGl0eSBhbmQgYm90aCBN U0kgYW5kIElOVHggKGxlZ2FjeSkNCj4gID4gPiBjYXBhYmlsaXR5ICA+ICA+ID4+ID4gPiBXaGF0 IGRvZXMgaXRzIEludGVycnVwdCAgPiA+IFBpbiByZWdpc3Rlcg0KPiAgPiA+IGNvbnRhaW4/ICBJ ZiBpdCdzICA+ID4+IHplcm8sIGl0IGRvZXNuJ3QgdXNlIElOVHggZWl0aGVyLCBzbyAgPiA+DQo+ ICA+ID4gYWNjb3JkaW5nIHRvIHRoZSBzcGVjIGl0ICA+ID4+IHNob3VsZCBnZW5lcmF0ZSBubyBp bnRlcnJ1cHRzLg0KPiAgPiA+ICA+ID4+ICA+ID4NCj4gID4gPiAgPiA+PiAgPiBBdCBhZGRyZXNz IG9mZnNldCAweDNDIGJ5IGRlZmF1bHQgaGFzIGEgdmFsdWUgb2YgMSwgYnV0IGl0DQo+ICA+ID4g aXMgID4gPj4gd3JpdGFibGUgID4gYnkgc29mdHdhcmUuIFNvIGRlZmF1bHQgaXMgSU5UeCBBLg0K PiAgPiA+ICA+ID4+DQo+ICA+ID4gID4gPj4gIDB4M2MgaXMgdGhlIEludGVycnVwdCAqTGluZSos IHdoaWNoIGlzIHJlYWQvd3JpdGUuICBUaGUNCj4gID4gPiBJbnRlcnJ1cHQgID4gPj4gICpQaW4q IGlzIGF0IDB4M2QgYW5kIHNob3VsZCBiZSByZWFkLW9ubHkuDQo+ICA+ID4gID4gPj4NCj4gID4g PiAgPg0KPiAgPiA+ICA+IFlvdSBhcmUgcmlnaHQuIEJ1dCBkZWZhdWx0IGlzIDEgYXQgdGhpcyBh ZGRyZXNzLg0KPiAgPiA+ICA+DQo+ICA+ID4gID4gPj4gIERvZXMgeW91ciBLZXlzdG9uZSBkcml2 ZXIgc3VwcG9ydCBNU0k/ICBJZiBzbywgc2luY2UgeW91cg0KPiAgPiA+IFJvb3QgID4gPj4gUG9y dCAgc3VwcG9ydHMgTVNJLCBJIHdvdWxkIHRoaW5rIHdlIHdvdWxkIHVzZSB0aGF0IGJ5DQo+ICA+ ID4gZGVmYXVsdCwgYW5kICA+ID4+IHRoZSBJTlR4ICBzdHVmZiB3b3VsZG4ndCBldmVuIG1hdHRl ci4NCj4gID4gPiAgPiA+DQo+ICA+ID4gID4gPiBMYXllcnNjYXBlIGlzIGFsc28gc2hvd3MgIkJv dGggbWVzc2FnZSBzaWduYWxlZCBpbnRlcnJ1cHRzDQo+ICA+ID4gKE1TSSkgYW5kICBsZWdhY3kg SU5UeCBhcmUgc3VwcG9ydGVkLiINCj4gID4gPiAgPiA+IEJ1dCBib3RoIG9mIHRoZW0gbm90IHdv cmsgZm9yIEFFUiBpbnRlcnJ1cHQgd2hlbiBkZXZpY2VzIG9yDQo+ICA+ID4gcm9vdCAgcG9ydCBy ZXBvcnQgYWVyIGVycm9yLg0KPiAgPiA+ICA+ID4gQnV0IGFub3RoZXIgR0lDIGludGVycnVwdCBs aW5lIGRvLg0KPiAgPiA+ICA+DQo+ICA+ID4gID4gU2FtZSB3aXRoIEtleXN0b25lLiBFdmVuIHRo b3VnaCBib3RoIE1TSSBhbmQgSU5UeCBhcmUgc3VwcG9ydGVkDQo+ICA+ID4gZXJyb3IgID4gaW50 ZXJydXB0IGF0IHJvb3QgcG9ydCBpcyByZXBvcnRlZCBvbiBhIGRpZmZlcmVudCBpbnRlcnJ1cHQN Cj4gID4gPiBsaW5lIHRoYW4gID4gTVNJL0lOVHguIFNvIGZvciBQb3dlciBNYW5hZ2VtZW50IGV2 ZW50IGludGVycnVwdCBpcw0KPiAgPiA+IGFsc28gZGlmZmVyZW50ICA+IGxpbmUuDQo+ICA+ID4N Cj4gID4gPiAgSSdtIGxvb2tpbmcgYXQgdGhlICJFcnJvciBNZXNzYWdlIENvbnRyb2xzIiBkaWFn cmFtIGluIHRoZSBQQ0llDQo+ICA+ID4gc3BlYyAgcjMuMCwgc2VjIDYuMi42LiAgRG9lcyB0aGlz IGhhcmR3YXJlIGZpdCBpbnRvIHRoZQ0KPiAgPiA+IHBsYXRmb3JtLXNwZWNpZmljICAiU3lzdGVt IEVycm9yIiBjYXNlIHRoZXJlPyAgRG8gdGhlIFJvb3QgQ29udHJvbA0KPiAgPiA+IGVuYWJsZSBi aXRzIChpbiB0aGUgUENJZQ0KPiAgPiA+ICBDYXBhYmlsaXR5KSBjb250cm9sIHRoaXMgaW50ZXJy dXB0PyAgSWYgc28sIG1heWJlIHRoaXMgbWFrZXMgbW9yZQ0KPiAgPiA+IHNlbnNlICB0aGFuIEkg dGhvdWdodC4NCj4gID4NCj4gID4gSXQgc3VwcG9zZWRseSBub3QgdGhlICJTeXN0ZW0gRXJyb3Ii IGNhc2UuIEJ1dCAidGhlIEVycm9yIEludGVycnVwdCINCj4gIGNhc2UuDQo+ICA+IFdoaWNoIG1l YW5zICIgUm9vdCBFcnJvciBDb21tYW5kIHJlZ2lzdGVyICIgY291bGQgY29udHJvbCB0aGUNCj4g ID4gaW50ZXJydXB0ICBsaW5lIHdlIGhhdmUgbm93LiAocmVmZXIgUENJZSBzcGVjIHIzLjAsIHNl YyA2LjIuNikNCj4gIA0KPiAgRGlkIHlvdSBhY3R1YWxseSB0cnkgdGhpcyBvdXQgYW5kIHZlcmlm eSB0aGF0IHRoZSBQQ0llIFJvb3QgQ29udHJvbA0KPiAgZW5hYmxlIGJpdHMgaGF2ZSBubyBlZmZl Y3QgYW5kIHRoZSBBRVIgUm9vdCBFcnJvciBDb21tYW5kIGJpdHMgZG8NCj4gIGNvbnRyb2wgaXQ/ ICBUaGUgbmFtZXMgYXJlIHZlcnkgc2ltaWxhciwgc28gdGhlcmUncyBsb3RzIG9mIHJvb20gZm9y DQo+ICBtaXN1bmRlcnN0YW5kaW5nIGhlcmUgOikNCg0KWWVzLCBhbGwgdGhlc2UgcmVzdWx0IHdl cmUgdGVzdGVkIGJlZm9yZSByZXBseS4NCg0KPiAgDQo+ICBJZiB0aGUgQUVSIFJvb3QgRXJyb3Ig Q29tbWFuZCBkb2VzIGNvbnRyb2wgdGhpcyBpbnRlcnJ1cHQsIEkgdGhpbmsgdGhlDQo+ICBQQ0lf Q09NTUFORF9JTlRYX0RJU0FCTEUgYml0IGluIHRoZSBQQ0kgQ29tbWFuZCByZWdpc3RlciBzaG91 bGQgYWxzbw0KPiAgY29udHJvbCBpdCAocGVyIHNlYyA2LjIuNC4xLjIpLg0KDQpZZXMsIEkgYW0g c3VyZSB0aGUgUENJX0NPTU1BTkRfSU5UWF9ESVNBQkxFIGJpdCBjYW4gYWxzbyBjb250cm9sIHRo aXMgaW50ZXJydXB0Lg0KDQo+ICANCj4gID4gTWF5IHRoaXMga2luZCBvZiBoYXJkd2FyZSBkZXNp Z24gcm91dGUgYnJva2VuIHRoZSBzcGVjPw0KPiAgDQo+ICBJZiB0aGUgUmVwb3J0aW5nIEVuYWJs ZSBiaXRzIGluIHRoZSBSb290IFBvcnQncyBBRVIgUm9vdCBFcnJvciBDb21tYW5kDQo+ICByZWdp c3RlciBjb250cm9sIHRoZSBpbnRlcnJ1cHQsIGJ1dCB0aGUgaW50ZXJydXB0IGlzIG5vdCBkZWxp dmVyZWQgdmlhDQo+ICB0aGUgUm9vdCBQb3J0J3MgSU5UeCBvciBNU0kvTVNJLVgsIEkgdGhpbmsg dGhlIGRlc2lnbiBpcyBub3QgZm9sbG93aW5nDQo+ICB0aGUgc3BlYy4NCj4gIA0KPiAgQWxsIHRo ZSBpbmZvcm1hdGlvbiBuZWVkZWQgYnkgdGhlIEFFUiBkcml2ZXIgc2hvdWxkIGJlIGNvbW11bmlj YXRlZCB2aWENCj4gIHRoZSBjb25maWcgc3BhY2UgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhl IHNwZWMgKEFFUiBjYXBhYmlsaXR5LA0KPiAgTVNJL01TSS1YIGNhcGFiaWxpdGllcywgSW50ZXJy dXB0IFBpbiwgZXRjLikgIFRoYXQgd2F5IHRoZSBkcml2ZXIgd29ya3MNCj4gIHdpdGhvdXQgY2hh bmdlIG9uIGZ1dHVyZSBzcGVjLWNvbXBsaWFudCBoYXJkd2FyZS4NCj4gIA0KPiAgPiBQTUUgYWxz byBsaWtlIHRoZSBBRVIuIEhvdHBsdWcgaXMgbm90IHN1cHBvcnRlZC4gT3RoZXJzIG5vdCBrbm93 bi4NCj4gID4gUG8gTGl1DQo+ICANCj4gIFBlciBzZWMgNi4xLjYsIEkgdGhpbmsgUE1FICpzaG91 bGQqIGJlIHNpZ25hbGVkIGJ5IHRoZSBSb290IFBvcnQncyBJTlR4DQo+ICBvciBNU0kvTVNJLVgu DQo+ICANCj4gIEluIHBhcnRpY3VsYXIsIGl0IHNheXMgIk5vdGUgdGhhdCBhbGwgb3RoZXIgaW50 ZXJydXB0IHNvdXJjZXMgd2l0aGluIHRoZQ0KPiAgc2FtZSBGdW5jdGlvbiB3aWxsIGFzc2VydCB0 aGUgc2FtZSB2aXJ0dWFsIElOVHggd2lyZSB3aGVuIHJlcXVlc3RpbmcNCj4gIHNlcnZpY2UuIiAg VG8gbWUsIHRoYXQgbWVhbnMgdGhhdCBpZiB3ZSdyZSB1c2luZyBJTlR4LCBpdCB3aWxsIGJlIHRo ZQ0KPiAgc2FtZSBJTlR4IGZvciBBRVIsIFBNRSwgaG90cGx1ZywgZXRjLiwgYW5kIGl0IHNob3Vs ZCBiZSB0aGUgb25lDQo+ICBpbmRpY2F0ZWQgYnkgdGhlIEludGVycnVwdCBQaW4gcmVnaXN0ZXIu DQo+ICANCj4gIEJ1dCBJIHRoaW5rIG9uIHlvdXIgUm9vdCBQb3J0Og0KPiAgDQo+ICAgIC0gVGhl cmUgaXMgYW4gTVNJIGNhcGFiaWxpdHksIGJ1dCBNU0kgZG9lc24ndCBhY3R1YWxseSB3b3JrIGF0 IGFsbA0KPiAgICAtIEludGVycnVwdCBQaW4gY29udGFpbnMgMSwgaW5kaWNhdGluZyBJTlRBLCB3 aGljaCBpcyByb3V0ZWQgdG8gSVJRIFgNCj4gICAgLSBBRVIgaW50ZXJydXB0cyBhcmUgcm91dGVk IHRvIHNvbWUgZGlmZmVyZW50IElSUSBZDQo+ICAgIC0gUE1FIGludGVycnVwdHMgYXJlIHJvdXRl ZCB0byBhIHRoaXJkIElSUSBaDQo+ICANCg0KVGhlIGRlc2NyaXB0aW9ucyBhcmUgYWxsIHJpZ2h0 Lg0KDQo+ICBTbyBob3cgc2hvdWxkIHdlIHdvcmsgYXJvdW5kIHRoaXM/ICBJIHRoaW5rIHlvdSBz aG91bGQgYmUgYWJsZSB0byBnZXQNCj4gIHBhcnR3YXkgdGhlcmUgd2l0aCBhIHF1aXJrIHRoYXQg c2V0czoNCj4gIA0KPiAgICBkZXYtPm5vX21zaSA9IDE7DQo+ICAgIGRldi0+aXJxID0gWTsNCj4g IA0KPiAgZm9yIHRoaXMgZGV2aWNlLiAgVGhhdCBzaG91bGQgbWFrZSBBRVIgd29yaywgYnV0IG9m IGNvdXJzZSBQTUUgd291bGQgbm90DQo+ICB3b3JrLg0KPiAgDQo+ICBJcyB0aGVyZSBhIHdheSB0 byBzZXQgdXAgeW91ciBpbnRlcnJ1cHQgY29udHJvbGxlciBzbyB0aGVzZSB0aHJlZQ0KPiAgaW50 ZXJydXB0cyAoWCwgWSwgWiBhYm92ZSkgYWxsIG1hcCB0byB0aGUgc2FtZSBMaW51eCBJUlE/ICBJ ZiB5b3UgY2FuIGRvDQo+ICB0aGF0LCB5b3UgY291bGQgc2V0IHVwIElOVEEsIHRoZSBBRVIgaW50 ZXJydXB0LCBhbmQgdGhlIFBNRSBpbnRlcnJ1cHQgdG8NCj4gIGFsbCBiZSBvbiB0aGUgc2FtZSBJ UlEgYW5kIGV2ZXJ5dGhpbmcgc2hvdWxkIHdvcmsuDQo+ICANCj4gIEJqb3JuDQoNCldlJ2xsIHRo aW5rIGFib3V0IGFsbCB0aGUgd2F5cy4gSXQgaXMgcmVhbGx5IGhlbHBmdWwsIHRoYW5rcyEgIA0K From mboxrd@z Thu Jan 1 00:00:00 1970 From: po.liu@nxp.com (Po Liu) Date: Wed, 8 Jun 2016 04:56:13 +0000 Subject: [PATCH 2/2] aer: add support aer interrupt with none MSI/MSI-X/INTx mode In-Reply-To: <20160607224634.GB2543@localhost> References: <20160602135546.GA8262@localhost> <575052B8.3090203@ti.com> <20160603040952.GA17904@localhost> <5751BEDF.3040300@ti.com> <20160604034852.GA15143@localhost> <57558248.4010502@ti.com> <20160606181049.GA15171@localhost> <20160607224634.GB2543@localhost> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Bjorn, Thanks for the kindly reply. All these are helpful. > From: Bjorn Helgaas [mailto:helgaas at kernel.org] > On Wed, June 08, 2016 6:47 AM > > On Tue, Jun 07, 2016 at 10:07:40AM +0000, Po Liu wrote: > > Hi Bjorn, > > > > > -----Original Message----- > > > > > > On Mon, Jun 06, 2016 at 10:01:44AM -0400, Murali Karicheri wrote: > > > > On 06/06/2016 03:32 AM, Po Liu wrote: > > > > > Hi Bjorn, > > > > > I confirm we met same problem with KeyStone base on DesignWare > > > design. > > > > > > > > > > > > > > > Best regards, > > > > > Liu Po > > > > > > > > > >> -----Original Message----- > > > > >> From: Bjorn Helgaas [mailto:helgaas at kernel.org] > >> Sent: > > > Saturday, June 04, 2016 11:49 AM > >> To: Murali Karicheri > >> > > > Cc: Po Liu; linux-pci at vger.kernel.org; linux-arm- > >> > > > kernel at lists.infradead.org; linux-kernel at vger.kernel.org; > >> > > > devicetree at vger.kernel.org; Arnd Bergmann; Roy Zang; Marc Zyngier; > > > > >> Stuart Yoder; Yang-Leo Li; Minghuan Lian; Bjorn Helgaas; Shawn > > > Guo; > >> Mingkai Hu; Rob Herring > >> Subject: Re: [PATCH 2/2] > > > aer: add support aer interrupt with none > >> MSI/MSI-X/INTx mode > > > > >> > >> On Fri, Jun 03, 2016 at 01:31:11PM -0400, Murali > > > Karicheri wrote: > > > > >> > Po, > > > > >> > > > > > >> > Sorry to hijack your discussion, but the problem seems to > > > be > >> same for > Keystone PCI controller which is also > > > designware (old > > > version) based. > > > > >> > > > > > >> > On 06/03/2016 12:09 AM, Bjorn Helgaas wrote: > > > > >> > > On Thu, Jun 02, 2016 at 11:37:28AM -0400, Murali > > > Karicheri > > > wrote: > > > > >> > >> On 06/02/2016 09:55 AM, Bjorn Helgaas wrote: > > > > >> > >>> On Thu, Jun 02, 2016 at 05:01:19AM +0000, Po Liu wrote: > > > > >> > >>>>> -----Original Message----- > >>>>> From: Bjorn > > > Helgaas > >> [mailto:helgaas at kernel.org] > >>>>> Sent: Thursday, > > > June 02, 2016 > >> 11:48 AM > >>>>> To: Po Liu > >>>>> Cc: > > > > >> linux-pci at vger.kernel.org; > >>>>> > >> > > > linux-arm-kernel at lists.infradead.org; > > > > >> > >>>>> linux-kernel at vger.kernel.org; > > > devicetree at vger.kernel.org; > >> Arnd > >>>>> Bergmann; Roy Zang; > > > Marc Zyngier; Stuart Yoder; > >> Yang-Leo Li; > >>>>> Minghuan > > > Lian; Bjorn Helgaas; Shawn Guo; > >> Mingkai Hu; Rob > >>>>> > > > Herring > >>>>> Subject: Re: [PATCH 2/2] > >> aer: add support > > > aer interrupt with > >>>>> none MSI/MSI-X/INTx > >> mode > >>>>> > > > > >>>>> [+cc Rob] > >>>>> > >>>>> Hi Po, > > >> >>>>> > >>>>> > > > On Thu, May 26, 2016 at 02:00:06PM +0800, Po Liu > >> wrote: > > > > >> > >>>>> > On some platforms, root port doesn't support > >> > > > MSI/MSI-X/INTx in RC mode. > > > > >> > >>>>> > When chip support the aer interrupt with none > > > > >> MSI/MSI-X/INTx > >>>>> mode, > maybe there is interrupt line > > > for > >> aer pme etc. Search > >>>>> the interrupt > number in > > > the fdt file. > > > > >> > >>>>> > > > > >> > >>>>> My understanding is that AER interrupt signaling can > > > be > >> done > >>>>> via INTx, MSI, or MSI-X (PCIe spec r3.0, sec > > > 6.2.4.1.2). > > > > >> > >>>>> Apparently your device doesn't support MSI or MSI-X. > > > Are > >> you > >>>>> saying it doesn't support INTx either? How > > > is the > >> interrupt you're requesting here different from INTx? > > > > >> > >>>> > > > > >> > >>>> Layerscape use none of MSI or MSI-X or INTx to > > > indicate the > >> > >>>> devices or root error in RC mode. But use > > > an independent SPI > >> > >>>> interrupt(arm interrupt controller) > line. > > > > >> > >>> > > > > >> > >>> The Root Port is a PCI device and should follow the > > > normal > >> PCI > >>> rules for interrupts. As far as I > > > understand, that > >> means it > >>> should use MSI, MSI-X, or > > > INTx. If your Root Port > >> doesn't use MSI > >>> or MSI-X, it > > > should use INTx, the > >> PCI_INTERRUPT_PIN register > >>> should > > > tell us which (INTA/ > >> INTB/etc.), and PCI_COMMAND_INTX_DISABLE > should work to disable it. > > > > >> > >>> That's all from the PCI point of view, of course. > > > > >> > >> > > > > >> > >> I am faced with the same issue on Keystone PCI hardware > > > and > >> it has > >> been on my TODO list for quite some time. > > > Keystone > >> PCI hardware > >> also doesn't use MSI or MSI-X or > > > INTx for > >> reporting errors received > >> at the root port, but > > > use a > >> platform interrupt instead (not > >> complaint to PCI > > > standard as > >> per PCI base spec). So I would need > >> similar > > > change to have > >> the error interrupt passed to the aer > >> > > > driver. So there are > >> hardware out there like Keystone which > > > requires to support this through platform IRQ. > > > > >> > > > > > > >> > > This is not a new area of the spec, and it's hard for me > > > to > >> believe > > that these two new PCIe controllers are both > > > broken > >> the same way > > (although I guess both are > > > DesignWare-based, so > >> maybe this is the > > same underlying > > > problem in both cases?). I > >> think it's more likely > > that > > > we just haven't figured out the > >> right way to describe this in > the DT. > > > > >> > > > > > >> > Keystone is using an older version of the designware IP and > > > it > >> > implements all of the interrupts in the application > > > register > >> space > unlike other newer version of the hardware. > > > So I assume, > >> the version > used on Layerscape is also an > > > older version and the > >> both have same > issue in terms of non > > > standard platform interrupt > >> used for error reporting. > > > > >> > > > > > >> > > I assume you have a Root Port with an AER capability, no > > > MSI > >> > > capability, and no MSI-X capability, right? > > > > >> > > > > > >> > Has AER capability and both MSI and INTx (legacy) > > > capability > > >> > > What does its Interrupt > > Pin register > > > contain? If it's > >> zero, it doesn't use INTx either, so > > > > > according to the spec it > >> should generate no interrupts. > > > > >> > > > > > > >> > At address offset 0x3C by default has a value of 1, but it > > > is > >> writable > by software. So default is INTx A. > > > > >> > > > > >> 0x3c is the Interrupt *Line*, which is read/write. The > > > Interrupt > >> *Pin* is at 0x3d and should be read-only. > > > > >> > > > > > > > > You are right. But default is 1 at this address. > > > > > > > > >> Does your Keystone driver support MSI? If so, since your > > > Root > >> Port supports MSI, I would think we would use that by > > > default, and > >> the INTx stuff wouldn't even matter. > > > > > > > > > > Layerscape is also shows "Both message signaled interrupts > > > (MSI) and legacy INTx are supported." > > > > > But both of them not work for AER interrupt when devices or > > > root port report aer error. > > > > > But another GIC interrupt line do. > > > > > > > > Same with Keystone. Even though both MSI and INTx are supported > > > error > interrupt at root port is reported on a different interrupt > > > line than > MSI/INTx. So for Power Management event interrupt is > > > also different > line. > > > > > > I'm looking at the "Error Message Controls" diagram in the PCIe > > > spec r3.0, sec 6.2.6. Does this hardware fit into the > > > platform-specific "System Error" case there? Do the Root Control > > > enable bits (in the PCIe > > > Capability) control this interrupt? If so, maybe this makes more > > > sense than I thought. > > > > It supposedly not the "System Error" case. But "the Error Interrupt" > case. > > Which means " Root Error Command register " could control the > > interrupt line we have now. (refer PCIe spec r3.0, sec 6.2.6) > > Did you actually try this out and verify that the PCIe Root Control > enable bits have no effect and the AER Root Error Command bits do > control it? The names are very similar, so there's lots of room for > misunderstanding here :) Yes, all these result were tested before reply. > > If the AER Root Error Command does control this interrupt, I think the > PCI_COMMAND_INTX_DISABLE bit in the PCI Command register should also > control it (per sec 6.2.4.1.2). Yes, I am sure the PCI_COMMAND_INTX_DISABLE bit can also control this interrupt. > > > May this kind of hardware design route broken the spec? > > If the Reporting Enable bits in the Root Port's AER Root Error Command > register control the interrupt, but the interrupt is not delivered via > the Root Port's INTx or MSI/MSI-X, I think the design is not following > the spec. > > All the information needed by the AER driver should be communicated via > the config space mechanisms described in the spec (AER capability, > MSI/MSI-X capabilities, Interrupt Pin, etc.) That way the driver works > without change on future spec-compliant hardware. > > > PME also like the AER. Hotplug is not supported. Others not known. > > Po Liu > > Per sec 6.1.6, I think PME *should* be signaled by the Root Port's INTx > or MSI/MSI-X. > > In particular, it says "Note that all other interrupt sources within the > same Function will assert the same virtual INTx wire when requesting > service." To me, that means that if we're using INTx, it will be the > same INTx for AER, PME, hotplug, etc., and it should be the one > indicated by the Interrupt Pin register. > > But I think on your Root Port: > > - There is an MSI capability, but MSI doesn't actually work at all > - Interrupt Pin contains 1, indicating INTA, which is routed to IRQ X > - AER interrupts are routed to some different IRQ Y > - PME interrupts are routed to a third IRQ Z > The descriptions are all right. > So how should we work around this? I think you should be able to get > partway there with a quirk that sets: > > dev->no_msi = 1; > dev->irq = Y; > > for this device. That should make AER work, but of course PME would not > work. > > Is there a way to set up your interrupt controller so these three > interrupts (X, Y, Z above) all map to the same Linux IRQ? If you can do > that, you could set up INTA, the AER interrupt, and the PME interrupt to > all be on the same IRQ and everything should work. > > Bjorn We'll think about all the ways. It is really helpful, thanks!