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

[Hans de Goede]

Hi,

On 2/24/21 8:36 PM, Mark Brown wrote:
> On Wed, Feb 24, 2021 at 08:14:12PM +0100, Hans de Goede wrote:
>> On 2/24/21 1:59 PM, Mark Brown wrote:
> 
>>> The problem I was thinking of is the situation where there are multiple
>>> options for the mute control in the hardware and it's a configuration
>>> decision which one to use.
> 
>> ATM we have no device where this situation happens, so I would prefer
>> to cross that bridge when we come to it.
> 
> You just added wm5012 machine drivers, that device is going to present
> issues with this approach.

I've no intention to add led-trigger support to the bytcr-wm5102 driver,
since to the best of my knowledge there are no mute LEDs on any designs
using the bytcr + wm5102 combination.

I'm aware of there actually being a mute LED on only 3 2-in-1 models
with detachable keyboards (with the mute LEDs sitting inside the
media-keys to toggle the mute, like how it is done on thinkpads):

1. The Thinkpad10 bytcr+rt5670 tablet with its USB ultrabook keyboard dock
2. The HP x2 10" clamshell designs with detachable keyboards in
   2 variants, bytcr + rt5640 and cht + rt5640.

Thats it, and in both cases the codecs have main ADC / DAC volume
controls which are the only ones suited for using as the control
to drive the led-trigger. Which is why this RFC just hardcoded
the trigger to that control.

As I said I'll happily respin this RFC series (and the not yet
posted similar rt5640 series) to tie the led-trigger to specific
controls based on DMI quirks.

Given that the use of mute LEDs itself is actually rare and especially
the use of mute LEDs in combination with ASoC coming up with some
generic configuration mechanism to allow userspace to tie the
led-trigger to any random 'Switch' type control is way overkill /
overengineering and I've no desire to spend a huge amount of time
on implementing this.

Not to mention that this would just be punting the actual problem
of figuring out which control to use to userspace, while the kernel
is actually in a better place to make this decision since the kernel
already uses DMI based quirks to deal with model specific configuration.

Regards,

Hans