Commit Graph

1 Commits

Author SHA1 Message Date
mycroft
97de30ff26 Several things:
* Rearrange the speed mapping table and adjust the code so that the highest
  rate can actually be used.  Previously we ended up rounding up slightly
  lower speeds and then losing because set_params couldn't set the mode
  back to the current one.
* Allow 260 as a valid I/O address, since the SB1 can be jumpered to this.
* Change the MPU-401 code so it can be attached as a separate device.
  (XXX Really, the SB code ought to just attach a subdevice itself.)
* Do not attach an OPL on the SB1.  Writing to the OPL registers at
  SB_base+0 on this card wedges my machine.
  (XXX Should we access it at 388 instead?  The Creative web site claims
  that this board *does* have an OPL2, but I haven't played with this
  extensively.)
* Allocate the SB DMA channels at open time, rather than attach time, so
  that a single DRQ can be used for multiple cards (if only one is in use
  at a given time).
  (XXX Let me tell you why this is a horrible hack.  If the ISA DMA code
  tries to allocate a bounce buffer after boot time, it will generally fail,
  because there is no contiguous memory below 16MB and the code to allocate
  contiguous pages doesn't know how to move things around.  Now, we
  shouldn't ever be using bounce buffers here, because we use
  isa_dmamem_alloc().  So we just turn off BUS_DMA_ALLOCNOW and we don't
  actually try to.  That's cool, and it even works, but isa_dmamem_alloc()
  has the same problem.  It just happens that we allocate the ring buffers
  at boot time, and whenever we reallocate them (due to the buffer size
  changing), we just deallocated the previous (contiguous) buffer, so we get
  lucky.  This is absolutely disgusting and needs to be fixed.)
1999-03-22 07:37:35 +00:00