>-----Original Message----- >From: linux-pci-owner@xxxxxxxxxxxxxxx [mailto:linux-pci-owner@xxxxxxxxxxxxxxx] On >Behalf Of Lucas Stach >Sent: Wednesday, May 14, 2014 4:42 AM >To: Phil Edworthy >Cc: Tim Harvey; linux-pci@xxxxxxxxxxxxxxx; Richard Zhu; Shawn Guo; Mohit Kumar; >Pratyush Anand; Marek Vasut; ABRAHAM, KISHON VIJAY; Arnd Bergmann; Jingoo Han >Subject: Re: [Q] Synopsys PCIe interrupts > >Hi Phil, > >please limit your lines to a reasonable amount of characters, thanks. > >Am Mittwoch, den 14.05.2014, 08:13 +0000 schrieb Phil Edworthy: >> Hi Tim, >> >> On 14 May 2014 05:55, Tim wrote: >> > On Tue, May 13, 2014 at 5:59 PM, Jingoo Han <jg1.han@xxxxxxxxxxx> >> > wrote: >> > > On Wednesday, May 14, 2014 1:14 AM, Phil Edworthy wrote: >> > >> >> > >> Hi, >> > >> >> > >> I am currently writing another driver that uses the Synopsys >> > >> Designware PCIe host controller driver. >> > >> >> > >> In general, it all looks good thanks to all involved in this driver. >> > >> One area that I am having a little problem with is the interrupts. >> > >> According to the documentation I have, the module has separate >> > >> interrupts for INTA, INTB, INTC, INTD, MSI, AER, bandwidth >> > >> management, PME (and possibly a couple of others as well). >> > >> >> > >> However, so far it looks like the upstream implementations just >> > >> use a single interrupt for the module, is that correct? I notice >> > >> that some DT bindings include other interrupts that are not part >> > >> of the Designware PCIe controller, but that's not what I'm talking about. >> > > >> > > (+cc Mohit Kumar, Pratyush Anand, Marek Vasut, Kishon Vijay Abraham I, >> > > Lucas Stach, Tim Harvey, Arnd Bergmann) >> > > >> > > PCIe Interrupt mapping is specific for SoC. >> > > >> > > In the case of Exynos, there are three interrupts for Exynos PCIe; >> > > INTx, MSI, PHY Link, respectively as below. >> > > >> > > ./arch/arm/boot/dts/exynos5440.dtsi >> > > interrupts = <0 20 0>, <0 21 0>, <0 22 0>; >> > > >> > > <0 20 0>: PCIe RC0 pulse interrupt, >> > > INTA, INTB, INTC and INTD, etc >> > > <0 21 0>: PCIe RC0 level interrupt, >> > > MSI, etc >> > > <0 22 0>: PCIe RC0 special interrupt, >> > > PHY Link related interrupts, etc >> > > >> > > So, there are three lines between GIC and PCIe. Also, IRQ mappings >> > > for other SoCs are different. >> > > >> > > For example, the IMX6 maps INTA/B/C/D to ARM GIC IRQ >> > > 155/154/153/152 respectively. >> > > >> > > Then, how many lines are there between GIC and PCIe in your SoC? >> > > How does your SoC map interrupts to GIC? >> > > >> > >> >> > >> In existing implementations, does the hardware just OR all these >> > >> interrupts together? >> > >> >> > >> > Phil, >> > >> > There is not just a single interrupt for the upstream implementations. >> > See: >> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/ >> > drivers/pci/ >> > host/pcie-designware.c#n742 >> > >> > of_irq_parse_and_map_pci(dev, slot, pin) is used to parse the >> > device-tree interrupt map which defines the multiple IRQ's that >> > Jingoo mentions above. For IMX6 these are defined in the imx6qdl.dtsi here: >> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/ >> > arch/arm/b >> > oot/dts/imx6qdl.dtsi#n146. >> > >> > So in other words, depending on the slot and pin (each legacy PCI >> > device can have 4 interrupt pins, INTA/B/C/D) the irq would get >> > mapped to a different interrupt. The interrupts are not OR'd together. >> >> I've just had a look through Lucas' patches for adding MSI interrupts >> to imx6qdl. From this it looks like imx6qdl has 4 interrupts, one is a >> combined interrupt for INTA and MSI, and the other three are for INTB, >> INTC, INTD. Is that correct? >> >It's the other way around: MSI and INTD share a single irq line, but in principle your >description is correct. > >> As I mentioned previously, the Synopsys DW PCIe Host IP (or at least >> the version 4.21a that I am looking at) actually outputs all of these >> interrupts (and others for AER, etc) as separate signals. Both the >> Exynos and imx6qdl SoCs appear to combine some of these interrupts. >> >I don't have access to the underlying DW IP core documentation, only to a i.MX specific one, >so I only know about this specific implementation. > >i.MX doesn't seem to have the AER irq wired up. > >Because of those differences I've pushed the irq properties of the binding into the SoC >specific part. >If we can enumerate all irq signals from the DW core we could maybe push this stuff back >into common doc/code, but I'm not sure about how to handle this without breaking the >Exynos binding. i.MX won't care as the only irq it uses besides the legacy irqs, which are >mapped through DT, is now a named irq. > >Regards, >Lucas > >-- >Pengutronix e.K. | Lucas Stach | >Industrial Linux Solutions | http://www.pengutronix.de/ | > >-- >To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message >to majordomo@xxxxxxxxxxxxxxx More majordomo info at >http://vger.kernel.org/majordomo-info.html BTW, I am working on a designware PCIE driver for keystone SoC (v1 is on the list now being reviewed) and it uses a older version of the IP (v3.65) and has 4 dedicated IRQs for Legacy, 8 MSI IRQs and 2 misc (PME, Error). Currently I have defined IRQs part of the platform device and used. Please review my driver and see if we can move this to DW PCI core. Murali ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
