On Fri, Jun 22, 2012 at 7:03 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Friday 22 June 2012, Thierry Reding wrote: >> On Fri, Jun 22, 2012 at 05:46:52AM -0600, Bjorn Helgaas wrote: >> > On Fri, Jun 22, 2012 at 5:00 AM, Thierry Reding >> > <thierry.reding@xxxxxxxxxxxxxxxxx> wrote: >> > >> Is the bus number aperture included somewhere? How do we know what >> > >> bus numbers are available for allocation under each bridge? >> > > >> > > Not yet. I don't think DT imposes a bus number allocation on PCI >> > > bridges. However the matching of DT nodes to PCI bridges is done based >> > > on the bus number. For that you provide a bus-ranges property which >> > > defines the bus aperture of the given PCI bridge. The DT matching code >> > > compares the first cell of this property with the primary bus number of >> > > the bridge. >> > >> > I don't fully understand this, but I can tell you that things don't >> > work very well if we don't know the aperture. We can make >> > assumptions, like the root bus is 00, and then enumerate everything >> > reachable from there. But then all we know is the largest bus number >> > actually reachable from bus 00, which is usually smaller then the end >> > of the aperture. We don't know how many unused bus numbers there are >> > in the aperture, so we can't safely allocate any for hot-added >> > devices. > > I believe the assumption today is that all bus numbers are ok on each > root port, which is usually the case. There was something about a Power > Mac that faked a single PCI bus number space across both an AGP and > a PCIe domain in pmac_pci_fixup_u4_of_node(), but I think that is the > exception. > > Is there any requirement to use a bus aperture on non-PC hardware? The requirement (if there is one) isn't anything related to PC-ness. I just don't understand how things can actually work if two host bridges both claim the same bus number. If we do a config read to that bus, both bridges should claim it and turn it into config cycles on their respective root buses, and we should get two responses. I would expect the second response to cause an "unexpected response" machine check or similar. Beyond that, Yinghai's recent "busn-alloc" work (now in my -next branch) tracks bus number assignments using a struct resource tree, and that obviously won't work with overlaps. Here's one of the relevant commits: http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=commitdiff;h=5cc62c202211096ec26309722ec27455d52c8726 >> I think DT support for PCI is lacking in a lot of areas. PowerPC seems >> to be the only architecture actively setting up busses according to the >> bus-range property specified in the DT. All other architectures seem to >> not pre-allocate bus apertures and go with the default instead. From >> what you say that means hot-plugging is out. Although I don't think the >> Tegra PCIe controller even supports hot-plugging. > > If the default is allowing any bus numbers, and that matches the > hardware capabilities, I think hot-plugging would work. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
