November 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 1/2] ASoC: rt298: fix wrong setting of gpio2_en
by Bard Liao 03 Nov '15

03 Nov '15

The register value to enable gpio2 was incorrect. So fix it. Signed-off-by: Bard Liao <bardliao(a)realtek.com> --- sound/soc/codecs/rt298.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt298.c b/sound/soc/codecs/rt298.c index 56e5e1a..b3f795c 100644 --- a/sound/soc/codecs/rt298.c +++ b/sound/soc/codecs/rt298.c @@ -1217,7 +1217,7 @@ static int rt298_i2c_probe(struct i2c_client *i2c, mdelay(10); if (!rt298->pdata.gpio2_en) - regmap_write(rt298->regmap, RT298_SET_DMIC2_DEFAULT, 0x4000); + regmap_write(rt298->regmap, RT298_SET_DMIC2_DEFAULT, 0x40); else regmap_write(rt298->regmap, RT298_SET_DMIC2_DEFAULT, 0); -- 1.8.1.1.439.g50a6b54

2 4

[alsa-devel] [PATCH] mfd: arizona: Add DT binding for irq_gpio property
by Sebastien Jan 03 Nov '15

03 Nov '15

Signed-off-by: Sebastien Jan <sjan(a)baylibre.com> --- drivers/mfd/arizona-core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c index 44cfdbb..23a0f93 100644 --- a/drivers/mfd/arizona-core.c +++ b/drivers/mfd/arizona-core.c @@ -814,6 +814,11 @@ static int arizona_of_get_core_pdata(struct arizona *arizona) count++; } + arizona->pdata.irq_gpio = of_get_named_gpio(arizona->dev->of_node, + "wlf,irq_gpio", 0); + if (arizona->pdata.irq_gpio < 0) + arizona->pdata.irq_gpio = 0; + return 0; } -- 1.9.1

2 2

Re: [alsa-devel] ASoC: Intel: Skylake: Add support for virtual dsp widgets
by Dan Carpenter 03 Nov '15

03 Nov '15

Hello Jeeja KP, This is a semi-automatic email about new static checker warnings. The patch 9a3b9dc636b0: "ASoC: Intel: Skylake: Add support for virtual dsp widgets" from Oct 27, 2015, leads to the following Smatch complaint: sound/soc/intel/skylake/skl-topology.c:453 skl_tplg_bind_sinks() error: we previously assumed 'sink' could be null (see line 452) sound/soc/intel/skylake/skl-topology.c 451 452 if (!sink) ^^^^ New check. Reversed? 453 return skl_tplg_bind_sinks(sink, skl, src_mconfig); ^^^^ This is dereferenced inside the function. 454 455 return 0; regards, dan carpenter

1 0

[alsa-devel] [PATCH] ASoC: wm8960: Fix the Input PGA Mute switch
by JongHo Kim 03 Nov '15

03 Nov '15

Change the xinvert value from 0 to 1 on the "Capture Switch" control WM8960 datasheet is shown as follows: Bit 7 at 00h and 01h register address 1 : Enable Mute, 0 : Disable Mute Signed-off-by: JongHo Kim <furmuwon(a)gmail.com> --- sound/soc/codecs/wm8960.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c index 0563753..5380798 100644 --- a/sound/soc/codecs/wm8960.c +++ b/sound/soc/codecs/wm8960.c @@ -229,7 +229,7 @@ SOC_DOUBLE_R_TLV("Capture Volume", WM8960_LINVOL, WM8960_RINVOL, SOC_DOUBLE_R("Capture Volume ZC Switch", WM8960_LINVOL, WM8960_RINVOL, 6, 1, 0), SOC_DOUBLE_R("Capture Switch", WM8960_LINVOL, WM8960_RINVOL, - 7, 1, 0), + 7, 1, 1), SOC_SINGLE_TLV("Right Input Boost Mixer RINPUT3 Volume", WM8960_INBMIX1, 4, 7, 0, lineinboost_tlv), -- 1.9.1

2 1

[alsa-devel] [PATCH] ASoC: rt5645: Add Mono ADC Boost Gain control
by Ben Zhang 03 Nov '15

03 Nov '15

"Mono ADC Boost Gain" (MX-20h) is a coarse capture volume control with a step of 12dB on the Mono audio path. It is similar to the "STO1 ADC Boost Gain" control on the Stereo1 audio path. Signed-off-by: Ben Zhang <benzh(a)chromium.org> --- sound/soc/codecs/rt5645.c | 3 +++ sound/soc/codecs/rt5645.h | 8 ++++++++ 2 files changed, 11 insertions(+) diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index f046bb8..f8c5e82 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -625,6 +625,9 @@ static const struct snd_kcontrol_new rt5645_snd_controls[] = { SOC_DOUBLE_TLV("STO2 ADC Boost Gain", RT5645_ADC_BST_VOL1, RT5645_STO2_ADC_L_BST_SFT, RT5645_STO2_ADC_R_BST_SFT, 3, 0, adc_bst_tlv), + SOC_DOUBLE_TLV("Mono ADC Boost Gain", RT5645_ADC_BST_VOL2, + RT5645_MONO_ADC_L_BST_SFT, RT5645_MONO_ADC_R_BST_SFT, 3, 0, + adc_bst_tlv), /* I2S2 function select */ SOC_SINGLE("I2S2 Func Switch", RT5645_GPIO_CTRL1, RT5645_I2S2_SEL_SFT, diff --git a/sound/soc/codecs/rt5645.h b/sound/soc/codecs/rt5645.h index 7cea282..9ddba59 100644 --- a/sound/soc/codecs/rt5645.h +++ b/sound/soc/codecs/rt5645.h @@ -322,6 +322,14 @@ #define RT5645_STO2_ADC_COMP_MASK (0x3 << 4) #define RT5645_STO2_ADC_COMP_SFT 4 +/* Mono ADC Boost Volume Control (0x20) */ +#define RT5645_MONO_ADC_L_BST_MASK (0x3 << 14) +#define RT5645_MONO_ADC_L_BST_SFT 14 +#define RT5645_MONO_ADC_R_BST_MASK (0x3 << 12) +#define RT5645_MONO_ADC_R_BST_SFT 12 +#define RT5645_MONO_ADC_COMP_MASK (0x3 << 10) +#define RT5645_MONO_ADC_COMP_SFT 10 + /* Stereo2 ADC Mixer Control (0x26) */ #define RT5645_STO2_ADC_SRC_MASK (0x1 << 15) #define RT5645_STO2_ADC_SRC_SFT 15 -- 2.6.0.rc2.230.g3dd15c0

1 1

[alsa-devel] Noise in tlv320aic3104-based audio system
by Rick Mann 02 Nov '15

02 Nov '15

I have a custom cape on a Beaglebone Black that uses a tlv320aic3104, connected to a tpa3140d2 audio power amp. I currently manually control the /shudown pins on the two ICs, and just turn them on before doing anything else. The system works. But I notice that when I open the output device for writing (via libao), I immediately hear hiss, even before I send any samples to the device. After I close the libao audio device, a few seconds later Linux sends some i2c commands to the tlv320 and it's once again silent. The perceived amplitude of this hiss does not seem to be affected by "amixer set PCM <0 - 127>" calls. Does anyone have any idea where this noise might be coming from? Is it just thermal or other noise in the routing of audio within the tlv320? Is there some configuration or routing I might be able to change to avoid it? Did I screw up somewhere in my circuit design or layout that only manifests when linux configures the chip for operation? Any ideas are appreciated. Thanks. -- Rick Mann rmann(a)latencyzero.com

4 19

[alsa-devel] ASoC: fsl_ssi: How do I gracefully restart after a channel slip is detected?
by Caleb Crome 02 Nov '15

02 Nov '15

Hi Again, I'm definitely making progress towards a fully working FSL SSI port in TDM mode. The TX seems to be fairly robust. However, there is a new problem now. The Rx can overrun, and what happens, I get an Rx channel slip. The DMA consuming data from the fifo is out of sync. I can detect this with the Rx overrun ISR. The question is, how do I restart everything gracefully? I somehow need to tell the DMA to restart on a frame boundary, and I need to restart the SSI, correct? I don't see any similar method to do this in the ESAI driver. Or perhaps I'm missing something and there is a better way to avoid the slip in the first place? Thanks again, -Caleb

2 1

[alsa-devel] fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.
by Caleb Crome 02 Nov '15

02 Nov '15

Hello Arnaud, all, I'm trying to get the i.MX6 SSI working in 16-channel TDM mode. FYI, I'm working with the stock 4.3 kernel at https://github.com/torvalds/linux. When I apply the patch below, the SSI does all configure properly and even starts streaming properly with all the bits in the right place on the SSI pins. However, given a little bit of time and/or IO to the SD card, the bit-stream slips by 1 slot, causing all of the channels to be misaligned. My changes to the SSI driver are very minimal (shown below), and amount to forcing it into network (TDM) mode, and changing the maximum channels, and setting the STCCR DC mask. There is no indication from user space that anything has slipped, so the data stream just continues on shifted by 1 slot. You (Arnaud) mentioned in a previous thread ("Multiple codecs on one sound card for multi-channel sound card"), that I should just have to set channels_max (and presumably the other changes I mentioned), and it'll work mostly. However, it's very unreliable at the moment. Any thoughts to how I can diagnose this problem would be greatly appreciated! So, what happens is this: The SSI Starts sending data like this: SLOT 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DATA 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 But then after time, something slips and without warning it goes to: SLOT 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DATA 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 37c5cd4..73778c2 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -749,7 +749,10 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream, CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK, channels == 1 ? 0 : i2smode); } - + ssi_private->i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET; + regmap_update_bits(regs, CCSR_SSI_SCR, + CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK, + ssi_private->i2s_mode); /* * FIXME: The documentation says that SxCCR[WL] should not be * modified while the SSI is enabled. The only time this can @@ -863,6 +866,15 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev, return -EINVAL; } scr |= ssi_private->i2s_mode; + // Set to 16 slots/frame + regmap_update_bits(regs, CCSR_SSI_STCCR, + CCSR_SSI_SxCCR_DC_MASK, + CCSR_SSI_SxCCR_DC(16)); + + regmap_update_bits(regs, CCSR_SSI_SRCCR, + CCSR_SSI_SxCCR_DC_MASK, + CCSR_SSI_SxCCR_DC(16)); + /* DAI clock inversion */ switch (fmt & SND_SOC_DAIFMT_INV_MASK) { @@ -1084,14 +1099,14 @@ static struct snd_soc_dai_driver fsl_ssi_dai_template = { .playback = { .stream_name = "CPU-Playback", .channels_min = 1, - .channels_max = 2, + .channels_max = 16, .rates = FSLSSI_I2S_RATES, .formats = FSLSSI_I2S_FORMATS, }, .capture = { .stream_name = "CPU-Capture", .channels_min = 1, - .channels_max = 2, + .channels_max = 16, .rates = FSLSSI_I2S_RATES, .formats = FSLSSI_I2S_FORMATS, }, Another thing I have tried is changing the watermark level for the fifo to give the DMA interrupt some extra time. The problem still happens, but seems to be a bit better. The fifo watermark change is this: diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 73778c2..7c2e4b0 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -54,6 +54,8 @@ #include "fsl_ssi.h" #include "imx-pcm.h" +#define WATERMARK 8 + /** * FSLSSI_I2S_RATES: sample rates supported by the I2S * @@ -943,7 +950,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev, * size. */ if (ssi_private->use_dma) - wm = ssi_private->fifo_depth - 2; + wm = ssi_private->fifo_depth - WATERMARK; else wm = ssi_private->fifo_depth; @@ -1260,8 +1267,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev, * We have burstsize be "fifo_depth - 2" to match the SSI * watermark setting in fsl_ssi_startup(). */ - ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2; - ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2; + ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - WATERMARK; + ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - WATERMARK; ssi_private->dma_params_tx.addr = ssi_private->ssi_phys + CCSR_SSI_STX0; ssi_private->dma_params_rx.addr = ssi_private->ssi_phys + CCSR_SSI_SRX0; Thanks, -Caleb

6 60

[alsa-devel] [PATCH] ALSA: hda - Fix lost 4k BDL boundary workaround
by Takashi Iwai 02 Nov '15

02 Nov '15

During the migration to HDA core code, we lost the workaround for 4k BDL boundary. The flag exists in the new hdac_bus, but it's never set. This resulted in the sudden sound stall on some controllers that require this workaround like Creative Recon3D. This patch fixes the issue by setting the flag for such controllers properly. Fixes: ccc98865aa44 ('ALSA: hda - Migrate more hdac_stream codes') Cc: <stable(a)vger.kernel.org> # v4.2+ Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_controller.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index d6b93a20361b..22dbfa563919 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -1060,6 +1060,9 @@ int azx_bus_init(struct azx *chip, const char *model, bus->needs_damn_long_delay = 1; } + if (chip->driver_caps & AZX_DCAPS_4K_BDLE_BOUNDARY) + bus->core.align_bdle_4k = true; + /* AMD chipsets often cause the communication stalls upon certain * sequence like the pin-detection. It seems that forcing the synced * access works around the stall. Grrr... -- 2.6.2

1 0

[alsa-devel] wm8960 sleep time is too long when system suspend
by Zidan Wang 02 Nov '15

02 Nov '15

Hi Mark, In wm8960 codec driver, suspend_bias_off has been enabled. So when system suspend, the wm8960 codec will go to bias off, it will disable VMID and VREF, then sleep 600ms. It seems that 600ms is too long for system suspend. Because the wm8960 datasheet don't mentioned the sleep time, so i want to check with you if we can shorten the sleep time. Best Regards, Zidan Wang

3 4