[PATCH] ALSA: core - add more card sysfs entries

[Pierre-Louis Bossart]

>>> Couldn't the driver probe the firmware files with some device-specific
>>> string suffix at first?  e.g. the driver can issue request_firmware()
>>> with $base_file-$dmi_board at first, then falls back to the generic
>>> $base_file.  A similar method was already used in Broadcom WiFi
>>> driver.
>>>
>>> Also, the driver may do request_firmware() with a fixed path for the
>>> custom firmware at first (e.g. "intel/sof-tplg-custom"); then a system
>>> integrator may set up a specific configuration even that doesn't match
>>> with DMI or whatever identifier.
>>
>> And when we have two firmware files which differs just by functionality
>> requested by user? Although your method will work, I won't close the
>> possibility to configure everything in udev rather using a hard coded 
>> fw load
>> scheme only.
>>
>>                         Jaroslav
>>
> 
> I've slept on it and now I think I see what you are trying to do.
> 
> 1. Load FW dependent on platform/user settings
> 2. Load appropriate topology for FW
> 3. Have UCM for the FEs and controls exposed by driver
> 
> 
> As for 1. I would say that FW should be loaded from one location
> if there is some platform that requires special FW just add quirks, like 
> it is done with every other driver, and if someone wants to build their 
> own special FW, they just replace it. We can't possibly support hundreds 
> of possible FW modifications if users want them by putting them in 
> separate files. Alternatively allow override via kernel parameters.
> Overriding FW files via udev would only make sense to me if it was 
> possible to upload new FW at runtime.

No, replacing firmware files is not viable.

Let me give you a practical example. In the course of SOF development, 
we routinely copy new test firmware+topology in the location of 
distribution-managed files. It's classic that when there is a 
distribution update in the background to install the latest SOF release, 
our test files are overwritten and it's not usual for developers to lose 
time trying to figure out why the functionality changed. We do need to 
have multiple paths and NEVER override what is provided by the 
distributions. it's the moral equivalent of /usr/bin v. /usr/local/bin.

Likewise, if an OEM has a custom version of firmware+topology, they may 
want to place it in their own packages that install *separately* from 
the default distribution. The udev rules provide a means to select the 
custom firmware, and if no rules are provided the default firmware with 
no customizations is used.

We are not talking about hundreds of configurations, but typically one 
directory per OEM. What they do internally is their problem, it's not 
for us to debate. The key point is that the custom files shall not 
interfere with the distribution baseline firmware, they have to be 
handled as separate packages that have their own release cycle and are 
possibly installed only in OEM custom images.

> I would say that same applies for 2.
> 
> This leaves number 3. which would require kernel exposing some kind of 
> information about loaded topology, so user space can use proper UCM.
> In topology manifest there are few reserved fields 
> (https://elixir.bootlin.com/linux/latest/source/include/uapi/sound/asoc.h#L382), 
> so we can add some information there which should be unique per topology 
> and then expose it in userspace on topology load, it can be the name of 
> UCM file topology wants to be loaded for example.
> 
> For example do something along those lines:
> 
> struct snd_soc_tplg_manifest {
>      __le32 size;        /* in bytes of this structure */
>      __le32 control_elems;    /* number of control elements */
>      __le32 widget_elems;    /* number of widget elements */
>      __le32 graph_elems;    /* number of graph elements */
>      __le32 pcm_elems;    /* number of PCM elements */
>      __le32 dai_link_elems;    /* number of DAI link elements */
>      __le32 dai_elems;    /* number of physical DAI elements */
>      __le32 ucm_files;    /* UCM files to use with topology */
>      __le32 reserved[19];    /* reserved for new ABI element types */
>      struct snd_soc_tplg_private priv;
> } __attribute__((packed));
> 
> struct snd_soc_tplg_ucm_files {
>      struct snd_soc_tplg_ctl_hdr hdr;
>      __le32 size;    /* size of struct in bytes */
>      __le32 count;    /* UCM entries */
>      char ucms[SNDRV_CTL_ELEM_ID_NAME_MAXLEN][];
> }
> 
> And then expose it somewhere under sysfs after parsing topology.

Yes I had a similar idea that we could expose in sysfs information taken 
from parsing the firmware (e.g. list of module UUIDs) and topology.

But it's not enough. The point is that you may use the same 
topology+firmware for different platforms, only the tuning varies. I 
think that's at that level that we should allow the OEMs to set a rule 
defining what the platform is and what tuning should be applied.