[alsa-devel] [PATCH 19/19] ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks

Hans de Goede hdegoede at redhat.com
Sun May 13 09:28:55 CEST 2018


Hi,

On 05/13/2018 09:11 AM, Takashi Iwai wrote:
> On Sat, 12 May 2018 23:21:58 +0200,
> Pierre-Louis Bossart wrote:
>>
>>>>
>>>> splitting platform and codec sides is a good idea (and something
>>>> that was done by removing all platform mixer settings from the HiFi
>>>> files)
>>>>
>>>> the problem remains that we have all these cdev strings that are
>>>> hard-codec with a card name. Same when the match happens based on a
>>>> DMI string, how would I know which of the platform settings to
>>>> apply without querying what the platform driver is?
>>>
>>> Well the DMI string would uniquely identify a certain model device,
>>> when we write the UCM file we should know what the platform + codec
>>> for that device is and we can simply hardcode them, like in
>>> my example above.
>>>
>>> But maybe I'm misunderstanding you?
>>
>> For the same DMI device, you could either enable the existing
>> intel/sst or SOF drivers. How would we handle UCM configs then? The
>> DMI name would need to be augmented with a prefix, or we use
>> *something* to add the references to SOF in the platform include and
>> ALSA device string.
> 
> You've already added the flavor suffix to snd_soc_set_dmi_name(), so
> they'll be unique, no?

Yes I was going to suggest doing something like that, but if we
already have that even better.

Note that the patch setting the longname based on the quirks
overrides (pre-empts really) snd_soc_set_dmi_name() and does
include  bytcr_rt5640 prefix, so this patch should make sure
that there is no name conflict between the sof and bytcr
machine drivers UCM profiles.

As mentioned in the commit message this pre-emption means we
loose the ability to have an UCM profile optimized for a
specific device, but we can work around this if necessary
with a flag which sets to not do set the quirk based
long-name on some models (if the need ever arises for this).

Regards,

Hans


More information about the Alsa-devel mailing list