ASoC topology loading vs card bind
Hi All,
Am trying to load a FrontEnd/pcm dai definition from ASoC topology however I hit a catch 22 situation here. Topology is loaded as part of component probe() but component probe is only called as part of sound-card bind().
Any pointers on how is this supposed to work?
Thanks, srini
On 3/17/2021 4:16 PM, Srinivas Kandagatla wrote:
Hi All,
Am trying to load a FrontEnd/pcm dai definition from ASoC topology however I hit a catch 22 situation here. Topology is loaded as part of component probe() but component probe is only called as part of sound-card bind().
Any pointers on how is this supposed to work?
Thanks, srini
Hi,
I would say I partially described how it works, when writing topology kunit tests, here is link to cover letter: https://lore.kernel.org/alsa-devel/20210120152846.1703655-1-amadeuszx.slawin...
To sum it up, there is no predefined order in which component and card should be created. After each one of them is created ASoC tries to rebind everything together and it should call component probe if everything connects correctly.
I'm not sure what problem you are seeing, but if you look at topology test cases I only define BE in it, no FEs. So I guess you can look at it.
You can also look at skylake (sound/soc/intel/skylake) or SOF (sound/soc/sof/) driver code which are real use cases of topology.
skylake and SOF code have pcm part which creates component and registers probe function responsible for loading topology. Separate part are machine drivers which create card (sound/soc/intel/boards).
On 17/03/2021 17:00, Amadeusz Sławiński wrote:
On 3/17/2021 4:16 PM, Srinivas Kandagatla wrote:
Hi All,
Am trying to load a FrontEnd/pcm dai definition from ASoC topology however I hit a catch 22 situation here. Topology is loaded as part of component probe() but component probe is only called as part of sound-card bind().
Any pointers on how is this supposed to work?
Thanks, srini
Hi,
I would say I partially described how it works, when writing topology kunit tests, here is link to cover letter: https://lore.kernel.org/alsa-devel/20210120152846.1703655-1-amadeuszx.slawin...
Thanks for the link.
To sum it up, there is no predefined order in which component and card should be created. After each one of them is created ASoC tries to rebind everything together and it should call component probe if everything connects correctly.
Probe defer is not the issue here. All the relevant components are successfully probed, however the FE dais did not get chance to register from topology due to the below situation.
I'm not sure what problem you are seeing, but if you look at topology test cases I only define BE in it, no FEs. So I guess you can look at it.
This will work because BE dais are not defined in topology file.
Am trying to load FE dais from topology file along with the graph definition.
Ex: Lets say we have a dai link in soundcard which has cpus->dai_name pointing to an FE dai ("MultiMedia1") available in topology file.
In this situation, sound card will be probed defered unless "MultiMedia1" dai is registered! However "MultiMedia1" dai can only be registered when the ASoC component("X") responsible for loading/reading tplg firmware is component->probed. This component("X") is only component->probed as part of soc_probe_link_components() during card bind.
So we are in catch 22 situation where in dai will not be registered because soc_probe_link_components() will not be called as dai is not registered.
You can also look at skylake (sound/soc/intel/skylake) or SOF (sound/soc/sof/) driver code which are real use cases of topology.
skylake and SOF code have pcm part which creates component and registers probe function responsible for loading topology. Separate part are machine drivers which create card (sound/soc/intel/boards).
Sure, I will dig in and see if I can find anything interesting :-)
--srini
Am trying to load FE dais from topology file along with the graph definition.
Ex: Lets say we have a dai link in soundcard which has cpus->dai_name pointing to an FE dai ("MultiMedia1") available in topology file.
Why would you want to do this? You are hard-coding an FE dailink in the machine driver, when it can be described in the topology.
Look at the SOF machine drivers, they have ZERO FEs hard-coded, precisely because we want the topology to define FEs.
And for legacy machine drivers, we also skip all FE dailinks and only use the ones from the topology.
On Thu, Mar 18, 2021 at 07:40:08AM -0500, Pierre-Louis Bossart wrote:
Lets say we have a dai link in soundcard which has cpus->dai_name pointing to an FE dai ("MultiMedia1") available in topology file.
Why would you want to do this? You are hard-coding an FE dailink in the machine driver, when it can be described in the topology.
Indeed - if the FE is defined entirely by the DSP firmware it seems sensible for the definition to come along with the topology provided with the firmware.
Thanks Pierre for inputs,
On 18/03/2021 12:40, Pierre-Louis Bossart wrote:
Am trying to load FE dais from topology file along with the graph definition.
Ex: Lets say we have a dai link in soundcard which has cpus->dai_name pointing to an FE dai ("MultiMedia1") available in topology file.
Why would you want to do this? You are hard-coding an FE dailink in the machine driver, when it can be described in the topology.
TBH, there is no reason to do that, I was just trying out ASoC topology on QCom platforms :-)
I will give that a go, hopefully that should help!
Look at the SOF machine drivers, they have ZERO FEs hard-coded, precisely because we want the topology to define FEs.
Do you have an example topology for this that I can take as reference?
thanks, srini
And for legacy machine drivers, we also skip all FE dailinks and only use the ones from the topology.
On 18/03/2021 12:40, Pierre-Louis Bossart wrote:
Ex: Lets say we have a dai link in soundcard which has cpus->dai_name pointing to an FE dai ("MultiMedia1") available in topology file. Why would you want to do this? You are hard-coding an FE dailink in the
machine driver, when it can be described in the topology.
By the looks of it, FE DAI and DAI link are created from single PCM object (SectionPCM), so no need to describe it separately.
--srini
participants (4)
-
Amadeusz Sławiński -
Mark Brown -
Pierre-Louis Bossart -
Srinivas Kandagatla