[PATCH v2] ASoC: core: clarify the driver name initialization

[Jaroslav Kysela]

On 21. 10. 22 16:36, Pierre-Louis Bossart wrote:
> 
> 
> On 10/21/22 01:37, Jaroslav Kysela wrote:
>> On 20. 10. 22 20:13, Pierre-Louis Bossart wrote:
>>> Hi Jaroslav,
>>>
>>>> Nope. It's just a short path for the non-driver field to not further
>>>> process the destination string (the name argument). The snprintf() call
>>>> sets all field types (it's before the condition). Just set the
>>>> driver_name field in the soc card structure and you will be fine.
>>>>
>>>> The UCM config must be updated to handle the new driver name. The fine
>>>> selection key should probably use the card name, because long name is
>>>> set from DMI:
>>>>
>>>> old:
>>>>
>>>> 1 [sofglkda7219max]: sof-glkda7219ma - sof-glkda7219max
>>>>                        Google-Phaser360-rev4
>>>>
>>>> new:
>>>>
>>>> 1 [sofglkda7219max]: SOF-Intel - sof-glkda7219max
>>>>                        Google-Phaser360-rev4
>>>>
>>>> UCM substitutions:
>>>>
>>>> 1 [${CardId}      ]: ${CardDriver} - ${CardName}
>>>>                        ${CardLongName}
>>>>
>>>> UCM conf:
>>>>
>>>> mkdir -p ucm2/conf.d/SOF-Intel
>>>> cat > ucm2/conf.d/SOF-Intel/SOF-Intel.conf <<EOF
>>>> Syntax 6
>>>> Include.0.File "/Intel/\${CardName}/\${CardName}.conf"
>>>> EOF
>>>
>>> I am not following any of this, sorry.
>>>
>>> The existing UCM configuration uses the card name, e.g.
>>> sof-glkda7219max. That works and needs zero extra work.
>>
>> Unfortunately, actually the wrapped driver names are used for the
>> primary lookups. The card name is not used at all in ucm2/conf.d.
> 
> ok, that's interesting because I've always used the card name with
> alsaucm :-)
> 
> 
> Usage: alsaucm <options> [command]
> 
> Available options:
>    -h,--help                  this help
>    -c,--card NAME             open card NAME
> 
> alsaucm -c sof-glkda7219max set _verb HiFi set _enadev Headphone
> 
> And if we move to use the driver name as the primary lookup then we'd
> still need the card name for alsaucm to work, so why use the driver name
> as a primary lookup?

The driver name is used for the lookups as defined in ucm2/ucm.conf. The 
driver/card name/card long name lookups are handled in the alsa-lib's code 
(converted to "hw:X" UCM card name). If you turn this fallback off (use 
"strict:sof-glkda7219max" UCM card name), things won't work.

> If we can report a less confusing driver name to the users, that's fine
> with me, but I don't get the idea of using the driver name as the first
> criterion to identify a setup, you'll also need the card name so why not
> use the card name as primary criterion?

It is not usable for the USB driver where every model has own name set from 
USB descriptors for example.

>>> If all the cards registered in sound/soc/intel/boards use the same
>>> "SOF-Intel" driver name, then the driver name cannot be used for any UCM
>>> selection.
>>
>> It can be used for the first level of the lookup. Eventually, we can add
>> ucm2/conf.d/${CardDriver}/${CardName}.conf search path to ucm2/ucm.conf
>> for the direct lookups to handle this case, but it's just an
>> optimization. I would start with the ${CardName} redirection as I
>> suggested. We can decide / make the ucm.conf change later.
>>
>>> What is the point of including all the cardName.conf files at a higher
>>> level that brings no obvious value beyond an indirection that we already
>>> have with the path ucm2/Intel ?
>>>
>>> What am I missing ??
>>
>> The goal is to fix the driver names (e.g. "sof-glkda7219ma",
>> "sof-mt8195_r101" etc.). If you like to keep the unique names, it's your
>> decision. I just prefer to have a string which is understandable to
>> users. UCM can handle the finer selection of the configuration at any
>> level now. Examples: sof-soundwire, USB-Audio
>> (ucm2/USB-Audio/USB-Audio.conf), SOF (ucm2/Intel/SOF/HiFi.conf).
> 
> I don't mind setting a common string, it's not going to be possible to
> capture all hardware variations in 15 characters.
> 
> What worries me is backwards compatibility with existing user setups. If
> someone updates their kernel and the change in driver name ends-up
> breaking audio that's a big no-no for me. That's a real issue for us in
> terms of support because we typically ask people reporting
> SOF/SoundWire/HDA/mic issues if they can installing with our development
> kernel.

We can use a similar mechanism as we did with 
CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES . The distributions can enable 
this when packages when UCM configs are updated. Also, new drivers should use 
new driver name scheme, it's only for the current drivers.

						Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.