ASoC driver names

[Jaroslav Kysela]

Dne 23. 04. 20 v 20:40 Mark Brown napsal(a):
> On Thu, Apr 23, 2020 at 11:17:30AM -0500, Pierre-Louis Bossart wrote:
> 
>> I am all for Jaroslav's proposal of making the driver name the basis for UCM
>> identification. we've been working on this since e.g. the addition of the
>> sof- prefix creates a driver name that makes no sense after a truncation of
>> the card name to 16 characters [1] [2] - still WIP.
> 
>> Making the card name more user-friendly is also a good thing, there's also a
>> nice hidden feature when the card name contains spaces, the last word -
>> typically the codec - is used for the card ID.
> 
>> But reporting an error when the driver name is not set is a bit extreme and
>> would break all Intel boards. I think we want to encourage people to move to
>> the suggested solution, but do we want to break existing setups?
> 
> That's an issue, yes - it makes me think we need a really strong case to
> change things.

I just wanted to point to the source location, where the check should be 
added. If you remove the return, then only the warning will be printed.

Also, we can add the .driver_name to all Intel drivers without the driver name 
change for the stable drivers. I would prefer the massive change (cleanup also 
those driver names conditionally), but I know, you're a bit paranoid here ;-)

>> I must admit I also don't see a generic solution when the card is generated
>> from a DT description, it's not straightforward to translate parsed elements
>> into human-readable ones.
> 
> We do let people just fill in an arbatrary string in the generic cards,
> not actually checked how many do something sensible though.  This is a
> big worry for me, if we're solving the problem by doing something that
> doesn't work for generic cards that means that as the generic cards get
> better and we need fewer custom cards whatever issues the current
> situation causes in userspace will get worse.  For them the commonality
> is likely to come from one or more of the components in the card and the
> card itself isn't really interesting.
> 
> 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.

The hardware configuration may be described in the card names and components 
string field (struct snd_ctl_card_info), so that the user space can do a more 
finer usage decision later.

>> While I am at it, I think we should probably avoid using the DMI information
>> for the long card name. It's just awful. It might be a better idea to add it
>> in the component strings (if it fits) so that UCM can use it internally, but
>> it's really horrible. Even with the clean-ups suggested by Jaroslav I
>> ended-up with this horror of a long name on my test device:
> 
>> root at Zotac:~# cat /proc/asound/cards
>>   0 [rt5640         ]: SOF - sof-bytcht rt5640
>>                        ZOTAC-XXXXXX-XX-CherryTrailFFD
> 
> I don't actually appear to have any DMI equipped systems with non-HDA
> sound cards but looking at the systems I have (a mix of Lenovo and Dell)
> they all have sensible display names in the DMI corresponding to the
> model name.  But yeah, outside of enterprise users nobody really pays
> attention to DMI so there's serious QoI issues in general.
> 
>> If we really wanted to be user-friendly we'd use something like
> 
>> "SOF card for Baytrail/Cherrytrail devices with Realtek RT5640 codec"
> 
>> and apply the same pattern for all machine drivers.
> 
> It kind of depends on how well filled in the DMI stuff is - if it's
> badly filled in it's obviously not useful but if you have a clear model
> name it works fairly well and matches what a lot of Windows systems do.

The question is if we resist to use this information in this form. UCM2 can 
read DMI over sysfs (e.g. /sys/class/dmi/id/product_name can be read using 
${sys:class/dmi/id/product_name} substitution and do the string / regex 
matching on it).

I would prefer to have the sound hardware description in the long name field 
than the whole hardware platform info here, too.

					Jaroslav

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