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

[Liam Girdwood]

+ Che, Rex and Hui from Canonical

On Tue, 2020-01-07 at 18:33 +0100, Jaroslav Kysela wrote:
> Dne 07. 01. 20 v 17:46 Pierre-Louis Bossart napsal(a):
> 
> > > 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.
> 
> The .conf files can be very easily compared with the original source.
> 
> Basically, I really want to let things to move forward. Everything is
> better 
> than to have the topology configuration in the big repo with all
> other things, 
> so I can accept this, too.
> 
> I had to probably use my time to work on something different than 
> libatopology, but at least I found several problems and did a lot
> of cleanups.
> 
> > 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.
> 
> The packagers should ensure the version sync.
> 

ok, I this should also include the ldc files. I will remove these from
linux-firmware.

This would mean that:-

1) linux-firmware would just contain versioned firmware binaries. Soft
link would link to latest version unless driver quirk or user (via
module param) request earlier version.

2.1) alsa-ucm-conf would contain versioned UCMs

2.2) alsa-ucm-conf would contain versioned topology M4s (local make
rule could build and install tplg binaries). Script could copy tagged
M4 releases from SOF for convenience.

2.3) alsa-ucm-conf would contain LDC files. Copy script ? Probably
better coming from CI as PR as part of a tagged release ?

Question for packagers, how will we version 2.1, 2.2 and 2.3 ? I would
assume via git tag ? 

If so how do we align alsa-ucm-conf release to kernel and SOF releases
? Do the distros keep manifest of "compatible" ingredient versions that
would track this ? I'm guessing the distro maintainer manage this based
on the version of kernel in the distro.

If this is acceptable I will push PRs for linux-firmware and alsa-ucm-
conf 

> > If we don't release them together we'll be in trouble (e.g. if
> > forthe DMIC name changes).
> 
> We are in trouble anyway :-) The new name is not much better (index
> inside
> the control name not respecting the rules in control-names.rst -
> kernel 
> documentation). But I know, someone missed to implement the control
> indexes in 
> the whole ASoC tree ;-) SOC_SINGLE() etc... I'm talking about
> snd_kcontrol_new->index.

Oh, that's probably my bad from 15 years ago !

Liam

> 
> 						Jaroslav
>