Message ID | 20210317172945.842280-1-perex@perex.cz (mailing list archive) |
---|---|
Headers | show |
Series | ALSA: control - add generic LED API | expand |
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@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