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

[PATCH] ASoC: qcom: x1e80100: Support boards with two speakers
by Krzysztof Kozlowski 17 Jul '25

17 Jul '25

Some Qualcomm X1E laptops have only two speakers. Regardless whether this sound card driver is suitable for them (we could re-use one for some older SoC), we should set reasonable channel map depending on the number of channels, not always 4-speaker setup. This change is necessary for bringing audio support on Lenovo Thinkpad T14s with Qualcomm X1E78100 and only two speakers. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- sound/soc/qcom/x1e80100.c | 40 ++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-) diff --git a/sound/soc/qcom/x1e80100.c b/sound/soc/qcom/x1e80100.c index 898b5c26bf1e..8eb57fc12f0d 100644 --- a/sound/soc/qcom/x1e80100.c +++ b/sound/soc/qcom/x1e80100.c @@ -95,23 +95,53 @@ static int x1e80100_snd_hw_params(struct snd_pcm_substream *substream, return qcom_snd_sdw_hw_params(substream, params, &data->sruntime[cpu_dai->id]); } +static int x1e80100_snd_hw_map_channels(unsigned int *ch_map, int num) +{ + switch (num) { + case 1: + ch_map[0] = PCM_CHANNEL_FC; + break; + case 2: + ch_map[0] = PCM_CHANNEL_FL; + ch_map[1] = PCM_CHANNEL_FR; + break; + case 3: + ch_map[0] = PCM_CHANNEL_FL; + ch_map[1] = PCM_CHANNEL_FR; + ch_map[2] = PCM_CHANNEL_FC; + break; + case 4: + ch_map[0] = PCM_CHANNEL_FL; + ch_map[1] = PCM_CHANNEL_LB; + ch_map[2] = PCM_CHANNEL_FR; + ch_map[3] = PCM_CHANNEL_RB; + break; + default: + return -EINVAL; + } + + return 0; +} + static int x1e80100_snd_prepare(struct snd_pcm_substream *substream) { struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream); struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0); struct x1e80100_snd_data *data = snd_soc_card_get_drvdata(rtd->card); struct sdw_stream_runtime *sruntime = data->sruntime[cpu_dai->id]; - const unsigned int rx_slot[4] = { PCM_CHANNEL_FL, - PCM_CHANNEL_LB, - PCM_CHANNEL_FR, - PCM_CHANNEL_RB }; + unsigned int channels = substream->runtime->channels; + unsigned int rx_slot[4]; int ret; switch (cpu_dai->id) { case WSA_CODEC_DMA_RX_0: case WSA_CODEC_DMA_RX_1: + ret = x1e80100_snd_hw_map_channels(rx_slot, channels); + if (ret) + return ret; + ret = snd_soc_dai_set_channel_map(cpu_dai, 0, NULL, - ARRAY_SIZE(rx_slot), rx_slot); + channels, rx_slot); if (ret) return ret; break; -- 2.43.0

3 2

[alsa-devel] ASoC TDM channel re-mapping
by Edward Cragg 17 Jun '25

17 Jun '25

Hi, We have an ASoC driver in which we have added support for TDM over an I2S interface. We would like to have the capability of re-mapping the channel ordering, for which i know there is a callback in place to start this process, set_channel_map. The only backend implementation of this is using the ALSA API and the .copy handler in an ALSA PCM driver to mutate data copied out of ALSA before it's DMA'd to hardware. This is in sound/soc/blackfin/bf5xx-i2s-pcm.c The problem we have is that the driver we're using currently uses a dmaengine based PCM driver, and i'm not sure whether this is compatible with using the .copy callback, without reimplementing the driver entirely as an ALSA PCM driver. Since there aren't very many examples in mainline, I was hoping to ask for advice for the best way of doing this. I wondered: - Would it be possible to add a functional copy callback using a dmaengine based PCM driver? - Otherwise, would there be a good way to implement channel remapping in a TDM frame using the dmaengine based PCM driver? or - Would the best way indeed be to reimplement the PCM driver as a normal ALSA PCM driver? Thanks, Ed Cragg

2 2

[PATCH] ASoC: qcom: soundwire: Add support for controlling audio CGCR from HLOS
by Srinivasa Rao Mandadapu 17 Jun '25

17 Jun '25

Add support for controlling soundwire audio CGCR interface using clock framework to make hclk ungating with software. As per new hardware changes, software has to always ungate hclk if soundwire is operational and keep it running. This requirement is for latest LPASS chipsets for RX, TX and WSA path to work. Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam(a)quicinc.com> Co-developed-by: Venkata Prasad Potturu <quic_potturu(a)quicinc.com> Signed-off-by: Venkata Prasad Potturu <quic_potturu(a)quicinc.com> --- This patch set depends on: -- Clock driver patches with reset control support, yet to be posted. drivers/soundwire/qcom.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index fb183bd..440aad8 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -12,6 +12,7 @@ #include <linux/of_irq.h> #include <linux/of_device.h> #include <linux/regmap.h> +#include <linux/reset.h> #include <linux/slab.h> #include <linux/slimbus.h> #include <linux/soundwire/sdw.h> @@ -129,6 +130,7 @@ struct qcom_swrm_ctrl { struct device *dev; struct regmap *regmap; void __iomem *mmio; + struct reset_control *audio_cgcr; #ifdef CONFIG_DEBUG_FS struct dentry *debugfs; #endif @@ -618,6 +620,8 @@ static int qcom_swrm_init(struct qcom_swrm_ctrl *ctrl) val = FIELD_PREP(SWRM_MCP_FRAME_CTRL_BANK_ROW_CTRL_BMSK, ctrl->rows_index); val |= FIELD_PREP(SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_BMSK, ctrl->cols_index); + reset_control_reset(ctrl->audio_cgcr); + ctrl->reg_write(ctrl, SWRM_MCP_FRAME_CTRL_BANK_ADDR(0), val); /* Enable Auto enumeration */ @@ -1269,6 +1273,9 @@ static int qcom_swrm_probe(struct platform_device *pdev) ctrl->bus.ops = &qcom_swrm_ops; ctrl->bus.port_ops = &qcom_swrm_port_ops; ctrl->bus.compute_params = &qcom_swrm_compute_params; + ctrl->audio_cgcr = devm_reset_control_get_exclusive(dev, "swr_audio_cgcr"); + if (IS_ERR(ctrl->audio_cgcr)) + dev_err(dev, "Failed to get audio_cgcr reset required for soundwire-v1.6.0\n"); ret = qcom_swrm_get_port_config(ctrl); if (ret) -- 2.7.4

2 3

[PATCH] ASoC: amd: acp: Fix support for a Huawei Matebook laptop
by Marian Postevca 17 Jun '25

17 Jun '25

Previous commit that added support for Huawei MateBook D16 2021 with Ryzen 4600H (HVY-WXX9 M1010) was incomplete. To activate support for this laptop, the DMI table in acp3x-es83xx machine driver must also be updated. Fixes: b5338b1b901e ("ASoC: amd: acp: Add support for a new Huawei Matebook laptop") Signed-off-by: Marian Postevca <posteuca(a)mutex.one> --- sound/soc/amd/acp/acp3x-es83xx/acp3x-es83xx.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/amd/acp/acp3x-es83xx/acp3x-es83xx.c b/sound/soc/amd/acp/acp3x-es83xx/acp3x-es83xx.c index f85b85ea4be9..2b0aa270a3e9 100644 --- a/sound/soc/amd/acp/acp3x-es83xx/acp3x-es83xx.c +++ b/sound/soc/amd/acp/acp3x-es83xx/acp3x-es83xx.c @@ -354,6 +354,14 @@ static const struct dmi_system_id acp3x_es83xx_dmi_table[] = { }, .driver_data = (void *)(ES83XX_ENABLE_DMIC|ES83XX_48_MHZ_MCLK), }, + { + .matches = { + DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "HUAWEI"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "HVY-WXX9"), + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "M1010"), + }, + .driver_data = (void *)(ES83XX_ENABLE_DMIC), + }, { .matches = { DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "HUAWEI"), -- 2.43.0

2 1

[PATCH 0/1] Swapped l/r channels on ThinkBook 13x Gen4
by MadEnvel 28 May '25

28 May '25

Earlier commits introduced audio support for Lenovo ThinBook 13x Gen 4 that needed a patch due to missing _DSD config. Unfortunately, it looks like the left and right channels in the config are swapped. This patch fixes channel assignment. Tested on Lenovo ThinkBook 13x Gen4. MadEnvel (1): Fix swapped left and right channels for Lenovo ThinBook 13x Gen4 sound sound/pci/hda/cs35l41_hda_property.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.45.2

4 4

[PATCH v2] ASoC: amd: use new ACP dev names for DAI links
by Brady Norander 20 May '25

20 May '25

On AMD SoC platforms with an ACP2x gpu ip block (such as stoneyridge), the amdgpu driver will create several platform devices for the ACP ASoC driver to communicate with the ACP hardware block on the gpu. These platform devices include dma for audio and one or multiple i2s interfaces. The amdgpu driver has always created these platform devices with automatic ids. The ASoC machine drives hardcode the platform device name. This creates an issue where if the ACP platform devices are not the first to be created, the ids can be different to what the machine drivers expect, causing them to not find the ACP platform devices and failing to load. Switch to using static ids for these ACP platform devices so that the names never change. Depends on patch: drm/amdgpu: use static ids for ACP platform devs [1] [1] https://lore.kernel.org/all/20250325210517.2097188-1-bradynorander@gmail.co… Signed-off-by: Brady Norander <bradynorander(a)gmail.com> --- v2: rewrite commit message to better describe the issue --- sound/soc/amd/acp-da7219-max98357a.c | 8 ++++---- sound/soc/amd/acp-es8336.c | 4 ++-- sound/soc/amd/acp-rt5645.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/soc/amd/acp-da7219-max98357a.c b/sound/soc/amd/acp-da7219-max98357a.c index 02b04f355ca6..42aa009c4e13 100644 --- a/sound/soc/amd/acp-da7219-max98357a.c +++ b/sound/soc/amd/acp-da7219-max98357a.c @@ -517,11 +517,11 @@ static const struct snd_soc_ops cz_rt5682_dmic1_cap_ops = { }; SND_SOC_DAILINK_DEF(designware1, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1"))); SND_SOC_DAILINK_DEF(designware2, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2"))); SND_SOC_DAILINK_DEF(designware3, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.3.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.3"))); SND_SOC_DAILINK_DEF(dlgs, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-DLGS7219:00", "da7219-hifi"))); @@ -533,7 +533,7 @@ SND_SOC_DAILINK_DEF(adau, DAILINK_COMP_ARRAY(COMP_CODEC("ADAU7002:00", "adau7002-hifi"))); SND_SOC_DAILINK_DEF(platform, - DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0.auto"))); + DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0"))); static struct snd_soc_dai_link cz_dai_7219_98357[] = { { diff --git a/sound/soc/amd/acp-es8336.c b/sound/soc/amd/acp-es8336.c index 0193b3eae7a6..b16dde0e2987 100644 --- a/sound/soc/amd/acp-es8336.c +++ b/sound/soc/amd/acp-es8336.c @@ -137,11 +137,11 @@ static const struct snd_soc_ops st_es8336_ops = { }; SND_SOC_DAILINK_DEF(designware1, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1"))); SND_SOC_DAILINK_DEF(codec, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-ESSX8336:00", "ES8316 HiFi"))); SND_SOC_DAILINK_DEF(platform, - DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.1.auto"))); + DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0"))); static struct snd_soc_dai_link st_dai_es8336[] = { { diff --git a/sound/soc/amd/acp-rt5645.c b/sound/soc/amd/acp-rt5645.c index 72ddad24dbda..11d373169380 100644 --- a/sound/soc/amd/acp-rt5645.c +++ b/sound/soc/amd/acp-rt5645.c @@ -108,15 +108,15 @@ static const struct snd_soc_ops cz_aif1_ops = { }; SND_SOC_DAILINK_DEF(designware1, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1"))); SND_SOC_DAILINK_DEF(designware2, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2"))); SND_SOC_DAILINK_DEF(codec, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-10EC5650:00", "rt5645-aif1"))); SND_SOC_DAILINK_DEF(platform, - DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0.auto"))); + DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0"))); static struct snd_soc_dai_link cz_dai_rt5650[] = { { -- 2.49.0

2 2

[PATCH 0/9] ALSA: usb-audio: More fixes / improvements on PCM
by Takashi Iwai 22 Apr '25

22 Apr '25

Hi, this is a patch set for USB-audio to fix and improve the PCM stream handling. The primary target is the enhancement of the low-latency playback that was introduced recently for dealing with the small period size (that is used typically by JACK). There are a few other fixes that are relevant with it. The current patches are found in topic/usb-audio branch of sound.git tree, too. Takashi === Takashi Iwai (9): ALSA: usb-audio: Restrict rates for the shared clocks ALSA: usb-audio: Fix possible race at sync of urb completions ALSA: usb-audio: Rename early_playback_start flag with lowlatency_playback ALSA: usb-audio: Disable low-latency playback for free-wheel mode ALSA: usb-audio: Disable low-latency mode for implicit feedback sync ALSA: usb-audio: Check available frames for the next packet size ALSA: usb-audio: Add spinlock to stop_urbs() ALSA: usb-audio: Improved lowlatency playback support ALSA: usb-audio: Avoid killing in-flight URBs during draining sound/usb/card.h | 11 ++- sound/usb/endpoint.c | 230 +++++++++++++++++++++++++++++++------------ sound/usb/endpoint.h | 13 ++- sound/usb/pcm.c | 157 ++++++++++++++++++++++------- 4 files changed, 305 insertions(+), 106 deletions(-) -- 2.26.2

2 23

[PATCH v2] ASoC: dwc: always enable/disable i2s irqs
by Brady Norander 08 Apr '25

08 Apr '25

Commit a42e988 ("ASoC: dwc: add DMA handshake control") changed the behavior of the driver to not enable or disable i2s irqs if using DMA. This breaks platforms such as AMD ACP. Audio playback appears to work but no audio can be heard. Revert to the old behavior by always enabling and disabling i2s irqs while keeping DMA handshake control. Fixes: a42e988 ("ASoC: dwc: add DMA handshake control") Signed-off-by: Brady Norander <bradynorander(a)gmail.com> --- v2: reword commit message to better describe the issue --- sound/soc/dwc/dwc-i2s.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/sound/soc/dwc/dwc-i2s.c b/sound/soc/dwc/dwc-i2s.c index 57b789d7fbed..5b4f20dbf7bb 100644 --- a/sound/soc/dwc/dwc-i2s.c +++ b/sound/soc/dwc/dwc-i2s.c @@ -199,12 +199,10 @@ static void i2s_start(struct dw_i2s_dev *dev, else i2s_write_reg(dev->i2s_base, IRER, 1); - /* I2S needs to enable IRQ to make a handshake with DMAC on the JH7110 SoC */ - if (dev->use_pio || dev->is_jh7110) - i2s_enable_irqs(dev, substream->stream, config->chan_nr); - else + if (!(dev->use_pio || dev->is_jh7110)) i2s_enable_dma(dev, substream->stream); + i2s_enable_irqs(dev, substream->stream, config->chan_nr); i2s_write_reg(dev->i2s_base, CER, 1); } @@ -218,11 +216,12 @@ static void i2s_stop(struct dw_i2s_dev *dev, else i2s_write_reg(dev->i2s_base, IRER, 0); - if (dev->use_pio || dev->is_jh7110) - i2s_disable_irqs(dev, substream->stream, 8); - else + if (!(dev->use_pio || dev->is_jh7110)) i2s_disable_dma(dev, substream->stream); + i2s_disable_irqs(dev, substream->stream, 8); + + if (!dev->active) { i2s_write_reg(dev->i2s_base, CER, 0); i2s_write_reg(dev->i2s_base, IER, 0); -- 2.49.0

2 1

[PATCH alsa-ucm-conf 1/2] sof-soundwire: cs42l43: Drop headset mic from mic mute LED
by Maciej Strozek 01 Apr '25

01 Apr '25

As per conversation in [1], let headsets be dropped from LED bindings. Also remove turning off the mics on device disable since they are now not needed. [1]: https://github.com/alsa-project/alsa-ucm-conf/pull/512 Signed-off-by: Maciej Strozek <mstrozek(a)opensource.cirrus.com> --- ucm2/codecs/cs42l43/init.conf | 6 ------ ucm2/sof-soundwire/cs42l43-dmic.conf | 2 -- ucm2/sof-soundwire/cs42l43.conf | 1 - 3 files changed, 9 deletions(-) diff --git a/ucm2/codecs/cs42l43/init.conf b/ucm2/codecs/cs42l43/init.conf index 0e987c21..c0fa863c 100644 --- a/ucm2/codecs/cs42l43/init.conf +++ b/ucm2/codecs/cs42l43/init.conf @@ -10,9 +10,3 @@ LibraryConfig.remap.Config { } } } - -BootSequence [ - cset "name='cs42l43 Decimator 1 Switch' 0" -] - -Macro [{ SetLED { LED="mic" Action="attach" CtlId="cs42l43 Decimator 1 Switch" } }] diff --git a/ucm2/sof-soundwire/cs42l43-dmic.conf b/ucm2/sof-soundwire/cs42l43-dmic.conf index 70ce40ff..b68a70d1 100644 --- a/ucm2/sof-soundwire/cs42l43-dmic.conf +++ b/ucm2/sof-soundwire/cs42l43-dmic.conf @@ -13,8 +13,6 @@ SectionDevice."Mic" { ] DisableSequence [ - cset "name='cs42l43 Decimator 3 Switch' 0" - cset "name='cs42l43 Decimator 4 Switch' 0" cset "name='cs42l43 DP1TX1 Input' 'None'" cset "name='cs42l43 DP1TX2 Input' 'None'" ] diff --git a/ucm2/sof-soundwire/cs42l43.conf b/ucm2/sof-soundwire/cs42l43.conf index 4b4e1187..51832126 100644 --- a/ucm2/sof-soundwire/cs42l43.conf +++ b/ucm2/sof-soundwire/cs42l43.conf @@ -33,7 +33,6 @@ SectionDevice."Headset" { ] DisableSequence [ - cset "name='cs42l43 Decimator 1 Switch' 0" cset "name='cs42l43 DP2TX1 Input' 'None'" cset "name='cs42l43 DP2TX2 Input' 'None'" ] -- 2.39.5

2 6

Difference in behaviour between physical devices and virtual endpoints
by GitHub issues - opened 31 Mar '25

31 Mar '25

alsa-project/alsa-lib issue #447 was opened from reuk: As a disclaimer, there's a good chance this is user error/misunderstanding rather than a bug, but I'd appreciate any insights to help me understand the behaviour I'm seeing. # Environment - Fedora 41 x86_64 - alsa-lib-devel-1.2.13-3 # Steps - Run `aseqdump -u 1` in a terminal - Connect ProtoZOA hardware via USB - Launch QjackCtl -> Graph, then connect the ProtoZOA's MIDI 2.0 output port (0) to `aseqdump`'s input port. <img width="535" alt="Image" src="https://github.com/user-attachments/assets/17bf6a74-f83d-41b4-afc6-05413a7a…" /> - Observe that `aseqdump` reports a new subscription from `24:0 -> 128:0` (the client IDs may vary, the important thing is that the subscription is between to ports with ID `0`). - Move one of the controllers on the ProtoZOA. Observe that `aseqdump` reports channel voice events on group 0 with source `24:1`. <img width="502" alt="Image" src="https://github.com/user-attachments/assets/2dfc5929-123f-4e33-abbb-ea0c2635…" /> - Connect `aseqdump` to port `1:Group 1 (FB1, FB2)`, and interact with the ProtoZOA. Observe that `aseqdump` still reports channel voice events on group 0 with source `24:1`. - Now, build and run the [seq-ump-example](https://github.com/alsa-project/alsa-lib/blob/master/test/…. - Connect the ProtoZOA to the ACMESynth input, and the ACMESynth output to `aseqdump` as shown. Observe that `aseqdump` does **not** report channel voice events when interacting with the ProtoZOA. <img width="790" alt="Image" src="https://github.com/user-attachments/assets/71349cd6-14b8-4df9-8ee6-ca1091c2…" /> - Finally, update the connections as shown, so that `aseqdump` is connected to ACMESynth's `1:Group 1 (Filter 1)` output. Observe that `aseqdump` now reports channel voice events with source `128:1` when interacting with the ProtoZOA. <img width="772" alt="Image" src="https://github.com/user-attachments/assets/57f4e767-b2d6-4156-8514-578851d5…" /> # TL;DR When we subscribe to a USB `MIDI 2.0` port, we receive messages from all of the endpoint's ports. Messages are dispatched to the appropriate port based on the message group. When we subscribe to a virtual UMP endpoint's `MIDI 2.0` port, this appears to *only* subscribe to that single port, and not to the rest of the ports on the endpoint, so that messages addressed to specific groups get lost. # Questions - Is this difference in behaviour between hardware and virtual endpoints intentional? - What is the "correct" way to subscribe to all UMP events from an endpoint? Should I subscribe just to the `MIDI 2.0` endpoint, or to all ports on the endpoint, or something else? Issue URL : https://github.com/alsa-project/alsa-lib/issues/447 Repository URL: https://github.com/alsa-project/alsa-lib

1 0