Dr. Dave wrote:So, I tried the AUA-3020 on a Fuel, no dice - but it apparently works on an O2. So of course that got me to thinking...
I had a QLA2212 here (which also does not work on a Fuel), the reason being that the AUA3020 and the QLA2212 (basically 2 QLA2200's-on-a-card) both use PCI bridge chips to map two devices into a single PCI slot, and apparently PCI bridge chips do not play well with XIO-based systems.
XIO machines may very well have problems, but it seems like SGI has gone to quite a bit of trouble to write a PCI-PCI bridge driver for XIO/Bridge PCI busses. A relevant note from /var/sysgen/mtune/kernel:
Code: Select all
* As of 6.5.19, general support for PCI-PCI bridges was added with the
* pciio_ppb driver. This can expose the well known RRB thrashing issue that
* Bridge and its derivatives (Xbridge and PIC-in-PCI-mode) exhibit.
* By default, pciio_ppb will disallow any PPB hierarchy hung off of a Bridge
* slot which contains more than one function advertising DMA master ability,
* generating a console message.
* When set to non-zero, pciio_multimaster_override will override this
* behavior and allow an arbitrary PPB hierarchy to be built up on Bridge.
pciio_multimaster_override 0 0 1
Looking through the 6.5.19 release notes
, I couldn't find any specific hardware fixes in 6.5.19 that would have warranted this driver. The only big change was adding support for the O3900, which maybe has some PCI-PCI bridged hardware.
There wasn't much mention of pciio_ppb on Google, but one hit was extremely interesting: an LKML post from SGI
with a bunch of Linux IA64 src to be put into 2.6. The reply is scathing:
Guy you drive me nuts with your silly hack it up on irix and
glue it into linux strategy!
And indeed, the code is straight out of Irix, and grafted onto Linux in a less-than-pretty way. For example, this massive 1MB patch
contains the entire source for the pciio_ppb driver. The code still uses IRIX's vertex_hdl_t type, which maps perfectly onto IRIX's hwgraph, but I have no idea they made it map onto Linux. For posterity, I'll post the pciio_ppb header here:
+ * Fairly generic PCI-PCI Bridge (PPB) driver module.
+ * This driver implements provider-independent PPB support for Irix.
+ * Goals
+ * =====
+ * Transparantly provide pciio services to PCI devices downstream of a PPB
+ * hierarchy.
+ * Implement as a provider-independent module.
+ * Design
+ * ======
+ * For the most part, devices behind a PPB are used in the same way as devices
+ * directly connected to a host bus. Drivers are written using the guidelines
+ * set forth in the device drivers programming guide. The most notable
+ * exception is that some providers might not allow config space pio maps to
+ * devices residing on secondary busses because of shared address space when
+ * accessing these devices.
+ * Other restrictions might come into play if devices behind a PPB request
+ * resources or mappings which are not compatable with each other when you
+ * consider that all subordinate devices originate at a common host slot. An
+ * example might be interrupt routing using DEVICE_ADMIN statements.
+ * All subordinate bus numbers in the system come from a shared pool, at start
+ * at 16. Bus numbers < 16 are left to the providers. A future modification to
+ * this code might move bus number allocation to be a per-provider function.
+ * While this code should be provider-independent, no attempt was made to
+ * retrofit this to O2. The O2 already had PPB support, and it did not seem
+ * worth the risk to break customer code that might relay on how O2 works.
+ * No attempt was made to restrict the configuration for the well-known
+ * bridge/xbridge issue of RRB thrashing when there are multiple PCI masters
+ * doing reads from a single bridge. The reasoning is that there is no easy way
+ * to tell if downstream PCI masters intend to do host DMA or not. It is
+ * perfectly ok to allow multiple masters doing device-to-device traffic.
+ * Provider implementations must make the following accomodations for this
+ * driver to work correctly:
+ * When accessing config space (pciio_config_get()/pciio_config_set())
+ * the provider should examine the pciio_info_t of the passed vhdl
+ * to determine if TYPE1 addressing should be used. This can be checked
+ * by pciio_info_type1_get() returning non-zero. This means that
+ * the bus/slot/function to be used are encoded in the address
+ * to be read/written, and the macros PCI_TYPE1_BUS,
+ * PCI_TYPE1_SLOT, and PCI_TYPE1_FUNC should be used to extract
+ * the correct values.
+ * In addition, if the provider stores non-zero bus numbers for the host
+ * PCI bus in a device's pciio_info_t->c_bus (as bridge/xbridge do), the
+ * provider code must determine if the register to be read resides on the
+ * host bus (actually PCI bus 0), or a subordinate bus (PCI bus != 0).
+ * pcibr accomplishes this by checking the pciio_info c_vertex against
+ * c_hostvertex. If they are the same, the device is on the host bus, and
+ * this is PCI bus 0. If not, the device is on a subordinate bus, and the
+ * bus number can be taken from c_bus.
+ * Providers must decide if it is appropriate for pio maps to be
+ * constructed for config space of devices on subordinate busses. For
+ * bridge/xbridge, this should not be allowed because all devices on
+ * subordinate busses share the same address space (the bus/slot to use is
+ * programmed in a bridge/xbridge register).
It doesn't appear that this code ever made it into the Linux kernel tree.
That FTP site has many other patches--not sure how interesting they are from an Irix POV.