[RFC v1] PCIe support for the Armada 370 and Armada XP SoCs

[Stephen Warren]

On 12/11/2012 12:52 AM, Thierry Reding wrote:
> On Mon, Dec 10, 2012 at 10:52:33AM -0700, Stephen Warren wrote:
>> On 12/07/2012 04:33 PM, Jason Gunthorpe wrote:
>>> On Fri, Dec 07, 2012 at 11:04:23PM +0100, Thomas Petazzoni
>>> wrote:
>>> 
>>>> * The most annoying problem is that when the hw_pci->setup() 
>>>> operation is called, we don't know the size of the memory and
>>>> I/O regions that each PCI device will need. And on Marvell
>>>> SoCs, for each PCI device, we have to set up an address
>>>> decoding window that associates a portion of the physical
>>>> address space with a given
>>> 
>>> I think a sane way to address this is to model the SOC as the
>>> root of the PCI-E and then model each of the ports as a
>>> non-compliant PCI-E bridge. The internal memory windows
>>> functionally map exactly to a PCI-E bridge memory window - just
>>> with annoyingly different register settings.
>> 
>> Mainly as background:
>> 
>> I /think/ Tegra has a similar HW setup (but perhaps not
>> identical) (based on a very brief reading of your emails and
>> brief knowledge of this aspect of the Tegra HW).
>> 
>> On Tegra, there is a 1GB physical address window that the PCIe 
>> controller serves. The controller has 2 or 3 ports, each a
>> separate PCIe domain I believe. There are registers in the PCIe
>> controller which route accessed made to the 1GB physical window
>> to the various child ports and transaction types.
> 
> No, the ports on Tegra are not separate PCIe domains. The
> configuration space mapping is shared between all ports and is
> programmed in the register space of the PCIe controller. This is
> what PCIe refers to as ECAM, only with a slightly incompatible
> mapping.

OK, so can you please remind me why the top-level PCIe controller node
has a child node for each port, with hard-coded non-intersecting
ranges for configuration space access? If they all go through the same
address range, and use standard PCI bridge registers to route
transactions to the separate ports, I would have expected no need for
explicit per-port sub-nodes or static address allocations.