On Tue, 31 Dec 2002 21:07:45 +0100 (CET), Jimi wrote:
>Well, I assumed there would be only 1 bridge at all and that resource window would
>need to get used for all
>devices on cardbus.
Well, there may be only one bridge chip but usually it has two PCI
functions implemented - one for each PCCard/Cardbus socket. My DELL
notebook at work has three sockets and two Cardbus chips with a total
of three bridge functions.
>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.
>Anyway, I think it would still be neat to detect the devices (and names) and put
>those into detection
>area (for e.g. some sort of hotplug-manager).
Fine.
>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
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)
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!
Thus, to make a long story short: without a proper PCI bus number
window setup you can't configure PCI/AGP/Cardbus devices behind the
bridge.
Ciao,
Dani
PS: I wish you all A Happy New Year!
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
