On Tue, Jan 29, 2013 at 12:07:00PM -0700, Bjorn Helgaas wrote: > > So when I say set aside, I mean for instance, the PCI-E entry in DT > > has 128M of physical address space marked for PCI MMIO use. The kernel > > does PCI resource allocation and the HW decoders in each link will be > > set to claim some portion of the 128M - based on the MMIO windows > > programmed on the PCI-PCI root port bridges. The reamining part of the > > 128M is dead address space, not claimed by any hardware block at all. > > Thanks, this really helps get to the issue that the PCI core will care > about. The root ports look like normal bridges, so the core assumes > it can manage their windows as needed, as long as the windows stay > inside the host bridge apertures that are logically upstream from the > root ports. Yes, that is basically correct. This is what the PCI-E specification says the root complex/root port should look like and this is what some SOC hardware implements fully in hardware. The small wrinkle with Marvell is that the PCI-PCI bridge config space is created by the driver since the HW does not expose a standard config space. > In your example, it sounds like the 128M should be treated as the host > bridge aperture. Is there any reason not to do that? It sounds like > there's no place you can actually program that 128M region into the > hardware, and you would just program pieces of that region as root > port windows. But that should be OK from the core's perspective. AFAIK this is already what Thomas's driver is doing.. 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
