Hi Lucas, On 14 May 2014 09:42, Lucas wrote: > please limit your lines to a reasonable amount of characters, thanks. Oops, recently change email client & I thought this was on, my bad. > 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. Ah, yes now I see that. > > 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. It's also possible that the i.MX doesn’t support AER. This is a configuration option for the Synopsys IP. > 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. I don’t have a lot of experience with DT bindings, though it appears as though it would be good if we could specify interrupts by their name, rather than the order in which they are listed. Of course, that would add some overhead to DT parsing. I can imagine this sort of problem happening with lots of other IP blocks. Thanks Phil ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
