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

[PATCH 0/5] ALSA: control - add generic LED trigger code
by Jaroslav Kysela 22 Feb '21

22 Feb '21

This patchset tries to resolve the diversity in the audio LED control among the ALSA drivers. A new control layer registration is introduced which allows to run additional operations on top of the elementary ALSA sound controls. A new control access group (three bits in the access flags) was introduced to carry the LED group information for the sound controls. The low-level sound drivers can just mark those controls using this access group. This information is exported to the user space and eventually the user space can create sound controls which can belong to a LED group. The actual state ('route') evaluation is really easy (the minimal value check for all channels / controls / cards). If there's more complicated logic for a given hardware, the card driver may eventually export a new read-only sound control for the LED group and do the logic itself. The new LED trigger control code is completely separated and possibly optional (there's no symbol dependency). The full code separation allows eventually to move this LED trigger control to the user space in future. Actually it replaces the already present functionality in the kernel space (HDA drivers) and allows a quick adoption for the recent hardware (SoundWire ASoC codecs). # lsmod | grep snd_ctl_led snd_ctl_led 16384 0 The sound driver implementation is really easy: 1) call snd_ctl_led_request() when control LED layer should be automatically activated / it calls module_request("snd-ctl-led") on demand / 2) mark all related kcontrols with SNDRV_CTL_ELEM_ACCESS_SPK_LED or SNDRV_CTL_ELEM_ACCESS_MIC_LED Original RFC: https://lore.kernel.org/alsa-devel/20210207201157.869972-1-perex@perex.cz/ Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: Perry Yuan <Perry.Yuan(a)dell.com> Jaroslav Kysela (5): ALSA: control - introduce snd_ctl_notify_one() helper ALSA: control - add layer registration routines ALSA: control - add generic LED trigger module as the new control layer ALSA: HDA - remove the custom implementation for the audio LED trigger ALSA: control - add sysfs support to the LED trigger module include/sound/control.h | 27 ++- include/uapi/sound/asound.h | 6 +- sound/core/Kconfig | 6 + sound/core/Makefile | 2 + sound/core/control.c | 173 ++++++++++++-- sound/core/control_led.c | 407 ++++++++++++++++++++++++++++++++ sound/pci/hda/Kconfig | 4 +- sound/pci/hda/hda_codec.c | 69 +----- sound/pci/hda/hda_generic.c | 162 ++----------- sound/pci/hda/hda_generic.h | 15 +- sound/pci/hda/hda_local.h | 16 +- sound/pci/hda/patch_ca0132.c | 4 +- sound/pci/hda/patch_realtek.c | 2 +- sound/pci/hda/patch_sigmatel.c | 6 +- sound/pci/hda/thinkpad_helper.c | 2 +- 15 files changed, 638 insertions(+), 263 deletions(-) create mode 100644 sound/core/control_led.c -- 2.29.2

5 20

[PATCH v2 0/5] ALSA: control - add generic LED API
by Jaroslav Kysela 21 Feb '21

21 Feb '21

This patchset tries to resolve the diversity in the audio LED control among the ALSA drivers. A new control layer registration is introduced which allows to run additional operations on top of the elementary ALSA sound controls. A new control access group (three bits in the access flags) was introduced to carry the LED group information for the sound controls. The low-level sound drivers can just mark those controls using this access group. This information is exported to the user space and eventually the user space can create sound controls which can belong to a LED group. The actual state ('route') evaluation is really easy (the minimal value check for all channels / controls / cards). If there's more complicated logic for a given hardware, the card driver may eventually export a new read-only sound control for the LED group and do the logic itself. The new LED trigger control code is completely separated and possibly optional (there's no symbol dependency). The full code separation allows eventually to move this LED trigger control to the user space in future. Actually it replaces the already present functionality in the kernel space (HDA drivers) and allows a quick adoption for the recent hardware (SoundWire / ASoC codecs). # lsmod | grep snd_ctl_led snd_ctl_led 16384 0 The sound driver implementation is really easy: 1) call snd_ctl_led_request() when control LED layer should be automatically activated / it calls module_request("snd-ctl-led") on demand / 2) mark all related kcontrols with SNDRV_CTL_ELEM_ACCESS_SPK_LED or SNDRV_CTL_ELEM_ACCESS_MIC_LED v2 changes: - fix the locking - remove the controls_rwsem read lock in the element get (the consistency is already protected with the global snd_ctl_led_mutex and possible partial value writes are catched with the next value change notification callback) - rename state to brightness and show the brightness unsigned integer value instead the text on/off string (sync with the LED core routines) - remove snd_ctl_led_hello() function (CI warning) - make snd_ctl_led_get_by_access() function static (CI warning) - move snd_ctl_layer_rwsem lock before the registraction callback call in snd_ctl_register_layer() - optimization v1: - https://lore.kernel.org/alsa-devel/20210211111400.1131020-1-perex@perex.cz/ Original RFC: - https://lore.kernel.org/alsa-devel/20210207201157.869972-1-perex@perex.cz/ Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: Perry Yuan <Perry.Yuan(a)dell.com> Jaroslav Kysela (5): ALSA: control - introduce snd_ctl_notify_one() helper ALSA: control - add layer registration routines ALSA: control - add generic LED trigger module as the new control layer ALSA: HDA - remove the custom implementation for the audio LED trigger ALSA: control - add sysfs support to the LED trigger module include/sound/control.h | 27 ++- include/uapi/sound/asound.h | 6 +- sound/core/Kconfig | 6 + sound/core/Makefile | 2 + sound/core/control.c | 173 ++++++++++++--- sound/core/control_led.c | 378 ++++++++++++++++++++++++++++++++ sound/pci/hda/Kconfig | 4 +- sound/pci/hda/hda_codec.c | 69 +----- sound/pci/hda/hda_generic.c | 162 +++----------- sound/pci/hda/hda_generic.h | 15 +- sound/pci/hda/hda_local.h | 16 +- sound/pci/hda/patch_ca0132.c | 4 +- sound/pci/hda/patch_realtek.c | 2 +- sound/pci/hda/patch_sigmatel.c | 6 +- sound/pci/hda/thinkpad_helper.c | 2 +- 15 files changed, 609 insertions(+), 263 deletions(-) create mode 100644 sound/core/control_led.c -- 2.29.2

2 8

[PATCH v4 0/9] ALSA: add virtio sound driver
by Anton Yakovlev 21 Feb '21

21 Feb '21

This series implements a driver part of the virtio sound device specification v8 [1]. The driver supports PCM playback and capture substreams, jack and channel map controls. A message-based transport is used to write/read PCM frames to/from a device. As a device part was used OpenSynergy proprietary implementation. v4 changes: - fixed sparse warnings, no functional change [1] https://lists.oasis-open.org/archives/virtio-dev/202003/msg00185.html Anton Yakovlev (9): uapi: virtio_ids: add a sound device type ID from OASIS spec ALSA: virtio: add virtio sound driver ALSA: virtio: handling control messages ALSA: virtio: build PCM devices and substream hardware descriptors ALSA: virtio: handling control and I/O messages for the PCM device ALSA: virtio: PCM substream operators ALSA: virtio: introduce jack support ALSA: virtio: introduce PCM channel map support ALSA: virtio: introduce device suspend/resume support MAINTAINERS | 9 + include/uapi/linux/virtio_ids.h | 1 + include/uapi/linux/virtio_snd.h | 334 +++++++++++++++++++++ sound/Kconfig | 2 + sound/Makefile | 3 +- sound/virtio/Kconfig | 10 + sound/virtio/Makefile | 13 + sound/virtio/virtio_card.c | 462 +++++++++++++++++++++++++++++ sound/virtio/virtio_card.h | 113 ++++++++ sound/virtio/virtio_chmap.c | 219 ++++++++++++++ sound/virtio/virtio_ctl_msg.c | 310 ++++++++++++++++++++ sound/virtio/virtio_ctl_msg.h | 78 +++++ sound/virtio/virtio_jack.c | 233 +++++++++++++++ sound/virtio/virtio_pcm.c | 499 ++++++++++++++++++++++++++++++++ sound/virtio/virtio_pcm.h | 121 ++++++++ sound/virtio/virtio_pcm_msg.c | 392 +++++++++++++++++++++++++ sound/virtio/virtio_pcm_ops.c | 491 +++++++++++++++++++++++++++++++ 17 files changed, 3289 insertions(+), 1 deletion(-) create mode 100644 include/uapi/linux/virtio_snd.h create mode 100644 sound/virtio/Kconfig create mode 100644 sound/virtio/Makefile create mode 100644 sound/virtio/virtio_card.c create mode 100644 sound/virtio/virtio_card.h create mode 100644 sound/virtio/virtio_chmap.c create mode 100644 sound/virtio/virtio_ctl_msg.c create mode 100644 sound/virtio/virtio_ctl_msg.h create mode 100644 sound/virtio/virtio_jack.c create mode 100644 sound/virtio/virtio_pcm.c create mode 100644 sound/virtio/virtio_pcm.h create mode 100644 sound/virtio/virtio_pcm_msg.c create mode 100644 sound/virtio/virtio_pcm_ops.c -- 2.30.0

1 9

[PATCH v3 0/7] HID: lenovo: Mute LED handling fixes and improvements
by Hans de Goede 21 Feb '21

21 Feb '21

Hi All, Here is v3 of my series with mute LED handling fixes and improvements for the hid-lenovo driver. v3 addresses the review-remarks from Marek Behún, thank you for all the reviews Marek. See the individual patches for detailed per patch changelogs. Regards, Hans Hans de Goede (7): HID: lenovo: Use brightness_set_blocking callback for setting LEDs brightness HID: lenovo: Fix lenovo_led_set_tp10ubkbd() error handling HID: lenovo: Check hid_get_drvdata() returns non NULL in lenovo_event() HID: lenovo: Remove lenovo_led_brightness_get() HID: lenovo: Set LEDs max_brightness value HID: lenovo: Map mic-mute button to KEY_F20 instead of KEY_MICMUTE HID: lenovo: Set default_triggers for the mute and micmute LEDs drivers/hid/hid-lenovo.c | 69 ++++++++++++++++++++++------------------ 1 file changed, 38 insertions(+), 31 deletions(-) -- 2.30.1

3 13

[PATCH] sound/usb generate midi streaming substream names from jack names
by George Harker 21 Feb '21

21 Feb '21

A number of devices have named substreams which are hard to remember / decypher from <device> MIDI n names. Eg. Korg puts a pass through on one substream and iConnectivity devices name the connections. This makes it easier to connect to the correct device. Devices which handle naming through quirks are unaffected by this change. Addresses TODO comment in sound/usb/midi.c Signed-off-by: George Harker <george(a)george-graphics.co.uk> --- sound/usb/midi.c | 122 ++++++++++++++++++++++++++++++++++++++--------- sound/usb/midi.h | 2 + 2 files changed, 101 insertions(+), 23 deletions(-) diff --git a/sound/usb/midi.c b/sound/usb/midi.c index 0c23fa6d8..c6651a566 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -47,6 +47,7 @@ #include <linux/usb.h> #include <linux/wait.h> #include <linux/usb/audio.h> +#include <linux/usb/midi.h> #include <linux/module.h> #include <sound/core.h> @@ -77,23 +78,6 @@ MODULE_AUTHOR("Clemens Ladisch <clemens(a)ladisch.de>"); MODULE_DESCRIPTION("USB Audio/MIDI helper module"); MODULE_LICENSE("Dual BSD/GPL"); - -struct usb_ms_header_descriptor { - __u8 bLength; - __u8 bDescriptorType; - __u8 bDescriptorSubtype; - __u8 bcdMSC[2]; - __le16 wTotalLength; -} __attribute__ ((packed)); - -struct usb_ms_endpoint_descriptor { - __u8 bLength; - __u8 bDescriptorType; - __u8 bDescriptorSubtype; - __u8 bNumEmbMIDIJack; - __u8 baAssocJackID[]; -} __attribute__ ((packed)); - struct snd_usb_midi_in_endpoint; struct snd_usb_midi_out_endpoint; struct snd_usb_midi_endpoint; @@ -1756,12 +1740,68 @@ static void snd_usbmidi_get_port_info(struct snd_rawmidi *rmidi, int number, } } +static struct usb_midi_in_jack_descriptor *find_usb_in_jack_descriptor( + struct usb_host_interface *hostif, uint8_t jack_id) +{ + unsigned char *extra = hostif->extra; + int extralen = hostif->extralen; + + while (extralen > 4) { + struct usb_midi_in_jack_descriptor *injd = + (struct usb_midi_in_jack_descriptor *)extra; + + if (injd->bLength > 4 && + injd->bDescriptorType == USB_DT_CS_INTERFACE && + injd->bDescriptorSubtype == UAC_MIDI_IN_JACK && + injd->bJackID == jack_id) + return injd; + if (!extra[0]) + break; + extralen -= extra[0]; + extra += extra[0]; + } + return NULL; +} + +static struct usb_midi_out_jack_descriptor *find_usb_out_jack_descriptor( + struct usb_host_interface *hostif, uint8_t jack_id) +{ + unsigned char *extra = hostif->extra; + int extralen = hostif->extralen; + + while (extralen > 4) { + struct usb_midi_out_jack_descriptor *outjd = + (struct usb_midi_out_jack_descriptor *)extra; + + if (outjd->bLength > 4 && + outjd->bDescriptorType == USB_DT_CS_INTERFACE && + outjd->bDescriptorSubtype == UAC_MIDI_OUT_JACK && + outjd->bJackID == jack_id) + return outjd; + if (!extra[0]) + break; + extralen -= extra[0]; + extra += extra[0]; + } + return NULL; +} + static void snd_usbmidi_init_substream(struct snd_usb_midi *umidi, - int stream, int number, + int stream, int number, int jack_id, struct snd_rawmidi_substream **rsubstream) { struct port_info *port_info; const char *name_format; + struct usb_interface *intf; + struct usb_host_interface *hostif; + struct usb_midi_in_jack_descriptor *injd; + struct usb_midi_out_jack_descriptor *outjd; + uint8_t jack_name_buf[32]; + uint8_t *default_jack_name = "MIDI"; + uint8_t *jack_name = default_jack_name; + uint8_t iJack; + size_t sz; + int res; struct snd_rawmidi_substream *substream = snd_usbmidi_find_substream(umidi, stream, number); @@ -1771,11 +1811,35 @@ static void snd_usbmidi_init_substream(struct snd_usb_midi *umidi, return; } - /* TODO: read port name from jack descriptor */ + intf = umidi->iface; + if (intf && jack_id >= 0) { + hostif = intf->cur_altsetting; + iJack = 0; + if (stream != SNDRV_RAWMIDI_STREAM_OUTPUT) { + /* in jacks connect to outs */ + outjd = find_usb_out_jack_descriptor(hostif, jack_id); + if (outjd) { + sz = USB_DT_MIDI_OUT_SIZE(outjd->bNrInputPins); + iJack = *(((uint8_t *) outjd) + sz - 1); + } + } else { + /* and out jacks connect to ins */ + injd = find_usb_in_jack_descriptor(hostif, jack_id); + if (injd) + iJack = injd->iJack; + } + if (iJack != 0) { + res = usb_string(umidi->dev, iJack, jack_name_buf, 32); + if (res) + jack_name = jack_name_buf; + } + } + port_info = find_port_info(umidi, number); - name_format = port_info ? port_info->name : "%s MIDI %d"; + name_format = port_info ? port_info->name : + (jack_name != default_jack_name ? "%s %s" : "%s %s %d"); snprintf(substream->name, sizeof(substream->name), - name_format, umidi->card->shortname, number + 1); + name_format, umidi->card->shortname, jack_name, number + 1); *rsubstream = substream; } @@ -1810,6 +1874,7 @@ static int snd_usbmidi_create_endpoints(struct snd_usb_midi *umidi, snd_usbmidi_init_substream(umidi, SNDRV_RAWMIDI_STREAM_OUTPUT, out_ports, + endpoints[i].assoc_out_jacks[j], &umidi->endpoints[i].out->ports[j].substream); ++out_ports; } @@ -1817,6 +1882,7 @@ static int snd_usbmidi_create_endpoints(struct snd_usb_midi *umidi, snd_usbmidi_init_substream(umidi, SNDRV_RAWMIDI_STREAM_INPUT, in_ports, + endpoints[i].assoc_in_jacks[j], &umidi->endpoints[i].in->ports[j].substream); ++in_ports; } @@ -1862,7 +1928,7 @@ static int snd_usbmidi_get_ms_info(struct snd_usb_midi *umidi, struct usb_host_endpoint *hostep; struct usb_endpoint_descriptor *ep; struct usb_ms_endpoint_descriptor *ms_ep; - int i, epidx; + int i, j, epidx; intf = umidi->iface; if (!intf) @@ -1875,7 +1941,7 @@ static int snd_usbmidi_get_ms_info(struct snd_usb_midi *umidi, ms_header->bDescriptorType == USB_DT_CS_INTERFACE && ms_header->bDescriptorSubtype == UAC_HEADER) dev_dbg(&umidi->dev->dev, "MIDIStreaming version %02x.%02x\n", - ms_header->bcdMSC[1], ms_header->bcdMSC[0]); + ((uint8_t *)&ms_header->bcdMSC)[1], ((uint8_t *)&ms_header->bcdMSC)[0]); else dev_warn(&umidi->dev->dev, "MIDIStreaming interface descriptor not found\n"); @@ -1911,6 +1977,10 @@ static int snd_usbmidi_get_ms_info(struct snd_usb_midi *umidi, endpoints[epidx].out_interval = 1; endpoints[epidx].out_cables = (1 << ms_ep->bNumEmbMIDIJack) - 1; + for (j = 0; j < ms_ep->bNumEmbMIDIJack; ++j) + endpoints[epidx].assoc_out_jacks[j] = ms_ep->baAssocJackID[j]; + for (; j < 0x10; ++j) + endpoints[epidx].assoc_out_jacks[j] = -1; dev_dbg(&umidi->dev->dev, "EP %02X: %d jack(s)\n", ep->bEndpointAddress, ms_ep->bNumEmbMIDIJack); } else { @@ -1928,6 +1998,10 @@ static int snd_usbmidi_get_ms_info(struct snd_usb_midi *umidi, endpoints[epidx].in_interval = 1; endpoints[epidx].in_cables = (1 << ms_ep->bNumEmbMIDIJack) - 1; + for (j = 0; j < ms_ep->bNumEmbMIDIJack; ++j) + endpoints[epidx].assoc_in_jacks[j] = ms_ep->baAssocJackID[j]; + for (; j < 0x10; ++j) + endpoints[epidx].assoc_in_jacks[j] = -1; dev_dbg(&umidi->dev->dev, "EP %02X: %d jack(s)\n", ep->bEndpointAddress, ms_ep->bNumEmbMIDIJack); } @@ -2244,11 +2318,13 @@ static int snd_usbmidi_create_endpoints_midiman(struct snd_usb_midi *umidi, snd_usbmidi_init_substream(umidi, SNDRV_RAWMIDI_STREAM_OUTPUT, cable, + -1 /* prevent trying to find jack */, &umidi->endpoints[cable & 1].out->ports[cable].substream); if (endpoint->in_cables & (1 << cable)) snd_usbmidi_init_substream(umidi, SNDRV_RAWMIDI_STREAM_INPUT, cable, + -1 /* prevent trying to find jack */, &umidi->endpoints[0].in->ports[cable].substream); } return 0; diff --git a/sound/usb/midi.h b/sound/usb/midi.h index 8c38aec22..3f153195c 100644 --- a/sound/usb/midi.h +++ b/sound/usb/midi.h @@ -13,6 +13,8 @@ struct snd_usb_midi_endpoint_info { uint8_t in_interval; uint16_t out_cables; /* bitmask */ uint16_t in_cables; /* bitmask */ + int16_t assoc_in_jacks[16]; + int16_t assoc_out_jacks[16]; }; /* for QUIRK_MIDI_YAMAHA, data is NULL */ -- 2.20.1

1 0

[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