[Sound-open-firmware] [PATCH 1/2] uapi: ipc: Add lbm in sof_ipc_dai_config

[Pierre-Louis Bossart]

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:
>>> 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)
>> 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 at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware