September 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/8] i2c: Remove redundant driver field from the i2c_client struct
by Lars-Peter Clausen 17 Oct '13

17 Oct '13

Hi, This series removes the redundant driver field from the i2c_client struct. The field is redundant since the same pointer can be accessed through to_i2c_driver(client->dev.driver). The commit log suggests that the field has been around since forever (since before v2.6.12-rc2) and it looks as if it was simply forgotten to remove it during the conversion of the i2c framework to the generic device driver model. Nevertheless there are a still a few users of the field around. This series first updates all users to use an alternative method of accessing the same data and then the last patch removes the driver field from the i2c_client struct. Note that due to this changes on most architectures neither the code size nor the type of generated instructions will change. This is due to the fact that we aren't really interested in the pointer value itself, but rather want to dereference it to access one of the fields of the struct. offset_of() (and hence to_i2c_driver) works by subtracting a offset from the pointer, so the compiler can internally create the sum of these two offsets and use that to access the field. E.g. on ARM the expression client->driver->command(...) generates ... ldr r3, [r0, #28] ldr r3, [r3, #32] blx r3 ... and the expression to_i2c_driver(client->dev.driver)->command(...) generates ... ldr r3, [r0, #160] ldr r3, [r3, #-4] blx r3 ... Other architectures will generate similar code. The most common pattern is to use the i2c_driver to get to the device_driver struct embedded in it. The same struct can easily be accessed through the device struct embedded in the i2c_client struct. E.g. client->driver->driver.field can be replaced by client->dev.driver->field. Here again the generated code is almost identical and only the offsets differ. E.g. on ARM the expression 'client->driver->driver.owner' generates ldr r3, [r0, #28] ldr r0, [r3, #44] and 'client->dev.driver->owner' generates ldr r3, [r0, #160] ldr r0, [r3, #8] The kernel overall code size is slightly reduced since the code that manages the driver field is removed and of course also the runtime memory footprint of the i2c_client struct is reduced. - Lars Lars-Peter Clausen (8): [media] s5c73m3: Don't use i2c_client->driver [media] exynos4-is: Don't use i2c_client->driver [media] core: Don't use i2c_client->driver drm: encoder_slave: Don't use i2c_client->driver drm: nouveau: Don't use i2c_client->driver ALSA: ppc: keywest: Don't use i2c_client->driver ASoC: imx-wm8962: Don't use i2c_client->driver i2c: Remove redundant 'driver' field from the i2c_client struct drivers/gpu/drm/drm_encoder_slave.c | 8 ++++---- drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 3 ++- drivers/i2c/i2c-core.c | 21 ++++++++++++--------- drivers/i2c/i2c-smbus.c | 10 ++++++---- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/platform/exynos4-is/media-dev.c | 6 +++--- drivers/media/v4l2-core/tuner-core.c | 6 +++--- drivers/media/v4l2-core/v4l2-common.c | 10 +++++----- include/linux/i2c.h | 2 -- include/media/v4l2-common.h | 2 +- sound/ppc/keywest.c | 4 ++-- sound/soc/fsl/imx-wm8962.c | 2 +- 12 files changed, 40 insertions(+), 36 deletions(-) -- 1.8.0

7 17

[alsa-devel] [PATCH 1/5] ARM: Kconfig: Move if ARCH_S3C64XX statement to mach-s3c64xx/Kconfig
by Tomasz Figa 11 Oct '13

11 Oct '13

All other platforms have this condition checked inside their own Kconfig files, so for consistency this patch makes it this way for mach-s3c64xx as well. Signed-off-by: Tomasz Figa <tomasz.figa(a)gmail.com> --- arch/arm/Kconfig | 2 -- arch/arm/mach-s3c64xx/Kconfig | 4 ++++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b766dad..dc51f8a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -995,9 +995,7 @@ source "arch/arm/mach-sti/Kconfig" source "arch/arm/mach-s3c24xx/Kconfig" -if ARCH_S3C64XX source "arch/arm/mach-s3c64xx/Kconfig" -endif source "arch/arm/mach-s5p64x0/Kconfig" diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig index bd14e3a..0e23910 100644 --- a/arch/arm/mach-s3c64xx/Kconfig +++ b/arch/arm/mach-s3c64xx/Kconfig @@ -3,6 +3,8 @@ # # Licensed under GPLv2 +if ARCH_S3C64XX + # temporary until we can eliminate all drivers using it. config PLAT_S3C64XX bool @@ -322,3 +324,5 @@ config MACH_S3C64XX_DT board. Note: This is under development and not all peripherals can be supported with this machine file. + +endif -- 1.8.3.2

5 9

[alsa-devel] Internal Mic Boost channel is unused
by Nathanael D. Noblet 10 Oct '13

10 Oct '13

Hello, I have an issue I'd like to help completely solve. Unfortunately I only have a tenuous grasp of what is actually going on so some of this could be wrong/include errors. Here's what I know. 1) I have the following hardware (alsa-info attached). 2) The internal microphone requires that the mic boost channel be something other than 0 to function properly. 3) Changing what pulseaudio expects things to be labelled causes the problem to go away. (via the attached patch to /usr/share/pulseaudio/paths/analog-input-mic.conf). From the discussion with David Henningsson (diwic on IRC). It seems that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics. I'd love to be able to help any way I can to get these fixed once and for all. Let me know if you need more information or what not. -- Nathanael d. Noblet t 403.875.4613

3 13

Re: [alsa-devel] Cannot load snd-usb-audio on 3.12-rc2
by Takashi Iwai 10 Oct '13

10 Oct '13

At Mon, 23 Sep 2013 16:41:07 -0700, Sarah Sharp wrote: > > The snd-usb-audio driver no longer loads properly on 3.12-rc2 when I > plug in my USB headset. It worked fine on 3.11-rc4 (not sure about > vanilla 3.11). > > Trying to manually load the driver fails: > > sarah@xanatos:~$ sudo modprobe snd-usb-audio > FATAL: Error inserting snd_usb_audio > (/lib/modules/3.12.0-rc2/kernel/sound/usb/snd-usb-audio.ko): Invalid argument > > dmesg shows: > > [ 44.231668] snd_usb_audio: `-2' invalid for parameter `index' There is no corresponding code change in the USB audio driver side, so I guess it must be in the module parameter parser that got broken. Does the patch below fix? thanks, Takashi --- diff --git a/kernel/params.c b/kernel/params.c index 81c4e78..c00d5b5 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -254,11 +254,11 @@ int parse_args(const char *doing, STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", unsigned long, kstrtoul); -STANDARD_PARAM_DEF(short, short, "%hi", long, kstrtoul); +STANDARD_PARAM_DEF(short, short, "%hi", long, kstrtol); STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", unsigned long, kstrtoul); -STANDARD_PARAM_DEF(int, int, "%i", long, kstrtoul); +STANDARD_PARAM_DEF(int, int, "%i", long, kstrtol); STANDARD_PARAM_DEF(uint, unsigned int, "%u", unsigned long, kstrtoul); -STANDARD_PARAM_DEF(long, long, "%li", long, kstrtoul); +STANDARD_PARAM_DEF(long, long, "%li", long, kstrtol); STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", unsigned long, kstrtoul); int param_set_charp(const char *val, const struct kernel_param *kp)

2 2

Re: [alsa-devel] [Alsa-user] hdmi sound rerouted?
by Clemens Ladisch 08 Oct '13

08 Oct '13

Dagg Stompler wrote: >> daggs(a)gmx.com wrote: >>> card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] >>> card 1: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0] >>> card 2: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0] >> >> The second one is called "Generic" because your kernel does not (yet) >> know the hardware. >> >>> 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cedar HDMI Audio [Radeon HD 5400/6300 Series] >>> 06:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV635 HDMI Audio [Radeon HD 3600 Series] >> >> These are the HDMI outputs of *two* graphics cards. The first one's >> model is so new that the driver doesn't know it. > > the 3600 doesn't have hdmi socket so I think it is irrelevant for my issue. The RV635 chip does support HDMI outputs (even if none are actually connected), so the corresponding PCI device shows up here. >>> If you update the kernel, you will get two devices named "HDA ATI HDMI". > > upgrade to where? Oops. Even the latest driver lacks the PCI IDs of many HDMI HDA devices (aa50/aa58/aa60/aa68/aa80/aa88/aa90/aa98: Cypress/Juniper/Redwood/Cedar/ Cayman+Antilles/Barts/Turks/Caicos). Alex, are these devices that require disabling snooping? Regards, Clemens

4 5

[alsa-devel] Can't get capturing from RME Hammerfall MADI card to work: sound loops & silcence
by Niels Laukens 08 Oct '13

08 Oct '13

Hi, I'm trying to capture audio from an RME Hammerfall MADI card (PCI ID 10ee:3fc6). The setup previously worked fine on Windows, so I'm currently assuming that the card and the input signal is OK. I wrote a very simple ALSA-application that simply opens the device, sets the access format to NONINTERLEAVED (which seems to be the only option the card likes), selects 32bit sampling (although the audio is 24bit, ALSA rejects this option), 48kHz sampling and 64 channels (also, the only option the card accepts). Next, it loops with snd_pcm_readn() to get 100ms worth of audio, and dumps channel 10 to file. (Full source in attachement) The result is strange for various reasons: * The second half of every buffer returned by snd_pcm_readn() is always zero's. * The call seems to return way to fast: I would expect to get 48000 frames/second, but judging from the timing of the snd_pcm_readn() call, it's more like 1536000 frames/second (i.e. 32 fold faster). * When playing back the resulting file, I do recognize some music, but it sounds like it's the same part over and over again. Also, restarting the capture program minutes later, returns the same (at least as far as my ears & brain can recall) fragment of audio. What am I doing wrong here? (Samples of the PCM-file are available upon request) I've also tried a related test with `arecord`, with similar but different results: * The audio was also interspersed with silence * The capture duration did not match the requested '-d' option: the recording was a factor of 2 shorter than requested. * There was more audio in the recording: if I manually cut out the silent parts, the audio sounded reasonable. What am I missing here? Is this the right place to ask? Or should this go to the RME forum? Thanks in advance, Niels

6 5

[alsa-devel] [PATCH - Ego Sys Waveterminal 192M 1/1] Update driver to support alsa changes happened since last driver commit. Add TLV support for dB scales. Add sampling rate control.
by klem.dev＠gmail.com 05 Oct '13

05 Oct '13

From: Clement Guedez <klem.dev(a)gmail.com> Signed-off-by: Clement Guedez <klem.dev(a)gmail.com> diff --git a/sound/pci/ice1712/wtm.c b/sound/pci/ice1712/wtm.c index bcf30a3..286be47 100644 --- a/sound/pci/ice1712/wtm.c +++ b/sound/pci/ice1712/wtm.c @@ -4,8 +4,8 @@ * Lowlevel functions for Ego Sys Waveterminal 192M * * Copyright (c) 2006 Guedez Clement <klem.dev(a)gmail.com> - * Some functions are taken from the Prodigy192 driver - * source + * Thanks to the developers of the Prodigy192 driver on which + * I based this driver * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -25,15 +25,25 @@ +#include <linux/io.h> #include <linux/delay.h> #include <linux/interrupt.h> #include <linux/init.h> +#include <linux/slab.h> #include <sound/core.h> #include "ice1712.h" #include "envy24ht.h" #include "wtm.h" #include "stac946x.h" +#include <sound/tlv.h> + +struct wtm_spec { + struct ak4114 *ak4114; + /* rate change needs atomic mute/unmute of all dacs*/ + struct mutex mute_mutex; +}; + /* @@ -68,6 +78,35 @@ static inline unsigned char stac9460_2_get(struct snd_ice1712 *ice, int reg) /* * DAC mute control */ +static void stac9460_dac_mute_all(struct snd_ice1712 *ice, unsigned char mute, + unsigned char *change) +{ + unsigned char new, old; + int idx; + + /*stac9460 1*/ + for (idx = 0; idx < 7; idx++) { + if (change[idx]) { + old = stac9460_get(ice, idx); + new = (~mute << 7 & 0x80) | (old & ~0x80); + change[idx] = (new != old); + if (change[idx]) + stac9460_put(ice, idx, new); + } + } + + /*stac9460 2*/ + for (idx = 0; idx < 3; idx++) { + if (change[idx + 7]) { + old = stac9460_2_get(ice, idx); + new = (~mute << 7 & 0x80) | (old & ~0x80); + change[idx + 7] = (new != old); + if (change[idx + 7]) + stac9460_2_put(ice, idx, new); + } + } +} + #define stac9460_dac_mute_info snd_ctl_boolean_mono_info static int stac9460_dac_mute_get(struct snd_kcontrol *kcontrol, @@ -96,10 +135,14 @@ static int stac9460_dac_mute_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_ice1712 *ice = snd_kcontrol_chip(kcontrol); + struct wtm_spec *spec = ice->spec; unsigned char new, old; int id, idx; int change; + mutex_lock(&spec->mute_mutex); + + if (kcontrol->private_value) { idx = STAC946X_MASTER_VOLUME; old = stac9460_get(ice, idx); @@ -127,6 +170,7 @@ static int stac9460_dac_mute_put(struct snd_kcontrol *kcontrol, stac9460_2_put(ice, idx - 6, new); } } + mutex_unlock(&spec->mute_mutex); return change; } @@ -175,7 +219,7 @@ static int stac9460_dac_vol_put(struct snd_kcontrol *kcontrol, if (kcontrol->private_value) { idx = STAC946X_MASTER_VOLUME; - nvol = ucontrol->value.integer.value[0] & 0x7f; + nvol = ucontrol->value.integer.value[0]; tmp = stac9460_get(ice, idx); ovol = 0x7f - (tmp & 0x7f); change = (ovol != nvol); @@ -186,7 +230,7 @@ static int stac9460_dac_vol_put(struct snd_kcontrol *kcontrol, } else { id = snd_ctl_get_ioffidx(kcontrol, &ucontrol->id); idx = id + STAC946X_LF_VOLUME; - nvol = ucontrol->value.integer.value[0] & 0x7f; + nvol = ucontrol->value.integer.value[0]; if (id < 6) tmp = stac9460_get(ice, idx); else @@ -339,7 +383,24 @@ static int stac9460_adc_vol_put(struct snd_kcontrol *kcontrol, * MIC / LINE switch fonction */ -#define stac9460_mic_sw_info snd_ctl_boolean_mono_info +static int stac9460_mic_sw_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + static char *texts[2] = { "Line In", "Mic" }; + + uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED; + uinfo->count = 1; + uinfo->value.enumerated.items = 2; + + if (uinfo->value.enumerated.item >= uinfo->value.enumerated.items) + uinfo->value.enumerated.item = uinfo->value.enumerated.items + - 1; + strcpy(uinfo->value.enumerated.name, + texts[uinfo->value.enumerated.item]); + + return 0; +} + static int stac9460_mic_sw_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) @@ -353,7 +414,7 @@ static int stac9460_mic_sw_get(struct snd_kcontrol *kcontrol, val = stac9460_get(ice, STAC946X_GENERAL_PURPOSE); else val = stac9460_2_get(ice, STAC946X_GENERAL_PURPOSE); - ucontrol->value.integer.value[0] = ~val>>7 & 0x1; + ucontrol->value.enumerated.item[0] = (val >> 7) & 0x1; return 0; } @@ -369,7 +430,7 @@ static int stac9460_mic_sw_put(struct snd_kcontrol *kcontrol, old = stac9460_get(ice, STAC946X_GENERAL_PURPOSE); else old = stac9460_2_get(ice, STAC946X_GENERAL_PURPOSE); - new = (~ucontrol->value.integer.value[0] << 7 & 0x80) | (old & ~0x80); + new = (ucontrol->value.enumerated.item[0] << 7 & 0x80) | (old & ~0x80); change = (new != old); if (change) { if (id == 0) @@ -380,6 +441,46 @@ static int stac9460_mic_sw_put(struct snd_kcontrol *kcontrol, return change; } + +/* + * Handler for setting correct codec rate - called when rate change is detected + */ +static void stac9460_set_rate_val(struct snd_ice1712 *ice, unsigned int rate) +{ + unsigned char old, new; + unsigned char changed[10]; + struct wtm_spec *spec = ice->spec; + + if (rate == 0) /* no hint - S/PDIF input is master, simply return */ + return; + else if (rate <= 48000) + new = 0x08; /* 256x, base rate mode */ + else if (rate <= 96000) + new = 0x11; /* 256x, mid rate mode */ + else + new = 0x12; /* 128x, high rate mode */ + old = stac9460_get(ice, STAC946X_MASTER_CLOCKING); + if (old == new) + return; + /* change detected, setting master clock, muting first */ + /* due to possible conflicts with mute controls - mutexing */ + mutex_lock(&spec->mute_mutex); + /* we have to remember current mute status for each DAC */ + stac9460_dac_mute_all(ice, 0, changed); + /*printk(KERN_DEBUG "Rate change: %d, new MC: 0x%02x\n", rate, new);*/ + stac9460_put(ice, STAC946X_MASTER_CLOCKING, new); + udelay(10); + /* unmuting - only originally unmuted dacs - + * i.e. those changed when muting */ + stac9460_dac_mute_all(ice, 1, changed); + mutex_unlock(&spec->mute_mutex); +} + + + +static const DECLARE_TLV_DB_SCALE(db_scale_dac, -19125, 75, 0); +static const DECLARE_TLV_DB_SCALE(db_scale_adc, 0, 150, 0); + /* * Control tabs */ @@ -390,15 +491,19 @@ static struct snd_kcontrol_new stac9640_controls[] = { .info = stac9460_dac_mute_info, .get = stac9460_dac_mute_get, .put = stac9460_dac_mute_put, - .private_value = 1 + .private_value = 1, + .tlv = { .p = db_scale_dac } }, { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | + SNDRV_CTL_ELEM_ACCESS_TLV_READ), .name = "Master Playback Volume", .info = stac9460_dac_vol_info, .get = stac9460_dac_vol_get, .put = stac9460_dac_vol_put, .private_value = 1, + .tlv = { .p = db_scale_dac } }, { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, @@ -419,11 +524,14 @@ static struct snd_kcontrol_new stac9640_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | + SNDRV_CTL_ELEM_ACCESS_TLV_READ), .name = "DAC Volume", .count = 8, .info = stac9460_dac_vol_info, .get = stac9460_dac_vol_get, .put = stac9460_dac_vol_put, + .tlv = { .p = db_scale_dac } }, { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, @@ -435,18 +543,40 @@ static struct snd_kcontrol_new stac9640_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | + SNDRV_CTL_ELEM_ACCESS_TLV_READ), .name = "ADC Volume", .count = 2, .info = stac9460_adc_vol_info, .get = stac9460_adc_vol_get, .put = stac9460_adc_vol_put, - + .tlv = { .p = db_scale_adc } } }; /*INIT*/ +static void stac9460_proc_regs_read(struct snd_info_entry *entry, + struct snd_info_buffer *buffer) +{ + struct snd_ice1712 *ice = entry->private_data; + int reg, val; + /* registers 0x0 - 0x14 */ + for (reg = 0; reg <= 0x15; reg++) { + val = stac9460_get(ice, reg); + snd_iprintf(buffer, "0x%02x = 0x%02x\n", reg, val); + } +} + +static void stac9460_proc_init(struct snd_ice1712 *ice) +{ + struct snd_info_entry *entry; + if (!snd_card_proc_new(ice->card, "stac9460_codec", &entry)) + snd_info_set_text_ops(entry, ice, stac9460_proc_regs_read); +} + + static int wtm_add_controls(struct snd_ice1712 *ice) { unsigned int i; @@ -458,46 +588,64 @@ static int wtm_add_controls(struct snd_ice1712 *ice) if (err < 0) return err; } + stac9460_proc_init(ice); return 0; } static int wtm_init(struct snd_ice1712 *ice) { - static unsigned short stac_inits_prodigy[] = { + static unsigned short stac_inits_wtm[] = { STAC946X_RESET, 0, + STAC946X_MASTER_CLOCKING, 0x11, (unsigned short)-1 }; unsigned short *p; + struct wtm_spec *spec; + /*WTM 192M*/ ice->num_total_dacs = 8; ice->num_total_adcs = 4; ice->force_rdma1 = 1; + ice->vt1720 = 0; /* ice1724, e.g. 23 GPIOs */ + + spec = kzalloc(sizeof(*spec), GFP_KERNEL); + if (!spec) + return -ENOMEM; + ice->spec = spec; + mutex_init(&spec->mute_mutex); /*initialize codec*/ - p = stac_inits_prodigy; + p = stac_inits_wtm; for (; *p != (unsigned short)-1; p += 2) { stac9460_put(ice, p[0], p[1]); stac9460_2_put(ice, p[0], p[1]); } + ice->gpio.set_pro_rate = stac9460_set_rate_val; return 0; } static unsigned char wtm_eeprom[] = { - 0x47, /*SYSCONF: clock 192KHz, 4ADC, 8DAC */ - 0x80, /* ACLINK : I2S */ - 0xf8, /* I2S: vol; 96k, 24bit, 192k */ - 0xc1 /*SPDIF: out-en, spidf ext out*/, - 0x9f, /* GPIO_DIR */ - 0xff, /* GPIO_DIR1 */ - 0x7f, /* GPIO_DIR2 */ - 0x9f, /* GPIO_MASK */ - 0xff, /* GPIO_MASK1 */ - 0x7f, /* GPIO_MASK2 */ - 0x16, /* GPIO_STATE */ - 0x80, /* GPIO_STATE1 */ - 0x00, /* GPIO_STATE2 */ + [ICE_EEP2_SYSCONF] = 0x67, /* 49MHz crystal, mpu401, + * spdif-in+ 1 stereo ADC, + * 4 stereo DACs + */ + [ICE_EEP2_ACLINK] = 0x80, /* I2S */ + [ICE_EEP2_I2S] = 0xf8, /* vol, 96k, 24bit, 192k */ + [ICE_EEP2_SPDIF] = 0xc1, /* out-en, out-int, spdif-in */ + [ICE_EEP2_GPIO_DIR] = 0x9f, + [ICE_EEP2_GPIO_DIR1] = 0xff, + [ICE_EEP2_GPIO_DIR2] = 0x7f, + [ICE_EEP2_GPIO_MASK] = 0x9f, + [ICE_EEP2_GPIO_MASK1] = 0xff, + [ICE_EEP2_GPIO_MASK2] = 0x7f, + [ICE_EEP2_GPIO_STATE] = 0x16, + [ICE_EEP2_GPIO_STATE1] = 0x80, + [ICE_EEP2_GPIO_STATE2] = 0x00, /* GPIO20: 0 = CD drive dig. input + * passthrough, + * 1 = SPDIF-OUT from ice1724 + */ }; -- 1.7.10.4

3 2

[alsa-devel] [PING!] Re: HDMI audio is not working on my new desktop
by Alexander E. Patrakov 05 Oct '13

05 Oct '13

2013/8/14 Alexander E. Patrakov <patrakov(a)gmail.com>: > Hello. > > I built a new desktop PC based on the Gigabyte H87N-WIFI motherboard. > It has one DVI and two HDMI outputs. However, I cannot get any sound > over HDMI. The same OS image works perfectly on my laptop that also > has an HDMI output. > > This is not a pulseaudio problem, as I don't get any sound even if I > test with this command: > > pasuspender -- speaker-test -c2 -D hdmi:0,2 # or, for that matter, 0,0 or 0,1 > > Alsa-info.sh has uploaded its output to > http://www.alsa-project.org/db/?f=1ad7192a15ff4a70b5ddb2579476dbb98adbd929 > > Please note this error in dmesg, it may be relevant: > > [ 1.803595] hda_codec: invalid CONNECT_LIST verb 5[1]:0 > [ 1.803719] hda_codec: invalid CONNECT_LIST verb 7[1]:0 As nobody replied, I have converted this into a formal bug report: https://bugzilla.kernel.org/show_bug.cgi?id=60769 Haswell people, _please_ comment on the bug. -- Alexander E. Patrakov

3 9

[alsa-devel] Microphone does not longer work on Lenovo N581
by Manuel Reimer 05 Oct '13

05 Oct '13

Hello, I'm using Archlinux and so usually run always on the latest kernel. But unfortunately somewhere with Kernel 3.9 my Intel sound got broken. Playback works, but no microphone is found. So I keep downgrading to 3.8.8 for some months, now. Can someone please help me with finding a solution for this? Is it really possible that the alsa driver "snd_had_intel" was broken between 3.8 and 3.9 and noone found this bug, so far? Thank you very much in advance Greetings, Manuel

3 4

[alsa-devel] [PATCH 1/6] ASoC: cs4271: Include linux/of.h header
by Sachin Kamat 04 Oct '13

04 Oct '13

'of_match_ptr' is defined in linux/of.h. Include it explicitly. Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- sound/soc/codecs/cs4271.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index a20f1bb..f6e9534 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -25,6 +25,7 @@ #include <linux/gpio.h> #include <linux/i2c.h> #include <linux/spi/spi.h> +#include <linux/of.h> #include <linux/of_device.h> #include <linux/of_gpio.h> #include <sound/pcm.h> -- 1.7.9.5

2 9