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.
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).
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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
