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