in not just used to access memory but is bassed to bus_space_xxx_n()
methods. For debugging purposes, bus_space can have additional constraints
which will be properly met by BUS_SPACE_ALIGNED_POINTER().
* 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.)
* Use a single routine to halt both input and output on Audio1.
* Reduce the number of register reads/writes used to set up a channel.
* A few other minor things.
* Separate the interrupt handlers based on which channel (audio1/audio2)
rather than which direction (input/output). Only register the handler for
audio1 on the 1788.
* Since the input sides are actually the same, GC the duplicated code.
* Re-KNF in a bunch of places.
* Make this work again on the 1887 in the Shark.
This is a workaround for crappy hardware, normal keyboard controllers
return a "0".
Should fix PR port-i386/6636 by Krister Walfridsson and problems
reported by chopps and fvdl.
mycroft