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