+int audioreach_tplg_init(struct snd_soc_component *component) +{ + struct device *dev = component->dev; + const struct firmware *fw; + int ret;
+ ret = request_firmware(&fw, "audioreach.bin", dev); + if (ret < 0) { + dev_err(dev, "tplg fw audioreach.bin load failed with %d\n", ret); + return ret; + }
How does this work if you want to change the topology, which will happen rather frequently if you have a framework precisely to change the DSP graph? You need to override a file in userspace?
Shouldn't you have a means to identify what topology file you want on a platform-basis?
Or at the very least a means to change the file name with a kernel parameter or something.
I totally agree, I was planning to do that as a next step. But now that you pointed it out, I can take a look at SOF for some ideas and add it in next version.
Good that we are on the same wavelength.
In initial uses on the Intel side, the kernel could retrieve an identifier from platform firmware (NHLT tables), and then fetch the topology.
snprintf(skl->tplg_name, sizeof(skl->tplg_name), "%x-%.6s-%.8s-%d%s", skl->pci_id, nhlt->header.oem_id, nhlt->header.oem_table_id, nhlt->header.oem_revision, "-tplg.bin");
As a fallback the topology was named "dfw_sst.bin", similar to your "audioreach.bin"
This was fine when the distribution controlled a limited number of builds but was impractical for generic distros which have to figure out what to add in /lib/firmware/
Later on a more generic topology name was added
snprintf(alt_tplg_name, sizeof(alt_tplg_name), "%s-tplg.bin", skl->mach->drv_name);
That's also problematic if the same machine driver can deal with multiple platforms, as we do now.
In SOF we took a different route, we added a topology name in the same tables used to identify a machine driver. Chrome recently added a more specific match when that approach failed to describe the platform, e.g. with the same they now use now have specific DMI matches for e.g. DMI_MATCH(DMI_OEM_STRING, "AUDIO-MAX98373_ALC5682I_I2S_UP4")
It's really hard to find a good solution that provides the means to describe a specific configuration while still bounding the number of topology files that need to be maintained. It's a constant battle in SOF development to try to limit changes or enforce consistency, ironically the additional flexibility that the topology provides is offset by the configuration management.
For DeviceTree platforms, you may be in the same case as the initial Intel approach, it's really easy to have a proliferation of topology file names, which becomes a nightmare to maintain for generic distributions.
BTW if you put information in DeviceTree blobs, it'll be interesting to determine where this information should be: the topology is used by the DSP driver, but it also contains information related to dailinks, which are defined in the machine driver. It's one of the issues I have with the ASoC topology framework: it blurs the layers between DSP and platform support. We're really missing a 'compatibility layer' between the hardware description, that should come from platform firmware, and the DSP topology that can be modified at will. The topology is essentially too flexible and ignores the hardware definition. 90% of our recent topology changes are just to swap interfaces and adjust to hardware changes, it's really painful to maintain, and mistakes are common with the topology referring to dailinks that don't exist.
Hope this helps! -Pierre