Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Mon, Mar 3, 2014 at 4:01 PM, Jason Gunthorpe
wrote:
> On Mon, Mar 03, 2014 at 03:40:43PM -0800, Tim Harvey wrote:
>
>> of_irq_parse_and_map_pci(). The GIC function that translates the
>> interrupt per domain is given irq_data: 0x123 0x04 0x00
>
> This has been shifted by 1 byte..
>
>> IRQ 123, which should get 32 added to it for irq155). Instead, the
>> implementation of gic_irq_domain_xlate()
>> (http://lxr.missinglinkelectronics.com/linux/drivers/irqchip/irq-gic.c#L832)
>> adds 32 to the 0x04 returning 20:
>> [1.841781] of_irq_parse_raw: /soc/pcie@0x0100:0001
>> [1.841813] of_irq_parse_raw: ipar=/soc/pcie@0x0100, size=1
>> [1.841838] -> addrsize=3
>> [1.841870] -> match=1 (imaplen=28)
> ^
>
> That looks odd, it should be the number of dwords in the
> interrupt-map, you have 4 lines of 8 dwords each, so it should be
> 32.
(+cc Grant Likely)
imaplen does indeed get initialized to 32 (size of interrupt-map /
sizeof(u32)) but its printed above after its been decremented in the
loop which is misleading
(http://lxr.missinglinkelectronics.com/linux/drivers/of/irq.c#L201)
The issue appears to me to be a bug in of_irq_parse_raw() which has
been around since Graht's original commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of/irq.c?id=7dc2e1134a22dc242175d5321c0c9e97d16eb87b
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9bcf2cf..8829197 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -237,11 +237,11 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle
/* Check for malformed properties */
if (WARN_ON(newaddrsize + newintsize > MAX_PHANDLE_ARGS)
goto fail;
- if (imaplen < (newaddrsize + newintsize))
+ if (imaplen < newintsize)
goto fail;
- imap += newaddrsize + newintsize;
- imaplen -= newaddrsize + newintsize;
+ imap += newintsize;
+ imaplen -= newintsize;
pr_debug(" -> imaplen=%d\n", imaplen);
}
The issue is that the interrupt-map table point (imap) needs to be
incremented over the parent unit interrupt specifier which is
newintsize cells, not newaddrsize + newintsize cells. The invalid
calculation would cause the pointer to get mis-aligned and thus only
the first interrupt entry would ever get properly checked for a match.
It looks like of_irq_parse_raw() is only called from
of_irq_parse_pci() which prior to Lucas' patch was only called from
pci_read_irq_line() called from pcibios_setup_device() used in
arch/arm/powerpc, so perhaps this function isn't widely used
explaining why the bug was never caught.
I'll post a patch shortly with the above fix.
>> [1.841972] irq_create_of_mapping: calling xlate for 123/4/0 3
>
> And it is the wrong data.. 123/4/0 is
right - this is shifted because of the issue above.
With the above patch Lucas' original patch now operates correctly to
resolve the 4 legacy PCI interrupts required when using a P2P bridge
on the IMX6.
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Mon, Mar 03, 2014 at 03:40:43PM -0800, Tim Harvey wrote: > of_irq_parse_and_map_pci(). The GIC function that translates the > interrupt per domain is given irq_data: 0x123 0x04 0x00 This has been shifted by 1 byte.. > IRQ 123, which should get 32 added to it for irq155). Instead, the > implementation of gic_irq_domain_xlate() > (http://lxr.missinglinkelectronics.com/linux/drivers/irqchip/irq-gic.c#L832) > adds 32 to the 0x04 returning 20: > [1.841781] of_irq_parse_raw: /soc/pcie@0x0100:0001 > [1.841813] of_irq_parse_raw: ipar=/soc/pcie@0x0100, size=1 > [1.841838] -> addrsize=3 > [1.841870] -> match=1 (imaplen=28) ^ That looks odd, it should be the number of dwords in the interrupt-map, you have 4 lines of 8 dwords each, so it should be 32. You have 7*4, which really suggests to me that your interrupt-map is corrupted somehow, are you sure you are using this: > interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, > <0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, > <0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, > <0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; If an element was missing it would explain why everything is broken, in fact if GIC_SPI was missing it would match the debug perfectly. > [1.841903] -> newintsize=3, newaddrsize=1 > [1.841916] -> imaplen=23 > [1.841928] -> new parent: /interrupt-controller@00a01000 > [1.841946] -> got it ! K.. > [1.841972] irq_create_of_mapping: calling xlate for 123/4/0 3 And it is the wrong data.. 123/4/0 is > For the slots above that swizzle to pin2,3,4 of_irq_parse_raw() > returns -EINVAL because for some reason it can't match an interrupt > mapping for the pcie host controller: > [1.842996] of_irq_parse_raw: /soc/pcie@0x0100/pcie@0,0:0002 > [1.843046] of_irq_parse_raw: ipar=/soc/pcie@0x0100, size=1 > [1.843070] -> addrsize=3 > [1.843100] -> match=0 (imaplen=28) > ^ indicates no match in interrupt map. Well, since we know the map is corrupted somehow, it isn't surprising that the 2nd entry won't match anything. It is probably matching against '0 0 2 &intc' Jason -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Mon, Mar 3, 2014 at 9:49 AM, Tim Harvey wrote:
> On Mon, Mar 3, 2014 at 12:11 AM, Jingoo Han wrote:
>> On Sunday, March 02, 2014 3:31 AM, Jason Gunthorpe wrote:
>>> On Fri, Feb 28, 2014 at 04:53:33PM -0800, Tim Harvey wrote:
>>>
> The configuration I'm testing is:
> root@OpenWrt:/# lspci -n
> 00:00.0 0604: 16c3:abcd (rev 01)
> 01:00.0 0604: 10b5:8609 (rev ba)
> 01:00.1 0880: 10b5:8609 (rev ba)
> 02:01.0 0604: 10b5:8609 (rev ba)
> 02:04.0 0604: 10b5:8609 (rev ba)
> 02:05.0 0604: 10b5:8609 (rev ba)
> 02:06.0 0604: 10b5:8609 (rev ba)
> 02:07.0 0604: 10b5:8609 (rev ba)
> 02:08.0 0604: 10b5:8609 (rev ba)
> 02:09.0 0604: 10b5:8609 (rev ba)
> 07:00.0 0280: 168c:002b (rev 01)
> 08:00.0 0200: 11ab:4380
> root@OpenWrt:/# lspci -tnv
> -[:00]---00.0-[01-09]--+-00.0-[02-09]--+-01.0-[03]--
>| +-04.0-[04]--
>| +-05.0-[05]--
>| +-06.0-[06]--
>| +-07.0-[07]00.0 168c:002b
>| +-08.0-[08]00.0 11ab:4380
>| \-09.0-[09]--
>\-00.1 10b5:8609
>
>
> The dev_info showing what of_irq_parse_and_map_pci() above produces:
> [1.818485] pci :00:00.0: dw_pcie_map_irq: 16c3:abcd slot0 pin1 irq20
> [1.818703] pci :01:00.0: dw_pcie_map_irq: 10b5:8609 slot0 pin1 irq20
> [1.818939] pci :01:00.1: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
> [1.819179] pci :02:01.0: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
> [1.819395] pci :02:04.0: dw_pcie_map_irq: 10b5:8609 slot0 pin1 irq20
> [1.819631] pci :02:05.0: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
> [1.819859] pci :02:06.0: dw_pcie_map_irq: 10b5:8609 slot0 pin3 irq0
> [1.820087] pci :02:07.0: dw_pcie_map_irq: 10b5:8609 slot0 pin4 irq0
> [1.820404] pci :02:08.0: dw_pcie_map_irq: 10b5:8609 slot0 pin1 irq20
> [1.820650] pci :02:09.0: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
> [1.820881] pci :07:00.0: dw_pcie_map_irq: 168c:002b slot0 pin4 irq0
> [1.821100] pci :08:00.0: dw_pcie_map_irq: 11ab:4380 slot0 pin1 irq20
>
> I'm not clear why irq 20 is getting returned for all the slots with
> (slot%4)=0 and func=0. If I start debugging of_irq_parse_pci() I see
> that it walks up the tree until it gets to the pcie host controller
> then calls of_irq_parse_raw() which is returning irq20 or -EINVAL.
For the slots above that are swizzling to pin1 this appears to be an
issue with irq_create_of_mapping() called form
of_irq_parse_and_map_pci(). The GIC function that translates the
interrupt per domain is given irq_data: 0x123 0x04 0x00 (meaning GIC
IRQ 123, which should get 32 added to it for irq155). Instead, the
implementation of gic_irq_domain_xlate()
(http://lxr.missinglinkelectronics.com/linux/drivers/irqchip/irq-gic.c#L832)
adds 32 to the 0x04 returning 20:
[1.841781] of_irq_parse_raw: /soc/pcie@0x0100:0001
[1.841813] of_irq_parse_raw: ipar=/soc/pcie@0x0100, size=1
[1.841838] -> addrsize=3
[1.841870] -> match=1 (imaplen=28)
[1.841903] -> newintsize=3, newaddrsize=1
[1.841916] -> imaplen=23
[1.841928] -> new parent: /interrupt-controller@00a01000
[1.841946] -> got it !
[1.841972] irq_create_of_mapping: calling xlate for 123/4/0 3
[1.841984] irq_create_of_mapping got irq from xlate: 20
^ added debugging shows 3 u32's passed to xlate and returned value of 20
[1.841998] irq: irq_create_mapping(0xbec10400, 0x14)
[1.842009] irq: -> using domain @bec10400
[1.842021] irq: -> existing mapping on virq 20
[1.842032] irq_create_of_mapping created virq=20
[1.842042] irq_create_of_mapping returning virq=20
[1.842059] pci :00:00.0: dw_pcie_map_irq: 16c3:abcd slot0 pin1 irq20
Perhaps this is a byte-ordering issue? I'm wondering if the args
created in of_irq_parse_pci are getting put in the wrong place for
what irq_create_of_mapping() expects.
For the slots above that swizzle to pin2,3,4 of_irq_parse_raw()
returns -EINVAL because for some reason it can't match an interrupt
mapping for the pcie host controller:
[1.842996] of_irq_parse_raw: /soc/pcie@0x0100/pcie@0,0:0002
[1.843046] of_irq_parse_raw: ipar=/soc/pcie@0x0100, size=1
[1.843070] -> addrsize=3
[1.843100] -> match=0 (imaplen=28)
^ indicates no match in interrupt map.
I think this is because size=1 above, when we should see an
interrupt-map of size 4. I'm guessing that the function is confused
between the single interrupt in the DT for the host controller, vs the
interrupt-map for the PCI interrupts.
At this point, with no match, of_irq_parse_raw() will travel up to the
parent of the interrupt which is wrong.
Note the pcie host controller DT is:
pcie: pcie@0x0100 {
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
reg = <0x01ff
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Mon, Mar 03, 2014 at 09:49:52AM -0800, Tim Harvey wrote: > I'm not clear why irq 20 is getting returned for all the slots with > (slot%4)=0 and func=0. If I start debugging of_irq_parse_pci() I see > that it walks up the tree until it gets to the pcie host controller > then calls of_irq_parse_raw() which is returning irq20 or -EINVAL. Can you share your DT as well? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Mon, Mar 3, 2014 at 12:11 AM, Jingoo Han wrote:
> On Sunday, March 02, 2014 3:31 AM, Jason Gunthorpe wrote:
>> On Fri, Feb 28, 2014 at 04:53:33PM -0800, Tim Harvey wrote:
>>
>> > In testing this on IMX6 I'm finding that 'of_irq_parse_and_map_pci()'
>> > always returns -EINVAL because it can't find a dt node for the host
>> > bridge:
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_pci_irq.c#n60.
>>
>> There may be some kind of issue in the pcie-designware.c:
>>
>> static struct pci_bus *dw_pcie_scan_bus(int nr, struct pci_sys_data *sys)
>> {
>> struct pci_bus *bus;
>> struct pcie_port *pp = sys_to_pcie(sys);
>>
>> if (pp) {
>> pp->root_bus_nr = sys->busnr;
>> bus = pci_scan_root_bus(NULL, sys->busnr, &dw_pcie_ops,
>> ^^^
>> Shouldn't be null for DT cases.
>>
>> Perhaps since the driver doesn't pass in a parent pointer, no parent
>> device is associated with the struct pci_bus that gets created, so
>> pci_bus_to_OF_node will always fail and the DT PCI mechanisms become
>> broken.
>
> Jason,
> Thank you for your advice. :-)
Jason,
Yes thank you - this does eliminate the -EINVAL from
of_irq_parse_pci() but something still is wrong (see below)
>
> Tim,
> I tested the following as Jason guided.
Jingoo,
Did you test this on in a configuration where devices are behind a
PCIe switch? I'm still not getting the right IRQ's for that
configuration.
I'm working with the following patch:
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designwa
index 3e0c2af..a563a8d 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -493,7 +493,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
dw_pci.nr_controllers = 1;
dw_pci.private_data = (void **)&pp;
- pci_common_init(&dw_pci);
+ pci_common_init_dev(pp->dev, &dw_pci);
pci_assign_unassigned_resources();
#ifdef CONFIG_PCI_DOMAINS
dw_pci.domain++;
@@ -726,7 +726,7 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct pci_s
if (pp) {
pp->root_bus_nr = sys->busnr;
- bus = pci_scan_root_bus(NULL, sys->busnr, &dw_pcie_ops,
+ bus = pci_scan_root_bus(pp->dev, sys->busnr, &dw_pcie_ops,
sys, &sys->resources);
} else {
bus = NULL;
@@ -742,6 +742,8 @@ static int dw_pcie_map_irq(const struct pci_dev *dev, u8 slo
int irq;
irq = of_irq_parse_and_map_pci(dev, slot, pin);
+ dev_info(&dev->dev, "%s: %04x:%04x slot%d pin%d irq%d\n",
+ __func__, dev->vendor, dev->device, slot, pin, irq);
if (!irq)
irq = pp->irq;
The configuration I'm testing is:
root@OpenWrt:/# lspci -n
00:00.0 0604: 16c3:abcd (rev 01)
01:00.0 0604: 10b5:8609 (rev ba)
01:00.1 0880: 10b5:8609 (rev ba)
02:01.0 0604: 10b5:8609 (rev ba)
02:04.0 0604: 10b5:8609 (rev ba)
02:05.0 0604: 10b5:8609 (rev ba)
02:06.0 0604: 10b5:8609 (rev ba)
02:07.0 0604: 10b5:8609 (rev ba)
02:08.0 0604: 10b5:8609 (rev ba)
02:09.0 0604: 10b5:8609 (rev ba)
07:00.0 0280: 168c:002b (rev 01)
08:00.0 0200: 11ab:4380
root@OpenWrt:/# lspci -tnv
-[:00]---00.0-[01-09]--+-00.0-[02-09]--+-01.0-[03]--
| +-04.0-[04]--
| +-05.0-[05]--
| +-06.0-[06]--
| +-07.0-[07]00.0 168c:002b
| +-08.0-[08]00.0 11ab:4380
| \-09.0-[09]--
\-00.1 10b5:8609
The dev_info showing what of_irq_parse_and_map_pci() above produces:
[1.818485] pci :00:00.0: dw_pcie_map_irq: 16c3:abcd slot0 pin1 irq20
[1.818703] pci :01:00.0: dw_pcie_map_irq: 10b5:8609 slot0 pin1 irq20
[1.818939] pci :01:00.1: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
[1.819179] pci :02:01.0: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
[1.819395] pci :02:04.0: dw_pcie_map_irq: 10b5:8609 slot0 pin1 irq20
[1.819631] pci :02:05.0: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
[1.819859] pci :02:06.0: dw_pcie_map_irq: 10b5:8609 slot0 pin3 irq0
[1.820087] pci :02:07.0: dw_pcie_map_irq: 10b5:8609 slot0 pin4 irq0
[1.820404] pci :02:08.0: dw_pcie_map_irq: 10b5:8609 slot0 pin1 irq20
[1.820650] pci :02:09.0: dw_pcie_map_irq: 10b5:8609 slot0 pin2 irq0
[1.820881] pci :07:00.0: dw_pcie_map_irq: 168c:002b slot0 pin4 irq0
[1.821100] pci :08:00.0: dw_pcie_map_irq: 11ab:4380 slot0 pin1 irq20
I'm not clear why irq 20 is getting returned for all the slots with
(slot%4)=0 and func=0. If I start debugging of_irq_parse_pci() I see
that it walks up the tree until it gets to the pcie host controller
then call
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Sunday, March 02, 2014 3:31 AM, Jason Gunthorpe wrote:
> On Fri, Feb 28, 2014 at 04:53:33PM -0800, Tim Harvey wrote:
>
> > In testing this on IMX6 I'm finding that 'of_irq_parse_and_map_pci()'
> > always returns -EINVAL because it can't find a dt node for the host
> > bridge:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_pci_irq.c#n60.
>
> There may be some kind of issue in the pcie-designware.c:
>
> static struct pci_bus *dw_pcie_scan_bus(int nr, struct pci_sys_data *sys)
> {
> struct pci_bus *bus;
> struct pcie_port *pp = sys_to_pcie(sys);
>
> if (pp) {
> pp->root_bus_nr = sys->busnr;
> bus = pci_scan_root_bus(NULL, sys->busnr, &dw_pcie_ops,
> ^^^
> Shouldn't be null for DT cases.
>
> Perhaps since the driver doesn't pass in a parent pointer, no parent
> device is associated with the struct pci_bus that gets created, so
> pci_bus_to_OF_node will always fail and the DT PCI mechanisms become
> broken.
Jason,
Thank you for your advice. :-)
Tim,
I tested the following as Jason guided.
You can test i.MX PCIe with this.
./drivers/pci/host/pcie-designware.c
@@ -726,7 +727,7 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct
pci_sys_data *sys)
if (pp) {
pp->root_bus_nr = sys->busnr;
- bus = pci_scan_root_bus(NULL, sys->busnr, &dw_pcie_ops,
+ bus = pci_scan_root_bus(pp->dev, sys->busnr, &dw_pcie_ops,
sys, &sys->resources);
} else {
bus = NULL;
However, I think that we may need to replace 'pci_common_init()'
with 'pci_common_init_dev()'.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Fri, Feb 28, 2014 at 04:53:33PM -0800, Tim Harvey wrote:
> In testing this on IMX6 I'm finding that 'of_irq_parse_and_map_pci()'
> always returns -EINVAL because it can't find a dt node for the host
> bridge:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_pci_irq.c#n60.
There may be some kind of issue in the pcie-designware.c:
static struct pci_bus *dw_pcie_scan_bus(int nr, struct pci_sys_data *sys)
{
struct pci_bus *bus;
struct pcie_port *pp = sys_to_pcie(sys);
if (pp) {
pp->root_bus_nr = sys->busnr;
bus = pci_scan_root_bus(NULL, sys->busnr, &dw_pcie_ops,
^^^
Shouldn't be null for DT cases.
Perhaps since the driver doesn't pass in a parent pointer, no parent
device is associated with the struct pci_bus that gets created, so
pci_bus_to_OF_node will always fail and the DT PCI mechanisms become
broken.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Fri, Feb 28, 2014 at 9:28 AM, Lucas Stach wrote: > This series cleans up the PCI irq mapping for all > the ARM PCI host drivers, so they handle it in the > way defined in the common PCI bindings. > > Testing appreciated. > > Lucas Stach (7): > ARM: dts: tegra: add PCIe interrupt mapping properties > PCI: tegra: use new OF interrupt mapping when possible > PCI: rcar: use new OF interrupt mapping when possible > ARM: dts: exynos5440: fix PCIe interrupt mapping > ARM: dts: imx6: add PCIe interrupt mapping properties > PCI: designware: use new OF interrupt mapping when possible > PCI: designware: split samsung and fsl bindings > > .../devicetree/bindings/pci/designware-pcie.txt| 69 + > .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 48 +++ > .../bindings/pci/nvidia,tegra20-pcie.txt | 8 +++ > .../bindings/pci/samsung,exynos5440-pcie.txt | 70 > ++ > arch/arm/boot/dts/exynos5440.dtsi | 4 +- > arch/arm/boot/dts/imx6qdl.dtsi | 11 > arch/arm/boot/dts/tegra20.dtsi | 4 ++ > arch/arm/boot/dts/tegra30.dtsi | 4 ++ > drivers/pci/host/pci-rcar-gen2.c | 8 ++- > drivers/pci/host/pci-tegra.c | 7 ++- > drivers/pci/host/pcie-designware.c | 8 ++- > 11 files changed, 168 insertions(+), 73 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > create mode 100644 > Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt > > -- > 1.8.5.3 > Lucas, In testing this on IMX6 I'm finding that 'of_irq_parse_and_map_pci()' always returns -EINVAL because it can't find a dt node for the host bridge: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_pci_irq.c#n60. So it seems there is still something missing in the imx6 devicetree regarding a 'host bridge'? Is this solution expecting the range/interrupt data from the PCI host controller to be encapsulated in a host-bridge node such as http://lxr.missinglinkelectronics.com/linux/Documentation/devicetree/bindings/pci/ralink,rt3883-pci.txt#L124? If so, thats not how the imx6 host controller node is currently defined. In my particular test case I have a baseboard with a socket on it and a PLX PEX860x PCIe switch on an add-in card. So I don't think it makes sense to me to describe the add-in card in the baseboard DT - that wouldn't be very plug-n-play. By the way, I'm not referring to the add-in card with the TI-XIO2001 PCIe-to-PCI bridge with the mismapped IRQ's - I'm aware that I would need to deal with that somehow in devicetree (still trying to understand how). Thanks, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Friday 28 February 2014, Lucas Stach wrote: > This series cleans up the PCI irq mapping for all > the ARM PCI host drivers, so they handle it in the > way defined in the common PCI bindings. > > Testing appreciated. > > Lucas Stach (7): > ARM: dts: tegra: add PCIe interrupt mapping properties > PCI: tegra: use new OF interrupt mapping when possible > PCI: rcar: use new OF interrupt mapping when possible > ARM: dts: exynos5440: fix PCIe interrupt mapping > ARM: dts: imx6: add PCIe interrupt mapping properties > PCI: designware: use new OF interrupt mapping when possible > PCI: designware: split samsung and fsl bindings Patches 1-6 Acked-by: Arnd Bergmann For the last patch, the clock information looks like it needs to be fixed. I realize that you are just documenting what the driver is using at the moment, but that is not a proper way of establishing a binding. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] PCI irq mapping fixes and cleanups
This series cleans up the PCI irq mapping for all the ARM PCI host drivers, so they handle it in the way defined in the common PCI bindings. Testing appreciated. Lucas Stach (7): ARM: dts: tegra: add PCIe interrupt mapping properties PCI: tegra: use new OF interrupt mapping when possible PCI: rcar: use new OF interrupt mapping when possible ARM: dts: exynos5440: fix PCIe interrupt mapping ARM: dts: imx6: add PCIe interrupt mapping properties PCI: designware: use new OF interrupt mapping when possible PCI: designware: split samsung and fsl bindings .../devicetree/bindings/pci/designware-pcie.txt| 69 + .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 48 +++ .../bindings/pci/nvidia,tegra20-pcie.txt | 8 +++ .../bindings/pci/samsung,exynos5440-pcie.txt | 70 ++ arch/arm/boot/dts/exynos5440.dtsi | 4 +- arch/arm/boot/dts/imx6qdl.dtsi | 11 arch/arm/boot/dts/tegra20.dtsi | 4 ++ arch/arm/boot/dts/tegra30.dtsi | 4 ++ drivers/pci/host/pci-rcar-gen2.c | 8 ++- drivers/pci/host/pci-tegra.c | 7 ++- drivers/pci/host/pcie-designware.c | 8 ++- 11 files changed, 168 insertions(+), 73 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
