SGI: Hardware

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 .

Guy you drive me nuts with your silly hack it up on irix and
glue it into linux strategy!

+ * 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).
+ *
+ */