ASoC topology loading vs card bind

ASoC topology loading vs card bind

[Srinivas Kandagatla]

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

Re: ASoC topology loading vs card bind

[Amadeusz Sławiński]

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.slawinski@linux.intel.com/

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).

Re: ASoC topology loading vs card bind

[Srinivas Kandagatla]

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.slawinski@linux.intel.com/ 
> 

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
> 

Re: ASoC topology loading vs card bind

[Pierre-Louis Bossart]

> 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.

Re: ASoC topology loading vs card bind

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC topology loading vs card bind

[Srinivas Kandagatla]

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.

Re: ASoC topology loading vs card bind

[Srinivas Kandagatla]

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