[alsa-devel] [PATCH] sound azt3328: add custom AC97 semi-emulation, to be able to use standard ALSA AC97 layer
tiwai at suse.de
Thu Feb 17 18:37:11 CET 2011
At Thu, 17 Feb 2011 00:15:47 +0100,
Andreas Mohr wrote:
> Make use of the very flexible ALSA ac97 layer (hooks for custom I/O!)
> on this weird AC97 copycat hardware,
> via semi-extended I/O translation/emulation.
> Some 5kB binary/loaded size saved (well... additional huge AC97 module penalty
> not factored in, of course ;-P).
> Given that the driver previously had 20kB that's not bad,
> but the much more important thing is to have AC97 layer stress-tested
> with a thoroughly weird AC97 copycat (or, simply put, if it were not for
> this AC97 test aspect, this effort would merely have been a nut job ;).
> The semi-emulated AC97 constellation appears to be working fine.
> Planning to remove old custom mixer parts if AC97-based operation holds
> Signed-off-by: Andreas Mohr <andi at lisas.de>
> Patch created on -rc3, tested and checkpatch.pl'd.
> GIT history seems clean, should thus apply easily.
> Index: linux-2.6/sound/pci/azt3328.c
> --- linux-2.6.orig/sound/pci/azt3328.c 2011-02-16 23:18:59.000000000 +0100
> +++ linux-2.6/sound/pci/azt3328.c 2011-02-16 23:19:02.000000000 +0100
> @@ -1,6 +1,5 @@
> - * azt3328.c - driver for Aztech AZF3328 based soundcards (e.g. PCI168).
> - * Copyright (C) 2002, 2005 - 2010 by Andreas Mohr <andi AT lisas.de>
> +/* azt3328.c - driver for Aztech AZF3328 based soundcards (e.g. PCI168).
> + * Copyright (C) 2002, 2005 - 2011 by Andreas Mohr <andi AT lisas.de>
> * Framework borrowed from Bart Hartgers's als4000.c.
> * Driver developed on PCI168 AP(W) version (PCI rev. 10, subsystem ID 1801),
> @@ -66,6 +65,13 @@
> * addresses illegally. So far unfortunately it looks like the very flexible
> * ALSA AC97 support is still not enough to easily compensate for such a
> * grave layout violation despite all tweaks and quirks mechanisms it offers.
> + * Well, not quite: now ac97 layer is much improved (bus-specific ops!),
> + * thus I was able to implement support - it's actually working quite well.
> + * An interesting item might be Aztech AMR 2800-W, since it's an AC97
> + * modem card which might reveal the Aztech-specific codec ID which
> + * we might want to pretend, too. Dito PCI168's brother, PCI368,
> + * where the advertising datasheet says it's AC97-based and has a
> + * Digital Enhanced Game Port.
> * - builtin genuine OPL3 - verified to work fine, 20080506
> * - full duplex 16bit playback/record at independent sampling rate
> * - MPU401 (+ legacy address support, claimed by one official spec sheet)
> @@ -189,6 +195,19 @@
> #include <sound/mpu401.h>
> #include <sound/opl3.h>
> #include <sound/initval.h>
> + * For now, use AC97 layer in case CONFIG_SND_AC97_CODEC is available.
> + * If our AC97 emulation turns out to work nicely,
> + * then make it unconditional and remove old custom AC97 crap
> + * (and Kconfig-select SND_AC97_CODEC).
In theory, this causes a problem when you build azt driver into kernel
and build ac97 as a module.
I'd suggest just to select AC97 always, and give some switch (either
static or dynamic) for AC97 control method.
More information about the Alsa-devel