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

[alsa-devel] [PATCH 0/2] ASoC: missing replace platform/codec to component
by Kuninori Morimoto 13 Feb '18

13 Feb '18

Hi Mark These are missing replace platform/codec patches which are not yet accepted (except ac97 issue) uniphier: aio-dmac arizona -- 1.9.1

3 4

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute
by Takashi Iwai 13 Feb '18

13 Feb '18

On Thu, 08 Feb 2018 07:21:36 +0100, Kirill Marinushkin wrote: > > On 02/07/18 06:45, Takashi Iwai wrote: > > On Mon, 29 Jan 2018 06:37:55 +0100, > > Kirill Marinushkin wrote: > >> The layout of the UAC2 Control request and response varies depending on > >> the request type. With the current implementation, only the Layout 2 > >> Parameter Block (with the 2-byte sized RANGE attribute) is handled > >> properly. For the Control requests with the 1-byte sized RANGE attribute > >> (Bass Control, Mid Control, Tremble Control), the response is parsed > >> incorrectly. > >> > >> This commit: > >> * fixes the wLength field value in the request > >> * fixes parsing the range values from the response > >> > >> Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") > >> Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com> > >> Cc: Jaroslav Kysela <perex(a)perex.cz> > >> Cc: Takashi Iwai <tiwai(a)suse.com> > >> Cc: Jaejoong Kim <climbbb.kim(a)gmail.com> > >> Cc: Bhumika Goyal <bhumirks(a)gmail.com> > >> Cc: Stephen Barber <smbarber(a)chromium.org> > >> Cc: Julian Scheel <julian(a)jusst.de> > >> Cc: alsa-devel(a)alsa-project.org > >> Cc: linux-kernel(a)vger.kernel.org > > Sorry for the late reply, as I've been (and still) off. > > > > Does this bug actually hit on any real devices, or is it only a > > logical error so far? In the former case, a Cc to stable is > > mandatory. > > > > In anyway, I'll review and merge it properly once after I back to > > work. > > > > > > thanks, > > > > Takashi > > Hello Takashi, > > Thank you for your answer. I will wait until you are back to work, don't > worry about the late replies. > > I did not hit the issue on a real device. > > During my UAC2 experiments, I reproduced this issue on the development > board, and then tested my solution on it. OK, if it happened on a development system, it's a real issue, and we should put Cc to stable. Now I applied the patch. Thanks! Takashi

2 3

[alsa-devel] [PATCH v3 0/3] add UniPhier audio nodes
by Katsuhiro Suzuki 13 Feb '18

13 Feb '18

This series adds device-tree nodes for Socionext audio system for UniPhier LD11/LD20 SoCs. This one enables I2S output for Line-In, Line-Out, S/PDIF output and compress audio output. Katsuhiro Suzuki (3): arm64: dts: uniphier: add sound node for UniPhier arm64: dts: uniphier: add speaker out for UniPhier LD11/LD20 boards arm64: dts: uniphier: add compress audio out for UniPhier LD11/LD20 .../boot/dts/socionext/uniphier-ld11-global.dts | 62 ++++++++++++++ arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 92 +++++++++++++++++++++ .../boot/dts/socionext/uniphier-ld20-global.dts | 62 ++++++++++++++ arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 96 ++++++++++++++++++++++ 4 files changed, 312 insertions(+) -- 2.15.1

2 4

[alsa-devel] [PATCH] ASoC: tlv320aic31xx: Fix master mode clock I2S bus clocks
by Peter Ujfalusi 13 Feb '18

13 Feb '18

In the reset state of the codec we do not have complete playback or capture routes. The audio playback/capture will not work due to missing clock signals on the I2S bus if PLL, MDAC/NDAC/DAC MADC/NADC/ADC is powered down. To make sure that even if all output/input is disconnected the codec is generating clocks, we need to have valid DAPM route in every case to power up the must needed parts of the codec. I have verified that switching DAC (during playback) or ADC (during capture) will stop the I2S clocks, so the only solution is to connect the 'Off' routes as well to output/input. Tested on am43x-epos-evm with aic3111 codec in master mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/codecs/tlv320aic31xx.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c index 858cb8be445f..d42a23eb916e 100644 --- a/sound/soc/codecs/tlv320aic31xx.c +++ b/sound/soc/codecs/tlv320aic31xx.c @@ -586,9 +586,11 @@ common31xx_audio_map[] = { {"DAC Left Input", "Left Data", "DAC IN"}, {"DAC Left Input", "Right Data", "DAC IN"}, {"DAC Left Input", "Mono", "DAC IN"}, + {"DAC Left Input", "Off", "DAC IN"}, {"DAC Right Input", "Left Data", "DAC IN"}, {"DAC Right Input", "Right Data", "DAC IN"}, {"DAC Right Input", "Mono", "DAC IN"}, + {"DAC Right Input", "Off", "DAC IN"}, {"DAC Left", NULL, "DAC Left Input"}, {"DAC Right", NULL, "DAC Right Input"}, @@ -601,6 +603,9 @@ common31xx_audio_map[] = { {"HP Right", "Switch", "Output Right"}, {"HPR Driver", NULL, "HP Right"}, {"HPR", NULL, "HPR Driver"}, + + {"HPL", NULL, "DAC Left"}, + {"HPR", NULL, "DAC Right"}, }; static const struct snd_soc_dapm_route @@ -621,16 +626,20 @@ aic31xx_audio_map[] = { {"MIC1LP P-Terminal", "FFR 10 Ohm", "MIC1LP"}, {"MIC1LP P-Terminal", "FFR 20 Ohm", "MIC1LP"}, {"MIC1LP P-Terminal", "FFR 40 Ohm", "MIC1LP"}, + {"MIC1LP P-Terminal", "Off", "MIC1LP"}, {"MIC1RP P-Terminal", "FFR 10 Ohm", "MIC1RP"}, {"MIC1RP P-Terminal", "FFR 20 Ohm", "MIC1RP"}, {"MIC1RP P-Terminal", "FFR 40 Ohm", "MIC1RP"}, + {"MIC1RP P-Terminal", "Off", "MIC1RP"}, {"MIC1LM P-Terminal", "FFR 10 Ohm", "MIC1LM"}, {"MIC1LM P-Terminal", "FFR 20 Ohm", "MIC1LM"}, {"MIC1LM P-Terminal", "FFR 40 Ohm", "MIC1LM"}, + {"MIC1LM P-Terminal", "Off", "MIC1LM"}, {"MIC1LM M-Terminal", "FFR 10 Ohm", "MIC1LM"}, {"MIC1LM M-Terminal", "FFR 20 Ohm", "MIC1LM"}, {"MIC1LM M-Terminal", "FFR 40 Ohm", "MIC1LM"}, + {"MIC1LM M-Terminal", "Off", "MIC1LM"}, {"MIC_GAIN_CTL", NULL, "MIC1LP P-Terminal"}, {"MIC_GAIN_CTL", NULL, "MIC1RP P-Terminal"}, -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

4 7

[alsa-devel] ASoC: rsnd: status debug message and its suppress
by Kuninori Morimoto 13 Feb '18

13 Feb '18

Hi Mark Renesas sound driver want to know status when debugging, but sometimes it is too much information. These patches indicate status information when debugging, but we can suppress it by special define Kuninori Morimoto (2): ASoC: rsnd: indicate IRQ error status for debug ASoC: rsnd: suppress rsnd_dai_call() debug message sound/soc/sh/rcar/core.c | 11 ++++++++++- sound/soc/sh/rcar/rsnd.h | 20 ++++++++++++++++++++ sound/soc/sh/rcar/src.c | 22 ++++++++++++++++++++-- sound/soc/sh/rcar/ssi.c | 16 +++++++++++++++- 4 files changed, 65 insertions(+), 4 deletions(-) Best regards --- Kuninori Morimoto

2 4

[alsa-devel] [asoc:topic/uniphier 3/7] sound/soc/uniphier/aio-core.c:907:5: sparse: symbol 'aiodma_rb_get_rp' was not declared. Should it be static?
by kbuild test robot 13 Feb '18

13 Feb '18

tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/uniphier head: db4cb3d04eba91db48da0032c44b83ed7185973c commit: f37fe2f9987b0460f25a87b1380f8e97a5959121 [3/7] ASoC: uniphier: add support for UniPhier AIO common driver reproduce: # apt-get install sparse git checkout f37fe2f9987b0460f25a87b1380f8e97a5959121 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> sound/soc/uniphier/aio-core.c:907:5: sparse: symbol 'aiodma_rb_get_rp' was not declared. Should it be Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 2

[alsa-devel] [asoc:topic/rt5659 1/3] sound/soc/codecs/rt5659.c:4048:6: sparse: symbol 'rt5659_intel_hd_header_probe_setup' was not declared. Should it be static?
by kbuild test robot 13 Feb '18

13 Feb '18

tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/rt5659 head: de86a33253d07675abbb1fa294ffb4f3df6f219e commit: 041e74b71491acadad74b275e8b05add165d92b4 [1/3] ASoC: rt5659: Add the support of Intel HDA Header reproduce: # apt-get install sparse git checkout 041e74b71491acadad74b275e8b05add165d92b4 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> sound/soc/codecs/rt5659.c:4048:6: sparse: symbol 'rt5659_intel_hd_header_probe_setup' was not declared. Should it be Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

2 2

[alsa-devel] [PATCH] ASoC: wm9081: fixup wm9081_digital_mute() reg read
by Kuninori Morimoto 13 Feb '18

13 Feb '18

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit 48c338764296 ("ASoC: wm9081: replace codec to component") replaced codec to component, but it didn't keep WM9081_DAC_DIGITAL_2 value to reg. This patch fixup it. Reported-by: kbuild test robot <fengguang.wu(a)intel.com> Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/codecs/wm9081.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm9081.c b/sound/soc/codecs/wm9081.c index 52dd610..5a0ea7b 100644 --- a/sound/soc/codecs/wm9081.c +++ b/sound/soc/codecs/wm9081.c @@ -1155,7 +1155,7 @@ static int wm9081_digital_mute(struct snd_soc_dai *codec_dai, int mute) struct snd_soc_component *component = codec_dai->component; unsigned int reg; - snd_soc_component_read32(component, WM9081_DAC_DIGITAL_2); + reg = snd_soc_component_read32(component, WM9081_DAC_DIGITAL_2); if (mute) reg |= WM9081_DAC_MUTE; -- 1.9.1

2 1

[alsa-devel] [asoc:topic/wm9705 1/1] sound/soc/codecs/wm9705.c:330:18: error: implicit declaration of function 'snd_soc_new_ac97_component'; did you mean 'snd_soc_new_ac97_codec'?
by kbuild test robot 13 Feb '18

13 Feb '18

tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/wm9705 head: 93ada23cd28b04d50ddd7b3e68a93706dc28b59c commit: 93ada23cd28b04d50ddd7b3e68a93706dc28b59c [1/1] ASoC: wm9705: replace codec to component config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 93ada23cd28b04d50ddd7b3e68a93706dc28b59c # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): sound/soc/codecs/wm9705.c: In function 'wm9705_soc_probe': >> sound/soc/codecs/wm9705.c:330:18: error: implicit declaration of function 'snd_soc_new_ac97_component'; did you mean 'snd_soc_new_ac97_codec'? [-Werror=implicit-function-declaration] wm9705->ac97 = snd_soc_new_ac97_component(component, WM9705_VENDOR_ID, ^~~~~~~~~~~~~~~~~~~~~~~~~~ snd_soc_new_ac97_codec >> sound/soc/codecs/wm9705.c:330:16: warning: assignment makes pointer from integer without a cast [-Wint-conversion] wm9705->ac97 = snd_soc_new_ac97_component(component, WM9705_VENDOR_ID, ^ >> sound/soc/codecs/wm9705.c:339:4: error: implicit declaration of function 'snd_soc_free_ac97_component'; did you mean 'snd_soc_free_ac97_codec'? [-Werror=implicit-function-declaration] snd_soc_free_ac97_component(wm9705->ac97); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ snd_soc_free_ac97_codec cc1: some warnings being treated as errors vim +330 sound/soc/codecs/wm9705.c 319 320 static int wm9705_soc_probe(struct snd_soc_component *component) 321 { 322 struct wm9705_priv *wm9705 = snd_soc_component_get_drvdata(component); 323 struct regmap *regmap; 324 325 if (wm9705->mfd_pdata) { 326 wm9705->ac97 = wm9705->mfd_pdata->ac97; 327 regmap = wm9705->mfd_pdata->regmap; 328 } else { 329 #ifdef CONFIG_SND_SOC_AC97_BUS > 330 wm9705->ac97 = snd_soc_new_ac97_component(component, WM9705_VENDOR_ID, 331 WM9705_VENDOR_ID_MASK); 332 if (IS_ERR(wm9705->ac97)) { 333 dev_err(component->dev, "Failed to register AC97 codec\n"); 334 return PTR_ERR(wm9705->ac97); 335 } 336 337 regmap = regmap_init_ac97(wm9705->ac97, &wm9705_regmap_config); 338 if (IS_ERR(regmap)) { > 339 snd_soc_free_ac97_component(wm9705->ac97); 340 return PTR_ERR(regmap); 341 } 342 #endif 343 } 344 345 snd_soc_component_set_drvdata(component, wm9705->ac97); 346 snd_soc_component_init_regmap(component, regmap); 347 348 return 0; 349 } 350 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

4 4

Re: [alsa-devel] [PATCH] ASoC: codecs: Add support for AK4458 DAC driver
by Mark Brown 13 Feb '18

13 Feb '18

On Wed, Jan 31, 2018 at 03:20:09PM +0200, Cosmin-Gabriel Samoila wrote: This looks pretty good overall, I've got some issues below but nothing too major: > +static int ak4458_i2c_remove(struct i2c_client *i2c) > +{ > + ak4458_remove(&i2c->dev); > + pm_runtime_disable(&i2c->dev); It's weird that the runtime PM handling is here and not in the shared code, and that it only exists in the I2C version. Why is this? > +static const struct soc_enum ak4458_dac_enum[] = { > +/*0*/ SOC_ENUM_SINGLE(AK4458_01_CONTROL2, 1, > + ARRAY_SIZE(ak4458_dem_select_texts), > + ak4458_dem_select_texts), > +/*1*/ SOC_ENUM_SINGLE(AK4458_0A_CONTROL6, 0, The fact that you need these comments is why these arrays are a bad idea - just use individually named variables as other drivers do. > +static const struct snd_kcontrol_new ak4458_snd_controls[] = { > + SOC_SINGLE_TLV("AK4458 L1ch Digital Volume", > + AK4458_03_LCHATT, 0/*shift*/, 0xFF/*max value*/, > + 0/*invert*/, latt_tlv), > + SOC_SINGLE_TLV("AK4458 R1ch Digital Volume", > + AK4458_04_RCHATT, 0, 0xFF, 0, ratt_tlv), It'd be more idiomatic to combine these into stereo pairs than have them as single channel controls. > +static const char * const ak4458_dac_select_texts[] = { "OFF", "ON" }; This looks like the users should be switch controls - what's the goal here? > + rstn = snd_soc_read(codec, AK4458_00_CONTROL1); > + rstn &= ~AK4458_RSTN_MASK; > + > + if (bit) > + rstn |= AK4458_RSTN; > + > + snd_soc_write(codec, AK4458_00_CONTROL1, rstn); This looks like an open coded snd_soc_update_bits()? > +static int ak4458_hw_params(struct snd_pcm_substream *substream, > + struct snd_pcm_hw_params *params, > + struct snd_soc_dai *dai) > +{ > + struct snd_soc_codec *codec = dai->codec; > + struct ak4458_priv *ak4458 = snd_soc_codec_get_drvdata(codec); > + u8 format; > + int pcm_width = max(params_physical_width(params), ak4458->slot_width); > + > +#ifdef AK4458_ACKS_USE_MANUAL_MODE > + u8 dfs1, dfs2; > +#endif What's this and why is it a compile time option? > + case 32: > + if (ak4458->fmt == SND_SOC_DAIFMT_I2S) > + format |= AK4458_DIF_32BIT_I2S; > + else if (ak4458->fmt == SND_SOC_DAIFMT_LEFT_J) > + format |= AK4458_DIF_32BIT_MSB; > + else if (ak4458->fmt == SND_SOC_DAIFMT_RIGHT_J) > + format |= AK4458_DIF_32BIT_LSB; > + else if (ak4458->fmt == SND_SOC_DAIFMT_DSP_B) > + format |= AK4458_DIF_32BIT_MSB; > + else > + return -EINVAL; This should be a switch statement. > + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { > + case SND_SOC_DAIFMT_I2S: > + case SND_SOC_DAIFMT_LEFT_J: > + case SND_SOC_DAIFMT_RIGHT_J: > + ak4458->fmt = fmt & SND_SOC_DAIFMT_FORMAT_MASK; > + break; > + case SND_SOC_DAIFMT_DSP_B: > + ak4458->fmt = fmt & SND_SOC_DAIFMT_FORMAT_MASK; > + break; All these cases seem to be the same? > +static int ak4458_trigger(struct snd_pcm_substream *substream, int cmd, > + struct snd_soc_dai *codec_dai) > +{ > + int ret = 0; > + > + dev_dbg(codec_dai->dev, "%s(%d)\n", __func__, __LINE__); > + return ret; > +} Remove empty functions. > + ak4458->mute_gpio = of_get_named_gpio(np, "ak4458,mute_gpio", 0); > + if (gpio_is_valid(ak4458->mute_gpio)) { Given that this is new code it'd be better to use GPIO descriptors, this will also allow support for non-DT systems - use devm_gpiod_get() and the matching APIs.

2 4