2001-11-13 16:14:31 +03:00
|
|
|
/* $NetBSD: mpu.c,v 1.5 2001/11/13 13:14:41 lukem Exp $ */
|
1998-08-07 04:00:55 +04:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Copyright (c) 1998 The NetBSD Foundation, Inc.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
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).
|
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.
|
|
|
|
|
*/
|
|
|
|
|
|
2001-11-13 16:14:31 +03:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
|
__KERNEL_RCSID(0, "$NetBSD: mpu.c,v 1.5 2001/11/13 13:14:41 lukem Exp $");
|
|
|
|
|
|
1998-08-07 04:00:55 +04:00
|
|
|
#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 <machine/cpu.h>
|
|
|
|
|
#include <machine/intr.h>
|
|
|
|
|
#include <machine/bus.h>
|
|
|
|
|
|
1998-08-18 01:16:09 +04:00
|
|
|
#include <dev/midi_if.h>
|
1998-08-07 04:00:55 +04:00
|
|
|
|
1999-08-01 22:05:39 +04:00
|
|
|
#include <dev/ic/mpuvar.h>
|
1998-08-07 04:00:55 +04:00
|
|
|
|
|
|
|
|
#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
|
1999-08-01 21:53:39 +04:00
|
|
|
int mpudebug = 0;
|
1998-08-07 04:00:55 +04:00
|
|
|
#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 *);
|
|
|
|
|
|
1999-08-01 21:53:39 +04:00
|
|
|
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 */
|
|
|
|
|
};
|
1998-08-07 04:00:55 +04:00
|
|
|
|
|
|
|
|
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;
|
1998-08-07 04:00:55 +04:00
|
|
|
{
|
|
|
|
|
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"));
|
1998-08-07 04:00:55 +04:00
|
|
|
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)
|
1998-08-07 04:00:55 +04:00
|
|
|
return 1;
|
|
|
|
|
bad:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
1999-08-02 21:37:41 +04:00
|
|
|
void
|
|
|
|
|
mpu_attach(sc)
|
|
|
|
|
struct mpu_softc *sc;
|
|
|
|
|
{
|
|
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
|
|
midi_attach_mi(&mpu_midi_hw_if, sc, &sc->sc_dev);
|
|
|
|
|
}
|
|
|
|
|
|
1998-08-07 04:00:55 +04:00
|
|
|
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;
|
1998-08-07 04:00:55 +04:00
|
|
|
{
|
|
|
|
|
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;
|
1998-08-07 04:00:55 +04:00
|
|
|
{
|
|
|
|
|
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"));
|
1998-08-07 04:00:55 +04:00
|
|
|
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"));
|
1998-08-07 04:00:55 +04:00
|
|
|
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;
|
1998-08-07 04:00:55 +04:00
|
|
|
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));
|
1998-08-07 04:00:55 +04:00
|
|
|
|
|
|
|
|
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
|
1998-08-07 04:00:55 +04:00
|
|
|
return EIO;
|
1999-10-05 07:29:22 +04:00
|
|
|
}
|
1998-08-07 04:00:55 +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;
|
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
|
|
|
struct mpu_softc *sc = addr;
|
|
|
|
|
|
|
|
|
|
DPRINTF(("mpu_close: sc=%p\n", sc));
|
1998-08-07 04:00:55 +04:00
|
|
|
|
|
|
|
|
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
|
1998-08-07 04:00:55 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
1998-08-07 04:00:55 +04:00
|
|
|
{
|
|
|
|
|
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));
|
1998-08-07 04:00:55 +04:00
|
|
|
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;
|
1998-08-07 04:00:55 +04:00
|
|
|
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;
|
1998-08-07 04:00:55 +04:00
|
|
|
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));
|
1998-08-07 04:00:55 +04:00
|
|
|
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);
|
1998-08-07 04:00:55 +04:00
|
|
|
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"));
|
1998-08-07 04:00:55 +04:00
|
|
|
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;
|
|
|
|
|
{
|
1999-08-02 21:37:41 +04:00
|
|
|
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
|
|
|
|
1999-08-02 21:37:41 +04: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;
|
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
|
|
|
struct mpu_softc *sc = addr;
|
|
|
|
|
|
1998-08-07 04:00:55 +04:00
|
|
|
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);
|
1998-08-07 04:00:55 +04:00
|
|
|
}
|
|
|
|
|
}
|