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

[Pan, Xiuli]

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
>