pci <-> device node mapping

[linas at austin.ibm.com]

On Wed, Jun 18, 2003 at 07:47:21AM +1000, Anton Blanchard wrote:
>
> > This is an unrelated issue, but what is the story for numbering/renumbering
> > PCI Id's?  In kernel-2.4.19, PHB's seem to chew up 256 PCI id's (for 4 slots)
> > and there are some machine configurations which have nearly a hundred PHB's.
> >
> > In one unhappy situation, we had a machine with a graphics card which
> > ended up with a PCI Id of 4097, and the default X11 couldn't find it,
> > and so X wouldn't run.  For some reason, X feels a need to scan the
> > PCI bus.  Changing X to scan up to 19,000 bus ID's (the theoretical
> > max for this box) caused X to take 20 seconds to come up.
>
> Yuck. Check out the thread on linux-kernel called "pci_domain_nr vs.
> /sys/devices". We are hashing out the final bits of pci domains which
> should solve that problem.
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=20030611150020%243d80%40gated-at.bofh.it

I read it, but I don't know enough about PCI to follow the discussion.
Does a PHB map to a PCI domain?  As mentioned above some current
machines will get something like 50 or 100 PHB's (48 or 64 or 96,
I would have to root around for the details), I'm presuming the
various participants are aware of this?

The other factoid, I guess you're probably aware of this, but the
slots with EADS seem to have the bus numbers spaced out so that
bus ID's were 32 apart. I don't know why it needs to be so sparse,
I thought I heard somebody utter the words 'hot plug' in the same
breath, but I'm no longer sure.

As long as the pci-hackers on LKML know about these order-of-magnitude
numbers & thier sparseness, I will assume I'm in good hands and that
the new code really will account for this, right?

--linas

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