Liam,
On 04/16/2015 11:48 PM, Liam Girdwood wrote:
It's been about 2 years since posting V1 of the ASoC dynamic firmware patches and a lot has changed since then ...
This RFC series is being posted instead of a V2 patch series atm since we are still completing some testing on the codebase and developing a new userspace tool. Expect V2 once more testing is completed shortly.
ASoC topology (formerly called dynamic firmware) allows audio DSP topology to be defined as part of the firmware package and not hard coded into the driver. This allows DSP vendors to ship multiple different firmwares or firmwares with programmable topologies for different devices (i.e. phones, tablets, TVs) using a single DSP driver. The DSP topology can be contained as part of the firmware file or exist as separate files. The topology core and file format is generic and not tied to any single vendor or device.
The topology core consists of kernel and userspace components :-
Kernel. The kernel core reads in the topology data and builds the driver capabilities and audio topology based on this data. This includes building the DAPM graph, setting PCM and DAI capabilities, registering kcontrols and registering DAPM widgets.
It is not entirely clear for me based on the first look, but who is responsible to initiate the topology load? Is it the component or machine driver? We have had issues with deferred probing when the component driver was in charge of loading the firmware. I got around this by initiating the FW load from the machine driver and via callbacks I notified the component driver to take over from that point. This fixed the probe order and I can also handle cases when the filesystem does not have the firmware so I can fall back to 'legacy' mode.
The userspace tool allows the creation of binary DSP FW topology files based on a topology text files.
Is it possible to get access to the user space part so if I have time I can try to convert the OMAP4/5 AESS/ABE code to use tplg?
Thanks, Péter
Changes since V1:-
o Name changed to ASoC Topology o Structures from soc.h and soc-dapm.h no longer exposed as UAPIs o Moved to component model from codec/platform model. o Added reserved fields in each UAPI structure. o UAPI structures packed and endianess defined for each structure. o Added support for PCM, DAI and codec <-> codec link capabilities. o Added support for client drivers manifests. o Added support for private data for each dynamic object type. o Single list of dynamic objects rather than list of each object type.
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel