August 2008 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] snd_pcm_avail_update does not return until I have 32768 bytes ready
by William Estrada 31 Aug '08

31 Aug '08

Hi group, I am having a little problem with ALSA. My problem is that snd_pcm_readi does not return until i have 32768 bytes available. I want to get an interrupt back when I have 80 bytes ( 1/100 of a second ). This delay is about 4.09 seconds which is much too long to want. My question is how do I tell ALSA to return from snd_pcm_avail_update when I have 80 bytes ready to read? -- William Estrada MrUmunhum(a)popdial.com Mt-Umunhum-Wireless.net ( http://Mt-Umunhum-Wireless.net ) Ymessenger: MrUmunhum

1 0

[alsa-devel] snd-soc-cs4270: Convert to a new-style i2c driver (work in progress)
by Jean Delvare 31 Aug '08

31 Aug '08

Hi Tibur, I am in the process of converting your cs4270 codec driver from the legacy i2c model to the new (standard) one. This is work in progress. The patch below converts the cs4270 driver itself. However we also need to convert its users. As far as I can see there's only one user at this point: mpc8610_hpcd. The problem is that this driver doesn't look like the other codec drivers I have already converted. So, we need to add code to instantiate the cs4270 i2c device, but I don't know where this should happen. Given that the mpc8610_hpcd is apparently based on Open Firmware, I guess that the i2c device should be instantiated directly by the platform code. I see that the device is declared in mpc8610_hpcd.dts, so maybe it's already done and my patch should work already? What do you think? Thanks. * * * * * Convert the cs4270 codec driver to the new (standard) device driver binding model. After this change, CS4720 devices are no longer discovered automatically and must instead be instantiated explicitly. Signed-off-by: Jean Delvare <khali(a)linux-fr.org> Cc: Timur Tabi <timur(a)freescale.com> --- sound/soc/codecs/cs4270.c | 79 +++++++++------------------------------------ 1 file changed, 16 insertions(+), 63 deletions(-) --- linux-2.6.27-rc5.orig/sound/soc/codecs/cs4270.c 2008-08-31 14:23:34.000000000 +0200 +++ linux-2.6.27-rc5/sound/soc/codecs/cs4270.c 2008-08-31 15:16:43.000000000 +0200 @@ -272,17 +272,6 @@ static int cs4270_set_dai_fmt(struct snd } /* - * A list of addresses on which this CS4270 could use. I2C addresses are - * 7 bits. For the CS4270, the upper four bits are always 1001, and the - * lower three bits are determined via the AD2, AD1, and AD0 pins - * (respectively). - */ -static const unsigned short normal_i2c[] = { - 0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F, I2C_CLIENT_END -}; -I2C_CLIENT_INSMOD; - -/* * Pre-fill the CS4270 register cache. * * We use the auto-increment feature of the CS4270 to read all registers in @@ -490,32 +479,18 @@ static int cs4270_mute(struct snd_soc_da #endif -static int cs4270_i2c_probe(struct i2c_adapter *adap, int addr, int kind); +static int cs4270_i2c_probe(struct i2c_client *i2c_client, + const struct i2c_device_id *id); -/* - * Notify the driver that a new I2C bus has been found. - * - * This function is called for each I2C bus in the system. The function - * then asks the I2C subsystem to probe that bus at the addresses on which - * our device (the CS4270) could exist. If a device is found at one of - * those addresses, then our probe function (cs4270_i2c_probe) is called. - */ -static int cs4270_i2c_attach(struct i2c_adapter *adapter) -{ - return i2c_probe(adapter, &addr_data, cs4270_i2c_probe); -} - -static int cs4270_i2c_detach(struct i2c_client *client) +static int cs4270_i2c_remove(struct i2c_client *client) { struct snd_soc_codec *codec = i2c_get_clientdata(client); - i2c_detach_client(client); codec->control_data = NULL; kfree(codec->reg_cache); codec->reg_cache = NULL; - kfree(client); return 0; } @@ -525,14 +500,19 @@ static const struct snd_kcontrol_new cs4 CS4270_VOLA, CS4270_VOLB, 0, 0xFF, 1) }; +static const struct i2c_device_id cs4270_i2c_id[] = { + { "cs4270", 0 }, + { } +}; + static struct i2c_driver cs4270_i2c_driver = { .driver = { .name = "CS4270 I2C", .owner = THIS_MODULE, }, - .id = I2C_DRIVERID_CS4270, - .attach_adapter = cs4270_i2c_attach, - .detach_client = cs4270_i2c_detach, + .probe = cs4270_i2c_probe, + .remove = cs4270_i2c_remove, + .id_table = cs4270_i2c_id, }; /* @@ -555,17 +535,14 @@ static struct snd_soc_device *cs4270_soc /* * Initialize the I2C interface of the CS4270 * - * This function is called for whenever the I2C subsystem finds a device - * at a particular address. - * * Note: snd_soc_new_pcms() must be called before this function can be called, * because of snd_ctl_add(). */ -static int cs4270_i2c_probe(struct i2c_adapter *adapter, int addr, int kind) +static int cs4270_i2c_probe(struct i2c_client *i2c_client, + const struct i2c_device_id *id) { struct snd_soc_device *socdev = cs4270_socdev; struct snd_soc_codec *codec = socdev->codec; - struct i2c_client *i2c_client = NULL; int i; int ret = 0; @@ -578,12 +555,6 @@ static int cs4270_i2c_probe(struct i2c_a /* Note: codec_dai->codec is NULL here */ - i2c_client = kzalloc(sizeof(struct i2c_client), GFP_KERNEL); - if (!i2c_client) { - printk(KERN_ERR "cs4270: could not allocate I2C client\n"); - return -ENOMEM; - } - codec->reg_cache = kzalloc(CS4270_NUMREGS, GFP_KERNEL); if (!codec->reg_cache) { printk(KERN_ERR "cs4270: could not allocate register cache\n"); @@ -592,11 +563,6 @@ static int cs4270_i2c_probe(struct i2c_a } i2c_set_clientdata(i2c_client, codec); - strcpy(i2c_client->name, "CS4270"); - - i2c_client->driver = &cs4270_i2c_driver; - i2c_client->adapter = adapter; - i2c_client->addr = addr; /* Verify that we have a CS4270 */ @@ -612,18 +578,10 @@ static int cs4270_i2c_probe(struct i2c_a goto error; } - printk(KERN_INFO "cs4270: found device at I2C address %X\n", addr); + printk(KERN_INFO "cs4270: found device at I2C address %X\n", + i2c_client->addr); printk(KERN_INFO "cs4270: hardware revision %X\n", ret & 0xF); - /* Tell the I2C layer a new client has arrived */ - - ret = i2c_attach_client(i2c_client); - if (ret) { - printk(KERN_ERR "cs4270: could not attach codec, " - "I2C address %x, error code %i\n", addr, ret); - goto error; - } - codec->control_data = i2c_client; codec->read = cs4270_read_reg_cache; codec->write = cs4270_i2c_write; @@ -651,17 +609,12 @@ static int cs4270_i2c_probe(struct i2c_a return 0; error: - if (codec->control_data) { - i2c_detach_client(i2c_client); - codec->control_data = NULL; - } + codec->control_data = NULL; kfree(codec->reg_cache); codec->reg_cache = NULL; codec->reg_cache_size = 0; - kfree(i2c_client); - return ret; } -- Jean Delvare

3 2

[alsa-devel] [PATCH] alsa-lib: Don't call the simple mixer interface "legacy"
by Lennart Poettering 31 Aug '08

31 Aug '08

The simpler mixer interface is not legacy, so the header file shouldn't claim otherwise. Fixes bug 3569 Lennart --- include/mixer.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/mixer.h b/include/mixer.h index 59deb9f..df92164 100644 --- a/include/mixer.h +++ b/include/mixer.h @@ -88,7 +88,7 @@ typedef int (*snd_mixer_event_t)(snd_mixer_class_t *class_, unsigned int mask, /** Mixer element type */ typedef enum _snd_mixer_elem_type { - /* Simple (legacy) mixer elements */ + /* Simple mixer elements */ SND_MIXER_ELEM_SIMPLE, SND_MIXER_ELEM_LAST = SND_MIXER_ELEM_SIMPLE } snd_mixer_elem_type_t; @@ -166,7 +166,7 @@ int snd_mixer_class_set_compare(snd_mixer_class_t *class_, snd_mixer_compare_t c * \{ */ -/* Simple (legacy) mixer elements API */ +/* Simple mixer elements API */ /** Mixer simple element channel identifier */ typedef enum _snd_mixer_selem_channel_id { -- 1.6.0.1 Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

2 1

[alsa-devel] [PATCH] alsa-lib: Reword doxygen doc for snd_pcm_delay()
by Lennart Poettering 31 Aug '08

31 Aug '08

snd_pcm_delay() is for synchronization purposes, it returns the overall latency of the stream, not just the latency induced by the hardware playback buffer. The documentation is a bit misleading about this fact, and some people already misunderstood it. So let's reword this to make the explanation clearer and explicit. This is a result of the discussions of the thread this mail belongs to: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-June/008456.html Lennart --- src/pcm/pcm.c | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index ee2300e..ae89795 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -939,11 +939,23 @@ int snd_pcm_hwsync(snd_pcm_t *pcm) * \param delayp Returned delay in frames * \return 0 on success otherwise a negative error code * - * Delay is distance between current application frame position and - * sound frame position. - * It's positive and less than buffer size in normal situation, - * negative on playback underrun and greater than buffer size on - * capture overrun. + * For playback the delay is defined as the time that a frame that is written + * to the PCM stream shortly after this call will take to be actually + * audible. It is as such the overall latency from the write call to the final + * DAC. + * + * For capture the delay is defined as the time that a frame that was + * digitized by the audio device takes until it can be read from the PCM + * stream shortly after this call returns. It is as such the overall latency + * from the initial ADC to the read call. + * + * Please note that hence in case of a playback underrun this value will not + * necessarily got down to 0. + * + * If the application is interested in the fill level of the playback buffer + * of the device, it should use snd_pcm_avail_update(). The + * value returned by that call is not directly related to the delay, since the + * latter might include some additional, fixed latencies the former does not. * * Note this function does not update the actual r/w pointer * for applications. The function #snd_pcm_avail_update() -- 1.6.0.1 Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

1 0

[alsa-devel] [PATCH] alsa-lib: Make sure SND_PCM_NO_xxx flags don't get lost when nonblocking mode is enabled
by Lennart Poettering 31 Aug '08

31 Aug '08

The plug PCM copies the 'mode' field from the slave PCM. If blocking mode is enabled for the plug PCM the mode is subsequently overwritten with the original requested 'mode'. If non-blocking mode is requested this does not happen. Because the hw PCM synthesizes the 'mode' from the actual file descriptor flags no SND_PCM_NO_xxx will ever be set for it. This has the effect that the 'mode' of the plug PCM will also not include those flags anymore -- unless they are overwritten as mentioned above. This basically means SND_PCM_NO_xxx is ignored for plug:hw:4711 style device strings opened in non-blocking mode. You can easily test this with "aplay --channels 7 --disable-channels -f S16_LE -r 44100 -D plug:hw:0" on a device that cannot do 7 channels. Normally this call should fail, however if you add "-N" to the command line this call will succeed. This patch simply copies the SND_PCM_NO_xxx flags back into the 'mode' field in case we don't overwrite it with the original anyway. Probably closes bug 3571 for good. Lennart --- src/pcm/pcm_hw.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index 1e1889c..c8d9a62 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -1507,7 +1507,13 @@ int _snd_pcm_hw_open(snd_pcm_t **pcmp, const char *name, /* revert to blocking mode for read/write access */ snd_pcm_hw_nonblock(*pcmp, 0); (*pcmp)->mode = mode; - } + } else + /* make sure the SND_PCM_NO_xxx flags don't get lost on the + * way */ + (*pcmp)->mode |= mode & (SND_PCM_NO_AUTO_RESAMPLE| + SND_PCM_NO_AUTO_CHANNELS| + SND_PCM_NO_AUTO_FORMAT| + SND_PCM_NO_SOFTVOL); hw = (*pcmp)->private_data; if (format != SND_PCM_FORMAT_UNKNOWN) -- 1.6.0.1 Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

1 0

Re: [alsa-devel] ALSA, select() question.
by William Estrada 29 Aug '08

29 Aug '08

Jaroslav, I got you Email address from http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg09605.html. <http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg09605.html> I am trying to write a C program that simply reads from a ALSA device and then writes back to it. The program work with one major problem, there is a 4.1 second delay between the read and the write. This delay is caused by the select() not returning at the right time. In you post you said to use: > Yes, but you have to create revents for snd_seq_poll_descriptors_revents() > to get the right event then. Don't use values from select() directly. > > Jaroslav > Do you have some sample code that I could look at so that I could fix my problem? -- William Estrada MrUmunhum(a)popdial.com Mt-Umunhum-Wireless.net ( http://Mt-Umunhum-Wireless.net ) Ymessenger: MrUmunhum

1 0

[alsa-devel] Issues with alsa-info.sh - Trying to track down the problem.
by Travis Place 29 Aug '08

29 Aug '08

Since the move to use alsa-project.org as the main place for uploads, some users have reported that no URL is being printed at the end of the script. I am trying to track down the problem, but would appreciate some help if possible. Thanks in advance, Travis Place (wishie)

2 4

[alsa-devel] [PATCH] ice1724 MIDI on PHASE 22 and PHASE 28 and a few minor fixes
by Vedran Miletić 29 Aug '08

29 Aug '08

Changelog: * added info about PHASE 28 (as far as I could collect, I don't have a card) * added info about TS22PCI and new revisions of PHASE 22 * disable 192k on PHASE 22 as AK4524 I2S doesn't support it * enable midi for both PHASE 22 and PHASE 28 * enable SPDIF reciever on PHASE 22 MIDI works for me, I have tried loopback and it plays good. Thanks for help Pavel and Takashi. diff --git a/pci/ice1712/phase.c b/pci/ice1712/phase.c index f5acdee..6e596e9 100644 --- a/pci/ice1712/phase.c +++ b/pci/ice1712/phase.c @@ -24,7 +24,8 @@ /* PHASE 22 overview: * Audio controller: VIA Envy24HT-S (slightly trimmed down version of Envy24HT) * Analog chip: AK4524 (partially via Philip's 74HCT125) - * Digital receiver: CS8414-CS (not supported in this release) + * Digital receiver: CS8414-CS (supported in this release) + * PHASE 22 revision 2.0 and Terrasoniq/Musonik TS22PCI have CS8416 (support status unknown, please test and report) * * Envy connects to AK4524 * - CS directly from GPIO 10 @@ -33,6 +34,12 @@ * CDTI may be completely blocked by 74HCT125's gate #1 controlled by GPIO 3 */ +/* PHASE 28 overview: + * Audio controller: VIA Envy24HT (full untrimmed version, 8 ins 8 outs) + * Analog chip: WM8770 (8 channel DAC, 2 channel ADC) + * Digital receiver: CS8414-CS (supported in this release) + */ + #include <asm/io.h> #include <linux/delay.h> #include <linux/interrupt.h> @@ -161,9 +168,9 @@ static int __devinit phase22_add_controls(struct snd_ice1712 *ice) } static unsigned char phase22_eeprom[] __devinitdata = { - [ICE_EEP2_SYSCONF] = 0x00, /* 1xADC, 1xDACs */ + [ICE_EEP2_SYSCONF] = 0x28, /* clock 512, mpu 401, spdif-in/1xADC, 1xDACs */ [ICE_EEP2_ACLINK] = 0x80, /* I2S */ - [ICE_EEP2_I2S] = 0xf8, /* vol, 96k, 24bit */ + [ICE_EEP2_I2S] = 0xf0, /* vol, 96k, 24bit */ [ICE_EEP2_SPDIF] = 0xc3, /* out-en, out-int, spdif-in */ [ICE_EEP2_GPIO_DIR] = 0xff, [ICE_EEP2_GPIO_DIR1] = 0xff, @@ -177,7 +184,7 @@ static unsigned char phase22_eeprom[] __devinitdata = { }; static unsigned char phase28_eeprom[] __devinitdata = { - [ICE_EEP2_SYSCONF] = 0x0b, /* clock 512, spdif-in/ADC, 4DACs */ + [ICE_EEP2_SYSCONF] = 0x2b, /* clock 512, mpu401, spdif-in/1xADC, 4xDACs */ [ICE_EEP2_ACLINK] = 0x80, /* I2S */ [ICE_EEP2_I2S] = 0xfc, /* vol, 96k, 24bit, 192k */ [ICE_EEP2_SPDIF] = 0xc3, /* out-en, out-int, spdif-in */ -- Vedran Miletić

2 9

[alsa-devel] [PATCH] ice1724: enable MIDI on Terratec Aureon 7.1 Universe
by Maximilian Rehkopf 29 Aug '08

29 Aug '08

This enables MIDI on Terratec Aureon 7.1 Universe cards specifically. Apparently the other envy24ht-based Aureon cards do not have MIDI ports, hence I added a Universe specific eeprom array. The newer cards (Aureon 7.1 PCI / 5.1 PCI/Fun) have MIDI but use a CMI DSP so this driver does not concern them at all. I am new to git, do I have to perform any git operations regarding the patch myself? Signed-off-by: Maximilian Rehkopf <otakon(a)gmx.net> -- Maximilian Rehkopf <otakon(a)gmx.net>

3 3

[alsa-devel] PATCH - via82xx vt1618 7.1 Audio Support
by John L. Utz III 29 Aug '08

29 Aug '08

1. Implement 7.1 Output for vt1618 codec. 2. Fix typos in comments from my previous 1617a patch. Signed-off-by: John L. Utz III <john.utz(a)dmx.com> diff --git a/pci/ac97/ac97_codec.c b/pci/ac97/ac97_codec.c index d0023e9..89f3050 100644 --- a/pci/ac97/ac97_codec.c +++ b/pci/ac97/ac97_codec.c @@ -168,7 +168,7 @@ static const struct ac97_codec_id snd_ac97_codec_ids[] = { { 0x54584e20, 0xffffffff, "TLC320AD9xC", NULL, NULL }, { 0x56494161, 0xffffffff, "VIA1612A", NULL, NULL }, // modified ICE1232 with S/PDIF { 0x56494170, 0xffffffff, "VIA1617A", patch_vt1617a, NULL }, // modified VT1616 with S/PDIF -{ 0x56494182, 0xffffffff, "VIA1618", NULL, NULL }, +{ 0x56494182, 0xffffffff, "VIA1618", patch_vt1618, NULL }, { 0x57454301, 0xffffffff, "W83971D", NULL, NULL }, { 0x574d4c00, 0xffffffff, "WM9701,WM9701A", NULL, NULL }, { 0x574d4C03, 0xffffffff, "WM9703,WM9707,WM9708,WM9717", patch_wolfson03, NULL}, @@ -609,7 +609,6 @@ AC97_SINGLE("PC Speaker Playback Volume", AC97_PC_BEEP, 1, 15, 1) static const struct snd_kcontrol_new snd_ac97_controls_mic_boost = AC97_SINGLE("Mic Boost (+20dB)", AC97_MIC, 6, 1, 0); - static const char* std_rec_sel[] = {"Mic", "CD", "Video", "Aux", "Line", "Mix", "Mix Mono", "Phone"}; static const char* std_3d_path[] = {"pre 3D", "post 3D"}; static const char* std_mix[] = {"Mix", "Mic"}; diff --git a/pci/ac97/ac97_patch.c b/pci/ac97/ac97_patch.c index bb028f8..7d5abf5 100644 --- a/pci/ac97/ac97_patch.c +++ b/pci/ac97/ac97_patch.c @@ -3465,7 +3465,7 @@ static int patch_vt1616(struct snd_ac97 * ac97) /* * unfortunately, the vt1617a stashes the twiddlers required for - * nooding the i/o jacks on 2 different regs. * thameans that we cant + * noodling the i/o jacks on 2 different regs. that means that we cant * use the easy way provided by AC97_ENUM_DOUBLE() we have to write * are own funcs. * @@ -3498,7 +3498,7 @@ static int snd_ac97_vt1617a_smart51_get(struct snd_kcontrol *kcontrol, pac97 = snd_kcontrol_chip(kcontrol); /* grab codec handle */ - /* grab our desirec bits, then mash them together in a manner + /* grab our desired bits, then mash them together in a manner * consistent with Table 6 on page 17 in the 1617a docs */ usSM51 = snd_ac97_read(pac97, 0x7a) >> 14; @@ -3576,6 +3576,201 @@ int patch_vt1617a(struct snd_ac97 * ac97) return err; } +/* VIA VT1618 8 CHANNEL AC97 CODEC + * + * VIA implements 'Smart 5.1' completely differently on the 1618 than + * it does on the 1617a. awesome! They seem to have sourced this + * particular revision of the technology from somebody else, it's + * called Universal Audio Jack and it shows up on some other folk's chips + * as well. + * + * ordering in this list reflects vt1618 docs for Reg 60h and + * the block diagram, DACs are as follows: + * + * OUT_O -> Front, + * OUT_1 -> Surround, + * OUT_2 -> C/LFE + * + * Unlike the 1617a, each OUT has a consistent set of mappings + * for all bitpatterns other than 00: + * + * 01 Unmixed Output + * 10 Line In + * 11 Mic In + * + * Special Case of 00: + * + * OUT_0 Mixed Output + * OUT_1 Reserved + * OUT_2 Reserved + * + * I have no idea what the hell Reserved does, but on an MSI + * CN700T, i have to set it to get 5.1 output - YMMV, bad + * shit may happen. + * + * If other chips use Universal Audio Jack, then this code might be applicable + * to them. + */ + +struct vt1618_uaj_item { + unsigned short mask; + unsigned short shift; + const char *items[4]; +}; + +/* This list reflects the vt1618 docs for Vendor Defined Register 0x60. */ + +static struct vt1618_uaj_item vt1618_uaj[3] = { + { + /* speaker jack */ + .mask = 0x03, + .shift = 0, + .items = { + "Speaker Out", "DAC Unmixed Out", "Line In", "Mic In" + } + }, + { + /* line jack */ + .mask = 0x0c, + .shift = 2, + .items = { + "Surround Out", "DAC Unmixed Out", "Line In", "Mic In" + } + }, + { + /* mic jack */ + .mask = 0x30, + .shift = 4, + .items = { + "Center LFE Out", "DAC Unmixed Out", "Line In", "Mic In" + }, + }, +}; + +static int snd_ac97_vt1618_UAJ_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + return ac97_enum_text_info(kcontrol, uinfo, + vt1618_uaj[kcontrol->private_value].items, + 4); +} + +/* All of the vt1618 Universal Audio Jack twiddlers are on + Vendor Defined Register 0x60, page 0. The bits, and thus + the mask, are the only thing that changes */ + +static int snd_ac97_vt1618_UAJ_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + unsigned short datpag, uaj; + + struct snd_ac97 *pac97 = snd_kcontrol_chip(kcontrol); + + mutex_lock(&pac97->page_mutex); + + datpag = snd_ac97_read(pac97, AC97_INT_PAGING) & AC97_PAGE_MASK; + snd_ac97_update_bits(pac97, AC97_INT_PAGING, AC97_PAGE_MASK, 0); + + uaj = snd_ac97_read(pac97, 0x60) & + vt1618_uaj[kcontrol->private_value].mask; + + snd_ac97_update_bits(pac97, AC97_INT_PAGING, AC97_PAGE_MASK, datpag); + mutex_unlock(&pac97->page_mutex); + + ucontrol->value.enumerated.item[0] = uaj >> + vt1618_uaj[kcontrol->private_value].shift; + + return 0; +} + +static int snd_ac97_vt1618_UAJ_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + return ac97_update_bits_page(snd_kcontrol_chip(kcontrol), 0x60, + vt1618_uaj[kcontrol->private_value].mask, + ucontrol->value.enumerated.item[0]<< + vt1618_uaj[kcontrol->private_value].shift, + 0); +} + +/* config aux in jack - not found on 3 jack motherboards or soundcards */ + +static int snd_ac97_vt1618_aux_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + static const char *txt_aux[] = {"Aux In", "Back Surr Out"}; + + return ac97_enum_text_info(kcontrol, uinfo, txt_aux, 2); +} + +static int snd_ac97_vt1618_aux_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + ucontrol->value.enumerated.item[0] = + (snd_ac97_read(snd_kcontrol_chip(kcontrol), 0x5c) & 0x0008)>>3; + return 0; +} + +static int snd_ac97_vt1618_aux_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + /* toggle surround rear dac power */ + + snd_ac97_update_bits(snd_kcontrol_chip(kcontrol), 0x5c, 0x0008, + ucontrol->value.enumerated.item[0] << 3); + + /* toggle aux in surround rear out jack */ + + return snd_ac97_update_bits(snd_kcontrol_chip(kcontrol), 0x76, 0x0008, + ucontrol->value.enumerated.item[0] << 3); +} + +static const struct snd_kcontrol_new snd_ac97_controls_vt1618[] = { + AC97_SINGLE("Exchange Center/LFE", 0x5a, 8, 1, 0), + AC97_SINGLE("DC Offset", 0x5a, 10, 1, 0), + AC97_SINGLE("Soft Mute", 0x5c, 0, 1, 1), + AC97_SINGLE("Headphone Amp", 0x5c, 5, 1, 1), + AC97_DOUBLE("Back Surr Volume", 0x5e, 8, 0, 31, 1), + AC97_SINGLE("Back Surr Switch", 0x5e, 15, 1, 1), + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "Speaker Jack Mode", + .info = snd_ac97_vt1618_UAJ_info, + .get = snd_ac97_vt1618_UAJ_get, + .put = snd_ac97_vt1618_UAJ_put, + .private_value = 0 + }, + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "Line Jack Mode", + .info = snd_ac97_vt1618_UAJ_info, + .get = snd_ac97_vt1618_UAJ_get, + .put = snd_ac97_vt1618_UAJ_put, + .private_value = 1 + }, + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "Mic Jack Mode", + .info = snd_ac97_vt1618_UAJ_info, + .get = snd_ac97_vt1618_UAJ_get, + .put = snd_ac97_vt1618_UAJ_put, + .private_value = 2 + }, + { + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "Aux Jack Mode", + .info = snd_ac97_vt1618_aux_info, + .get = snd_ac97_vt1618_aux_get, + .put = snd_ac97_vt1618_aux_put, + } +}; + +int patch_vt1618(struct snd_ac97 *ac97) +{ + return patch_build_controls(ac97, snd_ac97_controls_vt1618, + ARRAY_SIZE(snd_ac97_controls_vt1618)); +} + /* */ static void it2646_update_jacks(struct snd_ac97 *ac97)

2 3