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

[zhigangw]

On 2018年06月05日 09:19, 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.
>
>> 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.
>
> Thanks,
> ~Keyon
>
The LBM is an engineering mode, from the point of view of product,
we should not expose this engineer mode to end user.
This will introduce trouble. you can not promise the end user will not 
touch it.

Thanks
~zhigang
>>
>>>
>>>> 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