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

[Liam Girdwood]

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.

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