[Sound-open-firmware] [PATCH 1/2] uapi: ipc: Add lbm in sof_ipc_dai_config
From: Pan Xiuli xiuli.pan@linux.intel.com
Add loopback mode filed lbm in sof_ipc_dai_config to condif BE dai loobback mode.
Signed-off-by: Pan Xiuli xiuli.pan@linux.intel.com --- Work with patch set: SOF-Kernel: ASoC: SOF: upai: ipc: Add lbm in sof_ipc_dai_config ASoC: SOF: uapi: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode ASoC: SOF: topology: Add topology handler for dai config loopback mode SOF: uapi: ipc: Add lbm in sof_ipc_dai_config IPC: Add IPC handler for dai config loopback mode SOF-Tools: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode topology: m4: Add option for loopback mode in DAI config topology: test: Add loopback topology
test & santity test with: Mininow max rt5651 and UP2 Hifiberry PRO and CNL nocodec SOF master: 65ddcddfcc9a20f5b622cf3ba93dc326387a9d5d SOF-Tool master: 07d290c8ac6026af28bada021ac2215e3453fa88 https://github.com/plbossart/sound/tree/topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f
--- src/include/uapi/ipc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config {
/* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */ - uint16_t reserved; /* alignment */ + uint16_t lbm; /* loopback mode*/
/* HW specific data */ union {
From: Pan Xiuli xiuli.pan@linux.intel.com
Add handler to set loopback mode for dai if loopback mode is set from host.
Signed-off-by: Pan Xiuli xiuli.pan@linux.intel.com --- Work with patch set: SOF-Kernel: ASoC: SOF: upai: ipc: Add lbm in sof_ipc_dai_config ASoC: SOF: uapi: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode ASoC: SOF: topology: Add topology handler for dai config loopback mode SOF: uapi: ipc: Add lbm in sof_ipc_dai_config IPC: Add IPC handler for dai config loopback mode SOF-Tools: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode topology: m4: Add option for loopback mode in DAI config topology: test: Add loopback topology
test & santity test with: Mininow max rt5651 and UP2 Hifiberry PRO and CNL nocodec SOF master: 65ddcddfcc9a20f5b622cf3ba93dc326387a9d5d SOF-Tool master: 07d290c8ac6026af28bada021ac2215e3453fa88 https://github.com/plbossart/sound/tree/topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f
--- src/ipc/handler.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/src/ipc/handler.c b/src/ipc/handler.c index 581ce9e..5142646 100644 --- a/src/ipc/handler.c +++ b/src/ipc/handler.c @@ -401,6 +401,10 @@ static int ipc_dai_config(uint32_t header) return ret; }
+ /* set loopback mode */ + if (config->lbm) + dai_set_loopback_mode(dai, 1); + /* now send params to all DAI components who use that physical DAI */ return ipc_comp_dai_config(_ipc, config); }
On Mon, 2018-06-04 at 14:38 +0800, Xiuli Pan wrote:
From: Pan Xiuli xiuli.pan@linux.intel.com
Add loopback mode filed lbm in sof_ipc_dai_config to condif BE dai loobback mode.
Signed-off-by: Pan Xiuli xiuli.pan@linux.intel.com
Work with patch set: SOF-Kernel: ASoC: SOF: upai: ipc: Add lbm in sof_ipc_dai_config ASoC: SOF: uapi: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode ASoC: SOF: topology: Add topology handler for dai config loopback mode SOF: uapi: ipc: Add lbm in sof_ipc_dai_config IPC: Add IPC handler for dai config loopback mode SOF-Tools: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode topology: m4: Add option for loopback mode in DAI config topology: test: Add loopback topology
test & santity test with: Mininow max rt5651 and UP2 Hifiberry PRO and CNL nocodec SOF master: 65ddcddfcc9a20f5b622cf3ba93dc326387a9d5d SOF-Tool master: 07d290c8ac6026af28bada021ac2215e3453fa88 https://github.com/plbossart/sound/tree/topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f
src/include/uapi/ipc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config {
/* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */
- uint16_t reserved; /* alignment */
- uint16_t lbm; /* loopback mode*/
loopback is not tied to HW config, it can be enabled/disable at runtime so should use the standard IPC for component commands like volume.
Liam
On 6/4/2018 16:34, Liam Girdwood wrote:
On Mon, 2018-06-04 at 14:38 +0800, Xiuli Pan wrote:
From: Pan Xiuli xiuli.pan@linux.intel.com
Add loopback mode filed lbm in sof_ipc_dai_config to condif BE dai loobback mode.
Signed-off-by: Pan Xiuli xiuli.pan@linux.intel.com
Work with patch set: SOF-Kernel: ASoC: SOF: upai: ipc: Add lbm in sof_ipc_dai_config ASoC: SOF: uapi: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode ASoC: SOF: topology: Add topology handler for dai config loopback mode SOF: uapi: ipc: Add lbm in sof_ipc_dai_config IPC: Add IPC handler for dai config loopback mode SOF-Tools: topology: Add SOF_TKN_DAI_LBM for ssp loopback mode topology: m4: Add option for loopback mode in DAI config topology: test: Add loopback topology
test & santity test with: Mininow max rt5651 and UP2 Hifiberry PRO and CNL nocodec SOF master: 65ddcddfcc9a20f5b622cf3ba93dc326387a9d5d SOF-Tool master: 07d290c8ac6026af28bada021ac2215e3453fa88 https://github.com/plbossart/sound/tree/topic/sof-v4.14: 3ffd39334cb53aced88b8aba17cae3df9ee2736f
src/include/uapi/ipc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config {
/* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */
- uint16_t reserved; /* alignment */
- uint16_t lbm; /* loopback mode*/
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used? I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
Thanks Xiuli
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote:
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config {
/* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */
- uint16_t reserved; /* alignment */
- uint16_t lbm; /* loopback mode*/
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
SSp port is represented by AIF widget ? If so, add a kcontrol to it.
Liam
On 6/4/18 4:26 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote:
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config {
/* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */
- uint16_t reserved; /* alignment */
- uint16_t lbm; /* loopback mode*/
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here, this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
SSp port is represented by AIF widget ? If so, add a kcontrol to it.
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Mon, 2018-06-04 at 10:08 -0500, Pierre-Louis Bossart wrote:
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here, this will generate support issues.
We've had this in ALSA/ASoC with the codecs for some while now so most users will do a alsactl or UCM file with good settings. I know it's very easy to change the route with alsamixer/amixer and mute the output, but I think adding one more here probably wont matter that much.
LBM is only useful in test modes, and there's no problem generating test configurations.
LBM is very useful for debug/integration usages and it's easier/quicker to ask a user to enable the LBM kcontrol as a test than to modify their topology or use the test topology (which may not be valid for them).
Liam
On 06/04/2018 11:48 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 10:08 -0500, Pierre-Louis Bossart wrote:
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here, this will generate support issues.
We've had this in ALSA/ASoC with the codecs for some while now so most users will do a alsactl or UCM file with good settings. I know it's very easy to change the route with alsamixer/amixer and mute the output, but I think adding one more here probably wont matter that much.
LBM is only useful in test modes, and there's no problem generating test configurations.
LBM is very useful for debug/integration usages and it's easier/quicker to ask a user to enable the LBM kcontrol as a test than to modify their topology or use the test topology (which may not be valid for them).
It's a one-line addition to an alsa-lib .conf file compared to the risk of broken kcontrols when users don't know what they are doing - which is about 80% of support requests. There are just too many people out there playing randomly with amixer/alsamixer and then reporting issues. If you still want to go with the kcontrol, then make it conditional on a kernel module parameter to avoid accidental settings. Or we could go the debugfs route, with a root controlled access. The kcontrol accessible to everyone is just too flaky in my opinion.
On Mon, 2018-06-04 at 12:05 -0500, Pierre-Louis Bossart wrote:
On 06/04/2018 11:48 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 10:08 -0500, Pierre-Louis Bossart wrote:
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here, this will generate support issues.
We've had this in ALSA/ASoC with the codecs for some while now so most users will do a alsactl or UCM file with good settings. I know it's very easy to change the route with alsamixer/amixer and mute the output, but I think adding one more here probably wont matter that much.
LBM is only useful in test modes, and there's no problem generating test configurations.
LBM is very useful for debug/integration usages and it's easier/quicker to ask a user to enable the LBM kcontrol as a test than to modify their topology or use the test topology (which may not be valid for them).
It's a one-line addition to an alsa-lib .conf file compared to the risk of broken kcontrols when users don't know what they are doing - which is about 80% of support requests. There are just too many people out there playing randomly with amixer/alsamixer and then reporting issues. If you still want to go with the kcontrol, then make it conditional on a kernel module parameter to avoid accidental settings. Or we could go the debugfs route, with a root controlled access. The kcontrol accessible to everyone is just too flaky in my opinion.
I've no issues with a root only kcontrol. This gives protection and allows debug when needed.
Liam
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote:
On 6/4/18 4:26 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote:
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { /* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */ - uint16_t reserved; /* alignment */ + uint16_t lbm; /* loopback mode*/
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here,
Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Thanks, ~Keyon
I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
SSp port is represented by AIF widget ? If so, add a kcontrol to it.
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 2018年06月05日 09:19, Keyon Jie wrote:
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote:
On 6/4/18 4:26 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote:
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { /* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */ - uint16_t reserved; /* alignment */ + uint16_t lbm; /* loopback mode*/
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here,
Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Thanks, ~Keyon
The LBM is an engineering mode, from the point of view of product, we should not expose this engineer mode to end user. This will introduce trouble. you can not promise the end user will not touch it.
Thanks ~zhigang
I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
SSp port is represented by AIF widget ? If so, add a kcontrol to it.
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 06/04/2018 08:19 PM, Keyon Jie wrote:
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote:
On 6/4/18 4:26 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote:
diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h index 9b1063f..06498fb 100644 --- a/src/include/uapi/ipc.h +++ b/src/include/uapi/ipc.h @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { /* physical protocol and clocking */ uint16_t format; /* SOF_DAI_FMT_ */ - uint16_t reserved; /* alignment */ + uint16_t lbm; /* loopback mode*/
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here,
Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
which is a brilliant feature if you need the microphone data for e.g. hangouts or similar VoIP... As discussed with Liam, this is fine with a kcontrol as long as it's not exposed to end users.
this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Good luck with that. We have to add some protection here
Thanks, ~Keyon
I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
SSp port is represented by AIF widget ? If so, add a kcontrol to it.
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 6/5/2018 12:35, Pierre-Louis Bossart wrote:
On 06/04/2018 08:19 PM, Keyon Jie wrote:
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote:
On 6/4/18 4:26 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote:
> diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h > index 9b1063f..06498fb 100644 > --- a/src/include/uapi/ipc.h > +++ b/src/include/uapi/ipc.h > @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { > /* physical protocol and clocking */ > uint16_t format; /* SOF_DAI_FMT_ */ > - uint16_t reserved; /* alignment */ > + uint16_t lbm; /* loopback mode*/ >
loopback is not tied to HW config, it can be enabled/disable at runtime so hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here,
Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
which is a brilliant feature if you need the microphone data for e.g. hangouts or similar VoIP... As discussed with Liam, this is fine with a kcontrol as long as it's not exposed to end users.
this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Good luck with that. We have to add some protection here
OK, let me have a summary here: 1. LBM switch should be bind to each SSP, no question about this. 2. LBM switch should be protect or hidden to end user: debugfs or root access kcontrol (curious about if ALSA have such interface) For the Kcontrol I have some question below:
Thanks, ~Keyon
I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
SSp port is represented by AIF widget ? If so, add a kcontrol to it.
I tried to add mixer for AIF widgets, but DAPM is designed not to expose a kcontrol for AIF widgets. I have seen one of patch in EIG kernel [WORKAROUND] ASoC: dapm: fix stream directions for dsp_loopback links What is this dsp_loopback means here. Maybe I think we may add a dai_link widget for the switch.
Thanks Xiuli
Liam
On Tue, 2018-06-05 at 13:22 +0800, Pan, Xiuli wrote:
On 6/5/2018 12:35, Pierre-Louis Bossart wrote:
On 06/04/2018 08:19 PM, Keyon Jie wrote:
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote:
On 6/4/18 4:26 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote:
> > diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h > > index 9b1063f..06498fb 100644 > > --- a/src/include/uapi/ipc.h > > +++ b/src/include/uapi/ipc.h > > @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { > > /* physical protocol and clocking */ > > uint16_t format; /* SOF_DAI_FMT_ */ > > - uint16_t reserved; /* alignment */ > > + uint16_t lbm; /* loopback mode*/ > > > > loopback is not tied to HW config, it can be enabled/disable at > runtime so > hould use the standard IPC for component commands like volume.
OK, this is done by suggestion from Pierre to not use a kcontrol but a static topology token, So if it is need to be runtime enable/disable. Then a kcontrol or a debugfs should be used?
kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here,
Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
which is a brilliant feature if you need the microphone data for e.g. hangouts or similar VoIP... As discussed with Liam, this is fine with a kcontrol as long as it's not exposed to end users.
this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Good luck with that. We have to add some protection here
OK, let me have a summary here:
- LBM switch should be bind to each SSP, no question about this.
- LBM switch should be protect or hidden to end user: debugfs or root
access kcontrol (curious about if ALSA have such interface)
You could create a debugFS interface that could enable/disable global SOF driver debug mode. Once this is enabled the kcontrols for "DBG SSPn Loopback" would then work.
For the Kcontrol I have some question below:
Thanks, ~Keyon
I tried to use kcontrol but did not know which widget to bind with in the pipeline. The DAPM kcontrol has so many limit. What would you suggest to do with it?
SSp port is represented by AIF widget ? If so, add a kcontrol to it.
I tried to add mixer for AIF widgets, but DAPM is designed not to expose a kcontrol for AIF widgets.
ok, then just create a new vendor tuple that can be attached as private data to the DAI topology object. This tuple "flag" creates a kcontrol in the driver that uses the DAI component ID. In the FW dai.c handles the command and does the LBM or whatever.
I have seen one of patch in EIG kernel [WORKAROUND] ASoC: dapm: fix stream directions for dsp_loopback links What is this dsp_loopback means here. Maybe I think we may add a dai_link widget for the switch.
No idea, I've not seen it.
Liam
Thanks Xiuli
Liam
On 6/5/2018 15:52, Liam Girdwood wrote:
On Tue, 2018-06-05 at 13:22 +0800, Pan, Xiuli wrote:
On 6/5/2018 12:35, Pierre-Louis Bossart wrote:
On 06/04/2018 08:19 PM, Keyon Jie wrote:
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote:
On 6/4/18 4:26 AM, Liam Girdwood wrote:
On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote: >>> diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h >>> index 9b1063f..06498fb 100644 >>> --- a/src/include/uapi/ipc.h >>> +++ b/src/include/uapi/ipc.h >>> @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { >>> /* physical protocol and clocking */ >>> uint16_t format; /* SOF_DAI_FMT_ */ >>> - uint16_t reserved; /* alignment */ >>> + uint16_t lbm; /* loopback mode*/ >>> >> loopback is not tied to HW config, it can be enabled/disable at >> runtime so >> hould use the standard IPC for component commands like volume. > OK, this is done by suggestion from Pierre to not use a kcontrol > but a > static topology token, > So if it is need to be runtime enable/disable. Then a kcontrol or a > debugfs should be used? kcontrol is more flexible since we don't have to change topologies and they should come as standard with all SSP topologies.
I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here,
Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
which is a brilliant feature if you need the microphone data for e.g. hangouts or similar VoIP... As discussed with Liam, this is fine with a kcontrol as long as it's not exposed to end users.
this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Good luck with that. We have to add some protection here
OK, let me have a summary here:
- LBM switch should be bind to each SSP, no question about this.
- LBM switch should be protect or hidden to end user: debugfs or root
access kcontrol (curious about if ALSA have such interface)
You could create a debugFS interface that could enable/disable global SOF driver debug mode. Once this is enabled the kcontrols for "DBG SSPn Loopback" would then work.
For the Kcontrol I have some question below:
Thanks, ~Keyon
> I tried to use kcontrol but did not know which widget to bind with > in > the pipeline. The DAPM kcontrol has so many limit. > What would you suggest to do with it? SSp port is represented by AIF widget ? If so, add a kcontrol to it.
I tried to add mixer for AIF widgets, but DAPM is designed not to expose a kcontrol for AIF widgets.
ok, then just create a new vendor tuple that can be attached as private data to the DAI topology object. This tuple "flag" creates a kcontrol in the driver that uses the DAI component ID. In the FW dai.c handles the command and does the LBM or whatever.
May I use the token SOF_TKN_DAI_LBM to control the driver to create the kcontrol? Another question is about how to create a kcontorl only expose to root only? Or we may only create the kcontrol in #if DEBUG ?
Thanks Xiuli
I have seen one of patch in EIG kernel [WORKAROUND] ASoC: dapm: fix stream directions for dsp_loopback links What is this dsp_loopback means here. Maybe I think we may add a dai_link widget for the switch.
No idea, I've not seen it.
Liam
Thanks Xiuli
Liam
On 6/5/18 3:01 AM, Pan, Xiuli wrote:
On 6/5/2018 15:52, Liam Girdwood wrote:
On Tue, 2018-06-05 at 13:22 +0800, Pan, Xiuli wrote:
On 6/5/2018 12:35, Pierre-Louis Bossart wrote:
On 06/04/2018 08:19 PM, Keyon Jie wrote:
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote:
On 6/4/18 4:26 AM, Liam Girdwood wrote: > On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote: >>>> diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h >>>> index 9b1063f..06498fb 100644 >>>> --- a/src/include/uapi/ipc.h >>>> +++ b/src/include/uapi/ipc.h >>>> @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { >>>> /* physical protocol and clocking */ >>>> uint16_t format; /* SOF_DAI_FMT_ */ >>>> - uint16_t reserved; /* alignment */ >>>> + uint16_t lbm; /* loopback mode*/ >>>> >>> loopback is not tied to HW config, it can be enabled/disable at >>> runtime so >>> hould use the standard IPC for component commands like volume. >> OK, this is done by suggestion from Pierre to not use a kcontrol >> but a >> static topology token, >> So if it is need to be runtime enable/disable. Then a kcontrol or a >> debugfs should be used? > kcontrol is more flexible since we don't have to change topologies > and they > should come as standard with all SSP topologies. I don't really agree here. If a user sets the loopback kcontrol there's no audio any more. "Be careful what you wish for" seems to apply here,
Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
which is a brilliant feature if you need the microphone data for e.g. hangouts or similar VoIP... As discussed with Liam, this is fine with a kcontrol as long as it's not exposed to end users.
this will generate support issues. LBM is only useful in test modes, and there's no problem generating test configurations.
I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Good luck with that. We have to add some protection here
OK, let me have a summary here:
- LBM switch should be bind to each SSP, no question about this.
- LBM switch should be protect or hidden to end user: debugfs or root
access kcontrol (curious about if ALSA have such interface)
You could create a debugFS interface that could enable/disable global SOF driver debug mode. Once this is enabled the kcontrols for "DBG SSPn Loopback" would then work.
For the Kcontrol I have some question below:
Thanks, ~Keyon
>> I tried to use kcontrol but did not know which widget to bind with >> in >> the pipeline. The DAPM kcontrol has so many limit. >> What would you suggest to do with it? > SSp port is represented by AIF widget ? If so, add a kcontrol to it.
I tried to add mixer for AIF widgets, but DAPM is designed not to expose a kcontrol for AIF widgets.
ok, then just create a new vendor tuple that can be attached as private data to the DAI topology object. This tuple "flag" creates a kcontrol in the driver that uses the DAI component ID. In the FW dai.c handles the command and does the LBM or whatever.
May I use the token SOF_TKN_DAI_LBM to control the driver to create the kcontrol? Another question is about how to create a kcontorl only expose to root only? Or we may only create the kcontrol in #if DEBUG ?
kernel module parameter to avoid recompilation, e.g. 'expert-mode=1'?
Thanks Xiuli
I have seen one of patch in EIG kernel [WORKAROUND] ASoC: dapm: fix stream directions for dsp_loopback links What is this dsp_loopback means here. Maybe I think we may add a dai_link widget for the switch.
No idea, I've not seen it.
Liam
Thanks Xiuli
> Liam
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 6/5/2018 20:25, Pierre-Louis Bossart wrote:
On 6/5/18 3:01 AM, Pan, Xiuli wrote:
On 6/5/2018 15:52, Liam Girdwood wrote:
On Tue, 2018-06-05 at 13:22 +0800, Pan, Xiuli wrote:
On 6/5/2018 12:35, Pierre-Louis Bossart wrote:
On 06/04/2018 08:19 PM, Keyon Jie wrote:
On 2018年06月04日 23:08, Pierre-Louis Bossart wrote: > On 6/4/18 4:26 AM, Liam Girdwood wrote: >> On Mon, 2018-06-04 at 16:58 +0800, Pan, Xiuli wrote: >>>>> diff --git a/src/include/uapi/ipc.h b/src/include/uapi/ipc.h >>>>> index 9b1063f..06498fb 100644 >>>>> --- a/src/include/uapi/ipc.h >>>>> +++ b/src/include/uapi/ipc.h >>>>> @@ -345,7 +345,7 @@ struct sof_ipc_dai_config { >>>>> /* physical protocol and clocking */ >>>>> uint16_t format; /* SOF_DAI_FMT_ */ >>>>> - uint16_t reserved; /* alignment */ >>>>> + uint16_t lbm; /* loopback mode*/ >>>>> >>>> loopback is not tied to HW config, it can be enabled/disable at >>>> runtime so >>>> hould use the standard IPC for component commands like volume. >>> OK, this is done by suggestion from Pierre to not use a kcontrol >>> but a >>> static topology token, >>> So if it is need to be runtime enable/disable. Then a kcontrol >>> or a >>> debugfs should be used? >> kcontrol is more flexible since we don't have to change topologies >> and they >> should come as standard with all SSP topologies. > I don't really agree here. If a user sets the loopback kcontrol > there's no audio any more. "Be careful what you wish for" seems to > apply here, Actually not accurate here, there may still be audio which is coming from Tx of the same SSP port, only the audio data from SDI of SSP will be ignored.
which is a brilliant feature if you need the microphone data for e.g. hangouts or similar VoIP... As discussed with Liam, this is fine with a kcontrol as long as it's not exposed to end users.
> this will generate support issues. LBM is only useful in test > modes, > and there's no problem generating test configurations. I agree to add LBM kcontrol for each SSP here, similar to kinds of kcontrols exported by codec driver, they are only for expert, end user should not touch them if they can't understand it.
Good luck with that. We have to add some protection here
OK, let me have a summary here:
- LBM switch should be bind to each SSP, no question about this.
- LBM switch should be protect or hidden to end user: debugfs or root
access kcontrol (curious about if ALSA have such interface)
You could create a debugFS interface that could enable/disable global SOF driver debug mode. Once this is enabled the kcontrols for "DBG SSPn Loopback" would then work.
For the Kcontrol I have some question below:
Thanks, ~Keyon
>>> I tried to use kcontrol but did not know which widget to bind >>> with >>> in >>> the pipeline. The DAPM kcontrol has so many limit. >>> What would you suggest to do with it? >> SSp port is represented by AIF widget ? If so, add a kcontrol >> to it.
I tried to add mixer for AIF widgets, but DAPM is designed not to expose a kcontrol for AIF widgets.
ok, then just create a new vendor tuple that can be attached as private data to the DAI topology object. This tuple "flag" creates a kcontrol in the driver that uses the DAI component ID. In the FW dai.c handles the command and does the LBM or whatever.
May I use the token SOF_TKN_DAI_LBM to control the driver to create the kcontrol? Another question is about how to create a kcontorl only expose to root only? Or we may only create the kcontrol in #if DEBUG ?
kernel module parameter to avoid recompilation, e.g. 'expert-mode=1'?
Discussed with Liam, we agreed to use a debugfs to set debug mode for SOF driver to control the LBM switch.
Thanks Xiuli
Thanks Xiuli
I have seen one of patch in EIG kernel [WORKAROUND] ASoC: dapm: fix stream directions for dsp_loopback links What is this dsp_loopback means here. Maybe I think we may add a dai_link widget for the switch.
No idea, I've not seen it.
Liam
Thanks Xiuli
>> Liam
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
participants (6)
-
Keyon Jie -
Liam Girdwood -
Pan, Xiuli -
Pierre-Louis Bossart -
Xiuli Pan
-
zhigangw