2Below is what the bt878 data book says about the PCI bug compatibility
   3modes of the bt878 chip.
   5The triton1 insmod option sets the EN_TBFX bit in the control register.
   6The vsfx insmod option does the same for EN_VSFX bit.  If you have
   7stability problems you can try if one of these options makes your box
   8work solid.
  10drivers/pci/quirks.c knows about these issues, this way these bits are
  11enabled automagically for known-buggy chipsets (look at the kernel
  12messages, bttv tells you).
  16  Gerd
  18---------------------------- cut here --------------------------
  20Normal PCI Mode
  23The PCI REQ signal is the logical-or of the incoming function requests.
  24The inter-nal GNT[0:1] signals are gated asynchronously with GNT and
  25demultiplexed by the audio request signal. Thus the arbiter defaults to
  26the video function at power-up and parks there during no requests for
  27bus access. This is desirable since the video will request the bus more
  28often. However, the audio will have highest bus access priority. Thus
  29the audio will have first access to the bus even when issuing a request
  30after the video request but before the PCI external arbiter has granted
  31access to the Bt879. Neither function can preempt the other once on the
  32bus. The duration to empty the entire video PCI FIFO onto the PCI bus is
  33very short compared to the bus access latency the audio PCI FIFO can
  37430FX Compatibility Mode
  40When using the 430FX PCI, the following rules will ensure
  43 (1) Deassert REQ at the same time as asserting FRAME.
  44 (2) Do not reassert REQ to request another bus transaction until after
  45     finish-ing the previous transaction.
  47Since the individual bus masters do not have direct control of REQ, a
  48simple logical-or of video and audio requests would violate the rules.
  49Thus, both the arbiter and the initiator contain 430FX compatibility
  50mode logic. To enable 430FX mode, set the EN_TBFX bit as indicated in
  51Device Control Register on page 104.
  53When EN_TBFX is enabled, the arbiter ensures that the two compatibility
  54rules are satisfied. Before GNT is asserted by the PCI arbiter, this
  55internal arbiter may still logical-or the two requests. However, once
  56the GNT is issued, this arbiter must lock in its decision and now route
  57only the granted request to the REQ pin. The arbiter decision lock
  58happens regardless of the state of FRAME because it does not know when
  59FRAME will be asserted (typically - each initiator will assert FRAME on
  60the cycle following GNT). When FRAME is asserted, it is the initiator s
  61responsibility to remove its request at the same time. It is the
  62arbiters responsibility to allow this request to flow through to REQ and
  63not allow the other request to hold REQ asserted. The decision lock may
  64be removed at the end of the transaction: for example, when the bus is
  65idle (FRAME and IRDY). The arbiter decision may then continue
  66asynchronously until GNT is again asserted.
  69Interfacing with Non-PCI 2.1 Compliant Core Logic
  72A small percentage of core logic devices may start a bus transaction
  73during the same cycle that GNT is de-asserted. This is non PCI 2.1
  74compliant. To ensure compatibility when using PCs with these PCI
  75controllers, the EN_VSFX bit must be enabled (refer to Device Control
  76Register on page 104). When in this mode, the arbiter does not pass GNT
  77to the internal functions unless REQ is asserted. This prevents a bus
  78transaction from starting the same cycle as GNT is de-asserted. This
  79also has the side effect of not being able to take advantage of bus
  80parking, thus lowering arbitration performance. The Bt879 drivers must
  81query for these non-compliant devices, and set the EN_VSFX bit only if
  84 kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.