NetBSD/sys/dev/ic/mpu.c

278 lines
6.3 KiB
C
Raw Normal View History

1999-10-05 07:29:22 +04:00
/* $NetBSD: mpu.c,v 1.3 1999/10/05 03:29:22 itohy Exp $ */
/*
* Copyright (c) 1998 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Lennart Augustsson (augustss@netbsd.org).
*
* 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.
*/
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/errno.h>
#include <sys/ioctl.h>
#include <sys/syslog.h>
#include <sys/device.h>
#include <sys/proc.h>
#include <sys/buf.h>
#include <vm/vm.h>
#include <machine/cpu.h>
#include <machine/intr.h>
#include <machine/bus.h>
#include <dev/midi_if.h>
#include <dev/ic/mpuvar.h>
#ifdef AUDIO_DEBUG
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
#define DPRINTF(x) if (mpudebug) printf x
#define DPRINTFN(n,x) if (mpudebug >= (n)) printf x
int mpudebug = 0;
#else
#define DPRINTF(x)
#define DPRINTFN(n,x)
#endif
#define MPU_DATA 0
#define MPU_COMMAND 1
#define MPU_RESET 0xff
#define MPU_UART_MODE 0x3f
#define MPU_ACK 0xfe
#define MPU_STATUS 1
#define MPU_OUTPUT_BUSY 0x40
#define MPU_INPUT_EMPTY 0x80
#define MPU_MAXWAIT 10000 /* usec/10 to wait */
#define MPU_GETSTATUS(iot, ioh) (bus_space_read_1(iot, ioh, MPU_STATUS))
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_reset(struct mpu_softc *);
static __inline int mpu_waitready(struct mpu_softc *);
void mpu_readinput(struct mpu_softc *);
int mpu_open __P((void *, int,
void (*iintr)__P((void *, int)),
void (*ointr)__P((void *)), void *arg));
void mpu_close __P((void *));
int mpu_output __P((void *, int));
void mpu_getinfo __P((void *, struct midi_info *));
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 = {
mpu_open,
mpu_close,
mpu_output,
mpu_getinfo,
0, /* ioctl */
};
int
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
mpu_find(sc)
struct mpu_softc *sc;
{
if (MPU_GETSTATUS(sc->iot, sc->ioh) == 0xff) {
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
DPRINTF(("mpu_find: No status\n"));
goto bad;
}
sc->open = 0;
sc->intr = 0;
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
if (mpu_reset(sc) == 0)
return 1;
bad:
return 0;
}
void
mpu_attach(sc)
struct mpu_softc *sc;
{
printf("\n");
midi_attach_mi(&mpu_midi_hw_if, sc, &sc->sc_dev);
}
static __inline int
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
mpu_waitready(sc)
struct mpu_softc *sc;
{
int i;
for(i = 0; i < MPU_MAXWAIT; i++) {
if (!(MPU_GETSTATUS(sc->iot, sc->ioh) & MPU_OUTPUT_BUSY))
return 0;
delay(10);
}
return 1;
}
int
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
mpu_reset(sc)
struct mpu_softc *sc;
{
bus_space_tag_t iot = sc->iot;
bus_space_handle_t ioh = sc->ioh;
int i;
int s;
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
if (mpu_waitready(sc)) {
DPRINTF(("mpu_reset: not ready\n"));
return EIO;
}
s = splaudio(); /* Don't let the interrupt get our ACK. */
bus_space_write_1(iot, ioh, MPU_COMMAND, MPU_RESET);
for(i = 0; i < 2*MPU_MAXWAIT; i++) {
if (!(MPU_GETSTATUS(iot, ioh) & MPU_INPUT_EMPTY) &&
bus_space_read_1(iot, ioh, MPU_DATA) == MPU_ACK) {
splx(s);
return 0;
}
}
splx(s);
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
DPRINTF(("mpu_reset: No ACK\n"));
return EIO;
}
int
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
mpu_open(addr, flags, iintr, ointr, arg)
void *addr;
int flags;
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
struct mpu_softc *sc = addr;
DPRINTF(("mpu_open: sc=%p\n", sc));
if (sc->open)
return EBUSY;
1999-10-05 07:29:22 +04:00
#ifndef AUDIO_NO_POWER_CTL
if (sc->powerctl)
sc->powerctl(sc->powerarg, 1);
#endif
if (mpu_reset(sc) != 0) {
#ifndef AUDIO_NO_POWER_CTL
if (sc->powerctl)
sc->powerctl(sc->powerarg, 0);
#endif
return EIO;
1999-10-05 07:29:22 +04:00
}
bus_space_write_1(sc->iot, sc->ioh, MPU_COMMAND, MPU_UART_MODE);
sc->open = 1;
sc->intr = iintr;
sc->arg = arg;
return 0;
}
void
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
mpu_close(addr)
void *addr;
{
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 *sc = addr;
DPRINTF(("mpu_close: sc=%p\n", sc));
sc->open = 0;
sc->intr = 0;
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
mpu_reset(sc); /* exit UART mode */
1999-10-05 07:29:22 +04:00
#ifndef AUDIO_NO_POWER_CTL
if (sc->powerctl)
sc->powerctl(sc->powerarg, 0);
#endif
}
void
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
mpu_readinput(sc)
struct mpu_softc *sc;
{
bus_space_tag_t iot = sc->iot;
bus_space_handle_t ioh = sc->ioh;
int data;
while(!(MPU_GETSTATUS(iot, ioh) & MPU_INPUT_EMPTY)) {
data = bus_space_read_1(iot, ioh, MPU_DATA);
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
DPRINTFN(3, ("mpu_rea: sc=%p 0x%02x\n", sc, data));
if (sc->intr)
sc->intr(sc->arg, data);
}
}
int
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
mpu_output(addr, d)
void *addr;
int d;
{
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 *sc = addr;
int s;
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
DPRINTFN(3, ("mpu_output: sc=%p 0x%02x\n", sc, d));
if (!(MPU_GETSTATUS(sc->iot, sc->ioh) & MPU_INPUT_EMPTY)) {
s = splaudio();
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
mpu_readinput(sc);
splx(s);
}
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
if (mpu_waitready(sc)) {
DPRINTF(("mpu_output: not ready\n"));
return EIO;
}
bus_space_write_1(sc->iot, sc->ioh, MPU_DATA, d);
return 0;
}
void
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
mpu_getinfo(addr, mi)
void *addr;
struct midi_info *mi;
{
struct mpu_softc *sc = addr;
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
mi->name = sc->model;
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
mi->props = 0;
}
int
mpu_intr(addr)
void *addr;
{
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 *sc = addr;
if (MPU_GETSTATUS(sc->iot, sc->ioh) & MPU_INPUT_EMPTY) {
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
DPRINTF(("mpu_intr: no data\n"));
return (0);
} else {
mpu_readinput(sc);
return (1);
}
}