Musings on PCI busses

[Grant Likely]

On Wed, May 20, 2009 at 3:59 PM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
>> On Wed, May 20, 2009 at 1:24 PM, David Miller <davem at davemloft.net> wrote:
>> >> What do you mean by fully resolve ? IE. The issue above is specific to
>> >> IO space, which you can resolve both as MMIO, or as "IO" which in linux
>> >> means going through the special mapping for IO which allows the use of
>> >> the inX/outX instructions...
>> >
>> > I mean that all OF devices have fully resolved MMIO resources.  So
>> > very early serial devices that sit in I/O space on sparc64 end
>> > up being OF device drivers.  See for example, drivers/net/sunsu.c
>> > which is simply a 8250 chip that sits behind Sun's I/O space bus
>> > that sits on PCI and provides things normally found via ISA on
>> > x86 machines.  Another example is drivers/serial/sunsab.c
>>
>> Unfortunately in the embedded powerpc case we don't actually have real
>> OF.  We've only got the flattened device tree which usually doesn't
>> itemize the devices behind the PCI bus.  Instead we rely on the kernel
>> probing for them.
>
> We -can- itemize the PCI bus, it's up to you.

Yes, we could.  But I don't think it makes any sense to for the FDT
case.  The firmware infrastructure is not in place to fill out the
device tree with the PCI bus layout for the off board devices.

>
> That leads to another interesting discussion...
>
> On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
> from the OF tree (avoiding the config space probing entirely). This is
> very efficient and has some advantages such as avoiding touching the
> BARs for sizing (which mean avoiding to temporarily disable access to
> devices behind them, which can be useful when it's your serial port or
> system controller there) etc...
>
> It also have the advantage of avoiding a double PCI probe pass when the
> FW already did it and since most FW do ...
>
> I'm tempted to extract that code and stick it in a
> drivers/pci/probe_of.c or something like that for more generic usage. We
> also have a per-bus hook that allows to switch to "real" config space
> probing at any point of the hierarchy (for example, you can setup things
> so that only on-board devices are in OF and probed that away and
> anything on your slot gets probed by linux using config space, that sort
> of thing).

That would be interesting.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.