April 2022 - Alsa-devel - mailman.alsa-project.org

[PATCH] ASoC: rt5514: Fix event generation for "DSP Voice Wake Up" control
by Mark Brown 03 May '22

03 May '22

The driver has a custom put function for "DSP Voice Wake Up" which does not generate event notifications on change, instead returning 0. Since we already exit early in the case that there is no change this can be fixed by unconditionally returning 1 at the end of the function. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/rt5514.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5514.c b/sound/soc/codecs/rt5514.c index 1b9263460142..be8ece4630df 100644 --- a/sound/soc/codecs/rt5514.c +++ b/sound/soc/codecs/rt5514.c @@ -419,7 +419,7 @@ static int rt5514_dsp_voice_wake_up_put(struct snd_kcontrol *kcontrol, } } - return 0; + return 1; } static const struct snd_kcontrol_new rt5514_snd_controls[] = { -- 2.30.2

1 1

[PATCH 00/11] ASoC: SOF: Miscellaneous preparatory patches for IPC4
by Ranjani Sridharan 03 May '22

03 May '22

This series includes last few remaining miscellaneous patches to prepare for the introduction of new IPC version, IPC4, in the SOF driver. The changes include new IPC ops for topology parsing to set up the volume table, prepare the widgets for set up and free the routes. The remaining patches introduce new fields in the existing data structures for use in IPC4 and align the flows for widget/route set up so that they are common for both IPC3 and IPC4. Ranjani Sridharan (11): ASoC: SOF: Add a new op to set up volume table ASoC: SOF: sof-audio: reset route status before freeing widget ASoC: SOF: sof-audio: Set up widgets from source to sink ASoC: SOF: pcm: Move the call to snd_sof_pcm_platform_hw_params() ASoC: SOF: expose a couple of functions ASoC: SOF: Add a route_free op in struct sof_ipc_tplg_ops ASoC: SOF: Add two new fields to struct snd_sof_widget ASoC: SOF: pcm: remove unnecessary function declaration ASoC: SOF: topology: Skip parsing DAI link tokens if not needed ASoC: SOF: clarify use of widget complete flag ASoC: SOF: Add a prepare op to IPC topology widget ops sound/soc/sof/ipc3-control.c | 38 +++-- sound/soc/sof/pcm.c | 23 +-- sound/soc/sof/sof-audio.c | 302 +++++++++++++++++++++++++++++------ sound/soc/sof/sof-audio.h | 68 +++++++- sound/soc/sof/topology.c | 44 +++-- 5 files changed, 368 insertions(+), 107 deletions(-) -- 2.25.1

2 12

[PATCH] ASoC: max98090: Fix event generation for custom controls
by Mark Brown 03 May '22

03 May '22

The previous fix for event generation for custom controls compared the value already in the register with the value being written, missing the logic that only applies the value to the register when the control is already enabled. Fix this, compare the value cached in the driver data rather than the register. This should really be an autodisable control rather than open coded. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/max98090.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index 5146837c0fce..48dcf071bb5a 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -396,6 +396,7 @@ static int max98090_put_enab_tlv(struct snd_kcontrol *kcontrol, unsigned int sel = ucontrol->value.integer.value[0]; unsigned int val = snd_soc_component_read(component, mc->reg); unsigned int *select; + int change; switch (mc->reg) { case M98090_REG_MIC1_INPUT_LEVEL: @@ -416,6 +417,7 @@ static int max98090_put_enab_tlv(struct snd_kcontrol *kcontrol, if (sel < 0 || sel > mc->max) return -EINVAL; + change = *select != sel; *select = sel; /* Setting a volume is only valid if it is already On */ @@ -430,7 +432,7 @@ static int max98090_put_enab_tlv(struct snd_kcontrol *kcontrol, mask << mc->shift, sel << mc->shift); - return *select != val; + return change; } static const char *max98090_perf_pwr_text[] = -- 2.30.2

1 1

[PATCH AUTOSEL 5.17 01/22] ASoC: soc-pcm: use GFP_KERNEL when the code is sleepable
by Sasha Levin 02 May '22

02 May '22

From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit fb6d679fee95d272c0a94912c4e534146823ee89 ] At the kzalloc() call in dpcm_be_connect(), there is no spin lock involved. It's merely protected by card->pcm_mutex, instead. The spinlock is applied at the later call with snd_soc_pcm_stream_lock_irq() only for the list manipulations. (See it's *_irq(), not *_irqsave(); that means the context being sleepable at that point.) So, we can use GFP_KERNEL safely there. This patch revert commit d8a9c6e1f676 ("ASoC: soc-pcm: use GFP_ATOMIC for dpcm structure") which is no longer needed since commit b7898396f4bb ("ASoC: soc-pcm: Fix and cleanup DPCM locking"). Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Link: https://lore.kernel.org/r/e740f1930843060e025e3c0f17ec1393cfdafb26.16487579… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/soc-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 9a954680d492..11c9853e9e80 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1214,7 +1214,7 @@ static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe, be_substream->pcm->nonatomic = 1; } - dpcm = kzalloc(sizeof(struct snd_soc_dpcm), GFP_ATOMIC); + dpcm = kzalloc(sizeof(struct snd_soc_dpcm), GFP_KERNEL); if (!dpcm) return -ENOMEM; -- 2.35.1

4 10

[PATCH v2 0/2] Let userspace know when snd-hda-intel needs i915
by Mauro Carvalho Chehab 01 May '22

01 May '22

Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_ho… https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_m… In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099… So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. --- v2: the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (2): module: update dependencies at try_module_get() ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 4 +++- kernel/module/main.c | 35 +++++++++++++++++++++++++++++++++-- sound/hda/hdac_component.c | 2 +- 3 files changed, 37 insertions(+), 4 deletions(-) -- 2.35.1

3 5

[PATCH v3 0/2] Let userspace know when snd-hda-intel needs i915
by Mauro Carvalho Chehab 30 Apr '22

30 Apr '22

Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_ho… https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_m… In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099… So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. --- v3: minor fixes: - fixed a checkpatch warning; - use a single line for the new function prototype. v2: - the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (2): module: update dependencies at try_module_get() ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 4 +++- kernel/module/main.c | 33 +++++++++++++++++++++++++++++++-- sound/hda/hdac_component.c | 2 +- 3 files changed, 35 insertions(+), 4 deletions(-) -- 2.35.1

3 5

[PATCH v4 0/2] Let userspace know when snd-hda-intel needs i915
by Mauro Carvalho Chehab 30 Apr '22

30 Apr '22

Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_ho… https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_m… In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099… So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. --- v4: - fix a compilation warning reported by Intel's Kernel robot when !CONFIG_MODULE_UNLOAD or !CONFIG_MODULE. v3: minor fixes: - fixed a checkpatch warning; - use a single line for the new function prototype. v2: - the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (2): module: update dependencies at try_module_get() ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 8 +++++--- kernel/module/main.c | 33 +++++++++++++++++++++++++++++++-- sound/hda/hdac_component.c | 2 +- 3 files changed, 37 insertions(+), 6 deletions(-) -- 2.35.1

1 2

how can i swich between sound card without reboot in archlinux
by GitHub issues - edited 30 Apr '22

30 Apr '22

alsa-project/alsa-utils issue #144 was edited from EN-KS: I use riverwm and kitty. Currently there is no sound output when i try to plugin a usb 2.4G wireless headset in and then use alsamixer F6 to select the usb sound card unless I leave the usb adapter on the machine and reboot. the usb sound card was detected tho, Is this what it suppose to be? or any procedure that I missed? Issue URL : https://github.com/alsa-project/alsa-utils/issues/144 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

how can i swich between sound card without reboot in archlinux
by GitHub issues - opened 30 Apr '22

30 Apr '22

alsa-project/alsa-utils issue #144 was opened from EN-KS: currently there is no sound output when i try to plugin a usb 2.4G wireless headset in and then F6 to select the usb sound card unless I leave the usb adapter on the machine and reboot. the usb sound card was detected tho, Is this what it suppose to be? or any procedure that I missed? Issue URL : https://github.com/alsa-project/alsa-utils/issues/144 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] conf: vc4-hdmi: use a proper hdmi pcm, fix broken default pcm
by Matthias Reichl 30 Apr '22

30 Apr '22

Userspace expects to see a HDMI pcm, so remove the somewhat broken front and iec958 pcms and add a proper hdmi pcm instead. The hdmi pcm supports HD/HBR audio passthrough and relays the IEC958 status bits on to the kernel driver so it can switch to HBR audio packets if needed. The control hook is marked optional because kernels before 5.14 didn't expose the IEC958 controls. The default pcm never worked as dmix doesn't support the iec958 format. So drop dmix, only use plug and softvol, and use the hdmi pcm for iec958 formatting. Signed-off-by: Matthias Reichl <hias(a)horus.com> --- src/conf/cards/vc4-hdmi.conf | 78 ++++++++++++++++++++++-------------- 1 file changed, 48 insertions(+), 30 deletions(-) diff --git a/src/conf/cards/vc4-hdmi.conf b/src/conf/cards/vc4-hdmi.conf index 027804a1..af87b3a8 100644 --- a/src/conf/cards/vc4-hdmi.conf +++ b/src/conf/cards/vc4-hdmi.conf @@ -3,36 +3,9 @@ # subframe conversion # -<confdir:pcm/front.conf> +<confdir:pcm/hdmi.conf> -vc4-hdmi.pcm.front.0 { - @args [ CARD ] - @args.CARD { - type string - } - type hw - card $CARD -} - -# default with dmix -vc4-hdmi.pcm.default { - @args [ CARD ] - @args.CARD { - type string - } - type asym - playback.pcm { - type plug - slave.pcm { - @func concat - strings [ "dmix:" $CARD ] - } - } -} - -<confdir:pcm/iec958.conf> - -vc4-hdmi.pcm.iec958.0 { +vc4-hdmi.pcm.hdmi.0 { @args [ CARD AES0 AES1 AES2 AES3 ] @args.CARD { type string @@ -53,12 +26,57 @@ vc4-hdmi.pcm.iec958.0 { slave { format IEC958_SUBFRAME_LE pcm { - type plug + type hooks slave.pcm { type hw card $CARD + device 0 + } + hooks.0 { + type ctl_elems + hook_args [ + { + name "IEC958 Playback Default" + interface PCM + optional true + lock true + preserve true + value [ $AES0 $AES1 $AES2 $AES3 ] + } + ] } } } status [ $AES0 $AES1 $AES2 $AES3 ] + hdmi_mode true +} + +# default with plug and softvol +vc4-hdmi.pcm.default { + @args [ CARD ] + @args.CARD { + type string + } + type asym + playback.pcm { + type plug + slave.pcm { + type softvol + slave.pcm { + @func concat + strings [ + "cards.vc4-hdmi.pcm.hdmi.0:" + "CARD=" $CARD "," + "AES0=0x04," # IEC958_AES0_CON_NOT_COPYRIGHT | IEC958_AES0_CON_EMPHASIS_NONE + "AES1=0x82," # IEC958_AES1_CON_ORIGINAL | IEC958_AES1_CON_PCM_CODER + "AES2=0x00," # IEC958_AES2_CON_SOURCE_UNSPEC | IEC958_AES2_CON_CHANNEL_UNSPEC + "AES3=0x01" # IEC958_AES3_CON_FS_NOTID (iec958 plugin will fill in actual rate) + ] + } + control { + name "PCM Playback Volume" + card $CARD + } + } + } } -- 2.30.2

1 0