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

Does this compile any code?
by GitHub issues - opened 29 Mar '23

29 Mar '23

alsa-project/alsa-lib issue #309 was opened from stefan11111: If I build the same kernel twice, I get this output when building it the second time: ``` # make CALL scripts/checksyscalls.sh DESCEND objtool Kernel: arch/x86/boot/bzImage is ready (#17) ``` If I build the kernel again, only changing SND_X86, I get this output: ``` # make SYNC include/config/auto.conf CALL scripts/checksyscalls.sh DESCEND objtool Kernel: arch/x86/boot/bzImage is ready (#17) ``` It doesn't look like that option compiles any code. Issue URL : https://github.com/alsa-project/alsa-lib/issues/309 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ASoC: soc-topology.c: dai_link->platform again
by Kuninori Morimoto 29 Mar '23

29 Mar '23

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> On SOF, many topology is assuming dai_link->platform exists, and is allowed to be overwritten on each link_load(). This patch restore the removed dai_link->platform for SOF, and add the comment. Fixes: e7098ba9b378 ("ASoC: soc-topology.c: remove unnecessary dai_link->platform") Reported-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/87jzz7jczp.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/soc-topology.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index be9849749713..d0aca6b9058b 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -1685,8 +1685,8 @@ static int soc_tplg_fe_link_create(struct soc_tplg *tplg, struct snd_soc_dai_link_component *dlc; int ret; - /* link + cpu + codec */ - link = devm_kzalloc(tplg->dev, sizeof(*link) + (2 * sizeof(*dlc)), GFP_KERNEL); + /* link + cpu + codec + platform */ + link = devm_kzalloc(tplg->dev, sizeof(*link) + (3 * sizeof(*dlc)), GFP_KERNEL); if (link == NULL) return -ENOMEM; @@ -1724,6 +1724,14 @@ static int soc_tplg_fe_link_create(struct soc_tplg *tplg, link->codecs->name = "snd-soc-dummy"; link->codecs->dai_name = "snd-soc-dummy-dai"; + /* + * Many topology is assuming link has Platform. + * This might be overwritten at soc_tplg_dai_link_load(). + */ + link->platforms = &dlc[2]; + link->platforms->name = "snd-soc-dummy"; + link->num_platforms = 1; + /* enable DPCM */ link->dynamic = 1; link->ignore_pmdown_time = 1; -- 2.25.1

3 2

[PATCH for v6.3-rc] ASoC: SOF: avoid a NULL dereference with unsupported widgets
by Peter Ujfalusi 29 Mar '23

29 Mar '23

From: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> If an IPC4 topology contains an unsupported widget, its .module_info field won't be set, then sof_ipc4_route_setup() will cause a kernel Oops trying to dereference it. Add a check for such cases. Cc: stable(a)vger.kernel.org # 6.2 Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- Hi Mark, This patch is generated on top of 6.3-rc4, it will have conflict with asoc-next because we have ChainDMA scheduled for 6.4 in there. I should have taken this patch a faster track, but missed it when arranging the patches, features. We noticed this when trying to use our development IPC4 topologies with mainline which does not yet able to handle the process module types (slated fro 6.4). IPC4 is still evolving so it is not rare that fw/tplg/kernel needs to be lock-stepped, but NULL pointer dereference should not happen. This is how the merge conflict resolution should end up between 6.3 and 6.4: int ret; /* no route set up if chain DMA is used */ if (src_pipeline->use_chain_dma || sink_pipeline->use_chain_dma) { if (!src_pipeline->use_chain_dma || !sink_pipeline->use_chain_dma) { dev_err(sdev->dev, "use_chain_dma must be set for both src %s and sink %s pipelines\n", src_widget->widget->name, sink_widget->widget->name); return -EINVAL; } return 0; } if (!src_fw_module || !sink_fw_module) { /* The NULL module will print as "(efault)" */ dev_err(sdev->dev, "source %s or sink %s widget weren't set up properly\n", src_fw_module->man4_module_entry.name, sink_fw_module->man4_module_entry.name); return -ENODEV; } sroute->src_queue_id = sof_ipc4_get_queue_id(src_widget, sink_widget, SOF_PIN_TYPE_SOURCE); Can you send this patch for 6.3 cycle? Thank you, Peter sound/soc/sof/ipc4-topology.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index a623707c8ffc..669b99a4f76e 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -1805,6 +1805,14 @@ static int sof_ipc4_route_setup(struct snd_sof_dev *sdev, struct snd_sof_route * u32 header, extension; int ret; + if (!src_fw_module || !sink_fw_module) { + /* The NULL module will print as "(efault)" */ + dev_err(sdev->dev, "source %s or sink %s widget weren't set up properly\n", + src_fw_module->man4_module_entry.name, + sink_fw_module->man4_module_entry.name); + return -ENODEV; + } + sroute->src_queue_id = sof_ipc4_get_queue_id(src_widget, sink_widget, SOF_PIN_TYPE_SOURCE); if (sroute->src_queue_id < 0) { -- 2.40.0

2 1

[PATCH] Asoc: wm_adsp: Add support for loading firmware with prefix name
by Jianhua Lu 29 Mar '23

29 Mar '23

For platform using fdt, system_name is NULL, it doesn't provide a way to load firmware with prefix name, so add it. Signed-off-by: Jianhua Lu <lujianhua000(a)gmail.com> --- sound/soc/codecs/wm_adsp.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c index 216120b68b64..17481e42d440 100644 --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -760,6 +760,10 @@ static int wm_adsp_request_firmware_file(struct wm_adsp *dsp, *filename = kasprintf(GFP_KERNEL, "%s%s-%s-%s-%s.%s", dir, dsp->part, dsp->fwf_name, wm_adsp_fw[dsp->fw].file, system_name, filetype); + else if (asoc_component_prefix) + *filename = kasprintf(GFP_KERNEL, "%s%s-%s-%s-%s.%s", dir, dsp->part, + dsp->fwf_name, wm_adsp_fw[dsp->fw].file, asoc_component_prefix, + filetype); else *filename = kasprintf(GFP_KERNEL, "%s%s-%s-%s.%s", dir, dsp->part, dsp->fwf_name, wm_adsp_fw[dsp->fw].file, filetype); @@ -831,6 +835,16 @@ static int wm_adsp_request_firmware_files(struct wm_adsp *dsp, NULL, "bin"); return 0; } + } else if (asoc_component_prefix) { + if (!wm_adsp_request_firmware_file(dsp, wmfw_firmware, wmfw_filename, + cirrus_dir, NULL, + asoc_component_prefix, "wmfw")) { + adsp_dbg(dsp, "Found '%s'\n", *wmfw_filename); + wm_adsp_request_firmware_file(dsp, coeff_firmware, coeff_filename, + cirrus_dir, NULL, + asoc_component_prefix, "bin"); + return 0; + } } if (!wm_adsp_request_firmware_file(dsp, wmfw_firmware, wmfw_filename, -- 2.39.2

3 4

Re: [PATCH 3/4] ASoC: amd: acp: Add machine driver that enables sound for systems with a ES8336 codec
by Zhu Ning 29 Mar '23

29 Mar '23

> > The GPIO thing on Huawei Intel platform is too complicated, they use two GPIOs > > for headphone and speaker, and the headphone GPIO is inverted, which means low > > means on and high means off. Luckily there should be only one hardware config > > for the AMD acp3x platform GPIO and you may just choose the correct one. > > There being two different GPIOs sounds like it just allows the headphone > and speaker to be controlled separately - that seems more flexible, not > a problem? Yes it's called multi stream in Windows. However, extra GPIO causes more confusion in the driver. > > There is no such situation, and the system doesn't produce sound from speaker > > when headphones are plugged in. The user may manually open speaker using > > amixer sset 'Speaker' on or pavucontrol. > > Again, you're describing a specific configuration - someone might want > to do something different. Hi Marian Postevca you may want to separate the GPIO control by adding Headphone Power SND_SOC_DAPM_SUPPLY. You may also want to change the gpio handling function in the acp3x_es83xx_jack_events function. static const struct snd_soc_dapm_widget acp3x_es83xx_widgets[] = { SND_SOC_DAPM_SPK("Speaker", NULL), SND_SOC_DAPM_HP("Headphone", NULL), SND_SOC_DAPM_MIC("Headset Mic", NULL), SND_SOC_DAPM_MIC("Internal Mic", NULL), + SND_SOC_DAPM_SUPPLY("Headphone Power", SND_SOC_NOPM, 0, 0, + acp3x_es83xx_headphone_power_event, + SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMU), SND_SOC_DAPM_SUPPLY("Speaker Power", SND_SOC_NOPM, 0, 0, acp3x_es83xx_speaker_power_event, SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMU), }; static const struct snd_soc_dapm_route acp3x_es83xx_audio_map[] = { {"Headphone", NULL, "HPOL"}, {"Headphone", NULL, "HPOR"}, + {"Headphone", NULL, "Headphone Power"}, {"Speaker", NULL, "HPOL"}, {"Speaker", NULL, "HPOR"}, {"Speaker", NULL, "Speaker Power"}, }; +static int acp3x_es83xx_headphone_power_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct acp3x_es83xx_private *priv = get_mach_priv(w->dapm->card); + + dev_dbg(priv->codec_dev, "speaker power event: %d\n", event); + if (SND_SOC_DAPM_EVENT_ON(event)) + gpiod_set_value_cansleep(priv->gpio_headphone, true); + else + gpiod_set_value_cansleep(priv->gpio_headphone, false); + + return 0; +} + +static int acp3x_es83xx_speaker_power_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct acp3x_es83xx_private *priv = get_mach_priv(w->dapm->card); + + dev_dbg(priv->codec_dev, "speaker power event: %d\n", event); + if (SND_SOC_DAPM_EVENT_ON(event)) + gpiod_set_value_cansleep(priv->gpio_speakers, true); + else + gpiod_set_value_cansleep(priv->gpio_speakers, false); + + return 0; +}

2 1

[PATCH] ALSA: hda/realtek: Add quirk for Lenovo ZhaoYang CF4620Z
by huangwenhui 29 Mar '23

29 Mar '23

Fix headset microphone detection on Lenovo ZhaoYang CF4620Z. Signed-off-by: huangwenhui <huangwenhuia(a)uniontech.com> Change-Id: I89d3f4d1d18193418f74d0095b0e4daaf24c839f --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index e8b7f6bbfc59..a8810231a5b5 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7137,6 +7137,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK), SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K), SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD), + SND_PCI_QUIRK(0x17aa, 0x9e56, "Lenovo ZhaoYang CF4620Z", ALC286_FIXUP_SONY_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MBXP", ALC256_FIXUP_HUAWEI_MBXP_PINS), SND_PCI_QUIRK(0x19e5, 0x320f, "Huawei WRT-WX9 ", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */ -- 2.20.1

2 1

[PATCH] ALSA: remove unused loop_count variable
by Tom Rix 29 Mar '23

29 Mar '23

clang with W=1 reports sound/pci/asihpi/hpi6000.c:1256:6: error: variable 'loop_count' set but not used [-Werror,-Wunused-but-set-variable] u32 loop_count = 0; ^ This variable is not used so remove it. Signed-off-by: Tom Rix <trix(a)redhat.com> --- sound/pci/asihpi/hpi6000.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/pci/asihpi/hpi6000.c b/sound/pci/asihpi/hpi6000.c index 88d902997b74..72aa135d69f8 100644 --- a/sound/pci/asihpi/hpi6000.c +++ b/sound/pci/asihpi/hpi6000.c @@ -1253,7 +1253,6 @@ static u16 hpi6000_dsp_block_read32(struct hpi_adapter_obj *pao, int local_count = count; int xfer_size; u32 *pdata = dest; - u32 loop_count = 0; while (local_count) { if (local_count > c6711_burst_size) @@ -1273,7 +1272,6 @@ static u16 hpi6000_dsp_block_read32(struct hpi_adapter_obj *pao, pdata += xfer_size; local_hpi_address += sizeof(u32) * xfer_size; local_count -= xfer_size; - loop_count++; } if (time_out) -- 2.27.0

2 1

ALC1220 DualCodec - changing to headphone (front panel) port doesn't work without toggling pro audio profile
by GitHub issues - edited 29 Mar '23

29 Mar '23

alsa-project/alsa-ucm-conf issue #299 was edited from metronidazole: I have a Gigabyte x570 aorus pro motherboard with the ALC1220 audio device using the dualcodec model. I have two issues: A. jack sense doesnt work. I'm not sure if this is a UCM thing, but in my desktop environment (KDE Plasma 5.27) the headphones port shows as "unplugged" in system settings, and hdajacksensetest shows it as not detected "Pin 0x1b (Green Headphone, Front side): present = No". this is a minor issue B. more importantly, when i want to use my frontpanel headphones input, i have to do the following work around otherwise no sound comes out: 1. Start with Profile set to 'analog stereo output' and port 'line out' 2. Plug in headphones and set port to 'headphones (unplugged)' -> sound stops from speakers (rear line out port) and there is no output from the headphoens 3. Set profile to pro audio -> audio comes through headphones (front port). **to return back to speakers (rear out)** 4. Set profile to analog stereo output) and change the port to 'headphones (unplugged)' and then back to 'line out' -> sound comes out of speakers I have attached some debug info below: [alsa-info.txt](https://github.com/alsa-project/alsa-ucm-conf/files/11099085… [alsaucm.txt](https://github.com/alsa-project/alsa-ucm-conf/files/11099087/a… Any help would be appreciated Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/299 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALC1220 DualCodec - changing to headphone (front panel) port doesn't work without toggling pro audio profile
by GitHub issues - opened 29 Mar '23

29 Mar '23

alsa-project/alsa-ucm-conf issue #299 was opened from metronidazole: I have a Gigabyte x570 aorus pro motherboard with the ALC1220 audio device using the dualcodec model. I have two issues: A. jack sense doesnt work. I'm not sure if this is a UCM thing, but in my desktop environment (KDE Plasma 5.27) the headphones port shows as "unplugged" in system settings, and hdajacksensetest shows it as not detected "Pin 0x1b (Green Headphone, Front side): present = No". this is a minor issue B. more importantly, when i want to use my frontpanel headphones input, i have to do the following work around otherwise no sound comes out: 1. Start with Profile set to 'analog stereo output' and port 'line out' 2. Plug in headphones and set port to 'headphones (unplugged)' -> sound stops from speakers (rear line out port) and there is no output from the headphoens 3. Set profile to pro audio -> audio comes through headphones (front port). 4. Optionally, i can set the profile back to analog stero output and sound continues to come out through headphones (the port is however set to the default of 'line out') **to return back to speakers (rear out)** 5. While keeping the profile the same (as analog stereo output), i change port to 'headphones (unplugged)' and then change it back to 'line out' -> sound comes out of speakers I have attached some debug info below: [alsa-info.txt](https://github.com/alsa-project/alsa-ucm-conf/files/11099085… [alsaucm.txt](https://github.com/alsa-project/alsa-ucm-conf/files/11099087/a… Any help would be appreciated Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/299 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH] ALSA: ymfpci: Use register macro in place of integer literal
by Tasos Sahanidis 29 Mar '23

29 Mar '23

The macro for said register already exists, so just use it, to make the code more readable. Signed-off-by: Tasos Sahanidis <tasos(a)tasossah.com> --- sound/pci/ymfpci/ymfpci_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/ymfpci/ymfpci_main.c b/sound/pci/ymfpci/ymfpci_main.c index 2858736ed..24378f6fd 100644 --- a/sound/pci/ymfpci/ymfpci_main.c +++ b/sound/pci/ymfpci/ymfpci_main.c @@ -2214,7 +2214,7 @@ static void snd_ymfpci_free(struct snd_card *card) snd_ymfpci_free_gameport(chip); - pci_write_config_word(chip->pci, 0x40, chip->old_legacy_ctrl); + pci_write_config_word(chip->pci, PCIR_DSXG_LEGACY, chip->old_legacy_ctrl); release_firmware(chip->dsp_microcode); release_firmware(chip->controller_microcode); -- 2.25.1

2 1