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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
