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

[alsa-devel] Applied "ASoC: rsnd: add TDM Split mode support for Document" to the asoc tree
by Mark Brown 06 Nov '18

06 Nov '18

The patch ASoC: rsnd: add TDM Split mode support for Document 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 cf704dc83fd6600758e98ac71769eaeb00dfc770 Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Date: Tue, 6 Nov 2018 05:21:22 +0000 Subject: [PATCH] ASoC: rsnd: add TDM Split mode support for Document This patch adds TDM Split mode support. rsnd driver is assuming audio-graph-scu-card is used for Sound Card. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- .../bindings/sound/renesas,rsnd.txt | 91 +++++++++++++++++++ 1 file changed, 91 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 6ed1a3658ffd..453e8ec2ac78 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -188,6 +188,25 @@ In DMA mode, you can select not to use SSIU by using "no-busif" via SSI. SSIU handles BUSIF which will be used for TDM Split mode. This driver is assuming that audio-graph card will be used. +TDM Split mode merges 4 sounds. You can see 4 sound interface on system, +and these sounds will be merged SSIU/SSI. + + aplay -D plughw:0,0 xxxx.wav & + aplay -D plughw:0,1 xxxx.wav & + aplay -D plughw:0,2 xxxx.wav & + aplay -D plughw:0,3 xxxx.wav + + 2ch 8ch + [MEM] -> [SSIU 30] -+-> [SSIU 3] --> [Codec] + 2ch | + [MEM] -> [SSIU 31] -+ + 2ch | + [MEM] -> [SSIU 32] -+ + 2ch | + [MEM] -> [SSIU 33] -+ + +see "Example: simple sound card for TDM Split" + ============================================= * SSI (Serial Sound Interface) ============================================= @@ -648,6 +667,78 @@ rsnd_tdm: sound { }; }; +============================================= +Example: simple sound card for TDM Split +============================================= + +sound_card: sound { + compatible = "audio-graph-scu-card"; + prefix = "xxxx"; + routing = "xxxx Playback", "DAI0 Playback", + "xxxx Playback", "DAI1 Playback", + "xxxx Playback", "DAI2 Playback", + "xxxx Playback", "DAI3 Playback"; + convert-channels = <8>; /* TDM Split */ + + dais = <&rsnd_port0 /* playback ch1/ch2 */ + &rsnd_port1 /* playback ch3/ch4 */ + &rsnd_port2 /* playback ch5/ch6 */ + &rsnd_port3 /* playback ch7/ch8 */ + >; +}; + +audio-codec { + ... + port { + codec_0: endpoint@1 { + remote-endpoint = <&rsnd_ep0>; + }; + codec_1: endpoint@2 { + remote-endpoint = <&rsnd_ep1>; + }; + codec_2: endpoint@3 { + remote-endpoint = <&rsnd_ep2>; + }; + codec_3: endpoint@4 { + remote-endpoint = <&rsnd_ep3>; + }; + }; +}; + +&rcar_sound { + ... + ports { + rsnd_port0: port@0 { + rsnd_ep0: endpoint { + remote-endpoint = <&codec_0>; + ... + playback = <&ssiu30 &ssi3>; + }; + }; + rsnd_port1: port@1 { + rsnd_ep1: endpoint { + remote-endpoint = <&codec_1>; + ... + playback = <&ssiu31 &ssi3>; + }; + }; + rsnd_port2: port@2 { + rsnd_ep2: endpoint { + remote-endpoint = <&codec_2>; + ... + playback = <&ssiu32 &ssi3>; + }; + }; + rsnd_port3: port@3 { + rsnd_ep3: endpoint { + remote-endpoint = <&codec_3>; + ... + playback = <&ssiu33 &ssi3>; + }; + }; + }; +}; + ============================================= Example: simple sound card for Multi channel ============================================= -- 2.19.0.rc2

1 0

[alsa-devel] [PATCH - dmix v3 0/1] pcm: dmix: Align slave_hw_ptr to slave period boundary
by Timo Wischer 06 Nov '18

06 Nov '18

On 10/30/18 14:21, Takashi Iwai wrote: > Yes, and is this correct? Suppose you start a stream at the position > one sample before the next period (psize * N + (psize-1)). Then > slave_hw_ptr is psize * N. At the next moment, the dpcm->hw.ptr > reaches to psize * (N+1), and snd_pcm_dmix_sync_ptr() gets called. > Then slave_hw_ptr will be updated to psize * (N+1) although only one > sample has been processed? I have created a spreadsheet to simulate the behavior of dmix (see attachment). I used this sheet to test different corner cases with different implementations. Column B-D describes 3 corner cases with the original implementation. Column E-H describes the corner cases with patch v2 applied and column I-L describes the corner cases with patch v3. With patch v3 I was not able to find a corner case which would fail. All our internal audio test are also passing fine. The corner cases are described in the form N*period+period-1 (N+1)period+1 (N+2)period+1 The first line describes the value of dmix->spcm->hw.ptr when snd_pcm_dmix_start() will be called. The second line describes the hw_ptr when poll() returns for the first time and the third line describes the hw_ptr when poll() returns for the second time. In column B is the issue case described when the patch is not applied. snd_pcm_avail() returns 2 frames only (B27) but the buffer only contains 3 frames (B18). Therefore up to 5 frames are available (a buffer size of 8 frames is choosen). The issue case of patch v2 is shown in column H. snd_pcm_avail() returns 7 frames (H46) but the buffer contains still 3 frames (H37). Therefore there are only 5 frames free to overwrite. Do you see any corner cases which I missed or any other drawbacks? Best regards and thanks for your time Timo

3 5

[alsa-devel] [PATCH] ASoC: pxa-ssp: make suspend call resilient against multiple invocations
by Daniel Mack 06 Nov '18

06 Nov '18

The suspend callback is called twice when the machine is suspended, once through the ASoC layer and once through the platform device layer. Make sure not to confuse the clock layer with unbalanced calls, and bail out early if we are already suspended. Signed-off-by: Daniel Mack <daniel(a)zonque.org> --- sound/soc/pxa/pxa-ssp.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c index adcf8ba9d287..fd93706702a6 100644 --- a/sound/soc/pxa/pxa-ssp.c +++ b/sound/soc/pxa/pxa-ssp.c @@ -51,6 +51,7 @@ struct ssp_priv { uint32_t cr1; uint32_t to; uint32_t psp; + bool suspended; #endif }; @@ -142,6 +143,9 @@ static int pxa_ssp_suspend(struct snd_soc_dai *cpu_dai) struct ssp_priv *priv = snd_soc_dai_get_drvdata(cpu_dai); struct ssp_device *ssp = priv->ssp; + if (priv->suspended) + return 0; + if (!cpu_dai->active) clk_prepare_enable(ssp->clk); @@ -152,6 +156,8 @@ static int pxa_ssp_suspend(struct snd_soc_dai *cpu_dai) pxa_ssp_disable(ssp); clk_disable_unprepare(ssp->clk); + priv->suspended = true; + return 0; } @@ -161,6 +167,9 @@ static int pxa_ssp_resume(struct snd_soc_dai *cpu_dai) struct ssp_device *ssp = priv->ssp; uint32_t sssr = SSSR_ROR | SSSR_TUR | SSSR_BCE; + if (!priv->suspended) + return 0; + clk_prepare_enable(ssp->clk); __raw_writel(sssr, ssp->mmio_base + SSSR); @@ -174,6 +183,8 @@ static int pxa_ssp_resume(struct snd_soc_dai *cpu_dai) else clk_disable_unprepare(ssp->clk); + priv->suspended = false; + return 0; } -- 2.17.2

2 1

[alsa-devel] [PATCH] fix the kernel panic due to wrong use the dev memory API
by He, Bo 06 Nov '18

06 Nov '18

skl->dais is allocated with devm_kcalloc, can't free with the krealloc. Memory allocated with devm API is automatically freed on driver detach, Like all other devres resources. Refer to drivers/base/devres.c devm_kmalloc for more details. Signed-off-by: he, bo <bo.he(a)intel.com> --- sound/soc/intel/skylake/skl-pcm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/soc/intel/skylake/skl-pcm.c b/sound/soc/intel/skylake/skl-pcm.c index 823e391..928d314 100644 --- a/sound/soc/intel/skylake/skl-pcm.c +++ b/sound/soc/intel/skylake/skl-pcm.c @@ -1438,7 +1438,8 @@ int skl_platform_register(struct device *dev) } if (!skl->use_tplg_pcm) { - dais = krealloc(skl->dais, sizeof(skl_fe_dai) + + devm_kfree(dev, skl->dais); + dais = devm_kcalloc(dev, skl->dais, sizeof(skl_fe_dai) + sizeof(skl_platform_dai), GFP_KERNEL); if (!dais) { ret = -ENOMEM; @@ -1472,7 +1473,5 @@ int skl_platform_unregister(struct device *dev) } } - kfree(skl->dais); - return 0; } -- 2.7.4

3 4

[alsa-devel] [PATCH] ALSA: hda - Fix incorrect clearance of thinkpad_acpi hooks
by Takashi Iwai 06 Nov '18

06 Nov '18

Since the commit c647f806b8c2 ("ALSA: hda - Allow multiple ADCs for mic mute LED controls") we allow enabling the mic mute LED with multiple ADCs. The commit changed the function return value to be zero or a negative error, while this change was overlooked in the thinkpad_acpi helper code where it still expects a positive return value for success. This eventually leads to a NULL dereference on a system that has only a mic mute LED. This patch corrects the return value check in the corresponding code as well. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201621 Fixes: c647f806b8c2 ("ALSA: hda - Allow multiple ADCs for mic mute LED controls") Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/thinkpad_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/thinkpad_helper.c b/sound/pci/hda/thinkpad_helper.c index 97f49b751e6e..568575b72f2f 100644 --- a/sound/pci/hda/thinkpad_helper.c +++ b/sound/pci/hda/thinkpad_helper.c @@ -58,8 +58,8 @@ static void hda_fixup_thinkpad_acpi(struct hda_codec *codec, removefunc = false; } if (led_set_func(TPACPI_LED_MICMUTE, false) >= 0 && - snd_hda_gen_add_micmute_led(codec, - update_tpacpi_micmute) > 0) + !snd_hda_gen_add_micmute_led(codec, + update_tpacpi_micmute)) removefunc = false; } -- 2.19.1

1 0

[alsa-devel] [PATCH] ASoC: skl: always select SND_SOC_HDAC_HDA
by Arnd Bergmann 06 Nov '18

06 Nov '18

The skylake sound support is written to work both with or without CONFIG_SND_SOC_HDAC_HDA, and uses an #ifdef to decide whether it should link against that. However, this fails with SND_SOC_ALL_CODECS=m or SND_SOC_INTEL_SKL_HDA_DSP_GENERIC_MACH=m when the Skylake support itself is built-in, with this link error: sound/soc/intel/skylake/skl.o: In function `skl_probe': skl.c:(.text+0x56c): undefined reference to `snd_soc_hdac_hda_get_ops' Using an explicit 'select' here simplifies the logic and prevents it from happening, at the cost of always including the compile time dependency. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/intel/Kconfig | 1 + sound/soc/intel/skylake/skl.c | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index 0caa1f4eb94d..c21ce7624af1 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -109,6 +109,7 @@ config SND_SOC_INTEL_SKYLAKE depends on PCI && ACPI select SND_HDA_EXT_CORE select SND_HDA_DSP_LOADER + select SND_SOC_HDAC_HDA select SND_SOC_TOPOLOGY select SND_SOC_INTEL_SST select SND_SOC_ACPI_INTEL_MATCH diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c index 29225623b4b4..1069ee265ce5 100644 --- a/sound/soc/intel/skylake/skl.c +++ b/sound/soc/intel/skylake/skl.c @@ -870,9 +870,7 @@ static int skl_create(struct pci_dev *pci, hbus = skl_to_hbus(skl); bus = skl_to_bus(skl); -#if IS_ENABLED(CONFIG_SND_SOC_HDAC_HDA) ext_ops = snd_soc_hdac_hda_get_ops(); -#endif snd_hdac_ext_bus_init(bus, &pci->dev, &bus_core_ops, io_ops, ext_ops); bus->use_posbuf = 1; skl->pci = pci; -- 2.18.0

5 10

[alsa-devel] plughw behaviour not consistent with hw
by Stefano Antonelli 06 Nov '18

06 Nov '18

Hello list, I'm working on an application that requires a period time of 10ms. The hardware at the other end of the bus is a ulaw codec running at 8kHz. The application runs at 16kHz S16_LE and I was hoping to use the plughw device to do sample rate conversion and ulaw encode/decode. This way the application doesn't need to change to accommodate this ulaw codec. However, it's not working and I don't know how to go about debugging. I'm hoping I can get some pointers here. The problem is best illustrated by this output, first using plughw: alsa_read: 10 alsa_read: 20 alsa_read: 0 alsa_read: 20 alsa_read: 0 alsa_read: 20 alsa_read: 0 alsa_read: 20 alsa_read: 0 alsa_read: 20 It would appear that plughw gives the correct period time on the first call, but then subsequently buffers 2 periods before returning. Using hw with matching sample rate, sample format, and number of samples: alsa_read: 10 alsa_read: 10 alsa_read: 10 alsa_read: 10 alsa_read: 10 alsa_r ead: 10 alsa_read: 10 alsa_read: 10 alsa_read: 10 alsa_read: 10 This code snippet generated the above output: for (i = 0; i < 10; ++i) { gettimeofday(&time1, NULL); err = snd_pcm_readi (capture_handle, buf, NSMP); if (err != NSMP) { printf ("read from audio interface failed " " (%s)\n", snd_strerror (err)); exit (1); } gettimeofday(&time2, NULL); printf("alsa_read: %d\n", getTimeDiff(time1, time2)); } I have tried using the patch from here (without the environment variable switch): http://mailman.alsa-project.org/pipermail/alsa-devel/2008-October/01170 3.html to print out the configuration of plughw's plugin chain, but it generates no output. I've verified the md5sum of the library after compilation and it matches the one I compiled. And I ran ldconfig after replacing libasound.so. So I don't know what's going on there. I definitely call snd_pcm_hw_params() when setting up the capture device. This is using alsa-lib-1.0.25. Does anyone know why plughw might be acting the way it is and how I can get it to deliver 10ms periods? Equally appreciated would be any tips on how to debug this problem. Thanks, Stef

2 1

[alsa-devel] [PATCH][RESEND] ASoC: pcm3168a: remove read-only status register from snd_kcontrol_new
by Kuninori Morimoto 06 Nov '18

06 Nov '18

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> "DACn Zero Flag" and "ADCn Overflow Flag" are read-only status register. These information are needed for driver not for user. Let's remove these from snd_kcontrol_new. There is no detail explanation for these register on datasheet, but, judging from its behavior, it seems these register needs clock to read. Otherwise, I2C returns error. Therefor, amixer command will be failed under non working timing. Without this patch, user often fail amixer command. This patch is tested on R-Car H3 ulcb-kf board, SSI3/4 TDM sound. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- > Mark 2weeks passed. repost this patch sound/soc/codecs/pcm3168a.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/sound/soc/codecs/pcm3168a.c b/sound/soc/codecs/pcm3168a.c index 5f4327f..115f2165 100644 --- a/sound/soc/codecs/pcm3168a.c +++ b/sound/soc/codecs/pcm3168a.c @@ -133,10 +133,6 @@ static const struct snd_kcontrol_new pcm3168a_snd_controls[] = { SOC_DOUBLE("DAC2 Invert Switch", PCM3168A_DAC_INV, 2, 3, 1, 0), SOC_DOUBLE("DAC3 Invert Switch", PCM3168A_DAC_INV, 4, 5, 1, 0), SOC_DOUBLE("DAC4 Invert Switch", PCM3168A_DAC_INV, 6, 7, 1, 0), - SOC_DOUBLE_STS("DAC1 Zero Flag", PCM3168A_DAC_ZERO, 0, 1, 1, 0), - SOC_DOUBLE_STS("DAC2 Zero Flag", PCM3168A_DAC_ZERO, 2, 3, 1, 0), - SOC_DOUBLE_STS("DAC3 Zero Flag", PCM3168A_DAC_ZERO, 4, 5, 1, 0), - SOC_DOUBLE_STS("DAC4 Zero Flag", PCM3168A_DAC_ZERO, 6, 7, 1, 0), SOC_ENUM("DAC Volume Control Type", pcm3168a_dac_volume_type), SOC_ENUM("DAC Volume Rate Multiplier", pcm3168a_dac_att_mult), SOC_ENUM("DAC De-Emphasis", pcm3168a_dac_demp), @@ -176,9 +172,6 @@ static const struct snd_kcontrol_new pcm3168a_snd_controls[] = { SOC_DOUBLE("ADC1 Mute Switch", PCM3168A_ADC_MUTE, 0, 1, 1, 0), SOC_DOUBLE("ADC2 Mute Switch", PCM3168A_ADC_MUTE, 2, 3, 1, 0), SOC_DOUBLE("ADC3 Mute Switch", PCM3168A_ADC_MUTE, 4, 5, 1, 0), - SOC_DOUBLE_STS("ADC1 Overflow Flag", PCM3168A_ADC_OV, 0, 1, 1, 0), - SOC_DOUBLE_STS("ADC2 Overflow Flag", PCM3168A_ADC_OV, 2, 3, 1, 0), - SOC_DOUBLE_STS("ADC3 Overflow Flag", PCM3168A_ADC_OV, 4, 5, 1, 0), SOC_ENUM("ADC Volume Control Type", pcm3168a_adc_volume_type), SOC_ENUM("ADC Volume Rate Multiplier", pcm3168a_adc_att_mult), SOC_ENUM("ADC Overflow Flag Polarity", pcm3168a_adc_ov_pol), -- 2.7.4

1 0

[alsa-devel] aplay: fix description about options for process duration
by GitHub pull_request - opened 06 Nov '18

06 Nov '18

alsa-project/alsa-utils pull request #1 was opened from takaswie: Hi, At present, aplay has two options for duration to process PCM frames. However, the recent one ('--samples') option is not described yet in its manual. Furthermore, '-s' option was used for '--sleep-min' option once and description for this option was left as is. This can puzzle uses. This patchset improves description about options for process duration. Request URL : https://github.com/alsa-project/alsa-utils/pull/1 Patch URL : https://github.com/alsa-project/alsa-utils/pull/1.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[alsa-devel] [PATCH v2 0/3] Huawei laptops WMI & sound fixes
by Ayman Bagabas 05 Nov '18

05 Nov '18

This patch set fixes some of the issues with Huawei laptops. [PATCH v2 1/3] The first patch adds support for missing hotkeys on some models. Some hotkeys, like brightness keys, work out of the box on these models. [PATCH v2 2/3] This one enables the front speakers on the Huawei Matebook X Pro (MBXP). This solves bug 200501 https://bugzilla.kernel.org/show_bug.cgi?id=200501 It simply uses the pins configurations generated by hdajackretast using the settings posted on the bug page https://imgur.com/a/N1xsCVZ [PATCH v2 3/3] This enables the micmute LED on Huawei laptops. It calls an WMI method, using PATCH #1, to turn the micmute LED on/off. Ayman Bagabas (3): x86: add support for Huawei WMI hotkeys. ALSA: hda: fix front speakers on Huawei MBXP. ALSA: hda: add support for Huawei WMI MicMute LED drivers/platform/x86/Kconfig | 13 ++ drivers/platform/x86/Makefile | 1 + drivers/platform/x86/huawei_wmi.c | 224 ++++++++++++++++++++++++++++++ include/linux/huawei_wmi.h | 7 + sound/pci/hda/huawei_wmi_helper.c | 48 +++++++ sound/pci/hda/patch_realtek.c | 28 ++++ 6 files changed, 321 insertions(+) create mode 100644 drivers/platform/x86/huawei_wmi.c create mode 100644 include/linux/huawei_wmi.h create mode 100644 sound/pci/hda/huawei_wmi_helper.c -- 2.17.2

4 13