Dear Jason Gunthorpe, On Thu, 20 Feb 2014 10:35:18 -0700, Jason Gunthorpe wrote: > On Thu, Feb 20, 2014 at 09:55:18AM +0100, Thomas Petazzoni wrote: > > > Does that make sense? Keep in mind that I'm still not completely > > familiar with the PCI terminology, so maybe the above explanation does > > not use the right terms. > > Stated another way, the Marvel PCI-E to PCI-E bridge config space has > a quirk that requires the window BARs to be aligned on their size and > sized to a power of 2. Correct. > The first requirement is already being handled by hooking through > ARM's 'align_resource' callback. Absolutely. > One avenue would be to have mvebu_pcie_align_resource return a struct > resource and manipulate the size as well. Assuming the PCI core will > accommodate that. That would effectively be the easiest solution from the point of view of the PCIe driver. In practice, the story is a little bit more subtle than that: the PCIe driver may want to decide to either tell the PCI core to enlarge the window BAR up to the next power of two size, or to dedicate two windows to it. For example: * If the PCI core allocates a 96 KB BAR, we clearly want it to be enlarged to 128 KB, so that we have to create a single window for it. * However, if the PCI core allocates a 192 MB BAR, we may want to instead create two windows: a first one of 128 MB and a second one of 64 MB. This consumes two windows, but saves 64 MB of physical address space. (Note that I haven't tested myself the creation of two windows for the same target device, but I was told by Lior that it should work). As you can see from the two examples above, we may not necessarily want to enforce this power-of-two constraint in all cases. We may want to accept a non-power-of-2 size in the case of the 192 MB BAR, and let the mvebu-mbus driver figure out that it should allocate several consecutive windows to cover these 192 MB. But to begin with, rounding up all window BARs up to the next power of two size would be perfectly OK. Jason, would you mind maybe replying to Bjorn Helgaas email (Thu, 20 Feb 2014 12:18:42 -0700) ? I believe that a lot of the misunderstanding between Bjorn and me is due to the fact that I don't use the correct PCI terminology to describe how the Marvell hardware works, and how the Marvell PCIe driver copes with it. I'm sure you would explain it in a way that would be more easily understood by someone very familiar with the PCI terminology such as Bjorn. Thanks a lot! Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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
