Dne 11. 01. 20 v 0:15 Pierre-Louis Bossart napsal(a):
I'm not really convinced to handle .ldc in the other packages than the debugging ones. In my opinion, you should maintain the complete SOF binary firmware distribution in a separate package / tagged repository for all firmware / topology / .ldc files as the upstream reference and for the debugging. The ldc files do not belong to linux-firmware nor alsa-ucm-conf nor alsa-topology-conf.
https://github.com/thesofproject/sof/issues/2098
Also, if you like to release multiple versions of SOF firmware in the linux-firmware package, it should be properly documented (the purpose, what exact hardware is affected etc.). It is really difficult to have an orientation there (and we as the maintainers for various distributions should know what to do).
BTW: The SST firmware files are also affected with the lack of the documentation. I believe that only few people can tell us what firmware file belongs to the specific hardware / driver.
Thanks for challenging us and picking our brains.
I must admit I blindly followed the tradition, without asking questions. linux-firmware was required in the past and we also wanted to use alsa-conf-ucm for the rest. So conceptually I was set on a 2-part release.
If it's acceptable to distributions and users, it's true that having a TBD one-stop shop for all required binary/configuration/debug files, along with release collateral, would be a lot simpler. No risk of different parts flowing independently in different packages, pull requests being delayed, etc. Why not indeed?
That's be a big decision though so we'd need to have consensus from others (Debian, Chrome, Yocto, etc).
I mean to create "reference" repository with all tagged binaries / debuging files, so if we have a problem, we can look back to it and try to find the differences or debug the issue. I don't want to avoid the standard upstream sync.
linux-firmware:
I believe that the stable firmware files should be copied the linux-firmware repository without special firmware versions for the specific hardware or usage. Only the files which supports the "mainstream" hardware. If maintainers / users for the specific hardware cannot use the firmware files in the standard path used in the driver (auto-detection) they must modify the system configuration anyway (thus I don't see an issue to let them download the special firmware from the "reference" repository).
alsa-topology-conf:
I agreed to include SOF m4 files there. The files should be in sync with the linux-firmware updates.
alsa-ucm-conf:
Sync with the alsa-topology-conf updates. The ALSA release version is the link.
Also I am not clear on what you'd want to do with UCM files, keep them in alsa-conf but with firmware/topology somewhere else?
UCM is a bit abstraction and we can have more abstractions for the one kernel driver / interface. UCM should handle also multiple kernel / topology variants in my opinion. I would keep this as a separate interface.
The main problem seems that we have to deal with the multiple layers and you are afraid that we can have sync issues. I already proposed (I think in May last year) to have a way to determine the exact version used components (firmware, topology). Those values may be printed to the kernel log or exposed via sysfs / proc for the further analysis.
The first reported issues with the SOF driver/firmware show that the first question is what firmware / topology version we are using. Please, make this information visible. It would probably mean to put the SOF release version number to the topology binary files, too.
So basically, my proposal is:
1) create one source (tar ball file, repository tag) per SOF release - all things should be there (firmware, debug files, topologies) 2) push stable / tested mainstream firmware files to linux-firmware - licencing / copyright 3) push topology changes to alsa-topology-conf repo 4) propose UCM fixes to alsa-ucm-conf repo if required for the updated topology files
Jaroslav
-Pierre