Introduce two DT properties in dsp node: * fw-filename, optional property giving the firmware filename (if this is missing fw filename is read from board description) * tplg-filename, mandatory giving the topology filename.
These sound entirely like operating system configuration which I'd expect to be inferred from the machine identification. What happens if a system has multiple options for firmware files, or if the OS ships the topology and firmware bundled up in a single image to avoid them getting out of sync? What's the benefit of putting them in the DT?
Can you help me with this, specifically for selecting topology name.
I think I'm fine selecting a default value for SOF firmware name. It looks like even for Intel platforms there is no way of changing the firmware name.
But how about selecting topology name? We have lots of audio scenarios that can run on the exact same hardware:
- e.g
- Audio PCM playback + Post Processing
- Audio Compress playback
- Keyword detection
So, we need to use different topologies to select the scenario we want to demonstrate.
Would it be acceptable to add tplg_name as a module parameter?
we already have a "tplg_path" module parameter which was intended to differentiate between product skews/versions using the same hardware and firmware version. A typical example would be an OEM using 'public' firmware + topology for basic audio support, distributed through sof-bin and packaged by distros, and 3rd-party/closed sources firmware modules in more advanced packages distributed separately by the OEM. In the latter case you do want the same path for firmware and topology, otherwise you'd have a risk of using a topology making references to a library not bundled in the firmware.
There was an initial ask from Curtis to have the ability to override the firmware/topology names, but they've been able to work with the path parameters - set with udev rules for specific models.
If you wanted to demonstrate 'scenarios', you could use the same approach?
Two other points to reply to Mark:
- we currently don't support 'shipping the topology and firmware bundled up in a single image to avoid them getting out of sync'. No idea how that might work.
- if the machine driver is specified in DeviceTree, then the topology used is *required* to be aligned with the machine driver. The rules are that a topology may not make references to a BE dailink exposed in the machine driver, but conversely if the topology makes a reference to a BE dailink that is not exposed in the machine driver the topology parsing will fail. It's one of the current weaknesses of topology-based solutions, we have non-configurable hardware-related things that are described in topology but should really be described in platform firmware, be it ACPI or DT, and provided to the topology.