Dne 24. 04. 20 v 18:49 Mark Brown napsal(a):
On Fri, Apr 24, 2020 at 10:52:38AM +0200, Jaroslav Kysela wrote:
Dne 23. 04. 20 v 20:40 Mark Brown napsal(a):
My instinct is that the machine driver name is being used as a
proxy for something else here and that if we need to change the ABI
perhaps we need to extend it rather than trying to shoehorn things into
what's there.
My point is that this information is duplicated in the sense, that we have
three fields with the similar contents passed from the audio driver by the
ASoC drivers whose set only snd_soc_card->name from the device tree.
For generic drivers: They can pass a generic driver name (like 'ASoC
Simple') for the simple card driver (soc/generic/simple-card.c).
So my proposal is to change the driver_name to the right contents (it was
the initial intention for this field - changed somehow for ASoC). An
information about the used driver which is independent on the real
configuration (device tree, ACPI, component enumeration etc.). In other
words, the name should be more close to the source (top-level driver) code
name than the hardware configuration.
So if it's not really going to be used for anything particularly
concrete then I'm having a hard time summoning the enthusiasm for a
change.
The driver name is used as the directory name in UCM / UCM2. For DT, it means
thousands possible directories (one per board / board + codec variant and so
on..). The generic simple asoc card is a good example.
It feels more like a neatness thing than anything else and the
postitive case just isn't jumping out at me, certainly not as a thing to
force for everything. New stuff, sure. I guess I'm not bothered enough
to block any platform that has a burning desire to convert either though
if users start coming and complaining about kernel upgrades breaking
things we'd have to revert.
:-( I don't propose to force one way. We can conditionally change the driver
names using a well documented CONFIG_ option to keep compatibility with the
older user space code. The new driver names may be selected manually in the
kernel config.
I would prefer to have the sound hardware description in the long name field
than the whole hardware platform info here, too.
Does it also cope with the DT equivalents (and I guess there's nothing
we can do for board file based systems)? This stuff does get used for
embedded systems where the plastics are often important for the
configuration.
The author of DT config knows what hardware is described, thus this person
should be resposible for the nice GUI sound part name.
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
