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

[Pierre-Louis Bossart]

On 05/10/2018 01:01 PM, Hans de Goede wrote:
> Hi,
>
> On 10-05-18 19:46, Pierre-Louis Bossart wrote:
>> On 5/10/18 10:48 AM, 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?
>>
>> 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.