[alsa-devel] [Sound-open-firmware] Signed firmware availability for kbl/cnl

[Liam Girdwood]

On Fri, 2019-08-02 at 10:21 +0200, Jaroslav Kysela wrote:
> Dne 31. 07. 19 v 20:14 Pierre-Louis Bossart napsal(a):
> > On 7/31/19 12:29 PM, Jaroslav Kysela wrote:
> > > Dne 31. 07. 19 v 15:23 Liam Girdwood napsal(a):
> > > > + Mengdong
> > > > 
> > > > On Wed, 2019-07-24 at 18:23 +0200, Jaroslav Kysela wrote:
> > > > > > Yeah, been thinking about this atm. It may be better to
> > > > > > package the
> > > > > > binaries (firmware and topologies) as part of Linux
> > > > > > firmware repo
> > > > > > (since the driver expects to load them all from
> > > > > > lib/firmware) and
> > > > > > package the sources (firmware and topology) via sof tarball
> > > > > > ?
> > > > > 
> > > > > It looks good in my eyes, because topology files are another
> > > > > pieces
> > > > > of the
> > > > > driver from the user space perspective. The unanswered
> > > > > question is
> > > > > the UCM
> > > > > configuration which is linked to the topology configuration
> > > > > (if I
> > > > > understand
> > > > > this correctly). I proposed to place an unique
> > > > > identifier/version to
> > > > > the
> > > > > topology file and propagate this identifier to the user
> > > > > space, so the
> > > > > alsa-lib
> > > > > can pick the right UCM configuration when topology changes.
> > > > > The
> > > > > component
> > > > > string (snd_component_add function / struct snd_ctl_card_info
> > > > > ->
> > > > > components)
> > > > > can be used for this identification.
> > > > 
> > > > Apologizes for the delay, Pierre and I have been discussing
> > > > this
> > > > internally as we have to synchronise the deployment of the
> > > > topologies
> > > > and UCMs alongside the FW.
> > > 
> > > My strong point is that the driver with the different firmware
> > > and the
> > > topology file behaves differently from the user space
> > > perspective. It seems
> > > that there is no way to propagate the firmware (and topology?)
> > > version to the
> > > user space at the moment.
> > 
> > The topology may not be enough, e.g. for all Baytrail devices we
> > use the 
> > same simple topology. To pick the right UCM file you really need
> > the 
> > card information which may include the DMI info or some quirks 
> > (mono-speaker, analog mics). The topology is quite static and
> > doesn't 
> > expose anything that is board-specific or may vary between skews.
> 
> Yes, thus we need to use another UCM file (or make some parts
> conditional in
> the UCM config) depending on this and I would like to pass the exact
> hardware/firmware/topology identification which may affect the UCM,
> through
> the ALSA API to the user space level (UCM parser). Think from the
> packaging
> (Linux distributions) perspective. We have to handle all those
> situations, so
> all the configs, pieces to support all hardware variations must be
> prepared in
> the packages.

I think the UCM parser will currently only bail on cdev naming
differences, so I agree maybe something at the top level UCM "machine
global" level that can be used to check FW, topology (+anything else)
so we could bail earlier or warn and attempt to continue.

> 
> Also, the blind fw / topology / UCM relationship without any
> compatibility
> checks might cause issues when the user upgrades only some parts. The
> binary
> topology files might be packaged with the UCM files as proposed, but
> if an
> incompatible DSP firmware will be loaded (it's placed in the another
> package -
> linux-firmware), it should be reported to the user, too.
> 
> > > > Current thinking has changed from shipping FW + tplg via linux-
> > > > firmware
> > > > repo to only shipping FW binaries in the FW repo and using
> > > > alsa-ucm-
> > > > conf.git for UCMs + topologies (since the coupling between UCM
> > > > and
> > > > topology is tighter than the FW coupling).
> > > 
> > > This is fine, but I think that we should have a check
> > > (compatibility
> > > verification) in the user space level, too. More precisely, each
> > > level should
> > > do a verification if it's compatible with the tied level (driver
> > > -> firmware
> > > -> topology -> ucm).
> > 
> > The SOF driver checks if its supported ABI level is compatible
> > with 
> > firmware and topology levels (both files embed the information,
> > which 
> > doesn't have to be identical).
> 
> Ok, but if you add another functionality to the firmware or remove
> some, it
> might break the compatibility with the topology (different ALSA
> controls for
> example), right? I'm not sure if ABI checks are sufficient. It's more
> about
> the overall sound hardware abstraction for the user space (managed
> ALSA controls).
> 
> > I don't see how UCM would be checked since there's no direct
> > interaction 
> > with the driver, e.g. it's used by PulseAudio or CRAS and the only 
> > interaction is through the control and PCM APIs. Likewise UCM has
> > no> knowledge about topology or firmware.
> 
> The UCM parser code in alsa-lib (not applications) can do the check /
> configuration selection. This is exactly what I am proposing to do.
> Actually,
> for example, the UCM parser looks for sof-skl_hda_card.conf file
> without any
> other checks or conditions. You will agree that we cannot support all
> hardware
> variants with this, because some vendors might use other GPIOs etc..
> 
> So my proposal is to pass all necessary information throught the ALSA
> control
> API (struct snd_ctl_card_info -> components) so the UCM parser can
> pick the
> right config file based on the complete identification. It might
> fallback to
> sof-skl_hda_card.conf, but if new hardware variant exist, the file
> name might
> look like 'sof-skl_hda_card-TOPOLOGYID-VENDORID-PRODUCTID.conf' etc,
> etc....
> 

How would we get topology or FW version from the above identification ?

Would we also use semantic versioning to align the UCM with the
topology and FW ? Currently we use semantic versioning for topology and
FW.

Thanks

Liam