[Sound-open-firmware] [PTACH RFC 0/5] Add switch widget for loopback

[Pan, Xiuli]

Hi Liam,

Ping for RFC.

This is my previous kcontrol solution for topology part.

Does this can work with the runtime switch to loopback mode?


On 6/1/2018 11:24, Pan, Xiuli wrote:
>
>
> On 6/1/2018 07:15, Ranjani Sridharan wrote:
>> On Thu, 2018-05-31 at 16:08 -0500, Pierre-Louis Bossart wrote:
>>> On 5/31/18 12:37 PM, Ranjani Sridharan wrote:
>>>> On Thu, 2018-05-31 at 07:55 -0500, Pierre-Louis Bossart wrote:
>>>>> On 5/30/18 9:08 PM, Pan, Xiuli wrote:
>>>>>>
>>>>>> On 5/30/2018 21:06, Pierre-Louis Bossart wrote:
>>>>>>> On 5/30/18 4:51 AM, Xiuli Pan wrote:
>>>>>>>> From: Pan Xiuli <xiuli.pan at linux.intel.com>
>>>>>>>>
>>>>>>>> Have some clean up for the code may used.
>>>>>>>> Add some macros that are needed for the switch widget.
>>>>>>>> TODO: Have the useable get/put function for the kcontrol.
>>>>>>>>
>>>>>>>> Pan Xiuli (5):
>>>>>>>>      topology: mixer: Add CONTROLMIXER_MIN
>>>>>>>>      topology: utils: Add kdapm macro for route with
>>>>>>>> kcontrol
>>>>>>>>      topology: m4: add switch widget
>>>>>>>>      topology: sof: add pipeline loopback dai
>>>>>>>>      topology: test: add loopback test topology
>>>>>>> What do you mean by "loopback"?
>>>>>>> a) enabling capture on SSP with hardware LBM (LoopBackMode) -
>>>>>>> mirroring the playback data?
>>>>>>> b) enabling a capture-to-playback hostless pipeline -
>>>>>>> mirroring
>>>>>>> the
>>>>>>> capture data?
>>>>>> I think the it should be the a). This will try to enable SSP
>>>>>> driver
>>>>>> loopback mode with a kcontrol.
>>>>> Not sure if it's wise to expose a kcontrol to users for what is
>>>>> largely
>>>>> a test capability - not to mention that you will not typically
>>>>> turn
>>>>> this
>>>>> on/off dynamically.
>>>>> I'd suggest looking into using the topology+IPC to enable such
>>>>> custom
>>>>> tests.
>>>> If it is not needed to turn this ON/OFF dynamically, then could we
>>>> possibly just use a test FW with loopback mode enabled by default
>>>> instead? That way we can avoid the extra work on the
>>>> topology/driverside.
>>> It's one token and one field in the IPC structure, with no framework
>>> change.
>>> Compare that with requiring everyone to create a custom firmware
>>> when
>>> they want to test if the output looks correct...
I take Pierre's suggestion with the TOKEN version.

Thanks
Xiuli
>> Fair enough. I think topology is certainly the way to go.
>>
>> Xiuli, now that you dont need a kcontrol, are you still going to work
>> on that patch with a generic switch IO handler? Or should I take care
>> of it?
>
> I think Pierre give me another solution for this loopback mode.
> I would like to do a cleanup for the topology with kcontrol. But I 
> think it is not in high priority right now.
> We can have a sync later about how to make all kinds kcontrol work 
> with topology.
>
> Thanks
> Xiuli
>
>>>>>
>>>>>> Maybe we can try to make the b) also work.
>>>>>>
>>>>>> Thanks
>>>>>> Xiuli
>>>>>>>
>>>>>>>> topology/m4/mixercontrol.m4               | 16 ++++--
>>>>>>>>     topology/m4/switch.m4                     | 46
>>>>>>>> +++++++++++++++
>>>>>>>>     topology/m4/utils.m4                      |  4 ++
>>>>>>>>     topology/sof/pipe-dai-loopback.m4         | 36
>>>>>>>> ++++++++++++
>>>>>>>>     topology/sof/pipe-low-latency-capture.m4  |  3 +-
>>>>>>>>     topology/sof/pipe-low-latency-playback.m4 |  2 +
>>>>>>>>     topology/sof/pipe-pcm-media.m4            |  1 +
>>>>>>>>     topology/sof/pipe-tone.m4                 |  2 +
>>>>>>>>     topology/sof/pipe-volume-capture.m4       |  1 +
>>>>>>>>     topology/sof/pipe-volume-playback.m4      |  1 +
>>>>>>>>     topology/test/test-loopback-ssp.m4        | 94
>>>>>>>> +++++++++++++++++++++++++++++++
>>>>>>>>     topology/test/tplg-build.sh               |  2 +-
>>>>>>>>     12 files changed, 201 insertions(+), 7 deletions(-)
>>>>>>>>     create mode 100644 topology/m4/switch.m4
>>>>>>>>     create mode 100644 topology/sof/pipe-dai-loopback.m4
>>>>>>>>     create mode 100644 topology/test/test-loopback-ssp.m4
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Sound-open-firmware mailing list
>>>>>> Sound-open-firmware at alsa-project.org
>>>>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-fir
>>>>>> mwar
>>>>>> e
>>>>> _______________________________________________
>>>>> Sound-open-firmware mailing list
>>>>> Sound-open-firmware at alsa-project.org
>>>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmw
>>>>> are
>>>> _______________________________________________
>>>> Sound-open-firmware mailing list
>>>> Sound-open-firmware at alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar
>>>> e
>>>>
>>>
>> _______________________________________________
>> 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