[Sound-open-firmware] about SOF 1.2 topology support
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. 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 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. Any comment about these are welcomed. Thanks, ~Keyon
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.
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 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.
Any comment about these are welcomed.
Liam
Thanks, ~Keyon
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
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.
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.
Any comment about these are welcomed.
Liam
Thanks, ~Keyon
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
On Mon, 2018-05-21 at 09:15 -0700, Ranjani Sridharan wrote:
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 think the intention here is to add an associated kcontrol (not in any audio path/graph) for each SSP. The DAI FW driver will need to register a cmd() callback to support this and maybe a bespoke topology tuple will need to be used to bind the kcontrol to the SSP port. Liam
On 2018年05月22日 03:08, Liam Girdwood wrote:
On Mon, 2018-05-21 at 09:15 -0700, Ranjani Sridharan wrote:
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 think the intention here is to add an associated kcontrol (not in any audio path/graph) for each SSP. The DAI FW driver will need to register a cmd() callback to support this and maybe a bespoke topology tuple will need to be used to bind the kcontrol to the SSP port.
yep, that is what we did for 0.9.5. Thanks, ~Keyon
Liam
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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Mon, 2018-05-28 at 18:24 +0800, Keyon Jie wrote:
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.
The SOF DAI driver is a dummy type, so it has no logic, it's only used for binding DAI links. i.e. it does not matter when used to bind SSP and DMICs.
int num_dai; // Liam: so we can't support > 1 dais here?
Yes, untested.
... }
Liam
On 2018年05月28日 21:43, Liam Girdwood wrote:
On Mon, 2018-05-28 at 18:24 +0800, Keyon Jie wrote:
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.
The SOF DAI driver is a dummy type, so it has no logic, it's only used for binding DAI links. i.e. it does not matter when used to bind SSP and DMICs.
int num_dai; // Liam: so we can't support > 1 dais here?
Yes, untested.
I mean that in snd_soc_register_dais(), it require dai_drv array for count > 1 case, so when setting num_dai > 1, there will be mismatch here and memory invalid access here: soc_add_dai(component, dai_drv + i, count == 1 && legacy_dai_naming) Thanks, ~Keyon
... }
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Tue, 2018-05-29 at 13:26 +0800, Keyon Jie wrote:
I mean that in snd_soc_register_dais(), it require dai_drv array for count > 1 case, so when setting num_dai > 1, there will be mismatch here and memory invalid access here:
soc_add_dai(component, dai_drv + i, count == 1 && legacy_dai_naming)
An array of 1 ? Liam
On 2018年05月29日 23:31, Liam Girdwood wrote:
On Tue, 2018-05-29 at 13:26 +0800, Keyon Jie wrote:
I mean that in snd_soc_register_dais(), it require dai_drv array for count > 1 case, so when setting num_dai > 1, there will be mismatch here and memory invalid access here:
soc_add_dai(component, dai_drv + i, count == 1 && legacy_dai_naming)
An array of 1 ?
I prefer to change it to a pointer as it is not at the end of the structure. Thanks, ~Keyon
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
participants (3)
-
Keyon Jie -
Liam Girdwood -
Ranjani Sridharan