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

[PATCH 1/3] HID: elan: Silence mute LED errors being logged when the device is unplugged
by Hans de Goede 20 Feb '21

20 Feb '21

Being integrated into an USB keyboard-dock the mute LED can go away at any time, leading to the following errors: [ 918.667671] elan 0003:04F3:0755.0002: Failed to set mute led brightness: -19 [ 918.667737] leds elan:red:mute: Setting an LED's brightness failed (-19) Fix this by making the following changes: 1. Don't log an error from elan_mute_led_set_brigtness() when ret == ENODEV 2. Set the LED_HW_PLUGGABLE flag on the mute LED led_classdev Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/hid/hid-elan.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-elan.c b/drivers/hid/hid-elan.c index dae193749d44..71740988a3f6 100644 --- a/drivers/hid/hid-elan.c +++ b/drivers/hid/hid-elan.c @@ -445,7 +445,8 @@ static int elan_mute_led_set_brigtness(struct led_classdev *led_cdev, kfree(dmabuf); if (ret != ELAN_LED_REPORT_SIZE) { - hid_err(hdev, "Failed to set mute led brightness: %d\n", ret); + if (ret != -ENODEV) + hid_err(hdev, "Failed to set mute led brightness: %d\n", ret); return ret; } @@ -462,6 +463,7 @@ static int elan_init_mute_led(struct hid_device *hdev) mute_led->brightness_get = elan_mute_led_get_brigtness; mute_led->brightness_set_blocking = elan_mute_led_set_brigtness; mute_led->max_brightness = LED_ON; + mute_led->flags = LED_HW_PLUGGABLE; mute_led->dev = &hdev->dev; return devm_led_classdev_register(&hdev->dev, mute_led); -- 2.30.1

1 2

[PATCH] leds: trigger: audio: Add an activate callback to ensure the initial brightness is set
by Hans de Goede 20 Feb '21

20 Feb '21

Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in the speaker- and/or mic-mute keys on the keyboard. Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock) and the HP x2 10 series. The detachable nature of these keyboards means that the keyboard and thus the mute LEDs may show up after the user (or userspace restoring old mixer settings) has muted the speaker and/or mic. Current LED-class devices with a default_trigger of "audio-mute" or "audio-micmute" initialize the brightness member of led_classdev with ledtrig_audio_get() before registering the LED. This makes the software state after attaching the keyboard match the actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will show the right value. But before this commit nothing was actually calling the led_classdev's brightness_set[_blocking] callback so the value returned by ledtrig_audio_get() was never actually being send to the hw, leading to the mute LEDs staying in their default power-on state, after attaching the keyboard, even if ledtrig_audio_get() returns a different state. This could be fixed by having the individual LED drivers call brightness_set[_blocking] themselves after registering the LED, but this really is something which should be done by a led-trigger activate callback. Add an activate callback for this, fixing the issue of the mute LEDs being out of sync after (re)attaching the keyboard. Cc: Takashi Iwai <tiwai(a)suse.de> Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger") Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/leds/trigger/ledtrig-audio.c | 37 ++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/leds/trigger/ledtrig-audio.c b/drivers/leds/trigger/ledtrig-audio.c index f76621e88482..c6b437e6369b 100644 --- a/drivers/leds/trigger/ledtrig-audio.c +++ b/drivers/leds/trigger/ledtrig-audio.c @@ -6,10 +6,33 @@ #include <linux/kernel.h> #include <linux/leds.h> #include <linux/module.h> +#include "../leds.h" -static struct led_trigger *ledtrig_audio[NUM_AUDIO_LEDS]; static enum led_brightness audio_state[NUM_AUDIO_LEDS]; +static int ledtrig_audio_mute_activate(struct led_classdev *led_cdev) +{ + led_set_brightness_nosleep(led_cdev, audio_state[LED_AUDIO_MUTE]); + return 0; +} + +static int ledtrig_audio_micmute_activate(struct led_classdev *led_cdev) +{ + led_set_brightness_nosleep(led_cdev, audio_state[LED_AUDIO_MICMUTE]); + return 0; +} + +static struct led_trigger ledtrig_audio[NUM_AUDIO_LEDS] = { + [LED_AUDIO_MUTE] = { + .name = "audio-mute", + .activate = ledtrig_audio_mute_activate, + }, + [LED_AUDIO_MICMUTE] = { + .name = "audio-micmute", + .activate = ledtrig_audio_micmute_activate, + }, +}; + enum led_brightness ledtrig_audio_get(enum led_audio type) { return audio_state[type]; @@ -19,24 +42,22 @@ EXPORT_SYMBOL_GPL(ledtrig_audio_get); void ledtrig_audio_set(enum led_audio type, enum led_brightness state) { audio_state[type] = state; - led_trigger_event(ledtrig_audio[type], state); + led_trigger_event(&ledtrig_audio[type], state); } EXPORT_SYMBOL_GPL(ledtrig_audio_set); static int __init ledtrig_audio_init(void) { - led_trigger_register_simple("audio-mute", - &ledtrig_audio[LED_AUDIO_MUTE]); - led_trigger_register_simple("audio-micmute", - &ledtrig_audio[LED_AUDIO_MICMUTE]); + led_trigger_register(&ledtrig_audio[LED_AUDIO_MUTE]); + led_trigger_register(&ledtrig_audio[LED_AUDIO_MICMUTE]); return 0; } module_init(ledtrig_audio_init); static void __exit ledtrig_audio_exit(void) { - led_trigger_unregister_simple(ledtrig_audio[LED_AUDIO_MUTE]); - led_trigger_unregister_simple(ledtrig_audio[LED_AUDIO_MICMUTE]); + led_trigger_unregister(&ledtrig_audio[LED_AUDIO_MUTE]); + led_trigger_unregister(&ledtrig_audio[LED_AUDIO_MICMUTE]); } module_exit(ledtrig_audio_exit); -- 2.30.1

1 0

What is the semantics of snd_pcm_hw_params_any?
by GitHub issues - opened 20 Feb '21

20 Feb '21

alsa-project/alsa-lib issue #119 was opened from jpalus: It is not really a bug report but rather a request for clarification in attempt to figure out who is to blame for incorrect pulseaudio behavior. I've got two different cards -- one internal and one USB -- which behave quite differently for this simple high level code: ``` snd_pcm_open() snd_pcm_hw_params_any() iterate snd_pcm_hw_params_test_rate() to check for supported rates snd_pcm_hw_params_set_rate_near(44100) snd_pcm_hw_params() snd_pcm_hw_params_any() iterate snd_pcm_hw_params_test_rate() to check for supported rates ``` In essence supported sample rates are queried twice, always with snd_pcm_hw_params_any() before them, but separated by snd_pcm_hw_params_set_rate_near(). Now with internal card both iterations report 7 supported rates while for USB first iteration reports 4 rates and second only one (44100). Is that expected or is snd_pcm_hw_params_any() supposed to provide configuration which would result in all rates reported again? Issue URL : https://github.com/alsa-project/alsa-lib/issues/119 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ASoC: Intel: Skylake: Fix missing check in skl_pcm_trigger
by Dinghao Liu 19 Feb '21

19 Feb '21

When cmd == SNDRV_PCM_TRIGGER_STOP, we should also check the return value of skl_decoupled_trigger() just like what we have done in case SNDRV_PCM_TRIGGER_PAUSE_RELEASE. Signed-off-by: Dinghao Liu <dinghao.liu(a)zju.edu.cn> --- sound/soc/intel/skylake/skl-pcm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/intel/skylake/skl-pcm.c b/sound/soc/intel/skylake/skl-pcm.c index b1ca64d2f7ea..a5b1f333a500 100644 --- a/sound/soc/intel/skylake/skl-pcm.c +++ b/sound/soc/intel/skylake/skl-pcm.c @@ -516,6 +516,9 @@ static int skl_pcm_trigger(struct snd_pcm_substream *substream, int cmd, return ret; ret = skl_decoupled_trigger(substream, cmd); + if (ret < 0) + return ret; + if ((cmd == SNDRV_PCM_TRIGGER_SUSPEND) && !w->ignore_suspend) { /* save the dpib and lpib positions */ stream->dpib = readl(bus->remap_addr + -- 2.17.1

3 2

[PATCH] ASoC: imx-hdmi: no need to set .owner when using module_platform_driver
by Tian Tao 19 Feb '21

19 Feb '21

the module_platform_driver will call platform_driver_register. and It will set the .owner to THIS_MODULE Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- sound/soc/fsl/imx-hdmi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c index dbbb7618..cd0235a 100644 --- a/sound/soc/fsl/imx-hdmi.c +++ b/sound/soc/fsl/imx-hdmi.c @@ -223,7 +223,6 @@ MODULE_DEVICE_TABLE(of, imx_hdmi_dt_ids); static struct platform_driver imx_hdmi_driver = { .driver = { .name = "imx-hdmi", - .owner = THIS_MODULE, .pm = &snd_soc_pm_ops, .of_match_table = imx_hdmi_dt_ids, }, -- 2.7.4

2 1

[PATCH 0/2] dmic fix to allow userspace to choose ch count
by vamshi.krishna.gopal＠intel.com 18 Feb '21

18 Feb '21

From: Vamshi Krishna Gopal <vamshi.krishna.gopal(a)intel.corp-partner.google.com> hello, git.kernel.org/pub/scm/linux/kernel/git/vkoul/sound.git/commit/?h=intel2&id… git.kernel.org/pub/scm/linux/kernel/git/vkoul/sound.git/commit/?h=intel2&id… These patch series is about removing channel count selection based on mach/pdata and assign min and max channel only based on hw params. This allows userspcae to choose channel count. This patch series was Acked by Vinod and taken into his tree. But seems its missed to be posted. hence i've rebased the same commits and re sending. Naveen Manohar (2): ASoC: Intel: kbl: Remove option of choosing CH count based on pdata ASoC: Intel: kbl: update dmic fixup params sound/soc/intel/boards/kbl_rt5663_max98927.c | 44 +++++++------------- 1 file changed, 14 insertions(+), 30 deletions(-) -- 2.17.1

1 2

Re: [PATCH] ASoC: rt1316: Add RT1316 SDCA vendor-specific driver
by Mark Brown 18 Feb '21

18 Feb '21

On Tue, Feb 09, 2021 at 01:34:24AM +0000, Shuming [范書銘] wrote: > > Right, this was my expectation for how this would work - dynamic control at > > runtime so you can do stuff like that rather than a more static setup like slot > > assignment is normally.. > Actually, the "RX Channel Select" control could select the channel. > This control could select the different channels to output dynamically. > However, could I keep the rt1316_sdw_set_tdm_slot() here? > There will be more options to set this configuration. If there's a control to override it at runtime then duplicating that with set_tdm_slot() seems like it's going to be a route to confusion if people change it?

2 1

[PATCH] ASoC: soc-pcm: fix hw param limits calculation for multi-DAI
by Kai Vehmanen 18 Feb '21

18 Feb '21

In case DPCM runtime has multiple CPU DAIs, dpcm_init_runtime_hw() is called multiple times, once for each CPU DAI. This will will lead to ignoring hw limits of all but the first DAI. Fix this by moving soc_pcm_hw_init() up by one level to dpcm_init_runtime_hw(). Fixes: 140f553d1298 ("ASoC: soc-pcm: fix hwparams min/max init for dpcm") Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/soc/soc-pcm.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 37094aeff440..14d85ca1e435 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1531,10 +1531,12 @@ static void dpcm_init_runtime_hw(struct snd_pcm_runtime *runtime, { struct snd_pcm_hardware *hw = &runtime->hw; - soc_pcm_hw_init(hw); soc_pcm_hw_update_rate(hw, stream); soc_pcm_hw_update_chan(hw, stream); - soc_pcm_hw_update_format(hw, stream); + if (runtime->hw.formats) + runtime->hw.formats &= stream->formats; + else + runtime->hw.formats = stream->formats; } static void dpcm_runtime_merge_format(struct snd_pcm_substream *substream, @@ -1662,10 +1664,13 @@ static void dpcm_runtime_merge_rate(struct snd_pcm_substream *substream, static void dpcm_set_fe_runtime(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; + struct snd_pcm_hardware *hw = &runtime->hw; struct snd_soc_pcm_runtime *rtd = asoc_substream_to_rtd(substream); struct snd_soc_dai *cpu_dai; int i; + soc_pcm_hw_init(hw); + for_each_rtd_cpu_dais(rtd, i, cpu_dai) { /* * Skip CPUs which don't support the current stream base-commit: 140f553d1298e0ddbe21983efe5789fe8b484273 -- 2.29.2

2 1

[PATCH] ASoC: rt5682: remove jack detect delay
by Curtis Malainey 17 Feb '21

17 Feb '21

There is a 250ms delay on the jack detect interrupt currently, this delay is observable to users who are using inline controls. It can also mask multiple presses which is a negative experience. Cc: Bard liao <yung-chuan.liao(a)linux.intel.com> Cc: Shuming Fan <shumingf(a)realtek.com> Signed-off-by: Curtis Malainey <cujomalainey(a)chromium.org> --- sound/soc/codecs/rt5682-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c index 93c1603b42f1..b15c3e7d1f59 100644 --- a/sound/soc/codecs/rt5682-i2c.c +++ b/sound/soc/codecs/rt5682-i2c.c @@ -78,7 +78,7 @@ static irqreturn_t rt5682_irq(int irq, void *data) struct rt5682_priv *rt5682 = data; mod_delayed_work(system_power_efficient_wq, - &rt5682->jack_detect_work, msecs_to_jiffies(250)); + &rt5682->jack_detect_work, 0); return IRQ_HANDLED; } -- 2.30.0.478.g8a0d178c01-goog

2 1

ucm2: add support to for Qualcomm RB5 Platform
by GitHub pull_request - opened 17 Feb '21

17 Feb '21

alsa-project/alsa-ucm-conf pull request #84 was opened from lumag: Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/84 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/84.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0