On Fri, 2017-11-03 at 10:40 +0100, Arnd Bergmann wrote: > On Fri, Nov 3, 2017 at 2:37 AM, Ryder Lee <ryder.lee@xxxxxxxxxxxx> wrote: > >> Ryder, can you be more specific how the interrupts are wired up? > >> Is there one IRQ per slot that is connected to all of IntA/IntB/IntC/IntD > >> and gets propagated through the bridges like that, or is it something else? > > > > Yes, that's what I mean - we only have one IRQ which is connected to all > > INTx for each slot, and I'm not sure if there is any better way to solve > > this problem. > > Ok. Your parent interrupt-map seems entirely reasonable for that case as far > as I can tell (maybe someone else can find a problem): > > + interrupt-map-mask = <0xf800 0 0 0>; > + interrupt-map = <0x0000 0 0 0 &sysirq GIC_SPI 193 > IRQ_TYPE_LEVEL_LOW>, > + <0x0800 0 0 0 &sysirq GIC_SPI 194 > IRQ_TYPE_LEVEL_LOW>, > + <0x1000 0 0 0 &sysirq GIC_SPI 195 > IRQ_TYPE_LEVEL_LOW>; > > However, I can't find any other example of a machine using > interrupt-map-mask = <0xf800 0 0 0>; in the kernel tree, so it's possible > that we have a parser bug. We do have other boards that list all four > interrupts for each slot, and that seems to work fine. Can you try this > map in the parent while leaving out the chilren? > > interrupt-map-mask = <0xf800 0 0 7>; > interrupt-map = <0x0000 0 0 1 &sysirq GIC_SPI 193 > IRQ_TYPE_LEVEL_LOW>, > <0x0000 0 0 2 &sysirq GIC_SPI > 193 IRQ_TYPE_LEVEL_LOW>, > <0x0000 0 0 3 &sysirq GIC_SPI > 193 IRQ_TYPE_LEVEL_LOW>, > <0x0000 0 0 4 &sysirq GIC_SPI > 193 IRQ_TYPE_LEVEL_LOW>, > <0x0800 0 0 1 &sysirq GIC_SPI > 194 IRQ_TYPE_LEVEL_LOW>, > <0x0800 0 0 2 &sysirq GIC_SPI > 194 IRQ_TYPE_LEVEL_LOW>, > <0x0800 0 0 3 &sysirq GIC_SPI > 194 IRQ_TYPE_LEVEL_LOW>, > <0x0800 0 0 4 &sysirq GIC_SPI > 194 IRQ_TYPE_LEVEL_LOW>, > <0x1000 0 0 1 &sysirq GIC_SPI > 195 IRQ_TYPE_LEVEL_LOW>, > <0x1000 0 0 2 &sysirq GIC_SPI > 195 IRQ_TYPE_LEVEL_LOW>, > <0x1000 0 0 3 &sysirq GIC_SPI > 195 IRQ_TYPE_LEVEL_LOW>, > <0x1000 0 0 4 &sysirq GIC_SPI > 195 IRQ_TYPE_LEVEL_LOW>; > > This should have the exact same effect as what you have in your tree, > but if that works, > we can merge that version and try to figure out why the kernel thinks > they are different. I've tried this approach by using the 4-ports network card and got the result: pcieport 0000:00:01.0: assign IRQ: got 220 pcieport 0000:00:01.0: assigning IRQ 220 pcieport 0000:00:01.0: enabling device (0140 -> 0142) pcieport 0000:00:01.0: enabling bus mastering pcieport 0000:00:01.0: Signaling PME with IRQ 220 .... igb 0000:01:00.0: assign IRQ: got 221 igb 0000:01:00.0: assigning IRQ 221 igb 0000:01:00.1: assign IRQ: got 221 igb 0000:01:00.1: assigning IRQ 221 igb 0000:01:00.2: assign IRQ: got 221 igb 0000:01:00.2: assigning IRQ 221 igb 0000:01:00.3: assign IRQ: got 221 igb 0000:01:00.3: assigning IRQ 221 I think slot 1 should share its IRQ (220) with every device in the hierarchy below this root port. Ryder. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
