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

[alsa-devel] [PATCH] ASoC: sgtl5000: Enable VAG when DAC/ADC up
by Shawn Guo 29 Mar '12

29 Mar '12

From: Zeng Zhaoming <zengzm.kernel(a)gmail.com> As manual described, VAG is an internal voltage reference of DAC/ADC, So enabled it before DAC/ADC up. As the result, the issue that captured wave file has no sound gets fixed. One more thing should care about is VAG fully ramped down requires 400ms, wait it to avoid pop. Signed-off-by: Zeng Zhaoming <zengzm.kernel(a)gmail.com> Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- sound/soc/codecs/sgtl5000.c | 29 +++++++++++++++-------------- 1 files changed, 15 insertions(+), 14 deletions(-) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index d192626..d6f5aaf 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -143,11 +143,11 @@ static int mic_bias_event(struct snd_soc_dapm_widget *w, } /* - * using codec assist to small pop, hp_powerup or lineout_powerup - * should stay setting until vag_powerup is fully ramped down, - * vag fully ramped down require 400ms. + * As manual described, ADC/DAC only works when VAG powerup, + * So enabled VAG before ADC/DAC up. + * In power down case, we need wait 400ms when vag fully ramped down. */ -static int small_pop_event(struct snd_soc_dapm_widget *w, +static int power_vag_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { switch (event) { @@ -156,7 +156,7 @@ static int small_pop_event(struct snd_soc_dapm_widget *w, SGTL5000_VAG_POWERUP, SGTL5000_VAG_POWERUP); break; - case SND_SOC_DAPM_PRE_PMD: + case SND_SOC_DAPM_POST_PMD: snd_soc_update_bits(w->codec, SGTL5000_CHIP_ANA_POWER, SGTL5000_VAG_POWERUP, 0); msleep(400); @@ -201,12 +201,8 @@ static const struct snd_soc_dapm_widget sgtl5000_dapm_widgets[] = { mic_bias_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), - SND_SOC_DAPM_PGA_E("HP", SGTL5000_CHIP_ANA_POWER, 4, 0, NULL, 0, - small_pop_event, - SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_PRE_PMD), - SND_SOC_DAPM_PGA_E("LO", SGTL5000_CHIP_ANA_POWER, 0, 0, NULL, 0, - small_pop_event, - SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_PRE_PMD), + SND_SOC_DAPM_PGA("HP", SGTL5000_CHIP_ANA_POWER, 4, 0, NULL, 0), + SND_SOC_DAPM_PGA("LO", SGTL5000_CHIP_ANA_POWER, 0, 0, NULL, 0), SND_SOC_DAPM_MUX("Capture Mux", SND_SOC_NOPM, 0, 0, &adc_mux), SND_SOC_DAPM_MUX("Headphone Mux", SND_SOC_NOPM, 0, 0, &dac_mux), @@ -221,15 +217,20 @@ static const struct snd_soc_dapm_widget sgtl5000_dapm_widgets[] = { 0, SGTL5000_CHIP_DIG_POWER, 1, 0), - SND_SOC_DAPM_ADC("ADC", "Capture", SGTL5000_CHIP_ANA_POWER, 1, 0), - - SND_SOC_DAPM_DAC("DAC", "Playback", SGTL5000_CHIP_ANA_POWER, 3, 0), + SND_SOC_DAPM_ADC_E("ADC", "Capture", SGTL5000_CHIP_ANA_POWER, 1, 0, + power_vag_event, + SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), + SND_SOC_DAPM_DAC_E("DAC", "Playback", SGTL5000_CHIP_ANA_POWER, 3, 0, + power_vag_event, + SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), }; /* routes for sgtl5000 */ static const struct snd_soc_dapm_route sgtl5000_dapm_routes[] = { {"Capture Mux", "LINE_IN", "LINE_IN"}, /* line_in --> adc_mux */ {"Capture Mux", "MIC_IN", "MIC_IN"}, /* mic_in --> adc_mux */ + {"Mic Bias", NULL, "MIC_IN"}, /* mic_in --> mic bias */ + {"Capture Mux", "MIC_IN", "Mic Bias"}, /* mic bias --> adc_mux */ {"ADC", NULL, "Capture Mux"}, /* adc_mux --> adc */ {"AIFOUT", NULL, "ADC"}, /* adc --> i2s_out */ -- 1.7.5.4

3 2

[alsa-devel] ASoC:Question on strict sequence followed for trigger
by gsantosh＠codeaurora.org 29 Mar '12

29 Mar '12

Hi All, I see there is a strict sequence followed for trigger callback to codec dai, platform dai and cpu dai. In the below function of soc-core . int soc_pcm_trigger(struct snd_pcm_substream *substream, int cmd); In some scenarios we may require the sequence to be the other case to make sure the underlying DSP / codec is configured and triggered properly. I have a requirement that this sequence has to be 1) Codec_dai 2) Cpu_dai 3) Platform dai Will this call sequence can be changed or there is no room to change this sequence. Regards, Santosh M G.

3 2

Re: [alsa-devel] [PATCH linux-next] dmaengine: add context parameter fixups
by Fabio Estevam 29 Mar '12

29 Mar '12

On Fri, Mar 23, 2012 at 11:00 AM, Alexandre Bounine <alexandre.bounine(a)idt.com> wrote: > This patch fixes drivers that use device_prep_slave_sg() and > device_prep_dma_cyclic() interfaces and have been missed during the initial > release of interface changing patches. > > This patch is based on linux-next-20120322 code tree. > See https://lkml.org/lkml/2012/3/22/339 for build failure report. > > Signed-off-by: Alexandre Bounine <alexandre.bounine(a)idt.com> > Reported-by: Paul Gortmaker <paul.gortmaker(a)windriver.com> > --- > drivers/dma/sa11x0-dma.c | 2 +- > drivers/net/irda/sa1100_ir.c | 2 +- > sound/soc/sh/fsi.c | 7 +++---- > sound/soc/soc-dmaengine-pcm.c | 2 +- I have already taken care of sound/soc/soc-dmaengine-pcm.c: http://permalink.gmane.org/gmane.linux.alsa.devel/96215

4 10

Re: [alsa-devel] How to cross compile the alsa ?
by Dámaso López 29 Mar '12

29 Mar '12

Yeah, I configure with --enable-static=yes and another parameter : #CC=arm-gp2x-linux ./configure –host=i686.linux –target=arm-gp2x-linux –enable-store=no –enable-static=yes And same make and make install... But when I copy all files in corresponding directory on /usr/arm-gp2x-linux/usr/* after then I compile. But I look errors that not defined reference, I don't undertand, What I do bad?

2 14

[alsa-devel] [PATCH] ASoC: sgtl5000: fix power on/off of MIC bias
by Shawn Guo 29 Mar '12

29 Mar '12

From: Lionel Xu <Lionel.Xu(a)freescale.com> There is no sound in the recorded wav, to enable recording, the VAG should be powered up, and the mic bias resistor should be set up with proper value. Signed-off-by: Lionel Xu <lionel.xu(a)freescale.com> Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> Cc: Zeng Zhaoming <zengzm.kernel(a)gmail.com> --- sound/soc/codecs/sgtl5000.c | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index d192626..a24299c 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -132,11 +132,18 @@ static int mic_bias_event(struct snd_soc_dapm_widget *w, snd_soc_update_bits(w->codec, SGTL5000_CHIP_MIC_CTRL, SGTL5000_BIAS_R_MASK, SGTL5000_BIAS_R_4k << SGTL5000_BIAS_R_SHIFT); + + snd_soc_update_bits(w->codec, SGTL5000_CHIP_ANA_POWER, + SGTL5000_VAG_POWERUP, SGTL5000_VAG_POWERUP); break; case SND_SOC_DAPM_PRE_PMD: snd_soc_update_bits(w->codec, SGTL5000_CHIP_MIC_CTRL, - SGTL5000_BIAS_R_MASK, 0); + SGTL5000_BIAS_R_MASK, + SGTL5000_BIAS_R_off << SGTL5000_BIAS_R_SHIFT); + + snd_soc_update_bits(w->codec, SGTL5000_CHIP_ANA_POWER, + SGTL5000_VAG_POWERUP, 0); break; } return 0; @@ -197,7 +204,7 @@ static const struct snd_soc_dapm_widget sgtl5000_dapm_widgets[] = { SND_SOC_DAPM_OUTPUT("HP_OUT"), SND_SOC_DAPM_OUTPUT("LINE_OUT"), - SND_SOC_DAPM_MICBIAS_E("Mic Bias", SGTL5000_CHIP_MIC_CTRL, 8, 0, + SND_SOC_DAPM_MICBIAS_E("Mic Bias", SND_SOC_NOPM, 0, 0, mic_bias_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), @@ -229,7 +236,8 @@ static const struct snd_soc_dapm_widget sgtl5000_dapm_widgets[] = { /* routes for sgtl5000 */ static const struct snd_soc_dapm_route sgtl5000_dapm_routes[] = { {"Capture Mux", "LINE_IN", "LINE_IN"}, /* line_in --> adc_mux */ - {"Capture Mux", "MIC_IN", "MIC_IN"}, /* mic_in --> adc_mux */ + {"Mic Bias", NULL, "MIC_IN"}, /* mic_in --> mic bias */ + {"Capture Mux", "MIC_IN", "Mic Bias"}, /* mic bias --> adc_mux */ {"ADC", NULL, "Capture Mux"}, /* adc_mux --> adc */ {"AIFOUT", NULL, "ADC"}, /* adc --> i2s_out */ -- 1.7.4.1

4 5

Re: [alsa-devel] trying to get an eleven rack to work
by David Alexander 28 Mar '12

28 Mar '12

---------- Forwarded message ---------- From: "David Alexander" <lidxv0n(a)gmail.com> Date: Mar 27, 2012 10:45 PM Subject: Re: [alsa-devel] trying to get an eleven rack to work To: "Clemens Ladisch" <clemens(a)ladisch.de> Grant & Clemens, Sorry for the delay in getting the dev box set up. Here are the errors listed from the syslog with the suggested additions to quirks-table.h implemented: kernel: [ 74.128035] usb 2-4: new high speed USB device number 2 using ehci_hcd mtp-probe: checking bus 2, device 2: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-4" mtp-probe: bus: 2, device: 2 was not an MTP device kernel: [ 74.634592] ALSA mixer.c:1938 usbaudio: unit 32: unexpected type 0x09 kernel: [ 74.634606] snd-usb-audio: probe of 2-4:1.0 failed with error -5 kernel: [ 74.635228] ALSA mixer.c:1938 usbaudio: unit 32: unexpected type 0x09 kernel: [ 74.635246] snd-usb-audio: probe of 2-4:1.1 failed with error -5 kernel: [ 74.635717] ALSA mixer.c:1938 usbaudio: unit 32: unexpected type 0x09 kernel: [ 74.635732] snd-usb-audio: probe of 2-4:1.2 failed with error -5 kernel: [ 74.636515] ALSA mixer.c:1938 usbaudio: unit 32: unexpected type 0x09 kernel: [ 74.636529] snd-usb-audio: probe of 2-4:1.3 failed with error -5 kernel: [ 74.636973] ALSA mixer.c:1938 usbaudio: unit 32: unexpected type 0x09 kernel: [ 74.636986] snd-usb-audio: probe of 2-4:1.4 failed with error -5 kernel: [ 74.637027] usbcore: registered new interface driver snd-usb-audio Thank you, David On Tue, Mar 27, 2012 at 4:57 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote: > Grant Diffey wrote: >> my guess at the interface purposes from David's post are: >> >> Interface 1 is really custom (perhaps some sort of custom control/management thing tho I would of thought they'd use midi sysex for that) > > It's an audio control interface, just marked as vendor-specific. > >> Interface 3 looks like maybe a usb mixer without a descriptor? but that's a guess. > > Interface 3 is audio output. > >> Interface 4 is potentially usb2 audio output // looks similar to the maudioi fast track isosyncronous outputs > > Interface 4 is audio input, it has only an input endpoint. > >> Interface 5 is potentially usb2 audio input. // "" > > There is no interface 5. > >> can USB_DEVICE_VENDOR_SPEC deal with out of order compliant/quirked interfaces or only sequencial?? > > The one has nothing to do with the other. > > > Regards, > Clemens

1 0

[alsa-devel] [PATCH alsa-lib 1/1] doc: Fix typo in PCM formats
by Adrian Knoth 28 Mar '12

28 Mar '12

Of course, 24bit samples are not stored in three bits, but bytes. Signed-off-by: Adrian Knoth <adi(a)drcomp.erfurt.thur.de> diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index ea1afdc..18b43b3 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -209,13 +209,13 @@ The device is physicaly disconnected. It does not accept any I/O calls in this s \section pcm_formats PCM formats The full list of formats present the #snd_pcm_format_t type. -The 24-bit linear samples uses 32-bit physical space, but the sample is -stored in low three bits. Some hardware does not support processing of full +The 24-bit linear samples use 32-bit physical space, but the sample is +stored in the lower three bytes. Some hardware does not support processing of full range, thus you may get the significant bits for linear samples via #snd_pcm_hw_params_get_sbits() function. The example: ICE1712 chips support 32-bit sample processing, but low byte is ignored (playback) or zero (capture). The function snd_pcm_hw_params_get_sbits() -returns 24 in the case. +returns 24 in this case. \section alsa_transfers ALSA transfers -- 1.7.9.1

2 1

[alsa-devel] [patch] ALSA: asihpi - fix return type of hpios_locked_mem_alloc()
by Dan Carpenter 28 Mar '12

28 Mar '12

This function returns zero or -ENOMEM, but because it's type is u16, the -ENOMEM gets changed to 65524. None of the callers care, but lets fix it anyway as a cleanup. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/pci/asihpi/hpi_internal.h b/sound/pci/asihpi/hpi_internal.h index 4cc315d..8c63200 100644 --- a/sound/pci/asihpi/hpi_internal.h +++ b/sound/pci/asihpi/hpi_internal.h @@ -42,7 +42,7 @@ On error *pLockedMemHandle marked invalid, non-zero returned. If this function succeeds, then HpiOs_LockedMem_GetVirtAddr() and HpiOs_LockedMem_GetPyhsAddr() will always succed on the returned handle. */ -u16 hpios_locked_mem_alloc(struct consistent_dma_area *p_locked_mem_handle, +int hpios_locked_mem_alloc(struct consistent_dma_area *p_locked_mem_handle, /**< memory handle */ u32 size, /**< Size in bytes to allocate */ struct pci_dev *p_os_reference diff --git a/sound/pci/asihpi/hpios.c b/sound/pci/asihpi/hpios.c index 2d7d1c2..87f4385 100644 --- a/sound/pci/asihpi/hpios.c +++ b/sound/pci/asihpi/hpios.c @@ -43,7 +43,7 @@ void hpios_delay_micro_seconds(u32 num_micro_sec) On error, return -ENOMEM, and *pMemArea.size = 0 */ -u16 hpios_locked_mem_alloc(struct consistent_dma_area *p_mem_area, u32 size, +int hpios_locked_mem_alloc(struct consistent_dma_area *p_mem_area, u32 size, struct pci_dev *pdev) { /*?? any benefit in using managed dmam_alloc_coherent? */

2 1

Re: [alsa-devel] [PATCH] ASoC: ep93xx-i2s: use devm_* helpers to cleanup probe
by Mark Brown 28 Mar '12

28 Mar '12

On Mon, Mar 26, 2012 at 04:00:17PM -0700, H Hartley Sweeten wrote: > Use the devm_* helpers to cleanup the probe routine. This also eliminates > having to carry the mem value in the private data for the remove. > Signed-off-by: H Hartley Sweeten <hsweeten(a)visionengravers.com> > Cc: Mika Westerberg <mika.westerberg(a)iki.fi> > Cc: Liam Girdwood <lrg(a)ti.com> > Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > Cc: Jaroslav Kysela <perex(a)perex.cz> > CC: Takashi Iwai <tiwai(a)suse.de> > Cc: Vinod Koul <vinod.koul(a)intel.com> Applied, but again please take care of the above.

1 0

Re: [alsa-devel] [PATCH] ASoC: ep93xx-ac97: use devm_* helpers to cleanup probe
by Mark Brown 28 Mar '12

28 Mar '12

On Mon, Mar 26, 2012 at 04:00:08PM -0700, H Hartley Sweeten wrote: > Use the devm_* helpers to cleanup the probe routine. This also eliminates > having to carry the mem and irq values in the private data for the remove. > Signed-off-by: H Hartley Sweeten <hsweeten(a)visionengravers.com> > Cc: Mika Westerberg <mika.westerberg(a)iki.fi> > Cc: Liam Girdwood <lrg(a)ti.com> > Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > Cc: Jaroslav Kysela <perex(a)perex.cz> > CC: Takashi Iwai <tiwai(a)suse.de> Applied, but please: - Think more about your CC list. - Try to avoid putting it in the body of the e-mail.

1 0