On Wed, 01 Jan 2003 11:33:23 +0100 (CET), Daniela Engert wrote:
>>I won't configure anything at all in that case and leave it to the cardbus
>>driver.
>Exactly. Don't try to solve things which are already solved.
I didn't know that it was solved already, because I assumed it would work differently
:-)
>>BTW. why do you need to assign a PCI-bus to the cardbus controller device then? Or
>is this needed at
all??
>What most people call a PCI bus is in fact a tree of PCI buses. The
>root is the host-to-PCI bridge/s (there may be multiple) where PCI bus
>0 is dangling off. Desktop mobos with AGP have at least 2 buses (the
>AGP bus is sitting behind a PCI-to-AGP bridge). Today, there are often
I know this, but AGP is actually a PCI-to-PCI bridge. This one needs a PCI-bus
assigned of course.
>3 buses, PCI bus 0 is implemented as the HubLink (Intel), VLink (VIA),
>HyperTransport Channel (AMD, Nvidia), etc. and the "PCI BUS" visible to
>the user as actual slots is PCI bus 1. Think of the PCI bus tree as a
>directory tree, with non-bridge functions as regular files, and bridge
>functions as subdirectories.
>
>While it's pretty easy to route memory or IO space transactions up and
>down the tree from source to target, this doesn't hold true for
>configuration space transactions. There are special configuration space
>transaction types defined on a single PCI bus which PCI functions
>respond to, but the decoding if a particular config cycle has to take
>place on a given PCI bus has to be done by the bridge where the bus
>originates from. If so, a different signalling takes place for local
>config cycles (type 1 IIRC). All other configuration cycles need to be
>routed to the proper bridge function (by type 2 config cycles), and to
>do that you need a window of PCI bus numbers which are routed "down" to
>subordinate PCI buses by a PCI-to-anything bridge. So what't required:
>
>1) the number of the "upper" PCI bus a bridge sits on (primary bus)
>2) the number of the "lower" PCI bus "behind" a bridge (secondary bus)
>3) the highest PCI bus number "behind" a bridge (subordinate bus)
Ahhh.
That's what subordinate bus is. I tried to figure this out, but I found no explanation
anywhere.
>2) and 3) combined define the window of PCI bus numbers dangling off a
>particular bridge, and configuration cycles to these PCI buses has a
>bridge to forward down from upper PCI buses. The same is true in the
>opposite direction: config cycles originating from a lower bus (with a
>higher number) needs to be forwarded to upper buses except for the PCI
>bus the bridge itself sits on; in this case the bridge has to translate
>the routable type 2 config cycles into non-routable type 1 config
>cycles which non-bridge PCI functions respond to.
>Remember this scheme relies on a strong ordering of PCI bus numbers!
My current enumeration logic is as follows:
1) enumerate bus 0 and all already assigned buses (PCI2PCI bridges)
2) now check, if there were any unassigned PCI2PCI bridges
3) assign those and scan those freshly assigned buses
4) go 2 till no unassigned bridges are left anywhere
Is this logic okay or do I have to work exclusively on one freshly assigned bridge,
till there are no unassigned
bridges behind that bridge making all bus numbers to be behind each other.
e.g. (crazy example I know)
Bus 0 -> PCI2PCI Bridge -> PCI2PCI bridge -> NIC
-> PCI2PCI Bridge -> PCI2PCI bridge -> Soundcard
If all of those bridges are unassigned, my current way would be to assign bus 1 to the
1st bridge on bus 0 and
bus 2 to the 2nd bridge on bus 0. The bridge behind the NIC would get bus 3 and the
bridge behind the
soundcard would get bus 4.
Or should I work through all unassigned bridges in the whole making: 1st bridge -> bus
1. Bridge with NIC to
bus 2. 2nd bridge on bus 0 -> bus 3 and bridge with soundcard to bus 4?
As far as I understood the 2nd solution seems to be the right one.
Also I would really like to leave all assigned bridges (by BIOS) as they are. Is this
okay?
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
