[Sound-open-firmware] about SOF 1.2 topology support

[Keyon Jie]

Hi Liam,

During enabling #1, I found that we may need create snd_soc_dai_driver 
dynamically, currently we only have one cpu_dai for SOF, how do you 
think we should change for multiple cpu_dai support, or we actually 
don't need that?

Thanks,
~Keyon

/*
  * SOF Device Level.
  */
struct snd_sof_dev {
...
	/* ASoC components */
	struct snd_soc_platform_driver plat_drv;
	const struct snd_soc_component_driver *cmpnt_drv;
	struct snd_soc_dai_driver dai_drv; //Liam: we have only one 	dai_driver 
here.
	int num_dai; // Liam: so we can't support > 1 dais here?
...
}

On 2018年05月22日 09:06, Keyon Jie wrote:
> 
> 
> On 2018年05月22日 00:15, Ranjani Sridharan wrote:
>> On Mon, 2018-05-21 at 11:50 +0100, Liam Girdwood wrote:
>>> On Mon, 2018-05-21 at 18:27 +0800, Keyon Jie wrote:
>>>> Hi all,
>>>>
>>>> I am collecting the 1.2 topology support gap and try to figure out
>>>> the
>>>> priority and workload about that, and what I can imagine now are:
>>>>
>>>> 1. Multiple BEs(SSPs) support;
>>>>       This may need add BE definition for SOF from tplg file.
>>>
>>> 1.5 remove DMAC ID and DMAC channel from topology data.
>>
>> This is also in my task list for now.
> 
> Great.
> 
>>
>>>
>>>>
>>>> 2. Reference tplg m4 for different platforms, including
>>>> byt/cht/bdw/hsw/apl/cnl.
>>>>       This may need enable/verify types of pipeline(e.g. src,
>>>> media,
>>>> low-latency) can works separately and stably.
>>>>
>>>> 3. Refine host component buffer size, from pipeline format to pcm
>>>> capability max, and use buffer_set_size in params() for each
>>>> playback/capture.
>>>>       This means we can support different input formats(in the
>>>> capability
>>>> list) with a single tplg file.
>>>>
>>>> 4. Dynamic/hostless pipeline support.
>>>>       We have requirement to switching PCM(FEs) to different BEs at
>>>> runtime, and also host-less(e.g. tone may already support.
>>>> SSP2->SRC->SSP4, ...). we can add kcontrols to control those host-
>>>> less
>>>> pipeline.
>>>> 5. Add a kcontrol for each SSP BE to switch loopback on/off, for
>>>> test
>>>> purpose.
>>
>> I'm not sure there's support for adding kcontrols to BE link widgets in
>> alsa topology atm. You might want to check that.
>>
>>>> ...
>>>>
>>>> I will work on #5, then #1, then #2. I think Yan is working on
>>>> something
>>>> related with #3, and #4 may have dependency to #1.
>>>
>>> Ranjani is looking at #1 iirc.
>>
>> Yes, I'm looking at this, Keyon. I am currently adding support for DMIC
>> in topology and it could take a look at multiple BE's while I am at it.
> 
> good, then I can start #3 directly once #1 is done.
> 
> Ranjani, are you working on it with codec or nocodec?
> 
> Thanks,
> ~Keyon
> 
>>
>>>
>>>>
>>>> Any comment about these are welcomed.
>>>
>>>
>>> Liam
>>>>
>>>> Thanks,
>>>> ~Keyon
>>>>
>>>> _______________________________________________
>>>> Sound-open-firmware mailing list
>>>> Sound-open-firmware at alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar
>>>> e
>>
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware