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