October 2021 - Alsa-devel - mailman.alsa-project.org

Re: Fwd: [PATCH 4/8] ASoC: amd: acp: Add generic machine driver support for ACP cards
by Ajit Kumar Pandey 11 Oct '21

11 Oct '21

Apologies for corrupted reply format, some issue with thunderbird. We will update all below review comments in v2 patch series > On Thu, Sep 30, 2021 at 06:54:14PM +0530, Ajit Kumar Pandey wrote: > > A couple of things here, most of these are probably fine for now > other than the EXPORT_SYMBOL but I think you're likely to run > into issues going forward and need to refactor. > >> + switch (drvdata->hs_codec_id) { >> + case RT5682: >> + pll_id = RT5682_PLL2; >> + pll_src = RT5682_PLL2_S_MCLK; >> + freq_in = PCO_PLAT_CLK; >> + freq_out = RT5682_PLL_FREQ; >> + clk_id = RT5682_SCLK_S_PLL2; >> + clk_freq = RT5682_PLL_FREQ; >> + wclk_name = "rt5682-dai-wclk"; >> + bclk_name = "rt5682-dai-bclk"; >> + drvdata->dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF >> + | SND_SOC_DAIFMT_CBP_CFP; >> + snd_soc_dapm_add_routes(&rtd->card->dapm, rt5682_map, ARRAY_SIZE(rt5682_map)); >> + break; > > It feels like this is going to run into scaling issues going > forward and you're likely to need separate operations for > different CODECs rather than just different IDs. Similar issues > apply for the amps, it feels like you want to be passing separate > ops in rather than having these switch statements. Ok will change to use separate ops in v2 patch series instead of switch statements. > >> + /* Do nothing for dummy codec */ >> + if (!drvdata->hs_codec_id && drvdata->amp_codec_id) >> + return; > > Wha the test seems to say is do nothing if there's no CODEC but > there is an amp... > >> + >> + clk_disable_unprepare(drvdata->wclk); >> +} > > ...though I'd expect that given that the clock API accepts NULL > clocks you could just remove these checks and unconditionally use > the clocks. Ok will remove this check in v2 patch series. > >> + return 0; >> +} >> +EXPORT_SYMBOL_NS(acp_legacy_dai_links_create, SND_SOC_AMD_MACH); > > EXPORT_SYMBOL_GPL_NS() - ASoC is all EXPORT_SYMBOL_GPL > sure will update to use NS_GPL() in v2 patch chain

1 0

When will we have a new release?
by GitHub issues - opened 11 Oct '21

11 Oct '21

alsa-project/alsa-lib issue #185 was opened from leiserfg: There was an issue in the last release that affects pipewire while using laptops with `Comet Lake PCH` that was solved in alsa after the release. I'm currently using `master` via AUR but will love to be able to use a release version (so I don't have to re-build with every change on master) Issue URL : https://github.com/alsa-project/alsa-lib/issues/185 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH 00/13] Add Yellow Carp platform ASoC driver
by Vijendar Mukunda 11 Oct '21

11 Oct '21

Yellow Carp platform is new APU series based on acp6.x design. This patch set adds an ASoC driver for the ACP (Audio CoProcessor) block on AMD Yellow Carp APU with DMIC endpoint support. Vijendar Mukunda (13): ASoC: amd: add Yellow Carp ACP6x IP register header ASoC: amd: add Yellow Carp ACP PCI driver ASoC: amd: add acp6x init/de-init functions ASoC: amd: add platform devices for acp6x pdm driver and dmic driver ASoC: amd: add acp6x pdm platform driver ASoC: amd: add acp6x irq handler ASoC: amd: add acp6x pdm driver dma ops ASoC: amd: add acp6x pci driver pm ops ASoC: amd: add acp6x pdm driver pm ops ASoC: amd: enable Yellow carp acp6x drivers build ASoC: amd: create platform device for acp6x machine driver ASoC: amd: add YC machine driver using dmic ASoC: amd: enable yc machine driver build sound/soc/amd/Kconfig | 13 + sound/soc/amd/Makefile | 1 + sound/soc/amd/yc/Makefile | 9 + sound/soc/amd/yc/acp6x-mach.c | 76 ++++ sound/soc/amd/yc/acp6x-pdm-dma.c | 447 ++++++++++++++++++++++ sound/soc/amd/yc/acp6x.h | 107 ++++++ sound/soc/amd/yc/acp6x_chip_offset_byte.h | 444 +++++++++++++++++++++ sound/soc/amd/yc/pci-acp6x.c | 343 +++++++++++++++++ 8 files changed, 1440 insertions(+) create mode 100644 sound/soc/amd/yc/Makefile create mode 100644 sound/soc/amd/yc/acp6x-mach.c create mode 100644 sound/soc/amd/yc/acp6x-pdm-dma.c create mode 100644 sound/soc/amd/yc/acp6x.h create mode 100644 sound/soc/amd/yc/acp6x_chip_offset_byte.h create mode 100644 sound/soc/amd/yc/pci-acp6x.c -- 2.25.1

5 22

[PATCH] ALSA: usb-audio: Less restriction for low-latency playback mode
by Takashi Iwai 11 Oct '21

11 Oct '21

The recent support for the improved low-latency playback mode applied the SNDRV_PCM_INFO_EXPLICIT_SYNC flag for the target streams, but this was a slight overkill. The use of the flag above disables effectively both PCM status and control mmaps, while basically what we want to track is only about the appl_ptr update. For less restriction, use a more proper flag, SNDRV_PCM_INFO_SYNC_APPLPTR instead, which disables only the control mmap. Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 3bb095a3c9b6..95ec8eec1bb0 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -1102,7 +1102,7 @@ static int snd_usb_pcm_open(struct snd_pcm_substream *substream) /* need an explicit sync to catch applptr update in low-latency mode */ if (direction == SNDRV_PCM_STREAM_PLAYBACK && as->chip->lowlatency) - runtime->hw.info |= SNDRV_PCM_INFO_EXPLICIT_SYNC; + runtime->hw.info |= SNDRV_PCM_INFO_SYNC_APPLPTR; runtime->private_data = subs; subs->pcm_substream = substream; /* runtime PM is also done there */ -- 2.31.1

1 0

None
by srinivas.kandagatla＠linaro.org 11 Oct '21

11 Oct '21

On 08/10/2021 16:30, Mark Brown wrote: > On Fri, Oct 08, 2021 at 07:37:12PM +0530, Srinivasa Rao Mandadapu wrote: >> On 9/28/2021 2:01 PM, Srinivas Kandagatla wrote: > >>> In that case you should probably consider using regmap_register_patch() >>> for corrections to the default registers in sm8250 case. > >> As regmap_register_patch() not working in this use case, updating defaults >> in probe for sc7280 specific differences. > > In what way is regmap_register_patch() not working? SM8250 and SC7280 has different register defaults values for few (atleast 2 that we are aware of) registers. Initially we thought regmap_register_patch() would help in this case, but later learned that it was designed for completely different usecase and this will not update the cache values with the new values from reg_sequence passed to regmap_register_patch(). What we want was to be able to reflect that default values in the regcaches, so that subsequent writes are not ignored based on incorrect cache values. There are two ways to fix this, one is to come up with a full default register list specific to SC7280 or reuse SM8250 defaults with some modifications, other option is to update default registers based on compatible string before regmap creation. I suggested Srinivasa to use the second option as 99% of the defaults match to SM8250. --srini >

1 0

[PATCH] ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2.
by Cameron Berkenpas 11 Oct '21

11 Oct '21

The previous patch's HDA verb initialization for the Lenovo 13s sequence was slightly off. This updated verb sequence has been tested and confirmed working. Fixes: ad7cc2d41b7a ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555 Cc: <stable(a)vger.kernel.org> Cc: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Cameron Berkenpas <cam(a)neo-zeon.de> --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 4407f7da57c4..84d3e062a335 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -8344,7 +8344,7 @@ static const struct hda_fixup alc269_fixups[] = { .v.verbs = (const struct hda_verb[]) { { 0x20, AC_VERB_SET_COEF_INDEX, 0x24 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x41 }, - { 0x20, AC_VERB_SET_PROC_COEF, 0xb020 }, + { 0x20, AC_VERB_SET_COEF_INDEX, 0x26 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x2 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, -- 2.30.2

2 1

None
by srivasam＠codeaurora.org 11 Oct '21

11 Oct '21

On 10/8/2021 9:00 PM, Mark Brown wrote: > On Fri, Oct 08, 2021 at 07:37:12PM +0530, Srinivasa Rao Mandadapu wrote: >> On 9/28/2021 2:01 PM, Srinivas Kandagatla wrote: >>> In that case you should probably consider using regmap_register_patch() >>> for corrections to the default registers in sm8250 case. >> As regmap_register_patch() not working in this use case, updating defaults >> in probe for sc7280 specific differences. > In what way is regmap_register_patch() not working? Even after using this API, reg cache is not updating with the latest default values. The regmap_register_patch() implementation is bypassing Cache and writing values to HW. The requirement for updating previous defaults in cache is not solving here. -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

1 0

None
by srivasam＠codeaurora.org 11 Oct '21

11 Oct '21

On 10/8/2021 9:00 PM, Mark Brown wrote: > On Fri, Oct 08, 2021 at 07:37:12PM +0530, Srinivasa Rao Mandadapu wrote: >> On 9/28/2021 2:01 PM, Srinivas Kandagatla wrote: >>> In that case you should probably consider using regmap_register_patch() >>> for corrections to the default registers in sm8250 case. >> As regmap_register_patch() not working in this use case, updating defaults >> in probe for sc7280 specific differences. > In what way is regmap_register_patch() not working? Even after using this API, reg cache is not updating with the latest default values. The regmap_register_patch() implementation is bypassing Cache and writing values to HW. The requirement for updating previous defaults in cache is not solving here. -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

1 0

[PATCH 1/3] ASoc: amd: create platform device for VG machine driver
by Vijendar Mukunda 11 Oct '21

11 Oct '21

Create platform device for Vangogh machine driver. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda(a)amd.com> --- sound/soc/amd/vangogh/acp5x.h | 2 +- sound/soc/amd/vangogh/pci-acp5x.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/soc/amd/vangogh/acp5x.h b/sound/soc/amd/vangogh/acp5x.h index a808635f9740..fe5e1fa98974 100644 --- a/sound/soc/amd/vangogh/acp5x.h +++ b/sound/soc/amd/vangogh/acp5x.h @@ -23,7 +23,7 @@ #define ACP_ERR_INTR_MASK 0x20000000 #define ACP_EXT_INTR_STAT_CLEAR_MASK 0xFFFFFFFF -#define ACP5x_DEVS 3 +#define ACP5x_DEVS 4 #define ACP5x_REG_START 0x1240000 #define ACP5x_REG_END 0x1250200 #define ACP5x_I2STDM_REG_START 0x1242400 diff --git a/sound/soc/amd/vangogh/pci-acp5x.c b/sound/soc/amd/vangogh/pci-acp5x.c index a57b762d9f2e..137e64c47882 100644 --- a/sound/soc/amd/vangogh/pci-acp5x.c +++ b/sound/soc/amd/vangogh/pci-acp5x.c @@ -213,6 +213,9 @@ static int snd_acp5x_probe(struct pci_dev *pci, pdevinfo[2].num_res = 1; pdevinfo[2].res = &adata->res[2]; + pdevinfo[3].name = "acp5x_nu8821_cs35l41_mach"; + pdevinfo[3].id = 0; + pdevinfo[3].parent = &pci->dev; for (i = 0; i < ACP5x_DEVS; i++) { adata->pdev[i] = platform_device_register_full(&pdevinfo[i]); -- 2.25.1

3 6

[PATCH] ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2.
by Cameron Berkenpas 10 Oct '21

10 Oct '21

The previous patch's HDA verb initialization for the Lenovo 13s sequence was slightly off. This updated verb sequence has been tested and confirmed working. --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 4407f7da57c4..84d3e062a335 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -8344,7 +8344,7 @@ static const struct hda_fixup alc269_fixups[] = { .v.verbs = (const struct hda_verb[]) { { 0x20, AC_VERB_SET_COEF_INDEX, 0x24 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x41 }, - { 0x20, AC_VERB_SET_PROC_COEF, 0xb020 }, + { 0x20, AC_VERB_SET_COEF_INDEX, 0x26 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x2 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, -- 2.30.2

2 1