thesofproject
load topology for each device
Get device information from dai links. load topology for each device.
This should not impact the existing devices.
Topology PR: https://github.com/thesofproject/sof/pull/9668. I would like to start with SDCA codecs only. SDCA is more urgent than others. If we can create dai links based on the supported SDCA functions, we don't need to use quirks for enabling/disabling specific dai links.
The sof-docs PR is https://github.com/thesofproject/sof-docs/pull/507 and topology PR is https://github.com/thesofproject/sof/pull/9668. @ujfalusi @ranj063 @lgirdwood Could you review? Thanks.
@ranj063
- I didn't say that 1 topology file for each machine is not correct. But loading sub-topologies can significantly reduce our effort to enable a new codec configuration. We added more and more quirks to decide what endpoints are used in the machine. And create topologies for every single audio configuration. Those are not needed if we could detect what dai links should be created and what sub-topologies should be loaded. And, yes, it is more like that user can create a topology just for one device type. Like speakers. And the topology is applicable across platforms.
- Yes, but I hope we can have this feature ASAP as there are more and more quirks/SDW topologies coming. So that I decide to focus on the SDW cards first.
@ranj063 @kv2019i I will implement a card_tplg_ops. So that we can focus on the 'sof-soundwire' card, and it is easily to extend to other cards includes the non-Intel cards.
@ranj063 @kv2019i I will implement a
card_tplg_ops. So that we can focus on the 'sof-soundwire' card, and it is easily to extend to other cards includes the non-Intel cards.
@bardliao sounds good. Do you want to convert this to draft until you have the other solution ready?
@bardliao I still have some fundamental issues with this approach:
- The card_tplg_ops seems like it should belong in the machine driver code and not the SOF core.
- We end up parsing all the sub-topologies and storing all the info in sdev with no distinction that they come from different topologies.
- Error handling: If a sub-topology load fails, you dont seem to unload the first few successfully loaded topologies
@bardliao I still have some fundamental issues with this approach:
- The card_tplg_ops seems like it should belong in the machine driver code and not the SOF core.
IMHO, the whole topology stuff belongs to the component level instead of the card level. That's why it is in the SOF core.
- We end up parsing all the sub-topologies and storing all the info in sdev with no distinction that they come from different topologies.
Yes, my point is that we just put the widgets in different topology files, but they all belong to the same audio system. IOW, they all work together no matter where they are from. I.e. The outcome should be identical no matter we load a monolithic topology or some sub-topologies.
- Error handling: If a sub-topology load fails, you dont seem to unload the first few successfully loaded topologies
Yes, handled in the updated code.
@bardliao, somehow this is now again a bit confusing.
I think we should keep the check in fw-profile for the combine topology file. In the get_tplg_files callback (or in topology.c) we should check the existence of the per function fragments and if any of them is missing fall back to the combined one.
@ujfalusi I think the point that is difficult to get from this PR is that once we have the sub-topologies shipped with sof-bin, we're going to have all fragments available. So checking if the first is available is enough.
But in the fw-profile change the print for tplg name, as we might not load this at all. Hmm, so we should also print the topology files that we are intend to load if it is not the combined one to be able to see and troubleshoot if needed.
I think he does that in the PR as and when each of the topologies is loaded and it will complain when one of them fails to load.
@bardliao looks like there are some legit checkpatch errors. Can you please fix them?