August 2024 - Alsa-devel - mailman.alsa-project.org

[PATCH v7 0/4] ASoC: grace time for DPCM cleanup
by Kuninori Morimoto 28 Aug '24

28 Aug '24

Hi Mark, Pierre-Louis, Jerome Cc each ASoC driver maintainer This is v7 of DPCM cleanup As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.12 or v6.13 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com [2] https://lore.kernel.org/all/3e67d62d-fe08-4f55-ab5b-ece8a57154f9@linux.inte… Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wmo6dyxg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87msole5wc.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871q5tnuok.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87bk4oqerx.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/8734pctmte.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87r0ctwzr4.wl-kuninori.morimoto.gx@renesas.com v6 -> v7 - based on latest ASoC branch (for-6.12) v5 -> v6 - based on latest ASoC branch v4 -> v5 - typo fix: limition -> limitation - typo fix: catpure -> capture - include Intel patch v3 -> v4 - don't check Codec on DPCM - include Jerome's dpcm_xxx update patch v2 -> v3 - tidyup typo (reuqsts -> requests) - add Tested-by on git-log v1 -> v2 - tidyup Codec check warning output condition Jerome Brunet (1): ASoC: amlogic: do not use dpcm_playback/capture flags Kuninori Morimoto (2): ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition ASoC: remove snd_soc_dai_link_set_capabilities() Pierre-Louis Bossart (1): ASoC: Intel: sof_sdw: use playback/capture_only flags include/sound/soc-dai.h | 1 - include/sound/soc.h | 1 + sound/soc/fsl/imx-card.c | 3 -- sound/soc/generic/audio-graph-card.c | 2 - sound/soc/generic/audio-graph-card2.c | 2 - sound/soc/generic/simple-card.c | 2 - sound/soc/intel/boards/sof_sdw.c | 4 +- sound/soc/meson/axg-card.c | 11 +++-- sound/soc/meson/gx-card.c | 1 - sound/soc/meson/meson-card-utils.c | 4 +- sound/soc/qcom/common.c | 1 - sound/soc/soc-dai.c | 38 ---------------- sound/soc/soc-pcm.c | 65 +++++++++++++++------------ 13 files changed, 47 insertions(+), 88 deletions(-) -- 2.43.0

2 7

[PATCH v6 0/4] ASoC: grace time for DPCM cleanup
by Kuninori Morimoto 28 Aug '24

28 Aug '24

Hi Mark, Pierre-Louis, Jerome Cc each ASoC driver maintainer This is resend of v6 of DPCM cleanup As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.12 or v6.13 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com [2] https://lore.kernel.org/all/3e67d62d-fe08-4f55-ab5b-ece8a57154f9@linux.inte… Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wmo6dyxg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87msole5wc.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871q5tnuok.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87bk4oqerx.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/8734pctmte.wl-kuninori.morimoto.gx@renesas.com v5 -> v6 - based on latest ASoC branch v4 -> v5 - typo fix: limition -> limitation - typo fix: catpure -> capture - include Intel patch v3 -> v4 - don't check Codec on DPCM - include Jerome's dpcm_xxx update patch v2 -> v3 - tidyup typo (reuqsts -> requests) - add Tested-by on git-log v1 -> v2 - tidyup Codec check warning output condition Jerome Brunet (1): ASoC: amlogic: do not use dpcm_playback/capture flags Kuninori Morimoto (2): ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition ASoC: remove snd_soc_dai_link_set_capabilities() Pierre-Louis Bossart (1): ASoC: Intel: sof_sdw: use playback/capture_only flags include/sound/soc-dai.h | 1 - include/sound/soc.h | 1 + sound/soc/fsl/imx-card.c | 3 -- sound/soc/generic/audio-graph-card.c | 2 - sound/soc/generic/audio-graph-card2.c | 2 - sound/soc/generic/simple-card.c | 2 - sound/soc/intel/boards/sof_sdw.c | 4 +- sound/soc/meson/axg-card.c | 11 +++-- sound/soc/meson/gx-card.c | 1 - sound/soc/meson/meson-card-utils.c | 4 +- sound/soc/qcom/common.c | 1 - sound/soc/soc-dai.c | 38 ---------------- sound/soc/soc-pcm.c | 65 +++++++++++++++------------ 13 files changed, 47 insertions(+), 88 deletions(-) -- 2.43.0

2 5

[PATCH v5 0/4] ASoC: grace time for DPCM cleanup
by Kuninori Morimoto 28 Aug '24

28 Aug '24

Hi Mark, Pierre-Louis, Jerome Cc each ASoC driver maintainer This is v5 of DPCM cleanup As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.11 or v6.12 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com [2] https://lore.kernel.org/all/3e67d62d-fe08-4f55-ab5b-ece8a57154f9@linux.inte… Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wmo6dyxg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87msole5wc.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871q5tnuok.wl-kuninori.morimoto.gx@renesas.com v4 -> v5 - typo fix: limition -> limitation - typo fix: catpure -> capture - include Intel patch v3 -> v4 - don't check Codec on DPCM - include Jerome's dpcm_xxx update patch v2 -> v3 - tidyup typo (reuqsts -> requests) - add Tested-by on git-log v1 -> v2 - tidyup Codec check warning output condition Jerome Brunet (1): ASoC: amlogic: do not use dpcm_playback/capture flags Kuninori Morimoto (2): ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for availability limition ASoC: remove snd_soc_dai_link_set_capabilities() Pierre-Louis Bossart (1): ASoC: Intel: sof_sdw: use playback/capture_only flags include/sound/soc-dai.h | 1 - include/sound/soc.h | 1 + sound/soc/fsl/imx-card.c | 3 -- sound/soc/generic/audio-graph-card.c | 2 - sound/soc/generic/audio-graph-card2.c | 2 - sound/soc/generic/simple-card.c | 2 - sound/soc/intel/boards/sof_sdw.c | 4 +- sound/soc/meson/axg-card.c | 11 +++-- sound/soc/meson/gx-card.c | 1 - sound/soc/meson/meson-card-utils.c | 4 +- sound/soc/qcom/common.c | 1 - sound/soc/soc-dai.c | 38 ---------------- sound/soc/soc-pcm.c | 65 +++++++++++++++------------ 13 files changed, 47 insertions(+), 88 deletions(-) -- 2.43.0

2 9

Specifying supported hw params (channels, format, etc.) by the plug plugin in alsa config?
by Pavel Hofman 27 Aug '24

27 Aug '24

Hi, Please is it possible to restrict the hw params space for the plug plugin by some alsa configuration, so that it reports/accepts only a specific number of channels/specific sample format? I was not able to figure it out, I apologize if it's trivial :-) Thanks a lot. With regards, Pavel.

2 4

[PATCH -next 0/4] ASoC: fix module autoloading
by Liao Chen 27 Aug '24

27 Aug '24

Hi all, This patchset aims to enable autoloading of some use modules. By registering MDT, the kernel is allowed to automatically bind modules to devices that match the specified compatible strings. Liao Chen (4): ASoC: intel: fix module autoloading ASoC: google: fix module autoloading ASoC: tda7419: fix module autoloading ASoC: fix module autoloading sound/soc/codecs/chv3-codec.c | 1 + sound/soc/codecs/tda7419.c | 1 + sound/soc/google/chv3-i2s.c | 1 + sound/soc/intel/keembay/kmb_platform.c | 1 + 4 files changed, 4 insertions(+) -- 2.34.1

1 0

[PATCH v2] ASoC: tas2781: replace devm_kzalloc and scnprintf with devm_kstrdup
by Shenghao Ding 26 Aug '24

26 Aug '24

Replace devm_kzalloc and scnprintf with devm_kstrdup. Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- v2: - use devm_kstrdup instead of devm_kasprintf --- sound/soc/codecs/tas2781-i2c.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c index eb8732b1bb99..59fcce7fef7b 100644 --- a/sound/soc/codecs/tas2781-i2c.c +++ b/sound/soc/codecs/tas2781-i2c.c @@ -346,13 +346,11 @@ static int tasdevice_create_control(struct tasdevice_priv *tas_priv) } /* Create a mixer item for selecting the active profile */ - name = devm_kzalloc(tas_priv->dev, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, - GFP_KERNEL); + name = devm_kstrdup(tas_priv->dev, "Speaker Profile Id", GFP_KERNEL); if (!name) { ret = -ENOMEM; goto out; } - scnprintf(name, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, "Speaker Profile Id"); prof_ctrls[mix_index].name = name; prof_ctrls[mix_index].iface = SNDRV_CTL_ELEM_IFACE_MIXER; prof_ctrls[mix_index].info = tasdevice_info_profile; @@ -441,18 +439,13 @@ static int tasdevice_dsp_create_ctrls(struct tasdevice_priv *tas_priv) goto out; } - /* Create a mixer item for selecting the active profile */ - prog_name = devm_kzalloc(tas_priv->dev, - SNDRV_CTL_ELEM_ID_NAME_MAXLEN, GFP_KERNEL); - conf_name = devm_kzalloc(tas_priv->dev, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, + /* Create mixer items for selecting the active Program and Config */ + prog_name = devm_kstrdup(tas_priv->dev, "Speaker Program Id", GFP_KERNEL); - if (!prog_name || !conf_name) { + if (!prog_name) { ret = -ENOMEM; goto out; } - - scnprintf(prog_name, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, - "Speaker Program Id"); dsp_ctrls[mix_index].name = prog_name; dsp_ctrls[mix_index].iface = SNDRV_CTL_ELEM_IFACE_MIXER; dsp_ctrls[mix_index].info = tasdevice_info_programs; @@ -460,8 +453,12 @@ static int tasdevice_dsp_create_ctrls(struct tasdevice_priv *tas_priv) dsp_ctrls[mix_index].put = tasdevice_program_put; mix_index++; - scnprintf(conf_name, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, - "Speaker Config Id"); + conf_name = devm_kstrdup(tas_priv->dev, "Speaker Config Id", + GFP_KERNEL); + if (!conf_name) { + ret = -ENOMEM; + goto out; + } dsp_ctrls[mix_index].name = conf_name; dsp_ctrls[mix_index].iface = SNDRV_CTL_ELEM_IFACE_MIXER; dsp_ctrls[mix_index].info = tasdevice_info_configurations; -- 2.34.1

3 2

[PATCH] ASoC: MAINTAINERS: Drop incorrect tlv320aic31xx.txt path
by Krzysztof Kozlowski 26 Aug '24

26 Aug '24

tlv320aic31xx.txt was converted to DT schema (YAML) and new file is already matched by wildcard. This fixes get_maintainers.pl self-test warning: ./MAINTAINERS:22739: warning: no file matches F: Documentation/devicetree/bindings/sound/tlv320aic31xx.txt Fixes: e486feb7b8ec ("ASoC: dt-bindings: convert tlv320aic31xx.txt to yaml") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6574b4910f8a..028186bb4e8d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -22736,7 +22736,6 @@ F: Documentation/devicetree/bindings/sound/ti,pcm1681.yaml F: Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml F: Documentation/devicetree/bindings/sound/ti,tlv320*.yaml F: Documentation/devicetree/bindings/sound/ti,tlv320adcx140.yaml -F: Documentation/devicetree/bindings/sound/tlv320aic31xx.txt F: include/sound/tas2*.h F: include/sound/tlv320*.h F: include/sound/tpa6130a2-plat.h -- 2.43.0

2 1

[PATCH] MAINTAINERS: adjust file entries in TEXAS INSTRUMENTS AUDIO DRIVERS
by Lukas Bulwahn 26 Aug '24

26 Aug '24

From: Lukas Bulwahn <lukas.bulwahn(a)redhat.com> Commit e486feb7b8ec ("ASoC: dt-bindings: convert tlv320aic31xx.txt to yaml") converts tlv320aic31xx.txt to ti,tlv320dac3100.yaml, but misses to adjust the file entry in TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. The pattern ti,tlv320*.yaml in the section already covers ti,tlv320dac3100.yaml and ti,tlv320adcx140.yaml. So, further file entries in this section are redundant. Adjust the file entries in TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS accordingly. Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)redhat.com> --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5dd88c28c0f7..6aa85a43d8c1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -22753,8 +22753,6 @@ F: Documentation/devicetree/bindings/sound/ti,tpa6130a2.yaml F: Documentation/devicetree/bindings/sound/ti,pcm1681.yaml F: Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml F: Documentation/devicetree/bindings/sound/ti,tlv320*.yaml -F: Documentation/devicetree/bindings/sound/ti,tlv320adcx140.yaml -F: Documentation/devicetree/bindings/sound/tlv320aic31xx.txt F: include/sound/tas2*.h F: include/sound/tlv320*.h F: include/sound/tpa6130a2-plat.h -- 2.45.2

1 0

[PATCH v1] ASoC: tas2781: mark const variables tas2563_dvc_table as __maybe_unused
by Shenghao Ding 26 Aug '24

26 Aug '24

In case of tas2781, tas2563_dvc_table will be unused, so mark it as __maybe_unused. Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- include/sound/tas2563-tlv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/sound/tas2563-tlv.h b/include/sound/tas2563-tlv.h index faa3e194f73b..bb269b21f460 100644 --- a/include/sound/tas2563-tlv.h +++ b/include/sound/tas2563-tlv.h @@ -18,7 +18,7 @@ static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2563_dvc_tlv, -12150, 50, 1); /* pow(10, db/20) * pow(2,30) */ -static const unsigned char tas2563_dvc_table[][4] = { +static const __maybe_unused unsigned char tas2563_dvc_table[][4] = { { 0X00, 0X00, 0X00, 0X00 }, /* -121.5db */ { 0X00, 0X00, 0X03, 0XBC }, /* -121.0db */ { 0X00, 0X00, 0X03, 0XF5 }, /* -120.5db */ -- 2.34.1

4 6

[DISCUSSION] Why doesn't ALSA autogenerate/autoconfigure the mono profile by default?
by Xerox Slayer 25 Aug '24

25 Aug '24

Sorry if this is the wrong place to discuss this, but from what I managed to find out, this is primarily the responsibility of ALSA. This was pointed out by a reddit user, and to be frank, I was kinda surprised that this is not done by default. The user in question is hearing impaired (can listen on only one ear), so the user has no benefit of actually listening to stereo or any other multichannel audio, thus wanted to just set everything to mono (dual mono I presume) and was puzzled when there was no such option in pulseaudio (which pulls the profiles from ALSA). I did some more investigation and as it turns out, this profile is autogenerated, but only if the hardware has such capability (as is the case with any other profile). You can enable it manually by editing config files (in which case I presume the channel downconversion is done in software), but it seemed odd that one has to go through such trouble just to listen to mono sound. Thus, I think the mono profile should be taken as a special case scenario and be autogenerated/configured by default, regardless if it's supported in hardware or not. Once again, I'm sorry if this is not the place to ask/discuss this, but would appreciate if someone pointed me to where I can actually do this.

2 2