PCI probe code

[Benjamin Herrenschmidt]

>Ive been looking over our PCI probe code and it could do with a cleanup.
>It would be nice to make things simpler before PCI domains and PCI hotplug
>goes in. A recent bug I found suggests that our BAR reallocation code has
>always been buggy and I got to thinking...
>
>Can we assume that OF will always get the BAR allocation correct? If so
>then a bunch of code goes away. Even if this is not the case, we should
>be able to use the generic hooks a lot more than we currently do
>(eg we should probably use pci_assign_unassigned_resources)
>
>The question I have is how does iSeries handle BAR allocation?

I've been thinking about that for ppc32 as well, and encountered
various problems.

One of them is that OF will not assign BARs that aren't requested
by a card's OF driver (typically most ATI video cards with OF driver
will not request the IO BAR). The kernel wants all BARs assigned.
That leads into some problems as OF also tends to close the IO
region of PCI<->PCI bridges if no device below them has an assigned
IO BAR. I encoutered the case on the XServe where OF didn't assign
the IO BAR of the ATI card behind a PCI<->PCI bridge and closed that
bridge IO region (but kept a memory region of course). The kernel
tried to allocate that IO BAR, but failed becasue of the lack of the
IO region on the PCI<->PCI bridge. That's the reason why my tree
currently has some code to re-open IO regions, though that code is
probably not generic enough.

There are other issues with the code in setup-bus
(pci_assign_unassigned_resources and friends). Currently, on ppc32 at
least, pcibios_fixup_pbus_ranges() doesn't seem to be correct, thus
causing the setup-bus code to not properly deal with the various
offsets we have on some platforms.

Also, the code in setup-bus makes lots of assumptions about the layout
of resource in a pci_bus structure. Typically, it expects all busses
(including host busses, cardbus ones, etc...) to exactly follow the
layout of a PCI<->PCI bridge, that is resource 0 is IO, resource 1 is
MEM, and resource 2 is MEM+PREFETCH, period.

The result is that it doesn't deal properly with some setups I have
on pmac (dunno about you on chrp here) where a host bus may expose
several discontiguous MEM and no MEM+PREFETCH etc...

It would surely be nice to be able to "fix" setup-bus, though this
is a bit difficult as Ivan seems to be reluctant to adding genericity
to that code (he uses it on alpha afaik), I already had difficulties
getting him to accept that pci_read_bridge_bases should take care of
all 4 resource of the pci_bus structure when dealing with a transparent
bridge (a real one now that we fixed that code), he didn't fix it until
Linus himself told him he was wrong, so....

Ben.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/