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

[alsa-devel] [PATCH] ASoC: core: remove redundunt address operation for array type variable
by Takashi Sakamoto 13 Mar '17

13 Mar '17

The type of 'struct snd_ctl_elem_value.value.bytes.data' is 'unsigned char[512]'. In C language specification, address operation (&) for this type is just ignored, therefore: struct snd_ctl_elem_value elem_value; printf("%p\n", elem_value.value.bytes.data); printf("%p\n", &elem_value.value.bytes.data); These two evaluation have the same value, a pointer to the first element of the array. This kind of address operation is not good for readers, because it easily brings confusions as an address operations to pointers. For example, struct snd_kcontrol_new template; printf("%p\n", template.name); printf("%p\n", &template.name); These two evaluation have the different value. The former is 'unsigned char *', while the latter is 'unsigned char **'. This commit removes redundant address operation for array type variable to avoid misreading in reader side. Cc: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Fixes: f831b055ecec ("ASoC: core: Add support for masking out parts of coefficient blocks") Signed-off-by: Takashi Sakamoto <takashi.sakamoto(a)miraclelinux.com> --- sound/soc/soc-ops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index 500f98c..76b199b 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -658,11 +658,11 @@ int snd_soc_bytes_get(struct snd_kcontrol *kcontrol, ucontrol->value.bytes.data[0] &= ~params->mask; break; case 2: - ((u16 *)(&ucontrol->value.bytes.data))[0] + ((u16 *)ucontrol->value.bytes.data)[0] &= cpu_to_be16(~params->mask); break; case 4: - ((u32 *)(&ucontrol->value.bytes.data))[0] + ((u32 *)ucontrol->value.bytes.data)[0] &= cpu_to_be32(~params->mask); break; default: -- 2.9.3

2 1

[alsa-devel] [PATCH] ASoC: cs35l35: Fix display revision id
by Axel Lin 13 Mar '17

13 Mar '17

Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/cs35l35.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/cs35l35.c b/sound/soc/codecs/cs35l35.c index 260ed42..9c82e5e 100644 --- a/sound/soc/codecs/cs35l35.c +++ b/sound/soc/codecs/cs35l35.c @@ -1468,7 +1468,7 @@ static int cs35l35_i2c_probe(struct i2c_client *i2c_client, dev_info(&i2c_client->dev, "Cirrus Logic CS35L35 (%x), Revision: %02X\n", devid, - ret & 0xFF); + reg & 0xFF); /* Set the INT Masks for critical errors */ regmap_write(cs35l35->regmap, CS35L35_INT_MASK_1, -- 2.9.3

2 1

[alsa-devel] [PATCH] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode
by Kai-Heng Feng 13 Mar '17

13 Mar '17

HDA mode does not have these issues because necessary workarounds in linux/sound/pci/hda/patch_realtek.c are already applied. So we can leverage these workaournds into rt286. When jack is plugged, it rapidly generates I2C interrupts, which triggers rt286_irq() and rt286_jack_detect(), which causes the noise. alc_fixup_dell_xps13() in patch_realtek.c sets up a pin that can stop the frantic interrupts, hence fixes the click noise. When rt286 is under powersaving state, play a sound with headphone or plug a headphone in will produce a loud crack sound. alc_shutup_dell_xps13() patch_realtek.c mutes the headphone at plugging. Apply the same workaround to LDO2 power event can make the loud crack sound to a more tolerable pop sound. I found that unconditionally apply the workaround to all related power event can help a little further. Link: https://bugzilla.kernel.org/show_bug.cgi?id=112611 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1313434 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/soc/codecs/rt286.c | 67 +++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 63 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/rt286.c b/sound/soc/codecs/rt286.c index 74c0e4e..d041937 100644 --- a/sound/soc/codecs/rt286.c +++ b/sound/soc/codecs/rt286.c @@ -36,6 +36,8 @@ #define RT286_VENDOR_ID 0x10ec0286 #define RT288_VENDOR_ID 0x10ec0288 +#define AMP_OUT_MUTE 0xb080 + struct rt286_priv { struct reg_default *index_cache; int index_cache_size; @@ -47,6 +49,7 @@ struct rt286_priv { struct delayed_work jack_detect_work; int sys_clk; int clk_id; + void (*mute_hpo_func)(struct snd_soc_codec *codec); }; static const struct reg_default rt286_index_def[] = { @@ -472,10 +475,51 @@ static int rt286_set_dmic1_event(struct snd_soc_dapm_widget *w, return 0; } +/* Add HV, VREF and LDO1 event functions to workaround headphone crack noise */ +static int rt286_hv_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm); + struct rt286_priv *rt286 = snd_soc_codec_get_drvdata(codec); + + if (rt286->mute_hpo_func) + rt286->mute_hpo_func(codec); + + return 0; +} + +static int rt286_vref_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm); + struct rt286_priv *rt286 = snd_soc_codec_get_drvdata(codec); + + if (rt286->mute_hpo_func) + rt286->mute_hpo_func(codec); + + return 0; +} + +static int rt286_ldo1_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm); + struct rt286_priv *rt286 = snd_soc_codec_get_drvdata(codec); + + if (rt286->mute_hpo_func) + rt286->mute_hpo_func(codec); + + return 0; +} + static int rt286_ldo2_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm); + struct rt286_priv *rt286 = snd_soc_codec_get_drvdata(codec); + + if (rt286->mute_hpo_func) + rt286->mute_hpo_func(codec); switch (event) { case SND_SOC_DAPM_POST_PMU: @@ -516,16 +560,24 @@ static int rt286_mic1_event(struct snd_soc_dapm_widget *w, return 0; } +static void dell_dino_mute_hpo(struct snd_soc_codec *codec) +{ + snd_soc_write(codec, RT286_SET_AMP_GAIN_HPO, AMP_OUT_MUTE); +} + static const struct snd_soc_dapm_widget rt286_dapm_widgets[] = { SND_SOC_DAPM_SUPPLY_S("HV", 1, RT286_POWER_CTRL1, - 12, 1, NULL, 0), + 12, 1, rt286_hv_event, SND_SOC_DAPM_PRE_PMD | + SND_SOC_DAPM_PRE_PMU), SND_SOC_DAPM_SUPPLY("VREF", RT286_POWER_CTRL1, - 0, 1, NULL, 0), + 0, 1, rt286_vref_event, SND_SOC_DAPM_PRE_PMD | + SND_SOC_DAPM_PRE_PMU), SND_SOC_DAPM_SUPPLY_S("LDO1", 1, RT286_POWER_CTRL2, - 2, 0, NULL, 0), + 2, 0, rt286_ldo1_event, SND_SOC_DAPM_PRE_PMD | + SND_SOC_DAPM_PRE_PMU), SND_SOC_DAPM_SUPPLY_S("LDO2", 2, RT286_POWER_CTRL1, 13, 1, rt286_ldo2_event, SND_SOC_DAPM_PRE_PMD | - SND_SOC_DAPM_POST_PMU), + SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU), SND_SOC_DAPM_SUPPLY("MCLK MODE", RT286_PLL_CTRL1, 5, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("MIC1 Input Buffer", SND_SOC_NOPM, @@ -1190,6 +1242,11 @@ static int rt286_i2c_probe(struct i2c_client *i2c, regmap_update_bits(rt286->regmap, RT286_CBJ_CTRL1, 0xf000, 0xb000); } else { + /* Fix headphone click noise */ + if (dmi_check_system(dmi_dell_dino)) + regmap_write(rt286->regmap, + RT286_MIC1_DET_CTRL, 0x0020); + regmap_update_bits(rt286->regmap, RT286_CBJ_CTRL1, 0xf000, 0x5000); } @@ -1204,6 +1261,7 @@ static int rt286_i2c_probe(struct i2c_client *i2c, mdelay(10); regmap_write(rt286->regmap, RT286_MISC_CTRL1, 0x0000); + /* Power down LDO, VREF */ regmap_update_bits(rt286->regmap, RT286_POWER_CTRL2, 0xc, 0x0); regmap_update_bits(rt286->regmap, RT286_POWER_CTRL1, 0x1001, 0x1001); @@ -1222,6 +1280,7 @@ static int rt286_i2c_probe(struct i2c_client *i2c, RT286_SET_GPIO_DATA, 0x40, 0x40); regmap_update_bits(rt286->regmap, RT286_GPIO_CTRL, 0xc, 0x8); + rt286->mute_hpo_func = dell_dino_mute_hpo; } if (rt286->i2c->irq) { -- 2.10.0

3 7

[alsa-devel] Support for hardware amplifier
by Felix Bruns 13 Mar '17

13 Mar '17

Hi, I am working on embedded device (using an i.MX6 MCU) which has an external amplifier. Unfortunately I could not find much information if and how the gain of hardware amplifiers are controlled by alsa. (The only example for hardware amplification I found is the arcam-av plugin...) Is creating a plugin the recommended way of supporting (external) hardware amplification in alsa? Can somebody clarify or point me to another example? Thanks and kind regards, Felix Bruns ps: Sorry for posting this twice.

2 1

Re: [alsa-devel] [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free}
by Mark Brown 13 Mar '17

13 Mar '17

On Fri, Mar 10, 2017 at 04:24:07PM -0800, Brian Norris wrote: > On Thu, Mar 09, 2017 at 12:09:18PM +0100, Mark Brown wrote: > > Please think hard before including complete backtraces in upstream > > reports, they are very large and contain almost no useful information > > relative to their size so often obscure the relevant content in your > > message. If part of the backtrace is usefully illustrative then it's > > usually better to pull out the relevant sections. > I did think, and I did trim the trace significantly. I believe (or > believed; maybe incorrectly) that much of the remaining context *was* > useful, and that it could have answered some of Kuninori's questions, if > he chose to dig himself. As admitted in the commit message, I don't > really understand all of the relationships here, so it's hard to > highlight "only the relevant sections". Any editing you'd done is really not obvious looking at the trace (the inclusion of the top of the trace with the pgd and so on which really need the image to be useful is a bit of a flag here, as is the bit at the end after the end of the trace). It's certainly not mentioned or referenced. At the very least for probe errors it's generally safe to cut down to just the driver probe function is being called rather than showing the entire device model call stack, it's vanishingly rare for that to be adding anything and it's generally several times deeper than what the driver is doing. > I'm sorry that my post did not meet your standards though. Next time > I'll just post a revert with little context and no attempt to understand > what actually went wrong. Providing changes with little context and no conveyed understanding of exactly what went wrong is a very big part of the reason for complaining about people just splatting backtraces in and certainly not what I was asking for, it's sadly common to see a backtrace provided in lieu of any analysis and it does make the whole thing harder to read. That would be even more problematic than what you sent, I wouldn't have applied such a change at all unless I somehow reverse engineered the analysis. You do have a reasonable analysis of your change in the first couple of lines ("Not all platform drivers have pcm_{new,free} callbacks...") which is why I applied it, it's at least not going to do any harm to check that there's a function being provided.

1 0

[alsa-devel] Applied "ASoC: don't dereference NULL pcm_{new, free}" to the asoc tree
by Mark Brown 13 Mar '17

13 Mar '17

The patch ASoC: don't dereference NULL pcm_{new,free} has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From d6c098a1db468b7fd4635e831f276851dfd8852c Mon Sep 17 00:00:00 2001 From: Brian Norris <briannorris(a)chromium.org> Date: Wed, 8 Mar 2017 15:18:54 -0800 Subject: [PATCH] ASoC: don't dereference NULL pcm_{new,free} Not all platform drivers have pcm_{new,free} callbacks. Seen with a "snd-soc-dummy" codec from sound/soc/rockchip/rk3399_gru_sound.c. Fixes: 99b04f4c4051 ("ASoC: add Component level pcm_new/pcm_free") Signed-off-by: Brian Norris <briannorris(a)chromium.org> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/soc-core.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 6dca408faae3..2722bb0c5573 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -3326,7 +3326,10 @@ static int snd_soc_platform_drv_pcm_new(struct snd_soc_pcm_runtime *rtd) { struct snd_soc_platform *platform = rtd->platform; - return platform->driver->pcm_new(rtd); + if (platform->driver->pcm_new) + return platform->driver->pcm_new(rtd); + else + return 0; } static void snd_soc_platform_drv_pcm_free(struct snd_pcm *pcm) @@ -3334,7 +3337,8 @@ static void snd_soc_platform_drv_pcm_free(struct snd_pcm *pcm) struct snd_soc_pcm_runtime *rtd = pcm->private_data; struct snd_soc_platform *platform = rtd->platform; - platform->driver->pcm_free(pcm); + if (platform->driver->pcm_free) + platform->driver->pcm_free(pcm); } /** -- 2.11.0

1 0

[alsa-devel] Is snd_pcm_hw_constraint_mask64 really needed ?
by Chemsi Mehdi 13 Mar '17

13 Mar '17

Dear ALSA expert , I am working with an alsa codec driver where the driver is calling err = snd_pcm_hw_constraint_mask64(substream->runtime, SNDRV_PCM_HW_PARAM_FORMAT, formats); my driver is already setting format before that so I wonder why this function is called? Looks like it is needed to add audio constraints to substreams at open/startup time, but why ? what can be the issue if I do not call it ? Please explain to me Takashi. Thanks a lot in advance.

2 2

[alsa-devel] Help debugging a sound problem
by Jorge Fernandez Monteagudo 13 Mar '17

13 Mar '17

Hi all, This is my first email to the list. I've joined to it because I don't know where to look for help. We have a iMX6 (ARM) board with a STA559BW audio codec connected by the I2S interface. We are using a 3.14.52 kernel with a custom sta559 codec driver based on the TAS5709 codec driver. Our system has the alsa library 1.0.28. Our application uses SDL 1.2.15 to handle the sound system. When we run the application the sound system works ok, but when we leave the application running without playing any sound for one night then next morning we found the sound is delayed more or less one second from when the sound is played until the sound it's heard. Traces in the SDL audiocallback are ok, the same as when the sound is played ok. Another clue. An 'aplay' executed in another console is played ok with no delay. Another one. If the application process is attached with gdb and then deattached then the sounds works ok again! Any help is welcome in order to begin to debug this situation. Thanks! Jorge

2 1

[alsa-devel] [PATCH v3 0/7] ASoC: add OF-graph base simple-card
by Kuninori Morimoto 13 Mar '17

13 Mar '17

Hi Mark, Rob These are v3 of OF-graph base audio card patch-set. Main difference from v2 is that its name is Audio Graph Card instead of Simple Graph Card. I added 3 OF-graph helper functions for it. 1) - 3) : new OF-graph helper functions 4) - 7) : OF-graph base simple-card Kuninori Morimoto (7): 1) of_graph: add of_graph_get_remote_endpoint() 2) of_graph: add of_graph_get_port_parent() 3) of_graph: add of_graph_get_endpoint_count() 4) ASoC: add snd_soc_get_dai_id() 5) ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai() 6) ASoC: add audio-graph-card document 7) ASoC: add audio-graph-card support .../devicetree/bindings/sound/audio-graph-card.txt | 126 +++++++++ drivers/of/base.c | 60 +++- include/linux/of_graph.h | 21 ++ include/sound/simple_card_utils.h | 10 + include/sound/soc.h | 1 + sound/soc/generic/Kconfig | 8 + sound/soc/generic/Makefile | 2 + sound/soc/generic/audio-graph-card.c | 303 +++++++++++++++++++++ sound/soc/generic/simple-card-utils.c | 36 +++ sound/soc/soc-core.c | 23 ++ 10 files changed, 580 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/audio-graph-card.txt create mode 100644 sound/soc/generic/audio-graph-card.c -- 1.9.1

2 9

Re: [alsa-devel] [PATCH for-4.11] ASoC: don't dereference NULL pcm_{new, free}
by Kuninori Morimoto 13 Mar '17

13 Mar '17

Hi Brian Thank you for your feedback > There are 4 drivers calling that: > > snd_soc_dummy_probe > rt5514_spi_probe > 2 instances of snd_dmaengine_pcm_register, via rockchip_i2s_probe > > Only the latter two seem to run the assignment here: > > if (platform_drv->pcm_new) > platform->component.pcm_new = snd_soc_platform_drv_pcm_new; > > Both snd_soc_dummy_probe and rt5514_spi_probe find ->pcm_new NULL here. Hmm... The crasher was snd_dmaengine_pcm_register's platform ? This means, in your current kernel, dmaengine platform dosn't call its .pcm_new (= dmaengine_pcm_new) somehow ? I'm wondering why ->pcm_new became NULL which exists on probe timing ? Can you check component and driver by this patch ? This is very rough but enough for debug --------------------- diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 5933851..43da1ec 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -3322,6 +3322,10 @@ static int snd_soc_platform_drv_pcm_new(struct snd_soc_pcm_runtime *rtd) { struct snd_soc_platform *platform = rtd->platform; + printk("-------use name: %s, %p\n", + platform->component.name, + platform->driver); + return platform->driver->pcm_new(rtd); } @@ -3356,8 +3360,12 @@ int snd_soc_add_platform(struct device *dev, struct snd_soc_platform *platform, platform->component.probe = snd_soc_platform_drv_probe; if (platform_drv->remove) platform->component.remove = snd_soc_platform_drv_remove; - if (platform_drv->pcm_new) + if (platform_drv->pcm_new) { + printk("-------add name: %s, %p\n", + platform->component.name, + platform->driver); platform->component.pcm_new = snd_soc_platform_drv_pcm_new; + } if (platform_drv->pcm_free) platform->component.pcm_free = snd_soc_platform_drv_pcm_free; ---------------------

1 0