On Tue, Jan 29, 2013 at 12:18 PM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. Oh, so the actual *root port* itself doesn't conform to the spec? Wow, that's worse than I expected. Then I guess you have emulate it and make sure its config space is complete enough and functional enough so that all the link management, power management, AER, etc., code in the core works as well as it would with a conforming device. >> 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
