[RFC 2/2] ASoC: rt5670: Add LED trigger support

[Takashi Iwai]

On Tue, 23 Feb 2021 17:14:32 +0100,
Jaroslav Kysela wrote:
> 
> Dne 23. 02. 21 v 15:21 Takashi Iwai napsal(a):
> > On Tue, 23 Feb 2021 15:09:30 +0100,
> > Mark Brown wrote:
> >>
> >> On Tue, Feb 23, 2021 at 02:59:17PM +0100, Hans de Goede wrote:
> >>> On 2/23/21 2:45 PM, Mark Brown wrote:
> >>>> On Mon, Feb 15, 2021 at 03:24:19PM +0100, Hans de Goede wrote:
> >>
> >>>> Why just these particular controls - what if a system has separate mutes
> >>>> for speakers or something?
> >>
> >>> These are the main volume controls, which are always in the output / input
> >>> path independent on if we are outputting to e.g. speakers or the headphones.
> >>
> >>> We want to use the main volume control for this, because there always is
> >>> only 1 output mute LED and 1 input mute LED. Well at least that is the assumption
> >>> the current ledtrig-audio.c code has.
> >>
> >>> The idea is to only turn the single LED on if we are sure there will be not
> >>> sound output on any of the outputs, which is why we tie the LED to the
> >>> mute switch on the main volume control.
> >>
> >> Right, so that might work well on your particular system with your
> >> particular configuration but will it work well on other systems with
> >> different hardware?  It's not clear to me that it makes sense to go
> >> through all the drivers picking controls that might be used for this
> >> purpose - it seems both time consuming and error prone.  Consider a
> >> mostly digital device which has an ADC/DAC per input/output rather than
> >> a central ADC/DAC with analogue muxing for example, or a system with
> >> multiple DACs available for mixing together or analogue bypassess.  
> > 
> > That's one of my concerns in the recent actions for putting the
> > hard-coded mute LED controls.  So far, the only usage of led-audio
> > trigger is HD-audio, and it's enabled only for selected devices and
> > setups.  OTOH, if we apply the audio-led trigger generically in ASoC
> > codec driver, it's always done and might misfit; e.g. what happens if
> > two codecs are present on the system?.
> 
> That's the abstraction issue. We can use PCI, ACPI, DMI or DT checks at the
> _right_ place (machine top-level code) to mark those controls with the LED
> flags in the kernel space. I've never said that the right place is the generic
> ASoC codec driver.
> 
> On the other hand, rt5670 is really multi-purpose codec like HDA codecs with
> the recommended usage/routing from the designer, so it might make sense to add
> the default LED marking as we do for HDA.

So do you mean that the LED feature should be selectively enabled like
the current HD-audio?

> > Of course, this implementation would make the integration much easier,
> > and that's a big benefit.  So I have a mixed feeling and not decided
> > yet whether we should go for it right now...
> 
> I think that we can reconsider the LED handling implementation later, when
> someone brings something better on the table.

What worried me is the plan to expose this capability to user-space.
If it's only a kernel-internal, we can fix it in the kernel and
nothing else broken, but if it's a part of API, that's not easy.

So, if any, I'd like to avoid exposing to the user-space at first.
(But then it comes to the question how to deal with a case like AMD
ACP...)


thanks,

Takashi