July 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Applied "ASoC: adau171x1: Connect playback DAI to the DSP" to the asoc tree
by Mark Brown 09 Jul '18

09 Jul '18

The patch ASoC: adau171x1: Connect playback DAI to the DSP has been applied to the asoc tree at https://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 5bea327962fa296efd16f2d3369dd339ddd7ce6f Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Fri, 6 Jul 2018 16:19:14 +0300 Subject: [PATCH] ASoC: adau171x1: Connect playback DAI to the DSP The playback DAI is connected to the DSP and the DSP might be sourcing signals from the playback stream. Add a DAPM route between the two to make sure that the playback DAI is powered up, when the DSP is active. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/adau17x1.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/adau17x1.c b/sound/soc/codecs/adau17x1.c index ae41edd1c406..57169b8ff14e 100644 --- a/sound/soc/codecs/adau17x1.c +++ b/sound/soc/codecs/adau17x1.c @@ -299,6 +299,7 @@ static const struct snd_soc_dapm_route adau17x1_dsp_dapm_routes[] = { { "DSP", NULL, "Left Decimator" }, { "DSP", NULL, "Right Decimator" }, + { "DSP", NULL, "Playback" }, }; static const struct snd_soc_dapm_route adau17x1_no_dsp_dapm_routes[] = { -- 2.18.0.rc2

1 0

[alsa-devel] [PATCH] ASoC: pxa: make SND_PXA_SOC_SSP depend on PLAT_PXA
by Arnd Bergmann 09 Jul '18

09 Jul '18

For the moment, we can't enable CONFIG_SND_PXA_SOC_SSP unless we are building for ARM PXA or MMP: WARNING: unmet direct dependencies detected for PXA_SSP Depends on [n]: PLAT_PXA [=n] Selected by [y]: - SND_PXA_SOC_SSP [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] This adds an explicit dependency for it. Fixes: 0a94cf345740 ("ASoC: pxa: make SND_PXA2XX_SOC_I2S selectable") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/pxa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig index 2fc02c227f69..776e148b0aa2 100644 --- a/sound/soc/pxa/Kconfig +++ b/sound/soc/pxa/Kconfig @@ -34,6 +34,7 @@ config SND_PXA2XX_SOC_I2S config SND_PXA_SOC_SSP tristate "Soc Audio via PXA2xx/PXA3xx SSP ports" + depends on PLAT_PXA select PXA_SSP select SND_PXA2XX_LIB -- 2.9.0

2 1

[alsa-devel] [PATCH] sound: stm32: replace "%p" with "%pK"
by Benjamin Gaignard 09 Jul '18

09 Jul '18

The format specifier "%p" can leak kernel addresses. Use "%pK" instead. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)st.com> --- sound/soc/stm/stm32_adfsdm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/stm/stm32_adfsdm.c b/sound/soc/stm/stm32_adfsdm.c index db73fef3e500..0e9373064032 100644 --- a/sound/soc/stm/stm32_adfsdm.c +++ b/sound/soc/stm/stm32_adfsdm.c @@ -149,7 +149,7 @@ static int stm32_afsdm_pcm_cb(const void *data, size_t size, void *private) unsigned int old_pos = priv->pos; unsigned int cur_size = size; - dev_dbg(rtd->dev, "%s: buff_add :%p, pos = %d, size = %zu\n", + dev_dbg(rtd->dev, "%s: buff_add :%pK, pos = %d, size = %zu\n", __func__, &pcm_buff[priv->pos], priv->pos, size); if ((priv->pos + size) > buff_size) { -- 2.15.0

3 3

[alsa-devel] How to add new sound card with ASoC generic driver
by Riccardo Casagrande 09 Jul '18

09 Jul '18

Hello, I'm new to ALSA and linux in general, I need help from who knows well ALSA due to the tight schedule of the project. I'm working on a Yocto project on NXP i.MX6Quad. The hardware architetture is this: the i.MAX6Quad has 6 output connected to 3 ST FDA2100 and 2 input from ADC. In the first step what I need is simply to enable 6 output and send I2S audio to FDAs. In the second step is required a clock for ADC and enable input ports. I spent days/weeks reading docs, examples etc without success. I understood that working on device tree file and setting a simple audio card with generic codec properly is the answer, but my knowledge is almost nothing. I followed these docs/thread https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bin… https://community.nxp.com/thread/475428 but compiling I have syntax errors on device tree file. There is someone who can help me step by step? Thanks in advance Riccardo

1 0

[alsa-devel] Binding volume and mute switch
by Ladislav Michl 09 Jul '18

09 Jul '18

Hello, to provide almost self descriptive controls to alsamixer I'd like to achive something like this: http://ladislav.michl.sweb.cz/alsamixer1.png Master volume is muted using switch coupled with master volume control, microphone is muted using switch coupled with microphone volume control, etc... For mic and line input is works as expected, but for sidetone and master volume I had to use "proper" names for mixer controls, see bellow: /* Input mixer */ static const struct snd_kcontrol_new max9867_input_mixer_controls[] = { SOC_DAPM_DOUBLE("Mic Switch", MAX9867_INPUTCONFIG, 6, 4, 1, 0), SOC_DAPM_DOUBLE("Line Switch", MAX9867_INPUTCONFIG, 7, 5, 1, 0), }; /* Output mixer */ static const struct snd_kcontrol_new max9867_output_mixer_controls[] = { SOC_DAPM_DOUBLE_R("Line Bypass Switch", MAX9867_LEFTLINELVL, MAX9867_RIGHTLINELVL, 6, 1, 1), }; /* Sidetone mixer */ static const struct snd_kcontrol_new max9867_sidetone_mixer_controls[] = { SOC_DAPM_DOUBLE("Sidetone Switch", MAX9867_SIDETONE, 6, 7, 1, 0), }; /* Line out switch */ static const struct snd_kcontrol_new max9867_line_out_control = SOC_DAPM_DOUBLE_R("Switch", MAX9867_LEFTVOL, MAX9867_RIGHTVOL, 6, 1, 1); static const struct snd_soc_dapm_widget max9867_dapm_widgets[] = { SND_SOC_DAPM_INPUT("MICL"), SND_SOC_DAPM_INPUT("MICR"), SND_SOC_DAPM_INPUT("LINL"), SND_SOC_DAPM_INPUT("LINR"), SND_SOC_DAPM_MIXER("Left Input Mixer", MAX9867_PWRMAN, 6, 1, max9867_input_mixer_controls, ARRAY_SIZE(max9867_input_mixer_controls)), SND_SOC_DAPM_MIXER("Right Input Mixer", MAX9867_PWRMAN, 5, 1, max9867_input_mixer_controls, ARRAY_SIZE(max9867_input_mixer_controls)), SND_SOC_DAPM_ADC("ADCL", "HiFi Capture", MAX9867_PWRMAN, 1, 0), SND_SOC_DAPM_ADC("ADCR", "HiFi Capture", MAX9867_PWRMAN, 0, 0), SND_SOC_DAPM_MIXER("Digital", SND_SOC_NOPM, 0, 0, max9867_sidetone_mixer_controls, ARRAY_SIZE(max9867_sidetone_mixer_controls)), SND_SOC_DAPM_MIXER("Output Mixer", SND_SOC_NOPM, 0, 0, max9867_output_mixer_controls, ARRAY_SIZE(max9867_output_mixer_controls)), SND_SOC_DAPM_DAC("DACL", "HiFi Playback", MAX9867_PWRMAN, 3, 0), SND_SOC_DAPM_DAC("DACR", "HiFi Playback", MAX9867_PWRMAN, 2, 0), SND_SOC_DAPM_SWITCH("Master Playback", SND_SOC_NOPM, 0, 0, &max9867_line_out_control), SND_SOC_DAPM_OUTPUT("LOUT"), SND_SOC_DAPM_OUTPUT("ROUT"), }; static const struct snd_soc_dapm_route max9867_audio_map[] = { {"Left Input Mixer", "Mic Switch", "MICL"}, {"Right Input Mixer", "Mic Switch", "MICR"}, {"Left Input Mixer", "Line Switch", "LINL"}, {"Right Input Mixer", "Line Switch", "LINR"}, {"ADCL", NULL, "Left Input Mixer"}, {"ADCR", NULL, "Right Input Mixer"}, {"Digital", "Sidetone Switch", "ADCL"}, {"Digital", "Sidetone Switch", "ADCR"}, {"DACL", NULL, "Digital"}, {"DACR", NULL, "Digital"}, {"Output Mixer", "Line Bypass Switch", "LINL"}, {"Output Mixer", "Line Bypass Switch", "LINR"}, {"Output Mixer", NULL, "DACL"}, {"Output Mixer", NULL, "DACR"}, {"Master Playback", "Switch", "Output Mixer"}, {"LOUT", NULL, "Master Playback"}, {"ROUT", NULL, "Master Playback"}, }; With other control names than "Digital" for sidetone digital mixer, sidetone switch is shown separately from sidetone volume. The same for master volume switch, which is bind with master volume only once its name is "Master Playback". Is it intended to work this way or there is some other, more elegant way how to bind mute switch with volume control. (above solution seem too fragile to me) Thank you, ladis

1 0

[alsa-devel] Hiding some of the controls defined in codec driver from machine driver context
by Giedrius Trainavičius 09 Jul '18

09 Jul '18

Hello, Is it possible to 'hide' some of the controls of the codec in the machine driver? The codec I'm using exposes many advanced controls which are useful for board developers, but not for the end user, so I'd like to define my own 'simplified' controls, and take care of board specific logic internally in the machine driver. I found this old discussion on the topic: https://www.spinics.net/lists/alsa-devel/msg36386.html - I'm targeting kernel 4.14, maybe there's already some means to achieve this? Thank you! Giedrius.

2 1

Re: [alsa-devel] [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
by Lukas Wunner 09 Jul '18

09 Jul '18

On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote: > Now, I found the audio device will auto suspend even if the gpu is active, > and if I plug in a HDMI device it also do not resume back. > > 1. Did you encounter similar issue before? > 2. audio will auto suspend as default at beginning of boot, is it expect > behaviour? Yes, that's expected. Once you start streaming audio to attached displays, user space opens the codec device and this causes the HDA controller to runtime resume. If the discrete GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio. Do you need to runtime resume the HDA controller even if user space isn't streaming audio? Why, and in which situation exactly? You're saying above that the HDA controller isn't runtime resumed on hotplug of a display. Is that necessary to retrieve ELD or something? I'm not sure if there's code in the HDA driver to acquire a runtime PM ref on HPD, but maybe it's necessary. Or maybe the code is there but somehow no HPD interrupt is received by the HDA driver? Thanks, Lukas

1 0

[alsa-devel] Getting a notification of snd_kcontrol value change, defined in codec, in machine driver
by Giedrius Trainavičius 08 Jul '18

08 Jul '18

Hey, What would be the best way in machine driver to learn about changes of alsa mixer control values? The controls are defined in the codec driver. The intended use case would be to use the current volume setting for the codec on the board to forward to a dedicated microcontroller for visual feedback. I am aware that this could be bridged over via a user space program, but I will have to forward the current PCM stream format to the MCU anyway from hw_params, so ideally I would like all of this functionality contained in the machine driver. Thank you, Giedrius.

3 3

[alsa-devel] [PATCH] slimbus: stream: Fix htmldocs warnings
by Srinivas Kandagatla 07 Jul '18

07 Jul '18

This patch fixes below warning during building htmldoc: slimbus.h:352: warning: Function parameter or member 'name' not described in 'slim_stream_runtime' This patch also removes documentation for state variable in struct slim_stream_runtime which was redundant and removed. Reported-by: kbuild test robot <lkp(a)intel.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/slimbus/slimbus.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/slimbus/slimbus.h b/drivers/slimbus/slimbus.h index 411880f3fc0a..32ac4046154f 100644 --- a/drivers/slimbus/slimbus.h +++ b/drivers/slimbus/slimbus.h @@ -325,9 +325,8 @@ enum slim_transport_protocol { /** * struct slim_stream_runtime - SLIMbus stream runtime instance * - * @dev: Name of the stream + * @name: Name of the stream * @dev: SLIM Device instance associated with this stream - * @state: state of stream * @direction: direction of stream * @prot: Transport protocol used in this stream * @rate: Data rate of samples * -- 2.16.2

1 0

[alsa-devel] Bad header guard in alsa-lib
by Guillaume Blanc 06 Jul '18

06 Jul '18

Hello, While building alsa-lib, I got a redefinition error caused by a bad header guard in pcm_plugin.h. I assume this is a mistake and not a weird include trick, attached is a patch to fix this. Best regards, Guillaume Blanc

2 1