Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/sys/dev/isa/mpuvar.h

57 lines
2.5 KiB
C
Raw Normal View History

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 10:37:35 +03:00
/* $NetBSD: mpuvar.h,v 1.1 1999/03/22 07:37:35 mycroft Exp $ */
Add MIDI support. The MIDI devices can be accessed as ``raw'' through the /dev/rmidiN devices, or with a sequencer interface via /dev/music. So far the only supported MIDI device is the MPU401 port on SoundBlaster (and only on SB on isapnp, since we do not have locators with multiple values yet).
1998-08-07 04:00:55 +04:00
/*
* Copyright (c) 1998 The NetBSD Foundation, Inc.
* All rights reserved.
*
Make the copyright header conform to the NetBSD template.
1998-11-26 01:17:06 +03:00
* This code is derived from software contributed to The NetBSD Foundation
* by Lennart Augustsson (augustss@netbsd.org).
Add MIDI support. The MIDI devices can be accessed as ``raw'' through the /dev/rmidiN devices, or with a sequencer interface via /dev/music. So far the only supported MIDI device is the MPU401 port on SoundBlaster (and only on SB on isapnp, since we do not have locators with multiple values yet).
1998-08-07 04:00:55 +04:00
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the NetBSD
* Foundation, Inc. and its contributors.
* 4. Neither the name of The NetBSD Foundation nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
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 10:37:35 +03:00
struct mpu_softc {
Add MIDI support. The MIDI devices can be accessed as ``raw'' through the /dev/rmidiN devices, or with a sequencer interface via /dev/music. So far the only supported MIDI device is the MPU401 port on SoundBlaster (and only on SB on isapnp, since we do not have locators with multiple values yet).
1998-08-07 04:00:55 +04:00
bus_space_tag_t iot; /* tag */
bus_space_handle_t ioh; /* handle */
int open;
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 10:37:35 +03:00
void (*intr)__P((void *, int)); /* midi input intr handler */
Add MIDI support. The MIDI devices can be accessed as ``raw'' through the /dev/rmidiN devices, or with a sequencer interface via /dev/music. So far the only supported MIDI device is the MPU401 port on SoundBlaster (and only on SB on isapnp, since we do not have locators with multiple values yet).
1998-08-07 04:00:55 +04:00
void *arg; /* arg for intr() */
};
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 10:37:35 +03:00
struct midi_hw_if mpu_midi_hw_if;
Add MIDI support. The MIDI devices can be accessed as ``raw'' through the /dev/rmidiN devices, or with a sequencer interface via /dev/music. So far the only supported MIDI device is the MPU401 port on SoundBlaster (and only on SB on isapnp, since we do not have locators with multiple values yet).
1998-08-07 04:00:55 +04:00
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 10:37:35 +03:00
int mpu_find __P((struct mpu_softc *));
int mpu_open __P((void *, int,
Add MIDI support. The MIDI devices can be accessed as ``raw'' through the /dev/rmidiN devices, or with a sequencer interface via /dev/music. So far the only supported MIDI device is the MPU401 port on SoundBlaster (and only on SB on isapnp, since we do not have locators with multiple values yet).
1998-08-07 04:00:55 +04:00
void (*iintr)__P((void *, int)),
void (*ointr)__P((void *)), void *arg));
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 10:37:35 +03:00
void mpu_close __P((void *));
int mpu_output __P((void *, int));
void mpu_getinfo __P((void *, struct midi_info *));
int mpu_intr __P((void *));