Dear Rob Herring,

On Mon, 10 Dec 2012 17:24:44 -0600, Rob Herring wrote:

quoted

Marvell SoCs have up to 20 configurable address windows, which allow
you, at run time, to say "I would like the range from physical
address 0xYYYYYYYY to 0xZZZZZZZZ to correspond to the PCIe device
in port 1, lane 2, or to the NAND, or to this or that device".
Therefore, in the PCIe driver I proposed for the Armada 370/XP SoCs
[1], there is no need to encode all those ranges statically in the
DT.

That's not a unique feature. I'm not sure if any powerpc systems do
that though.

Yes, probably not an unique feature.

quoted

The only "ranges" property I'm using is to allow the DT sub-nodes
describing each PCIe port/lane to access the CPU registers that
allow to see if the PCIe link is up or down, access the PCI
configuration space and so on. So all ranges in my "ranges"
property correspond to normal CPU registers, like the one you would
put in the "reg" property for any device. The fact that those
devices are PCIe is really orthogonal here.

That doesn't really sound right.

Very likely, but I still don't get what is "the right way".

I don't think deviating from the normal binding is the right approach.
Perhaps the host driver should fill in the ranges property with the
addresses it uses. Then any child devices will get the right address
translation.

I don't really understand what you mean here. If you look at the host
driver code (arch/arm/mach-mvebu/pcie.c), for each PCIe interface
is simply does:

 * Create an address decoding window for the memory BAR
 * Create an address decoding window for the I/O BAR
 * Associate the memory BAR window address and the I/O bar window
   address with the PCIe interface

And that's it. See
https://github.com/MISL-EBU-System-SW/mainline-public/blob/marvell-pcie-v1/arch/arm/mach-mvebu/pcie.c#L107.

So this driver is both "deciding" of the physical addresses for each
PCIe interface, and "associating" them with the PCIe interfaces. How is
it useful to feed some addresses back into the Device Tree?

Also, while the h/w may support practically any config, there are
practical constraints of what Linux will use like there's no reason to
support more than 64K i/o space. PCI memory addresses generally start
at 0x100000. You probably don't need more than 1 memory window per
root complex (although prefetchable memory may also be needed).

I allocate one 64K I/O window and one memory window per PCIe interface
whose link is up (i.e a PCIe device is connected).

You could let the DT settings drive the address window configuration.

No, because I don't want to have absolute addresses for the windows: I
have 10 PCIe interfaces, but often, only a few of them are used. So I
don't want in the Device Tree to over-allocate hundreds of MB of
physical address space if it's not useful.

PCIe is dynamic, address window configuration is dynamic. And we should
hardcode all this configuration statically in the DT? Doesn't seem like
the right solution.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com