[PATCH v4 0/6] ALSA: control - add generic LED API

[Takashi Iwai]

On Wed, 17 Mar 2021 18:29:39 +0100,
Jaroslav Kysela wrote:
> 
> 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 not exported to the user space, but user space can
> manage the LED sound control associations through sysfs
> (last patch) per Mark's request. It makes things fully
> configurable in the kernel and user space (UCM).
> 
> 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 (ASoC codecs including SoundWire).
> 
> # lsmod | grep snd_ctl_led
> snd_ctl_led            24576  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
> 
> v4 changes:
>   - the LED access flags are private to kernel now (no user space
>     API change)
>   - fixes (kctl management, sysfs cleanup)
>   - add the sysfs LED marking kcontrol management
>     - https://lore.kernel.org/alsa-devel/28fffebd-1ce9-7480-0f2f-ed8369abddf1@perex.cz/
> v3 changes:
>   - reorder the controls_rwsem use to fix the remaining mutex issue
>     card->controls_rwsem <-> snd_ctl_layer_rwsem
> 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 at redhat.com>
> 
> Jaroslav Kysela (6):
>   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
>   ALSA: led control - add sysfs kcontrol LED marking layer

As we seem agreeing with this approach, I merged this patch set as is
now for 5.13.  For the further development, let's put changes over
there.

An immutable branch was created on top of the clean 5.12-rc5, and
tagged as mute-led-rework, too.

Mark, please pull from there if you need to patch further ASoC changes
that are relevant with the feature.


Thanks!

Takashi