Just a follow up thought - but how does it work for getting your hands on devices for the ALSA project? Is there somewhere Lenovo could maybe look at donating a unit too to help out?
Note - I don't have any authority to actually make such an offer - but I can look into it if it would be useful...
Thanks Mark
-----Original Message----- From: Sound-open-firmware <sound-open-firmware-bounces@alsa- project.org> On Behalf Of Mark Pearson Sent: Friday, October 25, 2019 9:56 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; Uimonen, Jaska jaska.uimonen@intel.com; sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: SOF firmware and topology files
Mark, I'm currently putting together / testing the sof ucm for Dell and
Lenovo devices.
Unfortunately I've not yet received the X1 (it is shipped to me). So ucm's
for
Dell and Lenovo will be in alsa-ucm-conf repository, Jaroslav has already
done
Some differentiation to handle Lenove differences.
Please do feel free to beat me up if you need anything tested - very happy to help out. I've been testing the current .conf file and it was good.
Pierre, actually I'm not sure how the topology differentiation will be
done?
So for example can we load different topology in these 2 manufacturers
device?
So if it is just overwriting the new topology with same name, how to
differentiate?
I hadn't really appreciated it could be different per device....which now I see it stated seems more obvious. I definitely need to understand these files better
The topology should change only if the firmware changed, e.g. with the addition of a processing, path or secret sauce that's not in the default firmware released by Intel.
We have a default topology file path which can be modified with a kernel module parameter (see in sof-pci-dev.c), and we could also add DMI quirks to do this change as well. The file name would be identical, just located in a different directory (and not necessarily in /lib/firmware/intel/sof-tplg).
If an OEM decided to make changes to the topology, I'd guess they are on the hook to provide such changes to downstream distros? I am not sure we can manage all possible variations in a central repo, it's hard enough to provide all the default pieces already...
That sounds reasonable to me, I just might need some help getting to the stage where I can build the first topology file that works. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware