pci and pcie device-tree binding - range No cells

[Thomas Petazzoni]

Dear Rob Herring,

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

> > 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.

> > 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