March 2022 - Alsa-devel - mailman.alsa-project.org

[PATCH] soundwire: qcom: fix build failures if CONFIG_PM=n
by Srinivas Kandagatla 03 Mar '22

03 Mar '22

Fix below build failure drivers/soundwire/qcom.c:1460:12: error: 'swrm_runtime_resume' defined but not used [-Werror=unused-function] by marking the resume swrm_runtime_resume() with __maybe_unused attribute. Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- drivers/soundwire/qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index e893aee1b057..6575695cd400 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -1459,7 +1459,7 @@ static bool swrm_wait_for_frame_gen_enabled(struct qcom_swrm_ctrl *swrm) return false; } -static int swrm_runtime_resume(struct device *dev) +static int __maybe_unused swrm_runtime_resume(struct device *dev) { struct qcom_swrm_ctrl *ctrl = dev_get_drvdata(dev); int ret; -- 2.21.0

2 2

Issue in pcm_dsnoop.c in alsa-lib
by Shengjiu Wang 03 Mar '22

03 Mar '22

Hi Takashi Iwai, Jaroslav Kysela We encountered an issue in the pcm_dsnoop use case, could you please help to have a look? *Issue description:* With two instances for dsnoop type device running in parallel, after suspend/resume, one of the instances will be hung in memcpy because the very large copy size is obtained. #3 0x0000ffffa78d5098 in snd_pcm_dsnoop_sync_ptr (pcm=0xaaab06563da0) at pcm_dsnoop.c:158 dsnoop = 0xaaab06563c20 slave_hw_ptr = 64 old_slave_hw_ptr = 533120 avail = *187651522444320* * Reason analysis: * The root cause that I analysis is that after suspend/resume, one instance will get the SND_PCM_STATE_SUSPENDED state from slave pcm device, then it will do snd_pcm_prepare() and snd_pcm_start(), which will reset the dsnoop->slave_hw_ptr and the hw_ptr of slave pcm device, then the state of this instance is correct. But another instance may not get the SND_PCM_STATE_SUSPENDED state from slave pcm device because slave device may have been recovered by first instance, so the dsnoop->slave_hw_ptr is not reset. but because hw_ptr of slave pcm device has been reset, so there will be a very large "avail" size. *Solution:* I didn't come up with a fix for this issue, seems there is no easy way to let another instance know this case and reset the dsnoop->slave_hw_ptr, could you please help? Best regards Wang shengjiu

2 1

[PATCH] ASoC: wm8350: Handle error for wm8350_register_irq
by Jiasheng Jiang 03 Mar '22

03 Mar '22

As the potential failure of the wm8350_register_irq(), it should be better to check it and return error if fails. Also, use 'free_' in order to avoid the same code. Fixes: a6ba2b2dabb5 ("ASoC: Implement WM8350 headphone jack detection") Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> --- sound/soc/codecs/wm8350.c | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/wm8350.c b/sound/soc/codecs/wm8350.c index 15d42ce3b21d..0c70bbfbedb5 100644 --- a/sound/soc/codecs/wm8350.c +++ b/sound/soc/codecs/wm8350.c @@ -1483,7 +1483,7 @@ static int wm8350_component_probe(struct snd_soc_component *component) ret = devm_regulator_bulk_get(wm8350->dev, ARRAY_SIZE(priv->supplies), priv->supplies); if (ret != 0) - return ret; + goto err; /* Put the codec into reset if it wasn't already */ wm8350_clear_bits(wm8350, WM8350_POWER_MGMT_5, WM8350_CODEC_ENA); @@ -1537,18 +1537,38 @@ static int wm8350_component_probe(struct snd_soc_component *component) wm8350_clear_bits(wm8350, WM8350_JACK_DETECT, WM8350_JDL_ENA | WM8350_JDR_ENA); - wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_JCK_DET_L, + ret = wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_JCK_DET_L, wm8350_hpl_jack_handler, 0, "Left jack detect", priv); - wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_JCK_DET_R, + if (ret != 0) + goto err; + + ret = wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_JCK_DET_R, wm8350_hpr_jack_handler, 0, "Right jack detect", priv); - wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_MICSCD, + if (ret != 0) + goto free_JCK_DET_L; + + ret = wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_MICSCD, wm8350_mic_handler, 0, "Microphone short", priv); - wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_MICD, + if (ret != 0) + goto free_JCK_DET_R; + + ret = wm8350_register_irq(wm8350, WM8350_IRQ_CODEC_MICD, wm8350_mic_handler, 0, "Microphone detect", priv); + if (ret != 0) + goto free_MICSCD; return 0; + +free_MICSCD: + wm8350_free_irq(wm8350, WM8350_IRQ_CODEC_MICSCD, priv); +free_JCK_DET_R: + wm8350_free_irq(wm8350, WM8350_IRQ_CODEC_JCK_DET_R, priv); +free_JCK_DET_L: + wm8350_free_irq(wm8350, WM8350_IRQ_CODEC_JCK_DET_L, priv); +err: + return ret; } static void wm8350_component_remove(struct snd_soc_component *component) -- 2.25.1

2 1

[PATCH] ASoC: hdac_hda: Avoid unexpected match when pcm_name is "Analog"
by Meng Tang 03 Mar '22

03 Mar '22

pcm name can be "Analog" and "Alt Analog", cpcm->name can be "Analog Codec DAI" and "Alt Analog Codec DAI". When pcm_name is "Analog", "Analog Codec DAI" and "Alt Analog Codec DAI" are both satisfy the 'if (strstr(cpcm->name, pcm_name))' condition, which may cause the returned cpcm to be "Alt Analog Codec DAI". Even if we get the pcm name by id, and "Analog Codec DAI" goes into the loop before "Alt Analog Codec DAI", but I still think we'd better have multiple insurances against unexpected return values. After, we can correctly return the expected result even if other relevant places are changed. Signed-off-by: Meng Tang <tangmeng(a)uniontech.com> --- sound/soc/codecs/hdac_hda.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/hdac_hda.c b/sound/soc/codecs/hdac_hda.c index 667f3df239c7..a9f61c7e44ee 100644 --- a/sound/soc/codecs/hdac_hda.c +++ b/sound/soc/codecs/hdac_hda.c @@ -363,8 +363,13 @@ static struct hda_pcm *snd_soc_find_pcm_from_dai(struct hdac_hda_priv *hda_pvt, } list_for_each_entry(cpcm, &hcodec->pcm_list_head, list) { - if (strstr(cpcm->name, pcm_name)) + if (strstr(cpcm->name, pcm_name)) { + if (strcmp(pcm_name, "Analog") == 0) { + if (strstr(cpcm->name, "Alt Analog")) + continue; + } return cpcm; + } } dev_err(&hcodec->core.dev, "didn't find PCM for DAI %s\n", dai->name); -- 2.20.1

2 1

[v2] ASoC: bt-sco: fix bt-sco-pcm-wb dai widget don't connect to the endpoint
by Jiaxin Yu 03 Mar '22

03 Mar '22

This patch fix the second dai driver's dai widget can't connect to the endpoint. Because "bt-sco-pcm" and "bt-sco-pcm-wb" dai driver have the same stream_name, so it will cause they have the same widget name. Therefor it will just create only one route when do snd_soc_dapm_add_route that only find the widget through the widget name. Signed-off-by: Jiaxin Yu <jiaxin.yu(a)mediatek.com> --- Change from v1: fix build error Hi maintainer, Need your comments. The patch is the one that I think it makes the most sense. Maybe we can define the new stream_name for "bt-sco-pcm-wb" and add the new route. sound/soc/codecs/bt-sco.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/bt-sco.c b/sound/soc/codecs/bt-sco.c index 4d286844e3c8..cf17b9741bd8 100644 --- a/sound/soc/codecs/bt-sco.c +++ b/sound/soc/codecs/bt-sco.c @@ -13,11 +13,15 @@ static const struct snd_soc_dapm_widget bt_sco_widgets[] = { SND_SOC_DAPM_INPUT("RX"), SND_SOC_DAPM_OUTPUT("TX"), + SND_SOC_DAPM_AIF_IN("BT_SCO_RX", "Playback", 0, + SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("BT_SCO_TX", "Capture", 0, + SND_SOC_NOPM, 0, 0), }; static const struct snd_soc_dapm_route bt_sco_routes[] = { - { "Capture", NULL, "RX" }, - { "TX", NULL, "Playback" }, + { "BT_SCO_TX", NULL, "RX" }, + { "TX", NULL, "BT_SCO_RX" }, }; static struct snd_soc_dai_driver bt_sco_dai[] = { -- 2.25.1

2 1

Re: [PATCH] wm8962: add a simple DMIC enable control
by Charles Keepax 03 Mar '22

03 Mar '22

On Wed, Feb 02, 2022 at 12:55:04PM +0100, Martin Kepplinger wrote: > Am Mittwoch, dem 02.02.2022 um 10:46 +0000 schrieb Charles Keepax: > > On Wed, Feb 02, 2022 at 11:17:34AM +0100, Martin Kepplinger wrote: > > > Am Mittwoch, dem 02.02.2022 um 09:53 +0000 schrieb Charles Keepax: > > > > On Tue, Feb 01, 2022 at 04:01:13PM +0100, Martin Kepplinger > > > > wrote: > > > Do you have a code example from a different codec that has roughly > > > what > > > is missing here? (the sound subsystem is new to me) > > > > Full disclosure this is complete untested, but it should be > > pretty close. Let me know if it does the trick and I will send a > > proper patch to the list. I do have a Librem 5 in a draw > > somewhere so can pull that out if we get really stuck, but that > > might have to wait until the weekend :-). > > > > I don't know if you guys are using the analogue bypass paths > > around the digital core on the chip. I think those will still > > work with the mics set to digital, so I have left the routes as > > is, but that might require some checking at some point. > > ok that's great and seems to work! that's luxury. > Excellent glad that is working for you, I will prep up a proper patch and send it to the list. Should get that done tomorrow morning, if I don't manage it this afternoon. > Volume / sensitivity of Analog input is too low, I saw that before. > What would you try to change that? > Hmm... you say you saw this before? I assume the input volume is always low, not just low sometimes? I would probably start by checking the voltage you have on the micbias, make sure that is as expected. Does the signal coming into the IN3R pin look low on a scope or is it just the level after it has been through the ADC on the chip that seems low? The input routing on this chip is pretty byzantine, the output of just "amixer" showing all the controls in the relevant use-case would probably be helpful to look over. I suspect there is a reasonable chance something around the input PGA is not configured to match the hardware, although I am not the most familiar with this part so hard to guess at exactly what off the top of my head. Finally, do you know how much the amplitude is off by? > you can do all of our tasks if you want to :) > Ha! Not sure about that, but happy to help out where I can. Thanks, Charles

2 13

Re: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
by Christian König 03 Mar '22

03 Mar '22

Am 28.02.22 um 20:56 schrieb Linus Torvalds: > On Mon, Feb 28, 2022 at 4:19 AM Christian König > <christian.koenig(a)amd.com> wrote: >> I don't think that using the extra variable makes the code in any way >> more reliable or easier to read. > So I think the next step is to do the attached patch (which requires > that "-std=gnu11" that was discussed in the original thread). > > That will guarantee that the 'pos' parameter of list_for_each_entry() > is only updated INSIDE the for_each_list_entry() loop, and can never > point to the (wrongly typed) head entry. > > And I would actually hope that it should actually cause compiler > warnings about possibly uninitialized variables if people then use the > 'pos' pointer outside the loop. Except > > (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for > inexplicable reasons - possibly because it already expected this > behavior > > (b) when I remove that NULL initializer, I still don't get a warning, > because we've disabled -Wno-maybe-uninitialized since it results in so > many false positives. > > Oh well. > > Anyway, give this patch a look, and at least if it's expanded to do > "(pos) = NULL" in the entry statement for the for-loop, it will avoid > the HEAD type confusion that Jakob is working on. And I think in a > cleaner way than the horrid games he plays. > > (But it won't avoid possible CPU speculation of such type confusion. > That, in my opinion, is a completely different issue) Yes, completely agree. > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. > > Anybody have any ideas? I think we should look at the use cases why code is touching (pos) after the loop. Just from skimming over the patches to change this and experience with the drivers/subsystems I help to maintain I think the primary pattern looks something like this: list_for_each_entry(entry, head, member) { if (some_condition_checking(entry)) break; } do_something_with(entry); So the solution should probably not be to change all those use cases to use more temporary variables, but rather to add a list_find_entry(..., condition) macro and consistently use that one instead. Regards, Christian. > > Linus

12 23

[PATCH] ASoC: mediatek: mt8183: support wb bt audio
by Jiaxin Yu 03 Mar '22

03 Mar '22

This patch use "bt-sco-pcm-wb" codec dai driver for wb bt audio. Signed-off-by: Jiaxin Yu <jiaxin.yu(a)mediatek.com> --- This patch depends on: https://patchwork.kernel.org/project/alsa-devel/patch/20220302013533.29068-… sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c b/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c index b0ec5ebd4f2d..889f9e4a96aa 100644 --- a/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c +++ b/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c @@ -260,7 +260,7 @@ SND_SOC_DAILINK_DEFS(pcm2, SND_SOC_DAILINK_DEFS(i2s0, DAILINK_COMP_ARRAY(COMP_CPU("I2S0")), - DAILINK_COMP_ARRAY(COMP_CODEC("bt-sco", "bt-sco-pcm")), + DAILINK_COMP_ARRAY(COMP_CODEC("bt-sco", "bt-sco-pcm-wb")), DAILINK_COMP_ARRAY(COMP_EMPTY())); SND_SOC_DAILINK_DEFS(i2s1, @@ -291,7 +291,7 @@ SND_SOC_DAILINK_DEFS(i2s3_rt1015p, SND_SOC_DAILINK_DEFS(i2s5, DAILINK_COMP_ARRAY(COMP_CPU("I2S5")), - DAILINK_COMP_ARRAY(COMP_CODEC("bt-sco", "bt-sco-pcm")), + DAILINK_COMP_ARRAY(COMP_CODEC("bt-sco", "bt-sco-pcm-wb")), DAILINK_COMP_ARRAY(COMP_EMPTY())); SND_SOC_DAILINK_DEFS(tdm, @@ -508,7 +508,6 @@ static struct snd_soc_dai_link mt8183_mt6358_ts3a227_dai_links[] = { .no_pcm = 1, .dpcm_capture = 1, .ignore_suspend = 1, - .be_hw_params_fixup = mt8183_i2s_hw_params_fixup, .ops = &mt8183_mt6358_i2s_ops, SND_SOC_DAILINK_REG(i2s0), }, @@ -541,7 +540,6 @@ static struct snd_soc_dai_link mt8183_mt6358_ts3a227_dai_links[] = { .no_pcm = 1, .dpcm_playback = 1, .ignore_suspend = 1, - .be_hw_params_fixup = mt8183_i2s_hw_params_fixup, .ops = &mt8183_mt6358_i2s_ops, SND_SOC_DAILINK_REG(i2s5), }, -- 2.25.1

2 1

[PATCH 0/7 resend] ASoC: fsl_sai: Cleanups and 1:1 bclk:mclk ratio support
by Sascha Hauer 03 Mar '22

03 Mar '22

Resending this with the Cc: list expanded as Nicolin said he doesn't work on FSL platforms at the moment. This series has some updates for the fsl_sai driver: Some general cleanup patches, a bugfix in the ip revision checking and finally the mclk setting is made more accurate and support for 1:1 bclk:mclk setting is added. Ahmad Fatoum (2): ASoC: fsl_sai: simplify register poking in fsl_sai_set_bclk ASoC: fsl_sai: implement 1:1 bclk:mclk ratio support Sascha Hauer (5): ASoC: fsl_sai: Drop unnecessary defines ASoC: fsl_sai: simplify irq return value ASoC: fsl_sai: store full version instead of major/minor ASoC: fsl_sai: Use better variable names ASoC: fsl_sai: use DIV_ROUND_CLOSEST() to calculate divider sound/soc/fsl/fsl_sai.c | 100 ++++++++++++++++++++-------------------- sound/soc/fsl/fsl_sai.h | 9 +--- 2 files changed, 52 insertions(+), 57 deletions(-) -- 2.30.2

1 7

[PATCH 0/2] ASoC: mediatek: mt8192-mt6359: support machine
by Jiaxin Yu 03 Mar '22

03 Mar '22

The series reuses mt8192-mt6359-rt1015-rt5682.c for supporting machine driver with rt1015p speaker amplifier and rt5682s headset codec. Jiaxin Yu (2): ASoC: dt-bindings: mt8192-mt6359: add new compatible for using rt1015p and rt5682 ASoC: mediatek: mt8192: support rt1015p_rt5682s .../sound/mt8192-mt6359-rt1015-rt5682.yaml | 1 + sound/soc/mediatek/Kconfig | 1 + .../mt8192/mt8192-mt6359-rt1015-rt5682.c | 87 +++++++++++++++++-- 3 files changed, 84 insertions(+), 5 deletions(-) -- 2.18.0

2 5