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

[Pan, Xiuli]

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 ?

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
>>