On Mon, Dec 10, 2012 at 08:03:50PM +0100, Thomas Petazzoni wrote:

quoted

00:00.0 Host bridge: SOC software emulated host bridge
00:01.1 PCI bridge: SOC software emulated PCI-E root port 1
00:01.2 PCI bridge: SOC software emulated PCI-E root port 2
00:02.0 Ethernet device..

With a tree like:
  00:00.0 -> 0:01.1
          -> 0:01.2 -> 00:02.0

Discovery is started from 00:00.0 and flows through all the ports in
one pass.

Hum, ok, this makes sense. I have no idea at the moment how to achieve
that, but I'll try to have a look. Do you have pointers to code doing
this?

I haven't studied the Linux code specifically for this, but a quick
perusal through the header file isn't showing up any existing support.

You'd have to confer with the PCI maintainers what they want, but a
possible way to start would be to fake the configuration query
results. This is already being done via a fixup to make the root port
report as a host bridge.

quoted

It sounds like the concept of a PCI-E bridge with internal
configuration could be generalized for more types of hardware that the
Marvell case. Pretty much all socs will have a similar design, a
number of PCI-E ports, a collection of address decoding/routing
windows and some registers to control them, someplace...

Indeed. But for example, in Marvell's case, the address decoding
windows mechanism is not specific to PCIe, it is also used for other
devices, so the management of those decoding windows cannot be entirely
left to the PCIe driver.

Yes, though you might want to think about having the window numbers
assigned staticly (for PCI-E and everything else) in device tree
rather than all the dynamic code. It would be simpler to just run
through the configuration that device tree has..

The window stuff is causing me problems today, I'm looking at an
option to have to kernel not program any windows. The kernel destroys
the settings from the bootloader, which are more correct than what it
puts in - in practice this means my kexec flow doesn't work since I
can't re-enter the bootload because the kernel unmapped it.

Jason