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

[alsa-devel] Error patching file pcm_native.c
by Delusion's Master 20 Nov '24

20 Nov '24

Hi, first of all I apologize in case you receive multiple copies of this message, but I forgot to specify a subject in the original mail. I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c: [..] copying file alsa-kernel/core/info.c patching file info.c copying file alsa-kernel/core/pcm.c patching file pcm.c Hunk #3 succeeded at 739 (offset 2 lines). Hunk #5 succeeded at 954 (offset 2 lines). Hunk #7 succeeded at 1045 (offset 2 lines). copying file alsa-kernel/core/pcm_native.c patching file pcm_native.c Hunk #4 succeeded at 1544 (offset -25 lines). Hunk #5 succeeded at 2827 (offset 12 lines). Hunk #6 succeeded at 2878 (offset 10 lines). Hunk #7 FAILED at 2906. Hunk #8 FAILED at 2922. Hunk #9 succeeded at 2915 (offset -23 lines). Hunk #10 succeeded at 3036 (offset 10 lines). Hunk #11 succeeded at 3027 (offset -23 lines). Hunk #12 succeeded at 3074 (offset 10 lines). Hunk #13 succeeded at 3098 (offset -23 lines). Hunk #14 succeeded at 3143 (offset 10 lines). Hunk #15 succeeded at 3124 (offset -23 lines). Hunk #16 succeeded at 3214 (offset 10 lines). Hunk #17 succeeded at 3208 (offset -23 lines). Hunk #18 succeeded at 3271 (offset 10 lines). Hunk #19 succeeded at 3304 (offset -23 lines). Hunk #20 succeeded at 3386 (offset 10 lines). Hunk #21 succeeded at 3411 (offset -23 lines). Hunk #22 succeeded at 3456 (offset 10 lines). Hunk #23 succeeded at 3450 (offset -23 lines). Hunk #24 succeeded at 3525 (offset 10 lines). Hunk #25 succeeded at 3644 (offset -23 lines). 2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej make[2]: *** [pcm_native.c] Error 1 It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates. I searched for this error and the only relevant report I could find is this one: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html a report from last April. What could the problem be? Thanks _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

3 10

[alsa-devel] [RFC PATCH 00/10] Add support for DMA and audio codec of F1C100s
by Mesih Kilinc 23 Oct '24

23 Oct '24

This is RFC patchset for Allwinner suniv F1C100s to support DMA and audio codec. Allwinner F1C100s has a audio codec that has necessary digital and analog parts. It has r-l headphone output and microphone, line, r-l FM inputs. ADC can capture any inputs and also output channels via mux. Any input channels or DAC samples can feed output channels. Add support for this audio codec. F1C100s utilizes DMA channels to send and receive ADC-DAC samples. So DMA support needed. Patch 1~5 adds support for DMA. Suniv F1C100s has very similar DMA to sun4i. But there is some dissimilarities also. Suniv features a DMA reset bit in clock control unit. It has smaller number of DMA channels. Several registers has different addresses. It's max burst size is 4 instead of 8. Also DMA endpoint numbers are different. Patch 6 adds DMA max burst option to sun4i-codec. Patch 7~8 Add support for suniv F1C100s audio codec. Patch 9 adds audio codec to suniv-f1c100s.dtsi Patch 10 adds audio codec support to Lichee Pi Nano board. Thanks! Mesih Kilinc (10): dma-engine: sun4i: Add a quirk to support different chips dma-engine: sun4i: Add has_reset option to quirk dt-bindings: dmaengine: Add Allwinner suniv F1C100s DMA dma-engine: sun4i: Add support for Allwinner suniv F1C100s ARM: dts: suniv: f1c100s: Add support for DMA ASoC: sun4i-codec: Add DMA Max Burst field dt-bindigs: sound: Add Allwinner suniv F1C100s Audio Codec ASoC: sun4i-codec: Add support for Allwinner suniv F1C100s ARM: dts: suniv: f1c100s: Add support for Audio Codec ARM: dts: suniv: f1c100s: Activate Audio Codec for Lichee Pi Nano .../devicetree/bindings/dma/sun4i-dma.txt | 4 +- .../devicetree/bindings/sound/sun4i-codec.txt | 5 + arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts | 8 + arch/arm/boot/dts/suniv-f1c100s.dtsi | 25 ++ drivers/dma/Kconfig | 4 +- drivers/dma/sun4i-dma.c | 221 ++++++++++-- sound/soc/sunxi/sun4i-codec.c | 371 ++++++++++++++++++++- 7 files changed, 601 insertions(+), 37 deletions(-) -- 2.7.4

5 18

[alsa-devel] unsupported variant of snd_hda_intel
by Alexandre 04 Jul '24

04 Jul '24

Hello, I have an Acer Aspire 4736G laptop. The soundcard that is shipped in this laptop is intel-hda based as shown (actually it's a realtek): cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0x9b300000 irq 46 Basic sound output is correct but few feature are missing: - internal mic seems to be found but do not works. - sound output stop working when trying to send it using HDMI output - heads do not work when plugged neither when forcing pulseaudio to use it. I have an ubuntu 10.10 which is shipped with alsa 1.0.23. I have googled around and tried loading the snd-hda-intel with several parameters () as found in HD-Audio-Models.txt to no avail. cat /proc/asound/pcm 00-00: ALC888 Analog : ALC888 Analog : playback 1 : capture 1 00-01: ALC888 Digital : ALC888 Digital : playback 1 00-03: NVIDIA HDMI : NVIDIA HDMI : playback 1 Where can I begin to help implement the support for this sound card? I have very skills in developement in general but am ready to try if it is not to hard (I supose I can use previous code for similar models).. I just need a shepherd. Thanks

4 4

[alsa-devel] echo-cancellation plugin advice?
by Max Klein 27 Oct '23

27 Oct '23

> Well, asym wouldn't be the answer. Basically you'll need to open two > slave PCMs in one plugin. So, it's no simple filter-type plugin. > It's doable, but not easy as it sounds, I guess. Takashi, can you please further explain why asym is not the solution and what you see as a problem? I am also trying to figure out if it would be possible to create such a plugin for ALSA? I am still searching for some good starting points on how to write an ALSA plugin... Jean-Marc Valin (http://lists.linuxaudio.org/pipermail/linux-audio-dev/2005-June/012454.html) already released his work as part of speex but as far I know there is no plugin that has been made out of it? Thanks for any hint! -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

3 2

[alsa-devel] [PATCH] ALSA: usb-audio: fix spelling mistake "Frequence" -> "Frequency"
by Colin King 02 Oct '20

02 Oct '20

From: Colin Ian King <colin.king(a)canonical.com> There are spelling mistakes in equalizer name fields, fix them. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/usb/mixer_us16x08.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/usb/mixer_us16x08.c b/sound/usb/mixer_us16x08.c index 26ed23b18b77..4f594f9552a8 100644 --- a/sound/usb/mixer_us16x08.c +++ b/sound/usb/mixer_us16x08.c @@ -1119,7 +1119,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQLOWFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ Low Frequence", + .name = "EQ Low Frequency", }, { /* EQ mid low gain */ .kcontrol_new = &snd_us16x08_eq_gain_ctl, @@ -1133,7 +1133,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQLOWMIDFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ MidLow Frequence", + .name = "EQ MidLow Frequency", }, { /* EQ mid low Q */ .kcontrol_new = &snd_us16x08_eq_mid_width_ctl, @@ -1154,7 +1154,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQHIGHMIDFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ MidHigh Frequence", + .name = "EQ MidHigh Frequency", }, { /* EQ mid high Q */ .kcontrol_new = &snd_us16x08_eq_mid_width_ctl, @@ -1175,7 +1175,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQHIGHFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ High Frequence", + .name = "EQ High Frequency", }, }; -- 2.19.1

3 3

[alsa-devel] Attempting to understand odd snd-usb-audio code and behavior
by Keith A. Milner 21 Aug '20

21 Aug '20

Over the last few weeks I've been trying to dig through the snd-usb-audio code to try to get an understanding of it. I've used ftrace and also a local version which I have heavily polluted with kprintf(KERN_INFO statements so I can track what it's doing in practice. I've been playing with this with some USB audio interfaces I have some which work, and some which don't, and trying to understand the differences and, ultimately, what I can do to make the non-functioning ones work. I've got to the point where I have a fairly good understanding of some parts, but I'm struggling to understand why the code is behaving as it does in practice. My observation when plugging the USB device in is that, as expected, it tries to build the audio device, and add components to it including attaching capture and playback streams. It seems to go through this phase without too many surprises, and we get to the standard dmesg output: usbcore: registered new interface driver snd-usb-audio After this, it gets confusing. It seems to open and close the PCMs (e.g, snd_usb_capture_open) several times in a row. Each time it sets up the hardware info, checks and sets the format and then closes the PCM. I don't see anything obviously different between most of these cycles. Here's an example my logging output (hopefully this will make sense): Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Called: pcm.c - snd_usb_capture_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Called: pcm.c - snd_usb_pcm_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Setting up hw info Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Checking format: Aug 22 20:04:16 kerneldev kernel: [ 923.140790] Interface number = 2 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] alt setting = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] alt setting index = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] format type = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] frame size = 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140791] Setting pt=125 ptmin=125 Aug 22 20:04:16 kerneldev kernel: [ 923.140792] Checking for unusual bit rates Aug 22 20:04:16 kerneldev kernel: [ 923.140794] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.140921] Called: pcm.c - snd_usb_hw_params for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Setting format: Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Bytes per period = 8816 Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Frames per period = 1102 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Periods per buffer = 4 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Channels = 2 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Rate = 44100 Aug 22 20:04:16 kerneldev kernel: [ 923.141279] Called: endpoint.c - snd_usb_add_endpoint of type 0 with direction 1 Aug 22 20:04:16 kerneldev kernel: [ 923.141292] Called: pcm.c - snd_usb_pcm_prepare for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141293] Called: pcm.c - configure_endpoint Aug 22 20:04:16 kerneldev kernel: [ 923.141294] Called: endpoint.c - snd_usb_endpoint_set_params for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] Setting endpoint params for endpoint num 142 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] channels=2 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] period bytes=8816 Aug 22 20:04:16 kerneldev kernel: [ 923.141295] frames per period=1102 Aug 22 20:04:16 kerneldev kernel: [ 923.141295] periods per buffer=4 Aug 22 20:04:16 kerneldev kernel: [ 923.141296] Called: endpoint.c - data_ep_set_params for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141301] Called: pcm.c - snd_usb_pcm_prepare for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142768] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.142772] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.142774] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.142830] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.142836] Called: pcm.c - snd_usb_hw_free for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142837] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142846] Called: pcm.c - snd_usb_capture_close for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146760] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.146834] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146838] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.146841] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146845] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146848] Called: pcm.c - snd_usb_capture_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146849] Called: pcm.c - snd_usb_pcm_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146849] Setting up hw info It seems to do this several times, before the behavior changing slightly, as it now starts to try to set the endpoint parameters and seems to leave the stream open. However, it then tries to open the stream and set the endpoint parameters again resulting in errors: Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] Called: endpoint.c - snd_usb_endpoint_set_params for endpoint 142, type 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] Setting endpoint params for endpoint num 142 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] channels=2 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] period bytes=1768 Aug 22 20:22:00 kerneldev kernel: [ 1987.452946] frames per period=221 Aug 22 20:22:00 kerneldev kernel: [ 1987.452946] periods per buffer=593 Aug 22 20:22:00 kerneldev kernel: [ 1987.452947] usb 1-1: Unable to change format on ep #8e: already in use Maybe this is driven by hotplug or something, but it seems to be performing a lot of pointless activities. Eventually it seems to try to open the PCM playback or capture stream (with some devices it opens playback, with others capture) and then checks the pointer: Aug 22 20:22:00 kerneldev kernel: [ 1987.470194] Called: pcm.c - snd_usb_substream_playback_trigger for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470198] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470198] Pointer is 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470656] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470657] Pointer is 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470660] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470660] Pointer is 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473567] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473569] Pointer is 0 The above is from a non-working device. For a working device the pointer increments. Eventually this activity ends: Aug 22 20:22:05 kerneldev kernel: [ 1992.473575] Called: pcm.c - snd_usb_substream_playback_trigger for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473576] Called: endpoint.c - snd_usb_endpoint_stop for endpoint 142, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473578] Called: endpoint.c - snd_usb_endpoint_stop for endpoint 13, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473602] Called: pcm.c - snd_usb_hw_free for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503287] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 142, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503288] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 13, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503323] Called: pcm.c - snd_usb_playback_close for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503656] Called: init.c - snd_card_file_remove This seems as if it might be some sort of test of the PCMs, to make sure they are working. Certainly in non-working devices the pcm_pointer stays at zero and in working devices it increments. It also seems to try harder with some devices than others, even though the device descriptors seem very similar. Can anyone explain any of this to me, particularly why it's exhibiting this behaviour. I've uploaded one of the logs from a non-working device to Pastebin if anyone wants to look at a full example: https://pastebin.com/uBZEuQ57 Also, is this the best way to approach this, or are there other tools/techniques that can help? I've experimented with ftrace and that was useful, but didn't give the level of detail I wanted. Cheers, Keith

3 10

[alsa-devel] [PATCH 0/2 v4] ALSA: pcm: anonymous dup implementation
by Jaroslav Kysela 12 Jun '20

12 Jun '20

This patchset contains the anonymous dup implementation with permissions checking for the ALSA's PCM interface in kernel to enable the restricted DMA sound buffer sharing for the restricted tasks. The code was tested through qemu and it seems to be pretty stable. The initial tinyalsa implementation can be found here: https://github.com/perexg/tinyalsa/commits/anondup v2 of the patches: - change clone parameter to subdevice number for the pcm attach - change SNDRV_PCM_PERM_MAX to SNDRV_PCM_PERM_MASK - the tinyalsa implementation was a little updated (restructured) v3 of the patches: - group integer declarations in snd_pcm_anonymous_dup() - replaced substream->pcm with pcm in snd_pcm_anonymous_dup() - added SNDRV_PCM_PERM_RW check for read/write/readv/writev syscalls v4 of the patches: - more simple restriction control (only two modes - full/buffer) - the tinyalsa implementation follows this change Cc: Phil Burk <philburk(a)google.com> Cc: Zach Riggle <riggle(a)google.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: Baolin Wang <baolin.wang(a)linaro.org> Jaroslav Kysela (2): ALSA: pcm: implement the anonymous dup (inode file descriptor) ALSA: pcm: implement the mmap buffer mode for the anonymous dup include/sound/pcm.h | 10 +++-- include/uapi/sound/asound.h | 6 ++- sound/core/oss/pcm_oss.c | 2 +- sound/core/pcm.c | 13 +++--- sound/core/pcm_compat.c | 1 + sound/core/pcm_native.c | 97 ++++++++++++++++++++++++++++++++++++++++++--- 6 files changed, 110 insertions(+), 19 deletions(-) -- 2.13.6

4 17

[alsa-devel] [PATCH] ASoC: stm32: sai: fix master clock management
by Olivier Moysan 16 Apr '20

16 Apr '20

When master clock is used, master clock rate is set exclusively. Parent clocks of master clock cannot be changed after a call to clk_set_rate_exclusive(). So the parent clock of SAI kernel clock must be set before. Ensure also that exclusive rate operations are balanced in STM32 SAI driver. Signed-off-by: Olivier Moysan <olivier.moysan(a)st.com> --- sound/soc/stm/stm32_sai_sub.c | 64 +++++++++++++++++++++++++++++++------------ 1 file changed, 47 insertions(+), 17 deletions(-) diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c index 3dd54bc54fa1..77aa38183955 100644 --- a/sound/soc/stm/stm32_sai_sub.c +++ b/sound/soc/stm/stm32_sai_sub.c @@ -70,6 +70,7 @@ #define SAI_IEC60958_STATUS_BYTES 24 #define SAI_MCLK_NAME_LEN 32 +#define SAI_RATE_11K 11025 /** * struct stm32_sai_sub_data - private data of SAI sub block (block A or B) @@ -311,6 +312,25 @@ static int stm32_sai_set_clk_div(struct stm32_sai_sub_data *sai, return ret; } +static int stm32_sai_set_parent_clock(struct stm32_sai_sub_data *sai, + unsigned int rate) +{ + struct platform_device *pdev = sai->pdev; + struct clk *parent_clk = sai->pdata->clk_x8k; + int ret; + + if (!(rate % SAI_RATE_11K)) + parent_clk = sai->pdata->clk_x11k; + + ret = clk_set_parent(sai->sai_ck, parent_clk); + if (ret) + dev_err(&pdev->dev, " Error %d setting sai_ck parent clock. %s", + ret, ret == -EBUSY ? + "Active stream rates conflict\n" : "\n"); + + return ret; +} + static long stm32_sai_mclk_round_rate(struct clk_hw *hw, unsigned long rate, unsigned long *prate) { @@ -492,25 +512,29 @@ static int stm32_sai_set_sysclk(struct snd_soc_dai *cpu_dai, struct stm32_sai_sub_data *sai = snd_soc_dai_get_drvdata(cpu_dai); int ret; - if (dir == SND_SOC_CLOCK_OUT) { + if (dir == SND_SOC_CLOCK_OUT && sai->sai_mclk) { ret = regmap_update_bits(sai->regmap, STM_SAI_CR1_REGX, SAI_XCR1_NODIV, (unsigned int)~SAI_XCR1_NODIV); if (ret < 0) return ret; - dev_dbg(cpu_dai->dev, "SAI MCLK frequency is %uHz\n", freq); - sai->mclk_rate = freq; + /* If master clock is used, set parent clock now */ + ret = stm32_sai_set_parent_clock(sai, freq); + if (ret) + return ret; - if (sai->sai_mclk) { - ret = clk_set_rate_exclusive(sai->sai_mclk, - sai->mclk_rate); - if (ret) { - dev_err(cpu_dai->dev, - "Could not set mclk rate\n"); - return ret; - } + ret = clk_set_rate_exclusive(sai->sai_mclk, freq); + if (ret) { + dev_err(cpu_dai->dev, + ret == -EBUSY ? + "Active streams have incompatible rates" : + "Could not set mclk rate\n"); + return ret; } + + dev_dbg(cpu_dai->dev, "SAI MCLK frequency is %uHz\n", freq); + sai->mclk_rate = freq; } return 0; @@ -917,11 +941,13 @@ static int stm32_sai_configure_clock(struct snd_soc_dai *cpu_dai, int div = 0, cr1 = 0; int sai_clk_rate, mclk_ratio, den; unsigned int rate = params_rate(params); + int ret; - if (!(rate % 11025)) - clk_set_parent(sai->sai_ck, sai->pdata->clk_x11k); - else - clk_set_parent(sai->sai_ck, sai->pdata->clk_x8k); + if (!sai->sai_mclk) { + ret = stm32_sai_set_parent_clock(sai, rate); + if (ret) + return ret; + } sai_clk_rate = clk_get_rate(sai->sai_ck); if (STM_SAI_IS_F4(sai->pdata)) { @@ -1080,9 +1106,13 @@ static void stm32_sai_shutdown(struct snd_pcm_substream *substream, regmap_update_bits(sai->regmap, STM_SAI_CR1_REGX, SAI_XCR1_NODIV, SAI_XCR1_NODIV); - clk_disable_unprepare(sai->sai_ck); + /* Release mclk rate only if rate was actually set */ + if (sai->mclk_rate) { + clk_rate_exclusive_put(sai->sai_mclk); + sai->mclk_rate = 0; + } - clk_rate_exclusive_put(sai->sai_mclk); + clk_disable_unprepare(sai->sai_ck); spin_lock_irqsave(&sai->irq_lock, flags); sai->substream = NULL; -- 2.7.4

2 3

[alsa-devel] [PATCH] ASoC: pcm: fix error handling when try_module_get() fails.
by Ranjani Sridharan 16 Apr '20

16 Apr '20

Handle error before returning when try_module_get() fails to prevent inconsistent mutex lock/unlock. Fixes: 52034add7 (ASoC: pcm: update module refcount if module_get_upon_open is set) Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> --- sound/soc/soc-pcm.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index d21247546f7f..be80a12fba27 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -518,8 +518,10 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) continue; if (component->driver->module_get_upon_open && - !try_module_get(component->dev->driver->owner)) - return -ENODEV; + !try_module_get(component->dev->driver->owner)) { + ret = -ENODEV; + goto module_err; + } ret = component->driver->ops->open(substream); if (ret < 0) { @@ -636,7 +638,7 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) component_err: soc_pcm_components_close(substream, component); - +module_err: if (cpu_dai->driver->ops->shutdown) cpu_dai->driver->ops->shutdown(substream, cpu_dai); out: -- 2.17.1

2 5

[alsa-devel] [PATCH] ASoC: wcd9335: Fix missing regmap requirement
by Marc Gonzalez 16 Apr '20

16 Apr '20

wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip' Signed-off-by: Marc Gonzalez <marc.w.gonzalez(a)free.fr> --- sound/soc/codecs/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 419142111b6d..33778dc99108 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -1162,6 +1162,7 @@ config SND_SOC_WCD9335 tristate "WCD9335 Codec" depends on SLIMBUS select REGMAP_SLIMBUS + select REGMAP_IRQ help The WCD9335 is a standalone Hi-Fi audio CODEC IC, supports Qualcomm Technologies, Inc. (QTI) multimedia solutions, -- 2.17.1

3 4