Re: [PATCH 19/19] ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks

[Hans de Goede <hdegoede@redhat.com>]

Hi Pierre-Louis,

On 10-05-18 17:48, Hans de Goede wrote:
> Hi,
> 
> On 10-05-18 17:00, Pierre-Louis Bossart wrote:
>> 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.
> 
> Hmm, it might make sense to split the includes in platform and codec includes, so
> to pick my example again we would get:
> 
> /usr/share/alsa/ucm/bytcr-rt5640-mono-spk-in1-mic/bytcr-rt5640-mono-spk-in1-mic.conf:
> 
> SectionUseCase."HiFi" {
>      SectionVerb {
>           EnableSequence [
>               cdev "hw:bytcrrt5640"
> 
>               File "../bytcr-rt5640/EnableSeq.conf" # This contains the platform mixer settings
>               File "../rt5640/EnableSeq.conf"
>           ]
> 
>           DisableSequence [
>           ]
> 
>           Value {
>               PlaybackPCM "hw:bytcrrt5640"
>               CapturePCM "hw:bytcrrt5640"
>           }
>        }
> 
>        File "../rt5640/Headset.conf"
>        File "../rt5640/MonoSpeaker.conf"
>        File "../rt5640/In1Mic.conf"
>        Comment "Play HiFi quality Music"
> }
> 
> SectionDefaults [
>        cdev "hw:bytcrrt5640"
> ]
> 
> And then for sof you would just need to
> offer a sof-rt5640/EnableSeq.conf, or
> maybe even leave it out completely.
> 
> And we might also be able to merge the platform
> enable sequences into a generic:
> 
> bytcr/EnableSeq.conf
> 
> I think that will at least fly for bytcr-rt5640 and
> butcr-rt5651, leading us being able to remove more
> duplicated UCM config. >
> How does this sound?

I've implemented the above scheme, see:
https://github.com/jwrdegoede/alsa-lib/commits/master

This seems to work well (I still need to test a
bit more, but so far the generic and one long-name
based profile work fine) and Mark has merged the
"ASoC: Intel: bytcr_rt5640: Set card long_name based on quirks"
patch in his for-next branch, so I plan to submit
the matching alsa-lib patches from my github for
upstream alsa-lib inclusion soon.

Regards,

Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel