[FEATURE] Upstream the firmware and topology files

[perexg]

We need to settle really the way, how the firmware and topology files will be pushed to upstream for the universal Linux usage. Actually, I cannot use SOF firmware files in our enterprise distribution, because they are not in upstream (linux-firmware). The same rule is for the topology files. The sources for alsatplg are not pushed to upstream (https://github.com/alsa-project/alsa-topology-conf - before those files were in alsa-lib) for SOF. The 1.4.1 SOF seems like a good starting point.

The goals should be (it's not difficult, please, spend little time to do this):

1. push firmware files ASAP to the official linux-firmware repository
2. push the topology files to alsa-topology-conf (in alsa-lib's .conf format)

The current situation when the distributions pick randomly the SOF firmware files and topologies is not ideal.

[juimonen]

alsa-project/alsa-topology-conf#1

This is from 1.4.1 tag. comments and suggestions please @plbossart @kv2019i @ranj063 and others...

[paulstelian97]

@juimonen For the i.MX8 topologies, we will need to update them as they currently have outdated backend names. Currently we're working on the kernel side (machine driver) to figure out what the final form is, and then we will send updates for the codec variants of the topologies. Does this mean that follow-up updates will come to alsa-project too, separately? Main concern is that the changes would be significant (diffs would be crazy).

[plbossart]

@perexg I agree with the need to fix all this, unfortunately it's crunch time for all of us and we've been distracted by other releases and travel. That's not an excuse I know but no one is trying to avoid the problem.

The firmware will be imported in linux-firmware, that's a given but it's taking time. We've apparently had misleading information on required configurations.

For the topology, I've already suggested we decouple them from the firmware repo. I wouldn't mind using alsa-topology-conf, but importing .conf files is not really useful for us, we generate those files with the m4 preprocessor and all tools to generate them are available, and the resulting files are unreadable really. It'd prefer importing the m4 files really. We can then work with distros to generate the packages necessary to copy the .tplg binaries into lib/firmware/intel/sof-tplg

[perexg]

I expected that point. The problem is that if other project will decide to use another preprocessor, then we need to add extra build infrastructure to https://github.com/alsa-project/alsa-topology-conf.

For distributions and almost all users, those files are "black magic" anyway, thus make them readable do not help us so much from the perspective to have working audio in the Linux system.

I think that we need to have one place where are the sources files for alsatplg are available in a "normalized" form with a link to the real source (like URL with the git tree and tag/branch name) in the comment, so the developers will be pointed to the right source and you'll have everything under the control.

[plbossart]

@perexg ok, so if there is no expectation that those .conf files are human-readable and that we don't have to deal with git diff/merge issues, we can indeed generate those files for each release and import them. At some point we are planning to ditch M4 and use a more formal way of generating/editing topologies so that would also make sure there is no disruption in the release process.

What I am not sure about is how we support users. In your model, the working version of the topology files will mechanically drift between releases and we'd also want power users to try the tip of the topology tree, e.g. for release candidates.

[juimonen]

@paulstelian97 are they outdated if using 1.4.1 tagged firmware? or has the change appeared later? I can remove imx conf files from initial import... Distros need to somehow track the dependencies what topology will work with what firmware as we might have breaks there, like really new topology might not work with old firmware...

[perexg]

My version of the normalized output was added to alsatplg (might be also used for the "check" what is really parsed):

alsa-project/alsa-utils@08d2341
alsa-project/alsa-utils@2656d4b

I added also possibility to sort the identifiers for the normalized output, but it might result with a different topology binary file (the -s option).

[dbaluta]

@paulstelian97 are they outdated if using 1.4.1 tagged firmware? or has the change appeared later? I can remove imx conf files from initial import... Distros need to somehow track the dependencies what topology will work with what firmware as we might have breaks there, like really new topology might not work with old firmware...

@juimonen it's OK you can keep the files in the initial import. The names of the DAI links from topology should match the names we provide in the kernel, but the changes in the kernel are not yet upstream so it doesn't matter for now what's in the topology files.

For consistency, I would prefer you to add them with the initial import and we will modify them later.

[perexg]

The discussion continues in the initial import from @juimonen here: alsa-project/alsa-topology-conf#1

[kv2019i]

We've beeb releasing bianries and topologies for long via https://github.com/thesofproject/sof-bin/releases so I think we can consider this closed.