[alsa-devel] [PATCH 19/19] ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks
Pierre-Louis Bossart
pierre-louis.bossart at linux.intel.com
Thu May 10 17:00:50 CEST 2018
On 5/10/18 5:27 AM, Hans de Goede wrote:
> Hi,
>
> On 08-05-18 20:35, Pierre-Louis Bossart wrote:
>> On 5/8/18 10:36 AM, Hans de Goede wrote:
>>> Many X86 devices using a BYT SoC + RT5640 codec are cheap devices with
>>> generic DMI strings, causing snd_soc_set_dmi_name() to fail to set a
>>> long_name, making it impossible for userspace to have a correct UCM
>>> profile which only uses inputs / outputs which are actually hooked up
>>> on the device.
>>>
>>> Our quirks already specify which input the internal mic is connected to
>>> and if a single (mono) speaker is used or if the device has stereo
>>> speakers.
>>>
>>> This commit sets a long_name based on the quirks so that userspace can
>>> have UCM profiles doing the right thing based on the long_name.
>>
>> Isn't this going to be complicated to manage for UCM? Just with this
>> patch alone, you'd need 8 UCM files to cover all the combinations. 16
>> if you add the 'sof-' prefix.
>>
>> seems like UCM should become more 'dynamic' and get quirk information
>> somehow (sysfs?) to enable/disable endpoints rather than rely on name
>> encoding to select the right profile?
>
> I agree that this is not ideal, but this is an improvement from the
> current state where we would need 1 UCM profile per board
> (assuming valid DMI data and thus a proper long-name being set),
> 6 profiles (dmic2 is not used anywhere sofar) is a whole lot easier
> to manage then 1 profile per board. So as said I believe this is
> a step in the right direction.
>
> And looking at the foreseeable future I simply don't see any of us
> having the time to implement an ideal solution for this. I would
> really like for end users to be able to run the latest upstream
> kernel + alsa-lib and have things just work, before this hardware
> becomes obsolete. I know that no-one having time to work on reworking
> UCM to make it more dynamic is not the best of arguments but it
> is something to take into consideration.
>
> Thinking more about this on the alsa-lib / UCM profile side we
> could have something like this:
>
> /usr/share/alsa/ucm/bytcr-rt5640-mono-spk-in1-mic/bytcr-rt5640-mono-spk-in1-mic.conf:
>
>
> SectionUseCase."HiFi" {
> File "../bytcr-rt5640/Generic.conf"
> File "../bytcr-rt5640/MonoSpeaker.conf"
> File "../bytcr-rt5640/In1Mic.conf"
> Comment "Play HiFi quality Music"
> }
>
> SectionDefaults [
> cdev "hw:bytcrrt5640"
> ]
>
> The only problem I can see with that is that the "ConflictingDevice"
> sections for the various inputs / outputs then would refer to not
> present SectionDevice sections. I have not tested this suggestion yet,
> but I'm willing to write an alsa-lib patch to ignore non present
> ConflictingDevice references, to make my suggestion work.
>
> I think doing things this way, thus avoiding the need to copy and
> paste a whole lot of UCM code for the 6 profiles it will not be
> a problem to maintain 6 profiles, as we're really just maintaining
> 6 config snippets such as the above example and only one complete
> profile.
>
> Would the solution I outlined above be acceptable to you?
The includes and disabling conflicting devices that aren't present make
sense. I have another issue though: for SOF integration I already
prepared a set of files, which are mostly identical to the regular ones
except that the platform-side mixer controls are removed (or different)
and the name of the card/device is different (sof- prefix). See on github.
I was nearly ready to submit all those files to the new repository, I
wasn't aware of your work so now need to figure out how to reuse all
this once we upstream SOF (any time now if I look at Liam's patches).
>
> Regards,
>
> Hans
>
>
>
>
>
>>> Note that if we ever encounter the need for a special UCM profile for
>>> some device we can add a quirk to set a specific long_name for the
>>> device,
>>>
>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>> ---
>>> sound/soc/intel/boards/bytcr_rt5640.c | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/sound/soc/intel/boards/bytcr_rt5640.c
>>> b/sound/soc/intel/boards/bytcr_rt5640.c
>>> index cfc520200214..9a1204dcdbc6 100644
>>> --- a/sound/soc/intel/boards/bytcr_rt5640.c
>>> +++ b/sound/soc/intel/boards/bytcr_rt5640.c
>>> @@ -929,6 +929,7 @@ static struct snd_soc_dai_link byt_rt5640_dais[] = {
>>> static char byt_rt5640_codec_name[SND_ACPI_I2C_ID_LEN];
>>> static char byt_rt5640_codec_aif_name[12]; /* = "rt5640-aif[1|2]" */
>>> static char byt_rt5640_cpu_dai_name[10]; /* = "ssp[0|2]-port" */
>>> +static char byt_rt5640_long_name[40]; /* =
>>> "bytcr-rt5640-*-spk-*-mic" */
>>> static int byt_rt5640_suspend(struct snd_soc_card *card)
>>> {
>>> @@ -1000,6 +1001,7 @@ struct acpi_chan_package { /* ACPICA seems to
>>> require 64 bit integers */
>>> static int snd_byt_rt5640_mc_probe(struct platform_device *pdev)
>>> {
>>> + const char * const map_name[] = { "dmic1", "dmic2", "in1", "in3" };
>>> const struct dmi_system_id *dmi_id;
>>> struct byt_rt5640_private *priv;
>>> struct snd_soc_acpi_mach *mach;
>>> @@ -1163,6 +1165,13 @@ static int snd_byt_rt5640_mc_probe(struct
>>> platform_device *pdev)
>>> }
>>> }
>>> + snprintf(byt_rt5640_long_name, sizeof(byt_rt5640_long_name),
>>> + "bytcr-rt5640-%s-spk-%s-mic",
>>> + (byt_rt5640_quirk & BYT_RT5640_MONO_SPEAKER) ?
>>> + "mono" : "stereo",
>>> + map_name[BYT_RT5640_MAP(byt_rt5640_quirk)]);
>>> + byt_rt5640_card.long_name = byt_rt5640_long_name;
>>> +
>>> ret_val = devm_snd_soc_register_card(&pdev->dev,
>>> &byt_rt5640_card);
>>> if (ret_val) {
>>>
>>
More information about the Alsa-devel
mailing list