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

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Tue Jun 5 06:35:19 CEST 2018



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



More information about the Sound-open-firmware mailing list