On Tue, Mar 12, 2013 at 09:38:19PM +0100, Thierry Reding wrote: > I've also verified that things actually do work with the binding that I > proposed for Tegra, even if I add device_type = "pci" to the root port > nodes. The reason is that the OF core looks up the type of the *parent* > node to find a matching bus. This happens to be the pcie-controller node > which is not a PCI device and therefore the address translation works > properly. Mitch pointed out early on that the parent node needs a 'device_type = "pci"' as well. The pcie-controller node would be classified as a 'bus node' according to the spec. Not going down the of_pci_* code paths for address translation at the root port bridge nodes is certainly not right. > ranges = <0x00000800 0 0 0x80000000 0 0x00001000 /* port 0 configuration space */ > 0x00001000 0 0 0x80001000 0 0x00001000 /* port 1 configuration space */ Section 12 says that the 'b,d,f' bits are 0 in ranges, so the above is in conflict with that language: In particular, the phys.hi fields of the child address spaces in the "ranges" property for PCI does not contain the same information as "reg" property entries within PCI nodes. The only information that is present in "ranges" phys.hi entries are the non-relocatable, prefetchable and the PCI address space bits for which the entry applies. I.e., only the n, p and ss bits are present; the bbbbbbbb, ddddd, fff and rrrrrrrr fields are 0. And the further requirement: When an address is to be mapped through a PCI bus bridge node, the phys.hi value of the address to be mapped and the child field of a "ranges" entry should be masked so that only the ss bits are compared. Which is embodied by the code in of_bus_pci_map, meaning the OF core won't even look at the bits in the high DW when searching ranges. Regards, Jason -- 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
