January 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/4] ASoC: Do not use core to handle msbits constraint for TI drivers
by Peter Ujfalusi 21 Jan '12

21 Jan '12

Hi, The implementation in the core applies the msbits constraint to all sample size. These codecs, and cpu dai drivers only have msbits constraint when they are configured with 32 bit sample size. Apply the msbits constraint in the drivers for 32 bit samples only. Regards, Peter --- Peter Ujfalusi (4): Revert "ASoC: tlv320dac33: Use core to set the msbits constraint" Revert "ASoC: twl4030: Use core to set the msbits constraint" Revert "ASoC: omap-dmic: Use core to set the msbits constraint" ASoC: omap-mcpdm: Do not use core to set msbit constraint sound/soc/codecs/tlv320dac33.c | 3 ++- sound/soc/codecs/twl4030.c | 7 +++---- sound/soc/omap/omap-dmic.c | 7 ++++--- sound/soc/omap/omap-mcpdm.c | 4 ++-- 4 files changed, 11 insertions(+), 10 deletions(-) -- 1.7.8.3

2 9

[alsa-devel] [PATCH] - HDA-Models.txt: Update model names
by Dave Lentz 21 Jan '12

21 Jan '12

Update Conexant model names and add Realtek ALC665. Signed-off-by: Dave Lentz <dtl131 at gmail.com> --- Documentation/sound/alsa/HD-Audio-Models.txt | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)

1 0

[alsa-devel] [PATCH v2] ASoC: Add external amplifier controls for Visstrim_M10.
by Javier Martin 20 Jan '12

20 Jan '12

Visstrim_M10 has an external class D amplifier. This patch provides support for controlling the 4 possible gain levels and per channel muting. Signed-off-by: Javier Martin <javier.martin(a)vista-silicon.com> --- Changes since v1: - Specify amplifier gains using tlv array. - Check range values in amplifier controls. --- sound/soc/imx/mx27vis-aic32x4.c | 80 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 80 insertions(+), 0 deletions(-) diff --git a/sound/soc/imx/mx27vis-aic32x4.c b/sound/soc/imx/mx27vis-aic32x4.c index d37e23c..155899c 100644 --- a/sound/soc/imx/mx27vis-aic32x4.c +++ b/sound/soc/imx/mx27vis-aic32x4.c @@ -25,16 +25,37 @@ #include <linux/moduleparam.h> #include <linux/device.h> #include <linux/i2c.h> +#include <linux/gpio.h> #include <sound/core.h> #include <sound/pcm.h> #include <sound/soc.h> #include <sound/soc-dapm.h> +#include <sound/tlv.h> #include <asm/mach-types.h> #include <mach/audmux.h> +#include <mach/iomux-mx27.h> #include "../codecs/tlv320aic32x4.h" #include "imx-ssi.h" +#define MX27VIS_AMP_GAIN 0 +#define MX27VIS_AMP_MUTE 1 + +#define MX27VIS_PIN_G0 (GPIO_PORTF + 9) +#define MX27VIS_PIN_G1 (GPIO_PORTF + 8) +#define MX27VIS_PIN_SDL (GPIO_PORTE + 5) +#define MX27VIS_PIN_SDR (GPIO_PORTF + 7) + +static int mx27vis_amp_gain; +static int mx27vis_amp_mute; + +static const int mx27vis_amp_pins[] = { + MX27VIS_PIN_G0 | GPIO_GPIO | GPIO_OUT, + MX27VIS_PIN_G1 | GPIO_GPIO | GPIO_OUT, + MX27VIS_PIN_SDL | GPIO_GPIO | GPIO_OUT, + MX27VIS_PIN_SDR | GPIO_GPIO | GPIO_OUT, +}; + static int mx27vis_aic32x4_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { @@ -74,8 +95,60 @@ static struct snd_soc_ops mx27vis_aic32x4_snd_ops = { .hw_params = mx27vis_aic32x4_hw_params, }; +static int mx27vis_amp_set(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct soc_mixer_control *mc = + (struct soc_mixer_control *)kcontrol->private_value; + int value = ucontrol->value.integer.value[0]; + unsigned int reg = mc->reg; + int max = mc->max; + + if (value > max) + return -EINVAL; + + switch (reg) { + case MX27VIS_AMP_GAIN: + gpio_set_value(MX27VIS_PIN_G0, value & 1); + gpio_set_value(MX27VIS_PIN_G1, value >> 1); + mx27vis_amp_gain = value; + break; + case MX27VIS_AMP_MUTE: + gpio_set_value(MX27VIS_PIN_SDL, value & 1); + gpio_set_value(MX27VIS_PIN_SDR, value >> 1); + mx27vis_amp_mute = value; + break; + } + return 0; +} + +static int mx27vis_amp_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct soc_mixer_control *mc = + (struct soc_mixer_control *)kcontrol->private_value; + unsigned int reg = mc->reg; + + switch (reg) { + case MX27VIS_AMP_GAIN: + ucontrol->value.integer.value[0] = mx27vis_amp_gain; + break; + case MX27VIS_AMP_MUTE: + ucontrol->value.integer.value[0] = mx27vis_amp_mute; + break; + } + return 0; +} + +/* From 6dB to 24dB in steps of 6dB */ +static const DECLARE_TLV_DB_SCALE(mx27vis_amp_tlv, 600, 600, 0); + static const struct snd_kcontrol_new mx27vis_aic32x4_controls[] = { SOC_DAPM_PIN_SWITCH("External Mic"), + SOC_SINGLE_EXT_TLV("LO Ext Boost", MX27VIS_AMP_GAIN, 0, 3, 0, + mx27vis_amp_get, mx27vis_amp_set, mx27vis_amp_tlv), + SOC_DOUBLE_EXT("LO Ext Mute Switch", MX27VIS_AMP_MUTE, 0, 1, 1, 0, + mx27vis_amp_get, mx27vis_amp_set), }; static const struct snd_soc_dapm_widget aic32x4_dapm_widgets[] = { @@ -146,6 +219,13 @@ static int __init mx27vis_aic32x4_init(void) MXC_AUDMUX_V1_PCR_RXDSEL(MX27_AUDMUX_HPCR1_SSI0) ); + ret = mxc_gpio_setup_multiple_pins(mx27vis_amp_pins, + ARRAY_SIZE(mx27vis_amp_pins), "MX27VIS_AMP"); + if (ret) { + printk(KERN_ERR "ASoC: unable to setup gpios\n"); + platform_device_put(mx27vis_aic32x4_snd_device); + } + return ret; } -- 1.7.0.4

2 1

Re: [alsa-devel] [PATCH] ASoC: mxs: Fix mxs-saif timeout
by Mark Brown 20 Jan '12

20 Jan '12

On Thu, Jan 19, 2012 at 10:23:22AM -0200, Fabio Estevam wrote: > On a mx28evk board the following errors happens on mxs-sgtl5000 probe: Applied, thanks!

1 0

[alsa-devel] [PATCH] ASoC: Enable line out VMID buffer for single ended line outputs in wm_hubs
by Mark Brown 20 Jan '12

20 Jan '12

For optimal performance the single ended line outputs require that the line output VMID buffer be enabled. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm_hubs.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c index 2a61094..9ccc416 100644 --- a/sound/soc/codecs/wm_hubs.c +++ b/sound/soc/codecs/wm_hubs.c @@ -613,6 +613,8 @@ SND_SOC_DAPM_INPUT("IN2RP:VXRP"), SND_SOC_DAPM_SUPPLY("MICBIAS2", WM8993_POWER_MANAGEMENT_1, 5, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("MICBIAS1", WM8993_POWER_MANAGEMENT_1, 4, 0, NULL, 0), +SND_SOC_DAPM_SUPPLY("LINEOUT_VMID_BUF", WM8993_ANTIPOP1, 7, 0, NULL, 0), + SND_SOC_DAPM_MIXER("IN1L PGA", WM8993_POWER_MANAGEMENT_2, 6, 0, in1l_pga, ARRAY_SIZE(in1l_pga)), SND_SOC_DAPM_MIXER("IN1R PGA", WM8993_POWER_MANAGEMENT_2, 4, 0, @@ -834,9 +836,11 @@ static const struct snd_soc_dapm_route lineout1_diff_routes[] = { }; static const struct snd_soc_dapm_route lineout1_se_routes[] = { + { "LINEOUT1N Mixer", NULL, "LINEOUT_VMID_BUF" }, { "LINEOUT1N Mixer", "Left Output Switch", "Left Output PGA" }, { "LINEOUT1N Mixer", "Right Output Switch", "Right Output PGA" }, + { "LINEOUT1P Mixer", NULL, "LINEOUT_VMID_BUF" }, { "LINEOUT1P Mixer", "Left Output Switch", "Left Output PGA" }, { "LINEOUT1N Driver", NULL, "LINEOUT1N Mixer" }, @@ -853,9 +857,11 @@ static const struct snd_soc_dapm_route lineout2_diff_routes[] = { }; static const struct snd_soc_dapm_route lineout2_se_routes[] = { + { "LINEOUT2N Mixer", NULL, "LINEOUT_VMID_BUF" }, { "LINEOUT2N Mixer", "Left Output Switch", "Left Output PGA" }, { "LINEOUT2N Mixer", "Right Output Switch", "Right Output PGA" }, + { "LINEOUT2P Mixer", NULL, "LINEOUT_VMID_BUF" }, { "LINEOUT2P Mixer", "Right Output Switch", "Right Output PGA" }, { "LINEOUT2N Driver", NULL, "LINEOUT2N Mixer" }, -- 1.7.7.3

1 0

[alsa-devel] Improve hw_params documentation -- details of constraint resolution
by Joerg-Cyril.Hoehle＠t-systems.com 20 Jan '12

20 Jan '12

Hi, Andrew Eikum recently improved the (still much lacking) ALSA documentation -- thanks Andrew: + * When a parameter is set or restricted using a snd_pcm_hw_params_set* + * function, all of the other ranges will be updated to exclude as many + * impossible configurations as possible. Attempting to set a parameter + * outside of its acceptable range will result in the function failing + * and an error code being returned. I'd like to check whether that's exactly what's happening. 1. Consider the following scenario: set_hw_params_period_near([in,out]10ms,[out]dir) yields 16ms and direction=0 <=> "exact match" set_hw_params_buffer_size(X) set_hw_params() So far, I thought that if ALSA replied with direction=0, then that corner stone of the configuration space was fixed. OTOH, if constraint resolutions occurs at the time of set_hw_params() *again and finally*, ALSA may realize that the particularly large or small buffer size X is not reachable with the 16ms period, whereas a 50ms or 5ms period may allow buffer size X. So what is the outcome? a) 16ms period and error from set_hw_params() because the constraints don't fit? b) revised 5 or 50ms period with buffer size X, because 5 or 50ms is a near period? c) 16ms period, error from set_buffer_size and success from set_hw_params as ALSA chooses an arbitrary buffer size (typically 4-8 periods)? I believe c) is implemented. The documentation may lead one to believe b) happens. Behaviour b) may better suit what users expect, but compatibility likely imposes c). Any "official" statement? 2. + * Attempting to set a parameter + * outside of its acceptable range will result in the function failing + * and an error code being returned. That does not seem to apply to the set_*_near() functions. set_hw_params_period_time(2ms) may fail because it's too small for the device at hand, whereas set_hw_params_period_time_near(2ms) causes the smallest supported period to be chosen. Does this need clarification or is using *_near not "attempting to set a parameter"? *_min and *_max appear to behave likewise: they set lower and upper bounds without checking whether these are reachable. I think the current behaviour, namely not checking whether near, min or max fall into the "acceptable range", is useful. Thank you for your help, Jörg Höhle

2 1

Re: [alsa-devel] [PATCH] snd-hda-intel: better Alienware M17x R3 quirk
by Takashi Iwai 20 Jan '12

20 Jan '12

At Thu, 19 Jan 2012 22:08:50 +0100, Albert Pool wrote: > > I have been told that this way the rear headphone connector is > working as well; with model=alienware only laptop speakers work. > The subsystem of both controller and codec is 1028:0490. > > Signed-off-by: Albert Pool <albertpool(a)solcon.nl> Thanks, applied now. Takashi > --- > sound/pci/hda/patch_sigmatel.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c > index 87e684f..4071354 100644 > --- a/sound/pci/hda/patch_sigmatel.c > +++ b/sound/pci/hda/patch_sigmatel.c > @@ -1608,7 +1608,7 @@ static const struct snd_pci_quirk stac92hd73xx_codec_id_cfg_tbl[] = { > SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x043a, > "Alienware M17x", STAC_ALIENWARE_M17X), > SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0490, > - "Alienware M17x", STAC_ALIENWARE_M17X), > + "Alienware M17x R3", STAC_DELL_EQ), > {} /* terminator */ > }; > > -- > 1.7.4.1 > >

1 0

[alsa-devel] [PATCH v2 0/2] patch set about the MXS-DMA
by Huang Shijie 20 Jan '12

20 Jan '12

patch 1: move the mxs dma header to a more common place. Beside the mx23/mx28, the apbh-dma is also used by MX50 and MX6Q. So move the mxs dma header file to a more common place, and rename it to mxs-dma.h patch 2: rewrite the last parameter of mxs_dma_prep_slave_sg(). In the new GPMI version, some hardware behavior changes. The WAIT4END bit should be set in the middle one of the ECC READ page DMA chain. The DMA chain should be set like this: +-----+ +-----+ +-----+ | cmd | ------------> | cmd | ------------------> | cmd | +-----+ +-----+ +-----+ ^ ^ | | | | set WAIT4END here too set WAIT4END here So rewrite the last parameter of mxs_dma_prep_slave_sg(), use the dma_ctrl_flags to set the proper DMA bit for DMA Command Structure. And change the relative drivers with the dma_ctrl_flags. TEST: Tested the mxs-mmc driver and gpmi-nand drive with the two patches in MX28 board. v1 --> v2: [1] squash the trial patches into single patch. [2] use the dma_ctrl_flags. Huang Shijie (2): mxs-dma : move the mxs dma.h to a more common place mxs-dma : rewrite the last parameter of mxs_dma_prep_slave_sg() drivers/dma/mxs-dma.c | 34 +++++++++++++++++--- drivers/mmc/host/mxs-mmc.c | 12 +++--- drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 28 +++++++++++++--- drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 6 +++- drivers/mtd/nand/gpmi-nand/gpmi-regs.h | 2 + .../include/mach/dma.h => include/linux/mxs-dma.h | 0 sound/soc/mxs/mxs-pcm.c | 2 +- sound/soc/mxs/mxs-pcm.h | 2 +- sound/soc/mxs/mxs-saif.c | 2 +- 9 files changed, 67 insertions(+), 21 deletions(-) rename arch/arm/mach-mxs/include/mach/dma.h => include/linux/mxs-dma.h (100%) -- 1.7.3.2

1 2

[alsa-devel] acer ferrari one hda realtek - attempt to improve forte mic IC support
by Alban Browaeys 19 Jan '12

19 Jan '12

A lot of reports about aspire one issues lead me to think the mic IC processing is the same as on this acer ferrari one 200. Looking at alsa-driver-aspire_one-v1.09 assembly I see that it setup the bdl entries to point to a capture buffer which it then split in two buffers : namely mic and speaker . This split happens by moving the first 32 bits to mic , the next 32 to speaker , then to mic and so forth. azx_pcm_hw formats is set to S16 LE. I was wondering about the the 32 bits step between mic and speaker buffer and ended up on azx_pcm_preapre where for the capture case snd_hda_calc_stream_format is hardcoded a number of channels of 4. My issue is I attempted the same trick and it seems I still miss something . Ie the azx_dev->format passed in azx_setup_controller to SD_FORMAT registry is incremented by 3 namely 0x33 . Though I still miss half of each samples same as when I was passing runtime->channels ie 2 and 0x31. The codec is ALC272X ATI SB. Best regards, Alban Browaeys

1 0

[alsa-devel] [alsa-lib PATCH] Document strdup allocation in snd_card_get_name family
by Andrew Eikum 19 Jan '12

19 Jan '12

This was spotted by Jörg Höhle on the wine-patches ML. Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> --- I noticed my documentation patches haven't been making their way into alsa-lib.git. Am I submitting these wrong? I added the SOB line above, although I notice not all patches that get into ALSA have it. On the other hand, alsa-lib.git hasn't been changed since November so perhaps my patches are sitting in someone's tree waiting to be pushed :) Please let me know if I can help get these in. src/control/cards.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)

2 3