Musings on PCI busses

[Benjamin Herrenschmidt]

On Tue, 2009-05-19 at 09:28 -0600, Grant Likely wrote:

> 1) Probe the host controller in an of_platform driver.  This has the
> advantage of simplicity.  The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus.  The bus parenthood also gets reflected in
> the device model and sysfs.  The disadvantage is that it defers PCI
> bus probing until after the of_platform bus is probed (maybe this is
> okay; maybe this already happens anyway).

We are doing that on Cell as mentioned by Arnd. However, there are a
few issues with that approach. One is that it relies on PCI-hotplug
related bits that currently only exist in 64-bit land. Another is
that doing so tends to expose various hidden issues or subtle
dependencies to the PCI stuff being setup early and probed early.

For example, some of the OF parsing bits may fail to convert memory
addresses to IO addresses if the PCI host bridges have not been
discovered yet, potentially causing issues with matching of resources
between the early serial stuff and the generic serial driver (if you
use an IO driven UART, the PCI 8250 driver may not properly figure out
that what it's finding in its IO BARs is actually the same port as
what it gets from the platform code as the later will end up with
memory addresses rather than IO ones). That's one example.

At this stage, I much prefer if we stick to doing the PHB discovery
at setup_arch() time, especially since there's other WIP in the area
of PCI coming from Kumar and I don't want to mixup multiple source of
problems in that area at the same time.

We can revisit that later but we'll have to be very careful.

Cheers,
Ben.