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

[Jaroslav Kysela]

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
> 


-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.