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

[Jaroslav Kysela]

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.

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....

							Jaroslav

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