October 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v4 1/3] ASoC: samsung: arndale: Simplify DAI link initialization
by Sylwester Nawrocki 04 Oct '19

04 Oct '19

There is only one DAI link so we can drop an unnecessary loop statement. Use card->dai_link in place of direct static arndale_rt5631_dai[] array dereference as a prerequisite for adding support for other CODECs. Unnecessary assignment of dai_link->codecs->name to NULL is removed. Reviewed-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Acked-by: Krzysztof Kozlowski <krzk(a)kernel.org> Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- Based on for-next branch from git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound Changes since v2: - none. Changes since v1: - rebased due to reordering patches in the series --- sound/soc/samsung/arndale_rt5631.c | 42 +++++++++++++----------------- 1 file changed, 18 insertions(+), 24 deletions(-) diff --git a/sound/soc/samsung/arndale_rt5631.c b/sound/soc/samsung/arndale_rt5631.c index fd8c6642fb0d..004c84fafad9 100644 --- a/sound/soc/samsung/arndale_rt5631.c +++ b/sound/soc/samsung/arndale_rt5631.c @@ -88,36 +88,30 @@ static void arndale_put_of_nodes(struct snd_soc_card *card) static int arndale_audio_probe(struct platform_device *pdev) { - int n, ret; struct device_node *np = pdev->dev.of_node; struct snd_soc_card *card = &arndale_rt5631; + struct snd_soc_dai_link *dai_link; + int ret; card->dev = &pdev->dev; + dai_link = card->dai_link; + + dai_link->cpus->of_node = of_parse_phandle(np, "samsung,audio-cpu", 0); + if (!dai_link->cpus->of_node) { + dev_err(&pdev->dev, + "Property 'samsung,audio-cpu' missing or invalid\n"); + return -EINVAL; + } - for (n = 0; np && n < ARRAY_SIZE(arndale_rt5631_dai); n++) { - if (!arndale_rt5631_dai[n].cpus->dai_name) { - arndale_rt5631_dai[n].cpus->of_node = of_parse_phandle(np, - "samsung,audio-cpu", n); - - if (!arndale_rt5631_dai[n].cpus->of_node) { - dev_err(&pdev->dev, - "Property 'samsung,audio-cpu' missing or invalid\n"); - return -EINVAL; - } - } - if (!arndale_rt5631_dai[n].platforms->name) - arndale_rt5631_dai[n].platforms->of_node = - arndale_rt5631_dai[n].cpus->of_node; - - arndale_rt5631_dai[n].codecs->name = NULL; - arndale_rt5631_dai[n].codecs->of_node = of_parse_phandle(np, - "samsung,audio-codec", n); - if (!arndale_rt5631_dai[0].codecs->of_node) { - dev_err(&pdev->dev, + if (!dai_link->platforms->name) + dai_link->platforms->of_node = dai_link->cpus->of_node; + + dai_link->codecs->of_node = of_parse_phandle(np, "samsung,audio-codec", 0); + if (!dai_link->codecs->of_node) { + dev_err(&pdev->dev, "Property 'samsung,audio-codec' missing or invalid\n"); - ret = -EINVAL; - goto err_put_of_nodes; - } + ret = -EINVAL; + goto err_put_of_nodes; } ret = devm_snd_soc_register_card(card->dev, card); -- 2.17.1

2 5

[alsa-devel] [PATCH] ASoC: wm_adsp: Don't generate kcontrols without READ flags
by Charles Keepax 04 Oct '19

04 Oct '19

From: Stuart Henderson <stuarth(a)opensource.cirrus.com> User space always expects to be able to read ALSA controls, so ensure no kcontrols are generated without an appropriate READ flag. In the case of a read of such a control zeros will be returned. Signed-off-by: Stuart Henderson <stuarth(a)opensource.cirrus.com> Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- sound/soc/codecs/wm_adsp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c index 85396d920e0a9..9b8bb7bbe945d 100644 --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -1259,8 +1259,7 @@ static unsigned int wmfw_convert_flags(unsigned int in, unsigned int len) } if (in) { - if (in & WMFW_CTL_FLAG_READABLE) - out |= rd; + out |= rd; if (in & WMFW_CTL_FLAG_WRITEABLE) out |= wr; if (in & WMFW_CTL_FLAG_VOLATILE) -- 2.11.0

2 1

[alsa-devel] [PATCH] ASoc: rockchip: i2s: Fix RPM imbalance
by Robin Murphy 04 Oct '19

04 Oct '19

If rockchip_pcm_platform_register() fails, e.g. upon deferring to wait for an absent DMA channel, we return without disabling RPM, which makes subsequent re-probe attempts scream with errors about the unbalanced enable. Don't do that. Fixes: ebb75c0bdba2 ("ASoC: rockchip: i2s: Adjust devm usage") Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- sound/soc/rockchip/rockchip_i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c index af2d5a6124c8..61c984f10d8e 100644 --- a/sound/soc/rockchip/rockchip_i2s.c +++ b/sound/soc/rockchip/rockchip_i2s.c @@ -677,7 +677,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev) ret = rockchip_pcm_platform_register(&pdev->dev); if (ret) { dev_err(&pdev->dev, "Could not register PCM\n"); - return ret; + goto err_suspend; } return 0; -- 2.21.0.dirty

2 1

[alsa-devel] [PATCH 0/6][resend] ASoC: soc-core cleanup - step 3
by Kuninori Morimoto 04 Oct '19

04 Oct '19

Hi Mark Some soc-core cleanup patch step3 are accepted, but not all. These are remains. Kuninori Morimoto (6): ASoC: soc-core: use devm_kzalloc() for rtd ASoC: soc-core: remove soc_remove_dai_links() ASoC: soc-core: add soc_setup_card_name() ASoC: soc-core: use devm_xxx for component related resource ASoC: soc-core: setup card->rtd_num at snd_soc_instantiate_card() ASoC: soc-ops: use snd_soc_card_get_kcontrol() at snd_soc_limit_volume() sound/soc/soc-core.c | 109 +++++++++++++++++++++++++++------------------------ sound/soc/soc-ops.c | 11 +----- 2 files changed, 59 insertions(+), 61 deletions(-) -- 2.7.4 Thank you for your help !! Best regards --- Kuninori Morimoto

3 18

[alsa-devel] [asoc:for-5.5 32/32] sound/soc/codecs/tas2770.c:796:3-8: No need to set .owner here. The core will do it.
by kbuild test robot 04 Oct '19

04 Oct '19

tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5 head: 1a476abc723e644248dba975b71122fcf878703b commit: 1a476abc723e644248dba975b71122fcf878703b [32/32] tas2770: add tas2770 smart PA kernel driver If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp(a)intel.com> coccinelle warnings: (new ones prefixed by >>) >> sound/soc/codecs/tas2770.c:796:3-8: No need to set .owner here. The core will do it. 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: rsnd: Document r8a774b1 bindings
by Biju Das 04 Oct '19

04 Oct '19

Document SoC specific bindings for RZ/G2N (r8a774b1) SoC. Signed-off-by: Biju Das <biju.das(a)bp.renesas.com> --- Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 5c52182..797fd03 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -268,6 +268,7 @@ Required properties: - "renesas,rcar_sound-r8a7745" (RZ/G1E) - "renesas,rcar_sound-r8a77470" (RZ/G1C) - "renesas,rcar_sound-r8a774a1" (RZ/G2M) + - "renesas,rcar_sound-r8a774b1" (RZ/G2N) - "renesas,rcar_sound-r8a774c0" (RZ/G2E) - "renesas,rcar_sound-r8a7778" (R-Car M1A) - "renesas,rcar_sound-r8a7779" (R-Car H1) -- 2.7.4

2 1

Re: [alsa-devel] Custom Kernel driver to open and use another ALSA PCM
by Kai Vehmanen 04 Oct '19

04 Oct '19

Hi, (routing back to alsa-devel, Ed's alsa-devel subscription is still pending so he can't sent to the list, forwarding with his permission) On Fri, 4 Oct 2019, ed nwave wrote: > The example used of a voice changing app was just an illustration of how > I need to connect "my driver" directly to a sound card driver that's > all. I understand the user-space comment entirely. The actual > objective is one common driver ( my PCM driver ) being used by 4 music > applications where I can dynamically switch the output PCM without > restarting the applications or the applications even knowing the output > cards not real. so far this is pretty much directly from original design goals of JACK. But ok, then you mention this: > I must have direct access to audio hardware i.e. hw:1,0 > for applications like RoonReady/ RAAT. So Pulseaudio's out. I require > the ability to Now this can be a problem of course if you cannot modify the apps. The you would have to route this via alsa-lib plugins. > follow ( like and MPD playlist ). As I understand Jack is set for a > certain rate and format at the start when connecting and does not update > rates automatically if the rate of the songs change; can jack connect > directly to hw and handle DSD rates?. This is all part of a headless I've been out of the loop for some years now, but no, I don't think JACK supports these. But you are anyways customizing quite a lot of SW, so you could e.g. consider extending JACK and/or some other audio server for this purpose, or just write a new one. > Other requirements are my applications must have no plugins or dmix and > connect directly to hardware i.e. hw:1,0 - due to rate demands, no > remixing. Another requirement is the latency required by one company to > attain multi-room streaming being about 1ms max, this is for > certification. Finally there's the need to change bit rate settings I think reaching the latency requirement (and not doing mixing) can certainly be done in user-space, so I still read the "need to access harwdare directly" more as "existing user-space components are not suitable for my needs" than a strict requirement for doing this in kernel. But alas, I get your context and I understand these constraints are real for you as well. Just wanted to make sure you have taken good enough look at user-space options. > All that's left for me to do is to connect pipe the data directly to the > driver for the my sound card. Question is can it be done? And if so, > where do I even start? How can I import snd_usb_audio and open it so it > appears a the typical snd_card struct? The longrunning trend has been to push stuff like this to user-space, so you will not find much examples. I haven't done this myself, so I'll let other people make recommendations. I'd start by looking at ALSA OSS emulation and the virtualized drivers we have (like sound/xen/). Br, Kai

1 0

Re: [alsa-devel] kernel freeze regression relating to imx-sdma
by Kevin Groeneveld 04 Oct '19

04 Oct '19

Hi Lucas, Thanks for the feedback. >-----Original Message----- >From: Lucas Stach [mailto:l.stach@pengutronix.de] >Sent: October 3, 2019 5:26 PM >To: Kevin Groeneveld; dmaengine(a)vger.kernel.org >Subject: Re: kernel freeze regression relating to imx-sdma > >Hi Kevin, > >Am Donnerstag, den 03.10.2019, 21:11 +0000 schrieb Kevin Groeneveld: >> We have recently come across an issue which can cause the linux kernel to >> freeze on an iMX6 based system. After bisecting the issue I have found the >> issue is related to the following imx-sdma commits: >> >> 64068853bc77786d1a28abb4087d6a3e93aedbe2 dmaengine: imx-sdma: use GFP_NOWAIT for dma descriptor allocations >> b8603d2a5795c42f78998e70dc792336e0dc20c9 dmaengine: imx-sdma: implement channel termination via worker >> ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0 Revert "dmaengine: imx-sdma: alloclate bd memory from dma pool" >> c06abca69218ac42fa58d1ba7a7b0d9bab5f1b18 Revert "dmaengine: imx-sdma: Use GFP_NOWAIT for dma allocations" >> >> If I revert these four commits the freeze does not happen. The issue is still >> present up to at least v5.3. >> >> The problem seems to be related to overruns when doing an SPDIF capture, >> particularly when there is not actually a valid SPDIF input to the iMX6. When >> the issue occurs the following is (usually) printed on the console (using a v5.0 >> based kernel): >> >> [ 1251.944877] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: >> [ 1251.950823] rcu: (detected by 0, t=2102 jiffies, g=220425, q=0) >> [ 1251.956866] rcu: All QSes seen, last rcu_sched kthread activity 2102 (95117-93015), jiffies_till_next_fqs=1, root ->qsmask 0x0 >> [ 1251.968266] arecord S 0 1916 1908 0x00000002 >> [ 1251.973816] [<8010dcec>] (unwind_backtrace) from [<8010a4c4>] (show_stack+0x10/0x14) >> [ 1251.981596] [<8010a4c4>] (show_stack) from [<8016b314>] (rcu_check_callbacks+0x57c/0x5d8) >> [ 1251.989806] [<8016b314>] (rcu_check_callbacks) from [<8016fe84>] (update_process_times+0x30/0x5c) >> [ 1251.998709] [<8016fe84>] (update_process_times) from [<8017e960>] (tick_sched_timer+0x44/0x94) >> [ 1252.007353] [<8017e960>] (tick_sched_timer) from [<80170a84>] (__hrtimer_run_queues+0xd8/0x160) >> [ 1252.016081] [<80170a84>] (__hrtimer_run_queues) from [<8017103c>] (hrtimer_interrupt+0xdc/0x284) >> [ 1252.024891] [<8017103c>] (hrtimer_interrupt) from [<8010d6c0>] (twd_handler+0x2c/0x38) >> [ 1252.032839] [<8010d6c0>] (twd_handler) from [<80160b34>] (handle_percpu_devid_irq+0x70/0x11c) >> [ 1252.041401] [<80160b34>] (handle_percpu_devid_irq) from [<8015c234>] (generic_handle_irq+0x18/0x28) >> [ 1252.050480] [<8015c234>] (generic_handle_irq) from [<8015c814>] (__handle_domain_irq+0xa0/0xb4) >> [ 1252.059211] [<8015c814>] (__handle_domain_irq) from [<8039098c>] (gic_handle_irq+0x58/0x90) >> [ 1252.067590] [<8039098c>] (gic_handle_irq) from [<80101a0c>] (__irq_svc+0x6c/0x90) >> [ 1252.075085] Exception stack(0x848afe30 to 0x848afe78) >> [ 1252.080155] fe20: 8decf200 00000000 00000000 80b84ac8 >> [ 1252.088354] fe40: 00000000 8decf200 892f7800 00001589 892f7800 00000000 00000000 848ae000 >> [ 1252.096549] fe60: 8d8cf000 848afe80 805721e8 8056aae4 60000013 ffffffff >> [ 1252.103200] [<80101a0c>] (__irq_svc) from [<8056aae4>] (__snd_pcm_stream_unlock_mode+0xc0/0xd8) >> [ 1252.111925] [<8056aae4>] (__snd_pcm_stream_unlock_mode) from [<00000000>] ( (null)) >> [ 1252.119695] rcu: rcu_sched kthread starved for 2102 jiffies! g220425 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 >> [ 1252.129877] rcu: RCU grace-period kthread stack dump: >> [ 1252.134938] rcu_sched R running task 0 10 2 0x00000000 >> [ 1252.142034] [<806eee5c>] (__schedule) from [<806eef80>] (schedule+0x90/0xa0) >> [ 1252.149116] [<806eef80>] (schedule) from [<806f2244>] (schedule_timeout+0x1f0/0x238) >> [ 1252.156891] [<806f2244>] (schedule_timeout) from [<8016940c>] (rcu_gp_kthread+0x550/0x8f0) >> [ 1252.165183] [<8016940c>] (rcu_gp_kthread) from [<8013a358>] (kthread+0x110/0x128) >> [ 1252.172693] [<8013a358>] (kthread) from [<801010e8>] (ret_from_fork+0x14/0x2c) >> [ 1252.179925] Exception stack(0x8f877fb0 to 0x8f877ff8) >> [ 1252.184991] 7fa0: 00000000 00000000 00000000 00000000 >> [ 1252.193187] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> [ 1252.201380] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 >> >> I suspect the issue may not actually be a bug with imx-sdma but a >> race condition elsewhere that is exposed by the four mentioned >> commits. >> >> I did notice that when an SPDIF overrun occurs >> dmaengine_terminate_async is called but dmaengine_synchronize is >> not. Should these calls always be paired? Or is it okay to call >> dmaengine_terminate_async without dmaengine_synchronize in some >> cases? > >Yes, it seems this uncovered a bug in the SPDIF driver. Before those >commits the dmaengine_terminate_async in the SDMA driver wasn't really >async, now it is. The API requires that you call dmaengine_synchronize >eventually after the terminate_async before starting any new operations >on the dmaengine. It doesn't necessarily need to be in the same >codepath, but the the async terminate always needs to be paired up with >a synchronize. I don't think the bug is limited to SPDIF. The calls to dmaengine_terminate_async are in sound/core/pcm_dmaengine.c. When the ALSA device is closed it does call dmaengine_synchronize. But when there is an overrun it does not. It was commit bc0e7345168c0f7483d2d1da86285d89136417cd (by Lars-Peter Clausen) where the call to dmaengine_synchronize was added for closing an ALSA device. It seems the overrun case was overlooked? I think maybe I should copy the ALSA list on this as well. I have also found another manifestation of the imx-sdma change which may be useful for others trying to debug this. If I run the following command: arecord -Dhw:4,0 -fS24_LE -c2 -r44100 --buffer-size 100 > /dev/null With kernel v4.20-rc5 I get an endless stream of overrun messages. With kernel v4.20-rc6 (which includes the four imx-sdma commits mentioned above) I get a few overrun messages but then arecord exits with "arecord: pcm_read:2096: read error: Input/output error" Best regards, Kevin

1 0

[alsa-devel] Custom Kernel driver to open and use another ALSA PCM
by ed nwave 04 Oct '19

04 Oct '19

Hello, A little bit of an unorthodox request but I need my custom PCM driver to connect directly to another PCM driver if possible. I have an application that already sees my custom PCM driver as the connected sound card, but I also need to pipe the PCM data within my driver after altering it out to another PCM of my choice ( my actual sound card ). As an example, my PCM driver acts as a sound card connected to a microphone capture application, within the my custom PCM I've added various "dalek" and other voice changing alterations and now I need to output this stream into my actual sound card. The sound card I need my driver to import or connect to is a DAC over USB and I believe the loaded kernel module is snd_sub_audio which I can see via lsmod. It's PCM hw:1,0. So is this possible? An if so, how? Even the most basic information would be appreciated. Thanks.

2 1

[alsa-devel] Making alsamixer configurable, adding mouse support + minor fixes ...
by GitHub pull_request - opened 03 Oct '19

03 Oct '19

alsa-project/alsa-utils pull request #28 was opened from braph: ... continued from PR #26 ... Request URL : https://github.com/alsa-project/alsa-utils/pull/28 Patch URL : https://github.com/alsa-project/alsa-utils/pull/28.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0