January 2020 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] memory leak in snd_pcm_hw_params
by syzbot 29 Jan '20

29 Jan '20

Hello, syzbot found the following crash on: HEAD commit: b3a60822 Merge branch 'for-v5.6' of git://git.kernel.org:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1351cf66e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=e97a1bc78afb77f dashboard link: https://syzkaller.appspot.com/bug?extid=30edd0f34bfcdc548ac4 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14e97735e00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13cd9bc9e00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+30edd0f34bfcdc548ac4(a)syzkaller.appspotmail.com executing program executing program executing program BUG: memory leak unreferenced object 0xffff888108fdefc0 (size 64): comm "syz-executor222", pid 7310, jiffies 4294946025 (age 13.660s) hex dump (first 32 bytes): 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 10 33 02 00 c9 ff ff 00 00 00 00 00 00 00 00 ..3............. backtrace: [<00000000c59c6b0c>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<00000000c59c6b0c>] slab_post_alloc_hook mm/slab.h:586 [inline] [<00000000c59c6b0c>] slab_alloc mm/slab.c:3320 [inline] [<00000000c59c6b0c>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3549 [<00000000478172ce>] kmalloc include/linux/slab.h:556 [inline] [<00000000478172ce>] kzalloc include/linux/slab.h:670 [inline] [<00000000478172ce>] snd_pcm_lib_malloc_pages+0x12b/0x200 sound/core/pcm_memory.c:404 [<0000000091532e16>] snd_pcm_hw_params+0x720/0x830 sound/core/pcm_native.c:691 [<000000002070a986>] snd_pcm_kernel_ioctl+0xb5/0x170 sound/core/pcm_native.c:3238 [<00000000394e99f4>] snd_pcm_oss_change_params_locked+0x745/0x1140 sound/core/oss/pcm_oss.c:944 [<00000000c81f42ac>] snd_pcm_oss_change_params+0x43/0x80 sound/core/oss/pcm_oss.c:1087 [<000000007710a1c0>] snd_pcm_oss_make_ready+0x55/0xc0 sound/core/oss/pcm_oss.c:1146 [<0000000069305204>] snd_pcm_oss_sync.isra.0+0xb8/0x310 sound/core/oss/pcm_oss.c:1707 [<00000000692460c8>] snd_pcm_oss_release+0xef/0x100 sound/core/oss/pcm_oss.c:2545 [<0000000013ba02c9>] __fput+0xed/0x300 fs/file_table.c:280 [<0000000080810f18>] ____fput+0x16/0x20 fs/file_table.c:313 [<00000000e6bb3aa6>] task_work_run+0x9d/0xc0 kernel/task_work.c:113 [<00000000b6ce71eb>] exit_task_work include/linux/task_work.h:22 [inline] [<00000000b6ce71eb>] do_exit+0x3fa/0xe20 kernel/exit.c:801 [<0000000045ce7ad3>] do_group_exit+0x4b/0xe0 kernel/exit.c:899 [<00000000aeb85903>] __do_sys_exit_group kernel/exit.c:910 [inline] [<00000000aeb85903>] __se_sys_exit_group kernel/exit.c:908 [inline] [<00000000aeb85903>] __x64_sys_exit_group+0x1c/0x20 kernel/exit.c:908 [<000000008b12db16>] do_syscall_64+0x73/0x220 arch/x86/entry/common.c:294 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

1 0

[alsa-devel] issue with alsa lib (ucm vs ucm2 folders?)
by Pedro Costa 29 Jan '20

29 Jan '20

Dear all, My apologies in advance for a very non-technical feedback from a non-expert. I was unable to get sound output after updating alsa-lib on my Manjaro Linux system. I managed to get it working after downgrading it to version 1.1.9.2. It seems that I faced the same problem as reported here: https://bbs.archlinux.org/viewtopic.php?id=251113 You may already be aware of the issue, but just in case I would like be sure that you are! Best regards, Pedro Costa

2 1

[alsa-devel] [CX2075] No sound after suspend/resume from front speaker
by Roman Šmakal 29 Jan '20

29 Jan '20

Hi, this still seem to be an issue. After startup everything works well until the laptop goes to suspend. Tried pretty much everything basic user can do (unmutes, rmmods and so on), still no way to wake the output. ALSA seems to be thinking, that output is active, you can set volume and stuff, but nothing happens. ALSA info: http://alsa-project.org/db/?f=9d1ee81fe037acb53ca381f2de27be420f83a373 Related links: https://www.reddit.com/r/archlinux/comments/4nwzua/ no_sound_after_suspend_killing_or_restarting/ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851404 Regards Roman

2 1

[alsa-devel] [PATCH v6 00/11] ASoC: Add support to WCD9340/WCD9341 codec
by Srinivas Kandagatla 29 Jan '20

29 Jan '20

This patchset adds support to Qualcomm WCD9340/WCD9341 Codec which is a standalone Hi-Fi audio codec IC. This codec supports both I2S/I2C and SLIMbus audio interfaces. On slimbus interface it supports two data lanes; 16 Tx ports and 8 Rx ports. It has Five DACs and seven dedicated interpolators, Multibutton headset control (MBHC), Active noise cancellation, Sidetone paths, MAD (mic activity detection) and codec processing engine. It supports Class-H differential earpiece out and stereo single ended headphones out. This codec also has integrated SoundWire controller. Patchset for this is already sent for review. This patchset has been tested on SDM845 based DragonBoard DB845c and Lenovo Yoga C630 laptop with WSA881x smart speaker amplifiers via soundwire and 4 DMICs. gpio controller patch does not have any link dependency, it can go by its own. Most of the code in this driver is rework of Qualcomm downstream drivers used in Andriod. Credits to Banajit Goswami and Patrick Lai's Team. Thanks, srini Changes since v5: - added correct MFD dependency to codec driver Srinivas Kandagatla (11): ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec mfd: wcd934x: add support to wcd9340/wcd9341 codec ASoC: wcd934x: add support to wcd9340/wcd9341 codec ASoC: wcd934x: add basic controls ASoC: wcd934x: add playback dapm widgets ASoC: wcd934x: add capture dapm widgets ASoC: wcd934x: add audio routings dt-bindings: gpio: wcd934x: Add bindings for gpio gpio: wcd934x: Add support to wcd934x gpio controller ASoC: qcom: dt-bindings: Add compatible for DB845c and Lenovo Yoga ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga .../bindings/gpio/qcom,wcd934x-gpio.yaml | 47 + .../devicetree/bindings/sound/qcom,sdm845.txt | 5 +- .../bindings/sound/qcom,wcd934x.yaml | 175 + drivers/gpio/Kconfig | 8 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-wcd934x.c | 104 + drivers/mfd/Kconfig | 12 + drivers/mfd/Makefile | 1 + drivers/mfd/wcd934x.c | 306 + include/linux/mfd/wcd934x/registers.h | 531 ++ include/linux/mfd/wcd934x/wcd934x.h | 31 + sound/soc/codecs/Kconfig | 8 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/wcd934x.c | 5084 +++++++++++++++++ sound/soc/qcom/sdm845.c | 86 +- 15 files changed, 6399 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/qcom,wcd934x-gpio.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml create mode 100644 drivers/gpio/gpio-wcd934x.c create mode 100644 drivers/mfd/wcd934x.c create mode 100644 include/linux/mfd/wcd934x/registers.h create mode 100644 include/linux/mfd/wcd934x/wcd934x.h create mode 100644 sound/soc/codecs/wcd934x.c -- 2.21.0

6 23

[alsa-devel] [PATCH] ASoC: amd: raven: Make the driver name consistent across files
by Akshu Agrawal 29 Jan '20

29 Jan '20

This fixes the issue of driver not getting auto loaded with MODULE_ALIAS. With this patch: find /sys/devices -name modalias -print0 | xargs -0 grep -i acp3x /sys/devices/pci0000:00/0000:00:08.1/0000:03:00.5/acp3x_i2s_playcap.2/modalias:platform:acp3x_i2s_playcap /sys/devices/pci0000:00/0000:00:08.1/0000:03:00.5/acp3x_i2s_playcap.0/modalias:platform:acp3x_i2s_playcap /sys/devices/pci0000:00/0000:00:08.1/0000:03:00.5/acp3x_rv_i2s_dma.0/modalias:platform:acp3x_rv_i2s_dma /sys/devices/pci0000:00/0000:00:08.1/0000:03:00.5/acp3x_i2s_playcap.1/modalias:platform:acp3x_i2s_playcap Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> --- sound/soc/amd/raven/acp3x-i2s.c | 6 +++--- sound/soc/amd/raven/acp3x-pcm-dma.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/soc/amd/raven/acp3x-i2s.c b/sound/soc/amd/raven/acp3x-i2s.c index bf51cadf8682..8619ed5f08ef 100644 --- a/sound/soc/amd/raven/acp3x-i2s.c +++ b/sound/soc/amd/raven/acp3x-i2s.c @@ -15,7 +15,7 @@ #include "acp3x.h" -#define DRV_NAME "acp3x-i2s" +#define DRV_NAME "acp3x_i2s_playcap" static int acp3x_i2s_set_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt) @@ -276,7 +276,7 @@ static struct snd_soc_dai_ops acp3x_i2s_dai_ops = { }; static const struct snd_soc_component_driver acp3x_dai_component = { - .name = "acp3x-i2s", + .name = DRV_NAME, }; static struct snd_soc_dai_driver acp3x_i2s_dai = { @@ -355,4 +355,4 @@ module_platform_driver(acp3x_dai_driver); MODULE_AUTHOR("Vishnuvardhanrao.Ravulapati(a)amd.com"); MODULE_DESCRIPTION("AMD ACP 3.x PCM Driver"); MODULE_LICENSE("GPL v2"); -MODULE_ALIAS("platform:" DRV_NAME); +MODULE_ALIAS("platform:"DRV_NAME); diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c b/sound/soc/amd/raven/acp3x-pcm-dma.c index aecc3c061679..c865aeca6907 100644 --- a/sound/soc/amd/raven/acp3x-pcm-dma.c +++ b/sound/soc/amd/raven/acp3x-pcm-dma.c @@ -15,7 +15,7 @@ #include "acp3x.h" -#define DRV_NAME "acp3x-i2s-audio" +#define DRV_NAME "acp3x_rv_i2s_dma" static const struct snd_pcm_hardware acp3x_pcm_hardware_playback = { .info = SNDRV_PCM_INFO_INTERLEAVED | @@ -534,4 +534,4 @@ MODULE_AUTHOR("Maruthi.Bayyavarapu(a)amd.com"); MODULE_AUTHOR("Vijendar.Mukunda(a)amd.com"); MODULE_DESCRIPTION("AMD ACP 3.x PCM Driver"); MODULE_LICENSE("GPL v2"); -MODULE_ALIAS("platform:" DRV_NAME); +MODULE_ALIAS("platform:"DRV_NAME); -- 2.17.1

1 0

[alsa-devel] [PATCH] ASoC: Intel: skl_hda_dsp_common: Fix global-out-of-bounds bug
by Cezary Rojewski 28 Jan '20

28 Jan '20

Definitions for idisp snd_soc_dai_links within skl_hda_dsp_common are missing platform component. Add it to address following bug reported by KASAN: [ 10.538502] BUG: KASAN: global-out-of-bounds in skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp] [ 10.538509] Write of size 8 at addr ffffffffc0606840 by task systemd-udevd/299 (...) [ 10.538519] Call Trace: [ 10.538524] dump_stack+0x62/0x95 [ 10.538528] print_address_description+0x2f5/0x3b0 [ 10.538532] ? skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp] [ 10.538535] __kasan_report+0x134/0x191 [ 10.538538] ? skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp] [ 10.538542] ? skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp] [ 10.538544] kasan_report+0x12/0x20 [ 10.538546] __asan_store8+0x57/0x90 [ 10.538550] skl_hda_audio_probe+0x13a/0x2b0 [snd_soc_skl_hda_dsp] [ 10.538553] platform_drv_probe+0x51/0xb0 [ 10.538556] really_probe+0x311/0x600 [ 10.538559] driver_probe_device+0x87/0x1b0 [ 10.538562] device_driver_attach+0x8f/0xa0 [ 10.538565] ? device_driver_attach+0xa0/0xa0 [ 10.538567] __driver_attach+0x102/0x1a0 [ 10.538569] ? device_driver_attach+0xa0/0xa0 [ 10.538572] bus_for_each_dev+0xe8/0x160 [ 10.538574] ? subsys_dev_iter_exit+0x10/0x10 [ 10.538577] ? preempt_count_sub+0x18/0xc0 [ 10.538580] ? _raw_write_unlock+0x1f/0x40 [ 10.538582] driver_attach+0x2b/0x30 [ 10.538585] bus_add_driver+0x251/0x340 [ 10.538588] driver_register+0xd3/0x1c0 [ 10.538590] __platform_driver_register+0x6c/0x80 [ 10.538592] ? 0xffffffffc03e8000 [ 10.538595] skl_hda_audio_init+0x1c/0x1000 [snd_soc_skl_hda_dsp] [ 10.538598] do_one_initcall+0xd0/0x36a [ 10.538600] ? trace_event_raw_event_initcall_finish+0x160/0x160 [ 10.538602] ? kasan_unpoison_shadow+0x36/0x50 [ 10.538605] ? __kasan_kmalloc+0xcc/0xe0 [ 10.538607] ? kasan_unpoison_shadow+0x36/0x50 [ 10.538609] ? kasan_poison_shadow+0x2f/0x40 [ 10.538612] ? __asan_register_globals+0x65/0x80 [ 10.538615] do_init_module+0xf9/0x36f [ 10.538619] load_module+0x398e/0x4590 [ 10.538625] ? module_frob_arch_sections+0x20/0x20 [ 10.538628] ? __kasan_check_write+0x14/0x20 [ 10.538630] ? kernel_read+0x9a/0xc0 [ 10.538632] ? __kasan_check_write+0x14/0x20 [ 10.538634] ? kernel_read_file+0x1d3/0x3c0 [ 10.538638] ? cap_capable+0xca/0x110 [ 10.538642] __do_sys_finit_module+0x190/0x1d0 [ 10.538644] ? __do_sys_finit_module+0x190/0x1d0 [ 10.538646] ? __x64_sys_init_module+0x50/0x50 [ 10.538649] ? expand_files+0x380/0x380 [ 10.538652] ? __kasan_check_write+0x14/0x20 [ 10.538654] ? fput_many+0x20/0xc0 [ 10.538658] __x64_sys_finit_module+0x43/0x50 [ 10.538660] do_syscall_64+0xce/0x700 [ 10.538662] ? syscall_return_slowpath+0x230/0x230 [ 10.538665] ? __do_page_fault+0x51e/0x640 [ 10.538668] ? __kasan_check_read+0x11/0x20 [ 10.538670] ? prepare_exit_to_usermode+0xc7/0x200 [ 10.538673] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: a78959f407e6 ("ASoC: Intel: skl_hda_dsp_common: use modern dai_link style") Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- sound/soc/intel/boards/skl_hda_dsp_common.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/sound/soc/intel/boards/skl_hda_dsp_common.c b/sound/soc/intel/boards/skl_hda_dsp_common.c index eb419e1ec42b..78ff5f24c40e 100644 --- a/sound/soc/intel/boards/skl_hda_dsp_common.c +++ b/sound/soc/intel/boards/skl_hda_dsp_common.c @@ -41,16 +41,19 @@ int skl_hda_hdmi_add_pcm(struct snd_soc_card *card, int device) return 0; } -SND_SOC_DAILINK_DEFS(idisp1, - DAILINK_COMP_ARRAY(COMP_CPU("iDisp1 Pin")), +SND_SOC_DAILINK_DEF(idisp1_cpu, + DAILINK_COMP_ARRAY(COMP_CPU("iDisp1 Pin"))); +SND_SOC_DAILINK_DEF(idisp1_codec, DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi1"))); -SND_SOC_DAILINK_DEFS(idisp2, - DAILINK_COMP_ARRAY(COMP_CPU("iDisp2 Pin")), +SND_SOC_DAILINK_DEF(idisp2_cpu, + DAILINK_COMP_ARRAY(COMP_CPU("iDisp2 Pin"))); +SND_SOC_DAILINK_DEF(idisp2_codec, DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi2"))); -SND_SOC_DAILINK_DEFS(idisp3, - DAILINK_COMP_ARRAY(COMP_CPU("iDisp3 Pin")), +SND_SOC_DAILINK_DEF(idisp3_cpu, + DAILINK_COMP_ARRAY(COMP_CPU("iDisp3 Pin"))); +SND_SOC_DAILINK_DEF(idisp3_codec, DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi3"))); SND_SOC_DAILINK_DEF(analog_cpu, @@ -83,21 +86,21 @@ struct snd_soc_dai_link skl_hda_be_dai_links[HDA_DSP_MAX_BE_DAI_LINKS] = { .id = 1, .dpcm_playback = 1, .no_pcm = 1, - SND_SOC_DAILINK_REG(idisp1), + SND_SOC_DAILINK_REG(idisp1_cpu, idisp1_codec, platform), }, { .name = "iDisp2", .id = 2, .dpcm_playback = 1, .no_pcm = 1, - SND_SOC_DAILINK_REG(idisp2), + SND_SOC_DAILINK_REG(idisp2_cpu, idisp2_codec, platform), }, { .name = "iDisp3", .id = 3, .dpcm_playback = 1, .no_pcm = 1, - SND_SOC_DAILINK_REG(idisp3), + SND_SOC_DAILINK_REG(idisp3_cpu, idisp3_codec, platform), }, { .name = "Analog Playback and Capture", -- 2.17.1

6 14

[alsa-devel] [PATCH 0/4] Add a better separation between i.MX8 families
by Daniel Baluta (OSS) 28 Jan '20

28 Jan '20

From: Daniel Baluta <daniel.baluta(a)nxp.com> So far the implementation was designed to support a generic platform named i.MX8. Anyhow, now working with specific i.MX8 instances we need to account for the differences. i.MX8 naming can be confusing at the first glance, so we need to have a clean separation between different platforms. Here is the split of i.MX8 per platforms. Notice that i.MX8 names the entire family, but also a sub-family. imx8 ├── imx8 │ └── imx8qm (*) ├── imx8m │ ├── imx8mm │ ├── imx8mn │ ├── imx8mp (*) │ └── imx8mq └── imx8x └── imx8qxp (*) Platforms marked with (*) contain a DSP. In the future there might be more platforms. This patchseries does the following: * renames imx8 to imx8x (because the only supported platform now is imx8qxp). * adds support for imx8 (which is imx8qm) A future patchset will add supprot for i.MX8MP. Paul Olaru (4): ASoC: SOF: Rename i.MX8 platform to i.MX8X ASoC: SOF: imx8: Add ops for i.MX8QM ASoC: SOF: Add i.MX8QM device descriptor dt-bindings: dsp: fsl: Add fsl,imx8qm-dsp entry .../devicetree/bindings/dsp/fsl,dsp.yaml | 1 + sound/soc/sof/imx/imx8.c | 57 ++++++++++++++++++- sound/soc/sof/sof-of-dev.c | 10 ++++ 3 files changed, 65 insertions(+), 3 deletions(-) -- 2.17.1

2 5

[alsa-devel] [PATCH v2 00/11] ASoC: SOF: Data probing
by Cezary Rojewski 28 Jan '20

28 Jan '20

This set of patches achieves few goals in order to enable data probing feature for audio DSP. First, provide new and alter existing interfaces (page allocation, runtime flow adjustments) to make them compress friendly. For HDA part, work has been done to account for compress streams when servicing IRQs, setting up BDLs and assigning DMAs. Finally, the end goal which are the probe APIs and usage itself. Probes can be treated as endpoints which allow for data extraction from or injection to target module - a great ally when debugging problematic audio issues such as distortions, glitches or gaps. Compress streams are a weapon of choice here to provide a lightweight implementation. While all available IPCs have been defined, current implementation covers extraction only, with injection scheduled for a later date. Initial review and development of probes can be found under: https://github.com/thesofproject/linux/pull/1276 with the hda-compress-enable set of patches being separated and reviewed on: https://github.com/thesofproject/linux/pull/1571 Tested on CML-U with rt5682 i2s board. Changes in v2: - No changes to ALSA core and hda patches - Removed "ASoC: Intel: sof_rt5682: Add compress probe DAI links" from the patchset list as requested by Pierre - updated copyright header for newly added files (dates) - probes over HDA no longer require SND_SOC_SOF_HDA_LINK enabled - renamed debugfs probe functions as requested by Pierre - probe IPC API has been updated to align with newest SOF FW & probe debug app (struct_size macro has been enlisted to make the size calculations transparent). This targets only "ASoC: SOF: Implement Probe IPC API" patch Cezary Rojewski (11): ALSA: hda: Allow for compress stream to hdac_ext_stream assignment ALSA: hda: Prepare for compress stream support ALSA: hda: Interrupt servicing and BDL setup for compress streams ALSA: core: Expand DMA buffer information ALSA: core: Implement compress page allocation and free routines ASoC: SOF: Intel: Account for compress streams when servicing IRQs ASoC: SOF: Implement Probe IPC API ASoC: SOF: Generic probe compress operations ASoC: SOF: Intel: Probe compress operations ASoC: SOF: Provide probe debugfs support ASoC: SOF: Intel: Add Probe compress CPU DAIs include/sound/compress_driver.h | 40 +++- include/sound/hdaudio.h | 2 + include/sound/hdaudio_ext.h | 2 + include/sound/sof/header.h | 11 ++ sound/core/compress_offload.c | 42 +++++ sound/hda/ext/hdac_ext_stream.c | 49 ++++- sound/hda/hdac_controller.c | 4 +- sound/hda/hdac_stream.c | 52 ++++-- sound/soc/sof/Kconfig | 9 + sound/soc/sof/Makefile | 3 +- sound/soc/sof/compress.c | 139 ++++++++++++++ sound/soc/sof/compress.h | 29 +++ sound/soc/sof/debug.c | 208 +++++++++++++++++++++ sound/soc/sof/intel/Kconfig | 9 + sound/soc/sof/intel/Makefile | 1 + sound/soc/sof/intel/apl.c | 9 + sound/soc/sof/intel/cnl.c | 9 + sound/soc/sof/intel/hda-compress.c | 132 +++++++++++++ sound/soc/sof/intel/hda-dai.c | 28 +++ sound/soc/sof/intel/hda-ipc.c | 4 +- sound/soc/sof/intel/hda-stream.c | 26 ++- sound/soc/sof/intel/hda.h | 30 +++ sound/soc/sof/ops.h | 43 +++++ sound/soc/sof/pcm.c | 11 +- sound/soc/sof/probe.c | 285 +++++++++++++++++++++++++++++ sound/soc/sof/probe.h | 85 +++++++++ sound/soc/sof/sof-priv.h | 24 +++ 27 files changed, 1245 insertions(+), 41 deletions(-) create mode 100644 sound/soc/sof/compress.c create mode 100644 sound/soc/sof/compress.h create mode 100644 sound/soc/sof/intel/hda-compress.c create mode 100644 sound/soc/sof/probe.c create mode 100644 sound/soc/sof/probe.h -- 2.17.1

2 21

[alsa-devel] [PATCH] ALSA: hda: Reset stream if DMA RUN bit not cleared
by Mohan Kumar 28 Jan '20

28 Jan '20

Tegra HDA has FIFO size which can hold upto 10 audio frames to support DVFS. When HDA DMA RUN bit is set to 0 to stop the stream, the DMA RUN bit will be cleared to 0 only after transferring all the remaining audio frames queued up in the fifo. This is not in sync with spec which states the controller will stop transmitting(output) in the beginning of the next frame for the relevant stream. The above behavior with Tegra HDA was resulting in machine check error during the system suspend flow with active audio playback with below kernel error logs. [ 33.524583] mc-err: [mcerr] (hda) csr_hdar: EMEM address decode error [ 33.531088] mc-err: [mcerr] status = 0x20000015; addr = 0x00000000 [ 33.537431] mc-err: [mcerr] secure: no, access-type: read, SMMU fault: none This was due to the fifo has more than one audio frame when the DMA RUN bit is set to 0 during system suspend flow and the timeout handling in snd_hdac_stream_sync() was not designed to handle this scenario. So the DMA will continue running even after timeout hit until all remaining audio frames in the fifo are transferred, but the suspend flow will try to reset the controller and turn off the hda clocks without the knowledge of the DMA is still running and could result in mc-err. The above issue can be resolved by doing stream reset with the help of snd_hdac_stream_reset() which would ensure the DMA RUN bit is cleared if the timeout was hit in snd_hdac_stream_sync(). Signed-off-by: Mohan Kumar <mkumard(a)nvidia.com> --- sound/hda/hdac_stream.c | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/sound/hda/hdac_stream.c b/sound/hda/hdac_stream.c index 682ed39f79b0..890ff1b7a878 100644 --- a/sound/hda/hdac_stream.c +++ b/sound/hda/hdac_stream.c @@ -629,20 +629,27 @@ void snd_hdac_stream_sync(struct hdac_stream *azx_dev, bool start, nwait = 0; i = 0; list_for_each_entry(s, &bus->stream_list, list) { - if (streams & (1 << i)) { - if (start) { - /* check FIFO gets ready */ - if (!(snd_hdac_stream_readb(s, SD_STS) & - SD_STS_FIFO_READY)) - nwait++; - } else { - /* check RUN bit is cleared */ - if (snd_hdac_stream_readb(s, SD_CTL) & - SD_CTL_DMA_START) - nwait++; + if (!(streams & (1 << i++))) + continue; + + if (start) { + /* check FIFO gets ready */ + if (!(snd_hdac_stream_readb(s, SD_STS) & + SD_STS_FIFO_READY)) + nwait++; + } else { + /* check RUN bit is cleared */ + if (snd_hdac_stream_readb(s, SD_CTL) & + SD_CTL_DMA_START) { + nwait++; + /* + * Perform stream reset if DMA RUN + * bit not cleared within given timeout + */ + if (timeout == 1) + snd_hdac_stream_reset(s); } } - i++; } if (!nwait) break; -- 2.17.1

2 1

[alsa-devel] UCM file lookup logic
by Tanu Kaskinen 28 Jan '20

28 Jan '20

Hi all, I was looking at the UCM files, and most paths have the following structure: <cardname>/<cardname>.conf I noticed that the "HDA Intel PCH" configuration uses some other scheme: HDA Intel PCH/HDAudio-DualCodecs.conf HDA Intel PCH/HDAudio-Gigabyte-ALC1220DualCodecs.conf HDA Intel PCH/HDAudio-Lenovo-DualCodecs.conf How are the directory and file names determined? If I write configuration for some random sound card that I don't have myself, where do I find the various identifiers in the alsa-info output? I don't even really know for sure what the <cardname> in the first example is, I've been assuming it's the name that appears in the square brackets in /proc/asound/cards. I think the lookup logic should be explained in the ucm2/README.md file. I can write a patch if someone expains the logic to me, but probably it's easier if you just write the patch yourself. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk

2 2