diff options
Diffstat (limited to 'sound/oss')
| -rw-r--r-- | sound/oss/Kconfig | 7 | ||||
| -rw-r--r-- | sound/oss/au1550_ac97.c | 9 | ||||
| -rw-r--r-- | sound/oss/emu10k1/midi.c | 2 | ||||
| -rw-r--r-- | sound/oss/msnd.c | 2 | ||||
| -rw-r--r-- | sound/oss/sb_ess.c | 28 |
5 files changed, 27 insertions, 21 deletions
diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig index 080ab03..3b8cdbc 100644 --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -114,8 +114,9 @@ config SOUND_VRC5477 with the AC97 codec. config SOUND_AU1550_AC97 - tristate "Au1550 AC97 Sound" - depends on SOUND_PRIME && SOC_AU1550 + tristate "Au1550/Au1200 AC97 Sound" + select SND_AC97_CODEC + depends on SOUND_PRIME && (SOC_AU1550 || SOC_AU1200) config SOUND_TRIDENT tristate "Trident 4DWave DX/NX, SiS 7018 or ALi 5451 PCI Audio Core" @@ -838,6 +839,6 @@ config SOUND_SH_DAC_AUDIO depends on SOUND_PRIME && CPU_SH3 config SOUND_SH_DAC_AUDIO_CHANNEL - int " DAC channel" + int "DAC channel" default "1" depends on SOUND_SH_DAC_AUDIO diff --git a/sound/oss/au1550_ac97.c b/sound/oss/au1550_ac97.c index 9011abe..4cdb862 100644 --- a/sound/oss/au1550_ac97.c +++ b/sound/oss/au1550_ac97.c @@ -213,7 +213,8 @@ rdcodec(struct ac97_codec *codec, u8 addr) } if (i == POLL_COUNT) { err("rdcodec: read poll expired!"); - return 0; + data = 0; + goto out; } /* wait for command done? @@ -226,7 +227,8 @@ rdcodec(struct ac97_codec *codec, u8 addr) } if (i == POLL_COUNT) { err("rdcodec: read cmdwait expired!"); - return 0; + data = 0; + goto out; } data = au_readl(PSC_AC97CDC) & 0xffff; @@ -237,6 +239,7 @@ rdcodec(struct ac97_codec *codec, u8 addr) au_writel(PSC_AC97EVNT_CD, PSC_AC97EVNT); au_sync(); + out: spin_unlock_irqrestore(&s->lock, flags); return data; @@ -1892,6 +1895,8 @@ static /*const */ struct file_operations au1550_audio_fops = { MODULE_AUTHOR("Advanced Micro Devices (AMD), dan@embeddededge.com"); MODULE_DESCRIPTION("Au1550 AC97 Audio Driver"); +MODULE_LICENSE("GPL"); + static int __devinit au1550_probe(void) diff --git a/sound/oss/emu10k1/midi.c b/sound/oss/emu10k1/midi.c index 25ae8e4..8ac77df 100644 --- a/sound/oss/emu10k1/midi.c +++ b/sound/oss/emu10k1/midi.c @@ -45,7 +45,7 @@ #include "../sound_config.h" #endif -static DEFINE_SPINLOCK(midi_spinlock __attribute((unused))); +static DEFINE_SPINLOCK(midi_spinlock); static void init_midi_hdr(struct midi_hdr *midihdr) { diff --git a/sound/oss/msnd.c b/sound/oss/msnd.c index 5dbfc0f..ba38d62 100644 --- a/sound/oss/msnd.c +++ b/sound/oss/msnd.c @@ -47,7 +47,7 @@ static multisound_dev_t *devs[MSND_MAX_DEVS]; static int num_devs; -int __init msnd_register(multisound_dev_t *dev) +int msnd_register(multisound_dev_t *dev) { int i; diff --git a/sound/oss/sb_ess.c b/sound/oss/sb_ess.c index fae05fe..180e95c 100644 --- a/sound/oss/sb_ess.c +++ b/sound/oss/sb_ess.c @@ -97,19 +97,19 @@ * * The documentation is an adventure: it's close but not fully accurate. I * found out that after a reset some registers are *NOT* reset, though the - * docs say the would be. Interresting ones are 0x7f, 0x7d and 0x7a. They are - * related to the Audio 2 channel. I also was suprised about the consequenses + * docs say the would be. Interesting ones are 0x7f, 0x7d and 0x7a. They are + * related to the Audio 2 channel. I also was surprised about the consequences * of writing 0x00 to 0x7f (which should be done by reset): The ES1887 moves * into ES1888 mode. This means that it claims IRQ 11, which happens to be my * ISDN adapter. Needless to say it no longer worked. I now understand why * after rebooting 0x7f already was 0x05, the value of my choice: the BIOS * did it. * - * Oh, and this is another trap: in ES1887 docs mixer register 0x70 is decribed - * as if it's exactly the same as register 0xa1. This is *NOT* true. The - * description of 0x70 in ES1869 docs is accurate however. + * Oh, and this is another trap: in ES1887 docs mixer register 0x70 is + * described as if it's exactly the same as register 0xa1. This is *NOT* true. + * The description of 0x70 in ES1869 docs is accurate however. * Well, the assumption about ES1869 was wrong: register 0x70 is very much - * like register 0xa1, except that bit 7 is allways 1, whatever you want + * like register 0xa1, except that bit 7 is always 1, whatever you want * it to be. * * When using audio 2 mixer register 0x72 seems te be meaningless. Only 0xa2 @@ -117,10 +117,10 @@ * * Software reset not being able to reset all registers is great! Especially * the fact that register 0x78 isn't reset is great when you wanna change back - * to single dma operation (simplex): audio 2 is still operation, and uses the - * same dma as audio 1: your ess changes into a funny echo machine. + * to single dma operation (simplex): audio 2 is still operational, and uses + * the same dma as audio 1: your ess changes into a funny echo machine. * - * Received the new that ES1688 is detected as a ES1788. Did some thinking: + * Received the news that ES1688 is detected as a ES1788. Did some thinking: * the ES1887 detection scheme suggests in step 2 to try if bit 3 of register * 0x64 can be changed. This is inaccurate, first I inverted the * check: "If * can be modified, it's a 1688", which lead to a correct detection @@ -135,7 +135,7 @@ * About recognition of ESS chips * * The distinction of ES688, ES1688, ES1788, ES1887 and ES1888 is described in - * a (preliminary ??) datasheet on ES1887. It's aim is to identify ES1887, but + * a (preliminary ??) datasheet on ES1887. Its aim is to identify ES1887, but * during detection the text claims that "this chip may be ..." when a step * fails. This scheme is used to distinct between the above chips. * It appears however that some PnP chips like ES1868 are recognized as ES1788 @@ -156,9 +156,9 @@ * * The existing ES1688 support didn't take care of the ES1688+ recording * levels very well. Whenever a device was selected (recmask) for recording - * it's recording level was loud, and it couldn't be changed. The fact that + * its recording level was loud, and it couldn't be changed. The fact that * internal register 0xb4 could take care of RECLEV, didn't work meaning until - * it's value was restored every time the chip was reset; this reset the + * its value was restored every time the chip was reset; this reset the * value of 0xb4 too. I guess that's what 4front also had (have?) trouble with. * * About ES1887 support: @@ -169,9 +169,9 @@ * the latter case the recording volumes are 0. * Now recording levels of inputs can be controlled, by changing the playback * levels. Futhermore several devices can be recorded together (which is not - * possible with the ES1688. + * possible with the ES1688). * Besides the separate recording level control for each input, the common - * recordig level can also be controlled by RECLEV as described above. + * recording level can also be controlled by RECLEV as described above. * * Not only ES1887 have this recording mixer. I know the following from the * documentation: |