December 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] Applied "ASoC: fsl_audmix: add missed pm_runtime_disable" to the asoc tree
by Mark Brown 25 Dec '19

25 Dec '19

The patch ASoC: fsl_audmix: add missed pm_runtime_disable has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 77fffa742285f2b587648d6c72b5c705633f146f Mon Sep 17 00:00:00 2001 From: Chuhong Yuan <hslester96(a)gmail.com> Date: Tue, 3 Dec 2019 19:13:03 +0800 Subject: [PATCH] ASoC: fsl_audmix: add missed pm_runtime_disable The driver forgets to call pm_runtime_disable in probe failure and remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan <hslester96(a)gmail.com> Acked-by: Nicolin Chen <nicoleotsuka(a)gmail.com> Link: https://lore.kernel.org/r/20191203111303.12933-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/fsl/fsl_audmix.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c index a1db1bce330f..5faecbeb5497 100644 --- a/sound/soc/fsl/fsl_audmix.c +++ b/sound/soc/fsl/fsl_audmix.c @@ -505,15 +505,20 @@ static int fsl_audmix_probe(struct platform_device *pdev) ARRAY_SIZE(fsl_audmix_dai)); if (ret) { dev_err(dev, "failed to register ASoC DAI\n"); - return ret; + goto err_disable_pm; } priv->pdev = platform_device_register_data(dev, mdrv, 0, NULL, 0); if (IS_ERR(priv->pdev)) { ret = PTR_ERR(priv->pdev); dev_err(dev, "failed to register platform %s: %d\n", mdrv, ret); + goto err_disable_pm; } + return 0; + +err_disable_pm: + pm_runtime_disable(dev); return ret; } @@ -521,6 +526,8 @@ static int fsl_audmix_remove(struct platform_device *pdev) { struct fsl_audmix *priv = dev_get_drvdata(&pdev->dev); + pm_runtime_disable(&pdev->dev); + if (priv->pdev) platform_device_unregister(priv->pdev); -- 2.20.1

1 0

[alsa-devel] [PATCH 0/3] ASoC: SOF: fixes for kernel oopses/use-after-free
by Pierre-Louis Bossart 25 Dec '19

25 Dec '19

More stability fixes for corner cases. It wasn't straightforward to add a Fixes tag for the two Intel patches, it's likely issues that can be applied to 5.3, possibly earlier. For Dragos' patch Ranjani mentioned this may be due to da704f26ba376 ('ASoC: soc-core: merge snd_soc_remove_dai_link() and soc_unbind_dai_link()'), but Morimoto-san may need to confirm. Dragos Tarcatu (1): ASoC: topology: Prevent use-after-free in snd_soc_get_pcm_runtime() Kai Vehmanen (1): ASoC: SOF: fix fault at driver unload after failed probe Pierre-Louis Bossart (1): ASoC: SOF: Intel: hda: hda-dai: fix oops on hda_link .hw_free sound/soc/soc-topology.c | 6 +++--- sound/soc/sof/intel/hda-dai.c | 11 +++++++++-- sound/soc/sof/ipc.c | 3 +++ 3 files changed, 15 insertions(+), 5 deletions(-) -- 2.20.1

3 5

[alsa-devel] [PATCH -next] ASoC: Intel: kbl_da7219_max98357a: remove unused variable 'constraints_16000' and 'ch_mono'
by YueHaibing 25 Dec '19

25 Dec '19

sound/soc/intel/boards/kbl_da7219_max98357a.c:343:48: warning: constraints_16000 defined but not used [-Wunused-const-variable=] sound/soc/intel/boards/kbl_da7219_max98357a.c:348:27: warning: ch_mono defined but not used [-Wunused-const-variable=] They are never used, so can be removed. Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- sound/soc/intel/boards/kbl_da7219_max98357a.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c b/sound/soc/intel/boards/kbl_da7219_max98357a.c index 537a889..0d55319 100644 --- a/sound/soc/intel/boards/kbl_da7219_max98357a.c +++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c @@ -336,19 +336,6 @@ static struct snd_soc_ops kabylake_dmic_ops = { .startup = kabylake_dmic_startup, }; -static const unsigned int rates_16000[] = { - 16000, -}; - -static const struct snd_pcm_hw_constraint_list constraints_16000 = { - .count = ARRAY_SIZE(rates_16000), - .list = rates_16000, -}; - -static const unsigned int ch_mono[] = { - 1, -}; - SND_SOC_DAILINK_DEF(dummy, DAILINK_COMP_ARRAY(COMP_DUMMY())); -- 2.7.4

2 1

[alsa-devel] [PATCH v4 0/2] Add the broadmobi BM818
by Angus Ainslie (Purism) 25 Dec '19

25 Dec '19

The broadmobi uses slightly different parameters from the option modems so add the paramters and document them. Changes since v3: Dropped unrelated indentation fix. Fixed const warning. Changes since v2: Use of_device_get_match_data to get the dai data. Updated subject styles. Changes since v1: Cut back the CC list. Use data from compatible match instead of explicit compatible match. Angus Ainslie (Purism) (2): ASoC: gtm601: add Broadmobi bm818 sound profile dt-bindings: sound: gtm601: add the broadmobi interface .../devicetree/bindings/sound/gtm601.txt | 10 +++++-- sound/soc/codecs/gtm601.c | 30 +++++++++++++++++-- 2 files changed, 35 insertions(+), 5 deletions(-) -- 2.17.1

2 4

[alsa-devel] [PATCH 0/2] ASoC: SOF: Intel: add support for TigerLake 4th iDISP link
by Pierre-Louis Bossart 25 Dec '19

25 Dec '19

TigerLake has 4 iDISP connections, not 3 as in previous generations. The patches add the relevant DAI definition. This was tested as having no impact on previous generations. Support for 4 links with the legacy HDaudio driver is already planned and will be release soon by Kai. Sathyanarayana Nujella (2): ASoC: SOF: Intel: hda: Add iDisp4 DAI ASoC: hdac_hda: Update hdac hda dai table to include intel-hdmi-hifi4 sound/soc/codecs/hdac_hda.c | 16 ++++++++++++++++ sound/soc/codecs/hdac_hda.h | 3 ++- sound/soc/sof/intel/hda-dai.c | 4 ++++ 3 files changed, 22 insertions(+), 1 deletion(-) -- 2.20.1

2 4

[alsa-devel] [PATCH] ASoC: SOF: imx8: Fix dsp_box offset
by Pierre-Louis Bossart 25 Dec '19

25 Dec '19

From: Daniel Baluta <daniel.baluta(a)nxp.com> dsp_box is used to keep DSP initiated messages. The value of dsp_offset is set by the DSP with the first message, so we need a way to bootstrap it in order to get the first message. We do this by setting the correct default dsp_box offset which on i.MX8 is not zero. Very interesting is why it has worked until now. On i.MX8, DSP communicates with ARM core using a shared SDRAM memory area. Actually, there are two shared areas: * SDRAM0 - starting at 0x92400000, size 0x800000 * SDRAM1 - starting at 0x92C00000, size 0x800000 SDRAM0 keeps the data sections, starting with .rodata. By chance fw_ready structure was placed at the beginning of .rodata. dsp_box_base is defined as SDRAM0 + dsp_box_offset and it is placed at the beginning of SDRAM1 (dsp_box_offset should be 0x800000). But because it is zero initialized by default it points to SDRAM0 where by chance the fw_ready was placed in the SOF firmware. Anyhow, SOF commit 7466bee378dd811b ("clk: make freq arrays constant") fw_ready is no longer at the beginning of SDRAM0 and everything shows how lucky we were until now. Fix this by properly setting the default dsp_box offset. Fixes: 202acc565a1f050 ("ASoC: SOF: imx: Add i.MX8 HW support") Signed-off-by: Daniel Baluta <daniel.baluta(a)nxp.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/sof/imx/imx8.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/sof/imx/imx8.c b/sound/soc/sof/imx/imx8.c index cfefcfd92798..dca85cf07ffa 100644 --- a/sound/soc/sof/imx/imx8.c +++ b/sound/soc/sof/imx/imx8.c @@ -304,6 +304,9 @@ static int imx8_probe(struct snd_sof_dev *sdev) } sdev->mailbox_bar = SOF_FW_BLK_TYPE_SRAM; + /* set default mailbox offset for FW ready message */ + sdev->dsp_box.offset = MBOX_OFFSET; + return 0; exit_pdev_unregister: -- 2.20.1

2 1

[alsa-devel] [PATCH] ALSA: ctl: allow TLV read operation for callback type of element in locked case
by Takashi Sakamoto 24 Dec '19

24 Dec '19

A design of ALSA control core allows applications to execute three operations for TLV feature; read, write and command. Furthermore, it allows driver developers to process the operations by two ways; allocated array or callback function. In the former, read operation is just allowed, thus developers uses the latter when device driver supports variety of models or the target model is expected to dynamically change information stored in TLV container. The core also allows applications to lock any element so that the other applications can't perform write operation to the element for element value and TLV information. When the element is locked, write and command operation for TLV information are prohibited as well as element value. Any read operation should be allowed in the case. At present, when an element has callback function for TLV information, TLV read operation returns EPERM if the element is locked. On the other hand, the read operation is success when an element has allocated array for TLV information. In both cases, read operation is success for element value expectedly. This commit fixes the bug. This change can be backported to v4.14 kernel or later. --- sound/core/control.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/core/control.c b/sound/core/control.c index 3fa1171dc1c2..49f3428dfacb 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -1398,8 +1398,9 @@ static int call_tlv_handler(struct snd_ctl_file *file, int op_flag, if (kctl->tlv.c == NULL) return -ENXIO; - /* When locked, this is unavailable. */ - if (vd->owner != NULL && vd->owner != file) + // Write and command operations are not allowed for locked element. + if (op_flag != SNDRV_CTL_TLV_OP_READ && + vd->owner != NULL && vd->owner != file) return -EPERM; return kctl->tlv.c(kctl, op_flag, size, buf); -- 2.20.1

3 5

[alsa-devel] [PATCH] xfer-opitons: Fix -Wformat=2 warnings
by Rosen Penev 24 Dec '19

24 Dec '19

Allows the compiler to check types. format string functions expect constant expressions, not constant variables. Signed-off-by: Rosen Penev <rosenp(a)gmail.com> --- axfer/xfer-options.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/axfer/xfer-options.c b/axfer/xfer-options.c index 3740b16..d4e5ff2 100644 --- a/axfer/xfer-options.c +++ b/axfer/xfer-options.c @@ -422,8 +422,6 @@ static int generate_path_with_suffix(struct xfer_context *xfer, const char *template, unsigned int index, const char *suffix) { - static const char *const single_format = "%s%s"; - static const char *const multiple_format = "%s-%i%s"; unsigned int len; len = strlen(template) + strlen(suffix) + 1; @@ -435,10 +433,10 @@ static int generate_path_with_suffix(struct xfer_context *xfer, return -ENOMEM; if (xfer->path_count == 1) { - snprintf(xfer->paths[index], len, single_format, template, + snprintf(xfer->paths[index], len, "%s%s", template, suffix); } else { - snprintf(xfer->paths[index], len, multiple_format, template, + snprintf(xfer->paths[index], len, "%s-%i%s", template, index, suffix); } @@ -449,8 +447,6 @@ static int generate_path_without_suffix(struct xfer_context *xfer, const char *template, unsigned int index, const char *suffix) { - static const char *const single_format = "%s"; - static const char *const multiple_format = "%s-%i"; unsigned int len; len = strlen(template) + 1; @@ -462,9 +458,9 @@ static int generate_path_without_suffix(struct xfer_context *xfer, return -ENOMEM; if (xfer->path_count == 1) { - snprintf(xfer->paths[index], len, single_format, template); + snprintf(xfer->paths[index], len, "%s", template); } else { - snprintf(xfer->paths[index], len, multiple_format, template, + snprintf(xfer->paths[index], len, "%s-%i", template, index); } -- 2.24.1

2 1

[alsa-devel] [PATCH] ALSA: hda - Apply sync-write workaround to old Intel platforms, too
by Takashi Iwai 23 Dec '19

23 Dec '19

Klaus Ethgen reported occasional high CPU usages in his system that seem caused by HD-audio driver. The perf output revealed that it's in the unsolicited event handling in the workqueue, and the problem seems triggered by some communication stall between the controller and the codec at the runtime or system resume. Actually a similar phenomenon was seen in the past for other Intel platforms, and we already applied the workaround to enforce sync-write for CORB/RIRB verbs for Skylake and newer chipsets (commit 2756d9143aa5 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"). Fortunately, the same workaround is applicable to the old chipset, and the experiment showed the positive effect. Based on the experiment result, this patch enables the sync-write workaround for all Intel chipsets. The only reason I hesitated to apply this workaround was about the possibly slightly higher CPU usage. But if the lack of sync causes a much severer problem even for quite old chip, we should think this would be necessary for all Intel chips. Reported-by: Klaus Ethgen <Klaus(a)ethgen.ch> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20191223171833.GA17053@chua Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f69c8de64bd6..5b92f290cbb0 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -282,12 +282,13 @@ enum { /* quirks for old Intel chipsets */ #define AZX_DCAPS_INTEL_ICH \ - (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE) + (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE |\ + AZX_DCAPS_SYNC_WRITE) /* quirks for Intel PCH */ #define AZX_DCAPS_INTEL_PCH_BASE \ (AZX_DCAPS_NO_ALIGN_BUFSIZE | AZX_DCAPS_COUNT_LPIB_DELAY |\ - AZX_DCAPS_SNOOP_TYPE(SCH)) + AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE) /* PCH up to IVB; no runtime PM; bind with i915 gfx */ #define AZX_DCAPS_INTEL_PCH_NOPM \ @@ -302,13 +303,13 @@ enum { #define AZX_DCAPS_INTEL_HASWELL \ (/*AZX_DCAPS_ALIGN_BUFSIZE |*/ AZX_DCAPS_COUNT_LPIB_DELAY |\ AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_I915_COMPONENT |\ - AZX_DCAPS_SNOOP_TYPE(SCH)) + AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE) /* Broadwell HDMI can't use position buffer reliably, force to use LPIB */ #define AZX_DCAPS_INTEL_BROADWELL \ (/*AZX_DCAPS_ALIGN_BUFSIZE |*/ AZX_DCAPS_POSFIX_LPIB |\ AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_I915_COMPONENT |\ - AZX_DCAPS_SNOOP_TYPE(SCH)) + AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE) #define AZX_DCAPS_INTEL_BAYTRAIL \ (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_I915_COMPONENT) -- 2.16.4

1 0

[alsa-devel] CPU hook snd_hda_intel
by Klaus Ethgen 23 Dec '19

23 Dec '19

Hello, Please keep me in Cc when you answer as I am not subscribed to the list. I use the most current kernel 5.4.1 (but I did have that problem since several 5.x versions) on gentoo on a X61s Lenovo laptop. What I see is that from time to time one CPU is constantly working and draining my battery with a process kworker/*-events. Today I was able to identify the source of the problem. The module snd-hda-intel seems to produce that load. When I unload the module, the CPU hook is gone. Even if I load it again, I have a good change to solve the problem. It also helps often to put the laptop to sleep and waking it up again. My relevant dmesg part is: [ 7.186766] snd_hda_intel 0000:00:1b.0: probe_mask set to 0x1 for device 17aa:20ac [ 7.563277] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=1 (0x12/0x0/0x0/0x0/0x0) type:speaker [ 7.563281] snd_hda_codec_generic hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 7.563284] snd_hda_codec_generic hdaudioC0D0: hp_outs=1 (0x11/0x0/0x0/0x0/0x0) [ 7.563286] snd_hda_codec_generic hdaudioC0D0: mono: mono_out=0x0 [ 7.563288] snd_hda_codec_generic hdaudioC0D0: inputs: [ 7.563292] snd_hda_codec_generic hdaudioC0D0: Internal Mic=0x15 [ 7.563294] snd_hda_codec_generic hdaudioC0D0: Mic=0x14 [ 7.563297] snd_hda_codec_generic hdaudioC0D0: Dock Mic=0x1c For reference I attach my kernel config to this mail. I am not sure if it is needed but better give as much as informations that I have. So please, if you have any idea how to narrow that problem or even solve it, help would be appreciated. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus(a)Ethgen.ch> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C

2 16