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

[Liam Girdwood]

On Mon, 2018-06-04 at 12:05 -0500, Pierre-Louis Bossart wrote:
> 
> On 06/04/2018 11:48 AM, Liam Girdwood wrote:
> > On Mon, 2018-06-04 at 10:08 -0500, Pierre-Louis Bossart wrote:
> > > > > > 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,
> > > this will generate support issues.
> > 
> > We've had this in ALSA/ASoC with the codecs for some while now so most users
> > will do a alsactl or UCM file with good settings. I know it's very easy to
> > change the route with alsamixer/amixer and mute the output, but I think
> > adding
> > one more here probably wont matter that much.
> > 
> > > LBM is only useful in test modes, and
> > > there's no problem generating test configurations.
> > 
> > LBM is very useful for debug/integration usages and it's easier/quicker to
> > ask a
> > user to enable the LBM kcontrol as a test than to modify their topology or
> > use
> > the test topology (which may not be valid for them).
> 
> It's a one-line addition to an alsa-lib .conf file compared to the risk 
> of broken kcontrols when users don't know what they are doing - which is 
> about 80% of support requests. There are just too many people out there 
> playing randomly with amixer/alsamixer and then reporting issues.
> If you still want to go with the kcontrol, then make it conditional on a 
> kernel module parameter to avoid accidental settings.
> Or we could go the debugfs route, with a root controlled access.
> The kcontrol accessible to everyone is just too flaky in my opinion.

I've no issues with a root only kcontrol. This gives protection and allows debug
when needed.

Liam