[Sound-open-firmware] Distribution of sof firmware and tplg files

[Pierre-Louis Bossart]

>> Jaroslav, IIUC you also proposed having the FW in the same repo as UCM,
>> topology. What's the advantage of this over linux-firmware for RPM/deb
>> packagers ?
>
> I proposed to distribute the topology files with the firmware files. 
> Thus put these non-user space things to linux-firmware and let UCM 
> describe the rest.
>
> The topology and firmware files are required to boot the hardware.
The topology is a convenience tool, not a requirement. we've had 
multiple cases where the topology was embedded in the firmware itself to 
reduce boot time.
>
> Pierre insists to distribute the topology files separately to allow 
> customizations (not sure who are target users - OEMs?). My opinion is 
> that if the auto-selection for any of firmware and topologies is 
> missing on the kernel side, the topology separation is not required 
> for the Linux mainstream. It would be sufficient to link to the 
> sources in a documentation file in the linux-firmware tree. So the 
> advanced users can work with it.

There is a rationale for not bundling firmware and topology together:

1. the firmware cannot be generated by the end-user in general (access 
to the xcc compiler and signature issues).

2. the topology files can be generated at will

3. the linux-firmware tree is supposed to be for binaries only. When we 
talked with linux-firmware maintainers several years ago, the 
recommendation was that everything that can be compiled/scripted is not 
welcome in that tree. IIRC we had the same feedback in one of the ALSA 
miniconf.

4. in the linux-firmware tree the expectation is that there are multiple 
versions of the firmware. This is useful for Intel, e.g. in some cases 
we had ABI issues with the CSME tools so it's very very interesting to 
ask users to try and boot a previous version. This is conversely not 
needed for topologies, there is no real link with the hardware or other 
low-level firmware.

5. the topology can contain default for volume levels and filters, and 
different users of the same hardware might have different preferences. I 
am not aware of the moral equivalent of /usr/local for firmware, so the 
user/distro would have to override the default files, or provide a 
kernel parameter to fetch the files from another location (already 
supported).

>
> So my last advice was to push the topologies in the normalized .conf 
> format to alsa-topology-conf repository and let the distributions to 
> choose, if they'll put this to their linux-firmware packages or create 
> a standalone package with topologies (which must be installed in the 
> same way as linux-firmware anyway).

I think it's not sustainable to import .conf files, it'd be a better 
idea to move all M4 files into alsa-topology-conf and provide a script 
to generate topologies - provided that the results are the *same* as 
what gets tested by the SOF CI and Intel QA. We should not have multiple 
options for the topology generation, either we all normalize the 
intermediate .conf or we don't. Doing otherwise is a sure way of having 
"works for me" bug reports and confused users.

I will also assert that topology and UCM files should be released 
together, the former define stream numbers and control names that are 
used by the latter. If we don't release them together we'll be in 
trouble (e.g. if for the DMIC name changes).

Regards

-Pierre