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

[PATCH] ALSA: pcm: One more dependency for hw constraints
by Takashi Iwai 23 Jan '21

23 Jan '21

The fix for a long-standing USB-audio bug required one more dependency variable to be added to the hw constraints. Unfortunately I didn't realize at debugging that the new addition may result in the overflow of the dependency array of each snd_pcm_hw_rule (up to three plus a sentinel), because USB-audio driver adds one more dependency only for a certain device and bus, hence it works as is for many devices. But in a bad case, a simple open always results in -EINVAL (with kernel WARNING if CONFIG_SND_DEBUG is set) no matter what is passed. Since the dependencies are real and unavoidable (USB-audio restricts the hw_params per looping over the format/rate/channels combos), the only good solution seems to raise the bar for one more dependency for snd_pcm_hw_rule -- so does this patch: now the hw constraint dependencies can be up to four. Fixes: 506c203cc3de ("ALSA: usb-audio: Fix hw constraints dependencies") Reported-by: Jamie Heilman <jamie(a)audible.transient.net> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/sound/pcm.h | 2 +- sound/core/pcm_native.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index 2336bf9243e1..2e1200d17d0c 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -229,7 +229,7 @@ typedef int (*snd_pcm_hw_rule_func_t)(struct snd_pcm_hw_params *params, struct snd_pcm_hw_rule { unsigned int cond; int var; - int deps[4]; + int deps[5]; snd_pcm_hw_rule_func_t func; void *private; diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 9f3f8e953ff0..c4aac703dc22 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -382,8 +382,8 @@ static int constrain_params_by_rules(struct snd_pcm_substream *substream, continue; /* - * The 'deps' array includes maximum three dependencies - * to SNDRV_PCM_HW_PARAM_XXXs for this rule. The fourth + * The 'deps' array includes maximum four dependencies + * to SNDRV_PCM_HW_PARAM_XXXs for this rule. The fifth * member of this array is a sentinel and should be * negative value. * -- 2.26.2

1 0

Question about hdac_ext_link ref_count management
by Ranjani Sridharan 23 Jan '21

23 Jan '21

Hi Takashi, While exploring some power optimizations on Intel platforms, I noticed that the hdac_ext_link ref_count is incremented during codec probe in hdac_hda_codec_probe() and the ref_count is held until the codec device is removed. I was wondering if it would be possible to call the get/put for the hdac_ext_link in the codec runtime suspend/resume callbacks so that the link is powered up only when the link is in use. Are there any downsides to doing this? Thanks, Ranjani

2 5

[PATCH v3 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support
by Hans de Goede 22 Jan '21

22 Jan '21

Hi all, Here is v3 om my series to rework the arizona codec jack-detect support to use the snd_soc_jack helpers instead of direct extcon reporting. This is done by reworking the extcon driver into an arizona-jackdet library and then modifying the codec drivers to use that directly, replacing the old separate extcon child-devices and extcon-driver. This brings the arizona-codec jack-detect handling inline with how all other ASoC codec driver do this. This was developed and tested on a Lenovo Yoga Tablet 1051L with a WM5102 codec. There are various interdependencies between the patches in this series, so IMHO it would be best if this entire series would be merged through the MFD tree. Note this series applies on top of my "[PATCH v4 0/5] MFD/ASoC: Add support for Intel Bay Trail boards with WM5102 codec" series. Changes in v3: -Move the bugfix patches to earlier in the series so that they apply to drivers/extcon/extcon-arizona.c so that they can be cherry-picked into the stable series -Split runtime_pm_get -> runtime_pm_get_sync changes out into their own patch -Simply move drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c instead of first adding arizona-jack.c as a copy and then later removing extcon-arizona.c -Some other small tweaks, see individual patch changelogs Regards, Hans Hans de Goede (13): mfd: arizona: Drop arizona-extcon cells extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged extcon: arizona: Fix various races on driver unbind extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c ASoC: arizona-jack: Move jack-detect variables to struct arizona_priv ASoC: arizona-jack: Use arizona->dev for runtime-pm ASoC: arizona-jack: convert into a helper library for codec drivers ASoC: arizona-jack: Use snd_soc_jack to report jack events ASoC: arizona-jack: Cleanup logging ASoC: arizona: Make the wm5102, wm5110, wm8997 and wm8998 drivers use the new jack library ASoC: Intel: bytcr_wm5102: Add jack detect support MAINTAINERS | 1 - drivers/extcon/Kconfig | 8 - drivers/extcon/Makefile | 1 - drivers/mfd/arizona-core.c | 20 - sound/soc/codecs/Makefile | 2 +- .../soc/codecs/arizona-jack.c | 539 +++++++----------- sound/soc/codecs/arizona.h | 44 ++ sound/soc/codecs/wm5102.c | 12 +- sound/soc/codecs/wm5110.c | 12 +- sound/soc/codecs/wm8997.c | 14 +- sound/soc/codecs/wm8998.c | 9 + sound/soc/intel/boards/bytcr_wm5102.c | 28 +- 12 files changed, 307 insertions(+), 383 deletions(-) rename drivers/extcon/extcon-arizona.c => sound/soc/codecs/arizona-jack.c (77%) -- 2.28.0

2 23

[PATCH alsa-lib 0/4] pcm: Fix missing appl_ptr and hw_ptr updates in snd_pcm_status()
by Takashi Iwai 22 Jan '21

22 Jan '21

Hi, here is the fixes for a crash with dmix plugin and co, as well as the missing appl_ptr/hw_ptr updates that are found on other plugins. Takashi === Takashi Iwai (4): pcm: direct: Fix the missing appl_ptr update pcm: ioplug: Pass appl_ptr and hw_ptr in snd_pcm_status() pcm: null: Pass appl_ptr and hw_ptr in snd_pcm_status() pcm: share: Pass appl_ptr and hw_ptr in snd_pcm_status() src/pcm/pcm_dmix.c | 1 + src/pcm/pcm_dshare.c | 1 + src/pcm/pcm_dsnoop.c | 1 + src/pcm/pcm_ioplug.c | 2 ++ src/pcm/pcm_null.c | 2 ++ src/pcm/pcm_share.c | 2 ++ 6 files changed, 9 insertions(+) -- 2.26.2

2 5

[PATCH] drivers: slimbus: Fix word resposible -> responsible in slimbus.h
by Bhaskar Chowdhury 22 Jan '21

22 Jan '21

s/resposible/responsible/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar(a)gmail.com> --- drivers/slimbus/slimbus.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/slimbus/slimbus.h b/drivers/slimbus/slimbus.h index 00a7f112574b..503e2a0200f5 100644 --- a/drivers/slimbus/slimbus.h +++ b/drivers/slimbus/slimbus.h @@ -368,7 +368,7 @@ struct slim_stream_runtime { * @get_laddr: It is possible that controller needs to set fixed logical * address table and get_laddr can be used in that case so that controller * can do this assignment. Use case is when the master is on the remote - * processor side, who is resposible for allocating laddr. + * processor side, who is responsible for allocating laddr. * @wakeup: This function pointer implements controller-specific procedure * to wake it up from clock-pause. Framework will call this to bring * the controller out of clock pause. -- 2.30.0

3 2

Wrong binds configuration for dmix plugin causes segmentation fault in alsa
by GitHub issues - opened 22 Jan '21

22 Jan '21

alsa-project/alsa-lib issue #117 was opened from elara-leitstellentechnik: On Debian buster I can get alsa to run into a segmentation fault with the following procedure: Configure dmix with two channels (binds) for a Mono device. (I am not sure that this is reproducible with any mono device, I tested with a Jabra LINK 230): ``` ~$ cat .asoundrc pcm."Jabra LINK 230" { type dmix ipc_key 1024 slave.pcm "hw:2,0" bindings { 0 0 # The next line is the problematic line that triggers the segfault 1 1 } } ``` Then when playing any sound file with e.g. mplayer and making it use the dmix device the following happens: ``` $ mplayer -ao alsa:device="Jabra LINK 230" /usr/share/sounds/alsa/Front_Left.wav MPlayer 1.3.0 (Debian), built with gcc-8 (C) 2000-2016 MPlayer Team do_connect: could not connect to socket connect: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /usr/share/sounds/alsa/Front_Left.wav. libavformat version 58.20.100 (external) Mismatching header version 58.12.100 Audio only file format detected. Load subtitles in /usr/share/sounds/alsa/ ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 1 ch, s16le, 768.0 kbit/100.00% (ratio: 96000->96000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== [AO_ALSA] alsa-lib: pcm_hw.c:1711:(snd_pcm_hw_open) open '/dev/snd/pcmC2D0p' failed (-77): File descriptor in bad state AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback... MPlayer interrupted by signal 11 in module: play_audio - MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash. [ This binary of MPlayer in Debian is currently compiled with '--enable-debug'; the debugging symbols are in the package 'mplayer-dbgsym'.] ``` I appreciate that configuring two bindings for a single-channel audio device is an error, but I am not sure that this justifies a segfault. Here is some more information I have been able to extract using gdb: ``` ~$ gdb --args mplayer -ao alsa:device="Jabra LINK 230" /usr/share/sounds/alsa/Front_Left.wav GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from mplayer...Reading symbols from /usr/lib/debug/.build-id/3a/9816e9d363979a4f76e6cb809a33dffda67d05.debug...done. done. (gdb) run Starting program: /usr/bin/mplayer -ao alsa:device=Jabra\ LINK\ 230 /usr/share/sounds/alsa/Front_Left.wav [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". MPlayer 1.3.0 (Debian), built with gcc-8 (C) 2000-2016 MPlayer Team do_connect: could not connect to socket connect: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /usr/share/sounds/alsa/Front_Left.wav. libavformat version 58.20.100 (external) Mismatching header version 58.12.100 Audio only file format detected. Load subtitles in /usr/share/sounds/alsa/ ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 1 ch, s16le, 768.0 kbit/100.00% (ratio: 96000->96000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== [AO_ALSA] alsa-lib: pcm_hw.c:1711:(snd_pcm_hw_open) open '/dev/snd/pcmC2D0p' failed (-77): File descriptor in bad state AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7a09b76 in mix_areas_16_smp (size=4160473088, size@entry=17424, dst=0x555555aa9510, src=0xde020109, sum=0x21fe0f3c, dst_step=2, src_step=4, sum_step=8) at pcm_dmix_x86_64.h:48 48 pcm_dmix_x86_64.h: No such file or directory. (gdb) where #0 0x00007ffff7a09b76 in mix_areas_16_smp (size=4160473088, size@entry=17424, dst=0x555555aa9510, src=0xde020109, sum=0x21fe0f3c, dst_step=2, src_step=4, sum_step=8) at pcm_dmix_x86_64.h:48 #1 0x00007ffff7a0ba1c in mix_areas (size=17424, dst_ofs=576, src_ofs=0, dst_areas=0x555555a927f0, src_areas=0x7fffe88b3000, dmix=0x555555a929e0) at pcm_dmix.c:215 #2 snd_pcm_dmix_sync_area (pcm=pcm@entry=0x555555a94850) at pcm_dmix.c:382 #3 0x00007ffff7a0bdfa in snd_pcm_dmix_start (pcm=0x555555a94850) at pcm_dmix.c:619 #4 0x00007ffff79d8b4a in __snd_pcm_start (pcm=0x555555a94850, pcm=0x555555a94850) at pcm_local.h:434 #5 snd1_pcm_write_areas (pcm=pcm@entry=0x555555a94850, areas=areas@entry=0x7fffffffcfd0, offset=offset@entry=0, size=<optimized out>, size@entry=18000, func=func@entry=0x7ffff79e46c0 <snd_pcm_mmap_write_areas>) at pcm.c:7421 #6 0x00007ffff79e4b01 in snd_pcm_mmap_writei (pcm=0x555555a94850, buffer=<optimized out>, size=18000) at pcm_mmap.c:153 #7 0x00005555556242f8 in play (data=0x555555ac4f70, len=<optimized out>, flags=<optimized out>) at libao2/ao_alsa.c:812 #8 0x000055555560bbab in fill_audio_out_buffers () at mplayer.c:2212 #9 main (argc=<optimized out>, argv=<optimized out>) at mplayer.c:3794 (gdb) ``` To me this looks like the segfault is triggered in pcm_dmix_x86_64.h:48 so I believe it is an alsa problem rather than a problem with mplayer. I hope this makes sense. If I can support with further information please let me know. Issue URL : https://github.com/alsa-project/alsa-lib/issues/117 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH 0/4] ASoC: mediatek: mt8192-mt6359: fix I2S corrupted for RT5682
by Tzung-Bi Shih 22 Jan '21

22 Jan '21

The series fixes the I2S corrupted when mt8192-mt6359 is playing and capturing via RT5682 in different formats. The 1st and 2nd patch refactor to use asoc_substream_to_rtd(). Just realized there is such a helper for the purpose. The 3rd patch simplies ops of Capture1 DAI link. The 4th patch adds format constriants to the I2S to make sure the settings are symmetric. Tzung-Bi Shih (4): ASoC: mediatek: mt8192-mt6359: use asoc_substream_to_rtd() ASoC: mediatek: mt8192: use asoc_substream_to_rtd() ASoC: mediatek: mt8192-mt6359: simply ops for Capture1 DAI link ASoC: mediatek: mt8192-mt6359: add format constraints for RT5682 sound/soc/mediatek/mt8192/mt8192-afe-pcm.c | 4 +- .../mt8192/mt8192-mt6359-rt1015-rt5682.c | 73 +++++++++++++++---- 2 files changed, 61 insertions(+), 16 deletions(-) -- 2.30.0.280.ga3ce27912f-goog

2 5

[PATCH v2 00/12] MFD/extcon/ASoC: Rework arizona codec jack-detect support
by Hans de Goede 22 Jan '21

22 Jan '21

Hi All, This series reworks the arizona codec jack-detect support to use the snd_soc_jack helpers instead of direct extcon reporting. This is done by reworking the extcon driver into an arizona-jackdet library and then modifying the codec drivers to use that directly, replacing the old separate extcon child-devices and extcon-driver. This brings the arizona-codec jack-detect handling inline with how all other ASoC codec driver do this. This was developed and tested on a Lenovo Yoga Tablet 1051L with a WM5102 codec. The MFD, ASoC and extcon parts can be merged independent from each-other although that could lead to a case where both the extcon driver and the new arizona-jackdet library will try to do jack-detection. If we end up with a git tree in that state then one of the 2 will fail to load because the other will already have claimed the IRQs, so this is not a problem really. Or the entire series could be merged through the MFD tree if people prefer that. Note that this series also paves the way for some further cleanups, removing some jackdetect related variables like hp_ena and hp_clamp from the arizona data struct shared between all the MFD child devices. I've deliberately not done that cleanup as part of this patch-series, since IMHO the series is big enough as is. These cleanups can be done in a follow-up series once this series has landed. Regards, Hans

6 34

[RFC][PATCH v5 0/2] audio jack software injection
by Hui Wang 22 Jan '21

22 Jan '21

the changes in the v5: - add a Kconfig to enable/disable the jack injection feature - replace all kzalloc with local char[] in the debugfs fops - replace the chars of !isalnum() to '_' for the jack folder's name - squash all .c files patches into one patch - add a document to explain jack injection, for easier review, put the document in a standalone patch. If needed, will squash this patch to the previous one. the changes in the v4: - change the sound-core to sound and change the sound_core_debugfs_root to sound_debugfs_root in the 0001-xxx.patch - change kzalloc/kfree to kvzalloc/kvfree in the debugfs fops for 0001-xxx.patch and 0003-xxx.patch - And if needed, I could squash 4 patches into 1 patch before merging. the changes in the v3 (for easy to review, divide change into 4 patches): - address the comment about the snd_jack_report() and _snd_jack_report(), the v2 design is hard to understand and is hard to review, in the v3, separate the jack_report to snd_jack_report() and snd_jack_inject_report(), hw jack events call snd_jack_report() as before, if a jack contains multi jack_kctl and the jack_kctl's sw_inject is enabled, the status and the related input-dev's events will not be reproted. The injection events call snd_jack_inject_report(). This change is squashed to 0001-xxx.patch, the rest part of 0001-xxx.patch is same as v2. - address the comment about folders'name in the 0002-xxx.patch, so far, drop the '/', ',', '=' and ' ' from the folders' name. - address the comment about adding more debugfs nodes in the 0003-xxx.patch, it adds kctl_id, mask_bits, status and type. - address the comment about save-n-restore jack's hw status in the 0004-xxx.patch, adding a hw_status_cache and save the last reported jack hw event, once the sw_inject is disabled, will restore all jack_kctl's state under the same snd_jack with hw_status_cache. [snip] the changes in the V2: - using debugfs instead of sysfs - using jack_ctrl to create a folder instead of snd_jack, since ASoC drivers could create multi jack_ctrls within a snd_jack - create a folder for each jack_ctrl instead for all jack_ctrls [ snip ] Hui Wang (2): alsa: jack: implement software jack injection via debugfs alsa: jack: add document for sound jack injection. Documentation/sound/designs/index.rst | 1 + .../sound/designs/jack-injection.rst | 124 ++++++++ include/sound/core.h | 2 + include/sound/jack.h | 1 + sound/core/Kconfig | 9 + sound/core/init.c | 10 + sound/core/jack.c | 298 +++++++++++++++++- sound/core/sound.c | 8 + 8 files changed, 449 insertions(+), 4 deletions(-) create mode 100644 Documentation/sound/designs/jack-injection.rst -- 2.25.1

2 4

[PATCH] ASoC: qcom: Fix number of HDMI RDMA channels on sc7180
by Stephen Boyd 22 Jan '21

22 Jan '21

Suspending/resuming with an HDMI dongle attached leads to crashes from an audio regmap. Unable to handle kernel paging request at virtual address ffffffc018068000 Mem abort info: ESR = 0x96000047 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000047 CM = 0, WnR = 1 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081b12000 [ffffffc018068000] pgd=0000000275d14003, pud=0000000275d14003, pmd=000000026365d003, pte=0000000000000000 Internal error: Oops: 96000047 [#1] PREEMPT SMP Call trace: regmap_mmio_write32le+0x2c/0x40 regmap_mmio_write+0x48/0x6c _regmap_bus_reg_write+0x34/0x44 _regmap_write+0x100/0x150 regcache_default_sync+0xc0/0x138 regcache_sync+0x188/0x26c lpass_platform_pcmops_resume+0x48/0x54 [snd_soc_lpass_platform] snd_soc_component_resume+0x28/0x40 soc_resume_deferred+0x6c/0x178 process_one_work+0x208/0x3c8 worker_thread+0x23c/0x3e8 kthread+0x144/0x178 ret_from_fork+0x10/0x18 Code: d503201f d50332bf f94002a8 8b344108 (b9000113) I can reliably reproduce this problem by running 'tail' on the registers file in debugfs for the hdmi regmap. # tail /sys/kernel/debug/regmap/62d87000.lpass-lpass_hdmi/registers [ 84.658733] Unable to handle kernel paging request at virtual address ffffffd0128e800c This crash happens because we're trying to read registers from the regmap beyond the length of the mapping created by ioremap(). The number of hdmi_rdma_channels determines the size of the regmap via this code in sound/soc/qcom/lpass-cpu.c: lpass_hdmi_regmap_config.max_register = LPAIF_HDMI_RDMAPER_REG(variant, variant->hdmi_rdma_channels); According to debugfs the size of the regmap is 0x68010 but according to the DTS file posted in [1] the size is only 0x68000 (see the first reg property of the lpass_cpu node). Let's change the number of channels to be 3 instead of 4 so the math works out to have a max register of 0x67010, nicely fitting inside of the region size of 0x68000. Note: I tried to bump up the size of the register region to the next page to include the 0x68010 register but then the tail command caused SErrors with an async abort, implying that the register region doesn't exist or it isn't clocked because the bus is telling us that the register read failed. I reduce the number of channels and played audio through the HDMI channel and it kept working so I think this is correct. Fixes: 2ad63dc8df6b ("ASoC: qcom: sc7180: Add support for audio over DP") Link: https://lore.kernel.org/r/1601448168-18396-2-git-send-email-srivasam@codeau… [1] Cc: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Cc: Srinivasa Rao <srivasam(a)codeaurora.org> Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Cc: Cheng-Yi Chiang <cychiang(a)chromium.org> Signed-off-by: Stephen Boyd <swboyd(a)chromium.org> --- sound/soc/qcom/lpass-sc7180.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c index 85db650c2169..3127b6022ea3 100644 --- a/sound/soc/qcom/lpass-sc7180.c +++ b/sound/soc/qcom/lpass-sc7180.c @@ -174,7 +174,7 @@ static struct lpass_variant sc7180_data = { .rdma_channels = 5, .hdmi_rdma_reg_base = 0x64000, .hdmi_rdma_reg_stride = 0x1000, - .hdmi_rdma_channels = 4, + .hdmi_rdma_channels = 3, .dmactl_audif_start = 1, .wrdma_reg_base = 0x18000, .wrdma_reg_stride = 0x1000, base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e -- https://chromeos.dev

3 3