ASoC driver names

[Jaroslav Kysela]

Dne 24. 04. 20 v 20:15 Mark Brown napsal(a):
> On Fri, Apr 24, 2020 at 07:11:46PM +0200, Jaroslav Kysela wrote:
>> Dne 24. 04. 20 v 18:49 Mark Brown napsal(a):
> 
>>> 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.
> 
> Sure, then you end up with a few directories with huge numbers of files
> which seems similar?

We can add more levels on demand (when the configs will grow) using the 
conditions in UCM2. For example:

ucm2/ASoC\ Simple/ASoC\ Simple.conf
- which can point to (based on other sound driver / sysfs strings):
   - ucm2/ASoC Simple/platform1/rt999/board1.conf
   - ucm2/ASoC Simple/platform1/rt999/board2.conf

etc...

The conditions may also shrink the number of configuration files, because the 
cards might be different only slightly.

The current scheme is "too flat" and constrained.

>  TBH if UCM weren't doing the directory thing it'd
> be easier to see fixing the neatness issue, what UCM is doing means that
> it's much more likely that people will notice a problem.
 >
> 
>>>   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.
> 
> That does provide some mitigation, though there's some potential for
> confusion too.  We could try it and see I guess.

Thanks.

					Jaroslav

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