On Tue, Jan 07, 2014 at 04:35:01PM +0100, Arnd Bergmann wrote: > > >> + 0x00000000 0x0 0xd0000000 0xe0 0xd0000000 0x0 0x00200000 /* cfg */ > > > > > > config space is not normally in the ranges property, and I think you will need > > > it in the pcie node itself as a 'reg' property so the code can access it. > > > > pcie-designware.c does it that way. I just followed their implementation. > > I don't remember what led to that, it still seems wrong and I can't > find anything in the PCI binding for host bridges telling their > config space this way. When we discussed the mvebu PCI driver (which is, so far, the most throughly discussed PCI binding) it was concluded that the config space ranges like the above was OK only if it exactly described the standard ECAM layout. Idea being that standard/core code should be able to see that ranges, map the range and issue config accesses via the ECAM rules. > > >> + interrupt-map-mask = <0x0 0x0 0x0 0x7>; > > >> + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1>; > > > > > > Only one IRQ for all devices? > > > > The node represents a port. I believe that Linux framework uses only > > one of the legacy IRQs per port. Rest all remain unused. Hence I > > removed them. Please correct me if I am wrong. > > Any PCI device can normally have four interrupts (IntA through > IntD), which are traditionally separate pins on a PCI bus, but get > emulated on PCIe. While it's not common for any normal device to use > more than one IRQ, a bridge device will swizzle these (virtual) IRQ > lines, so a device behind the bridge actually gets a different host > IRQ. Agree, the binding should handle all four INTA,B,C,D assertions delivered to the port. If HW is able to decode the 4 ints into seperate Linux interrupt numbers then that should be described. If HW routes them all to a single number then interrupt-map-mask should be all 0. Arnd's point about swizzling effects the layout of the interrupt-map. When it is placed at the pcie-controller node level the map will incorporate one swizzle of the on-the-wire INTx messages. If the HW doesn't swizzle the INTx as the TLP passes through the bridge then it probably makes more sense to put the interrupt-map in the DT node of the bridge like mvebu does. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
