[RFC 2/2] ASoC: rt5670: Add LED trigger support
Hans de Goede
hdegoede at redhat.com
Wed Feb 24 20:14:12 CET 2021
Hi,
On 2/24/21 1:59 PM, Mark Brown wrote:
> On Tue, Feb 23, 2021 at 08:03:58PM +0100, Hans de Goede wrote:
>> On 2/23/21 6:20 PM, Mark Brown wrote:
>
>>> We already need ACPI and DMI quirks in the CODEC drivers anyway due to
>>> the limitations of ACPI so it wouldn't be particularly surprising to
>>> have stuff there. OTOH this would fix things per machine while with
>>> fancier hardware things might easily be flexible enough that there's
>>> multiple choices that could be made depending on use case.
>
>> I have a feeling from the discussion here that you would prefer this
>> per model/machine option over the current patch which unconditionally
>> sets the SNDRV_CTL_ELEM_ACCESS_SPK/MIC_LED flag on the main DAC/ADC
>> mute controls ?
>
>> So I believe that it would be best for me to respin this patch
>> series moving to making this a per model/machine thing, correct?
>
> Yes, we at least need to be able to do that even if we end up hard
> coding it in some CODEC drivers as the device is inflexible. There are
> devices where the concept of "main DAC/ADC" just doesn't apply.
>
>>> I'd be a lot more comfortable with ASoC having some runtime control for
>>> overriding which controls get mapped, even if we try to pick defaults
>>> with quirks.
>
>> The drivers in question already allow overriding their quirks bitmap
>> via a module-parameter. If we are going to enable the mixer-element
>
> I'm not a big fan of module parameters TBH, it's not great for
> usability.
>
>> And then the user can always override the settings using the quirk
>> module parameter. This is not exactly runtime control, but IMHO it
>> is close enough and anything else will just overcomplicate things.
>> I'm aware of only 3 model 2-in-1s which need this and on those
>> 3 the implementation is very straight forward.
>
> 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.
Regards,
Hans
More information about the Alsa-devel
mailing list