Re: ASoC: soc-pcm2.c ?

[Takashi Iwai <tiwai@suse.de>]

On Tue, 03 Feb 2026 19:17:15 +0100,
Mark Brown wrote:
> 
> On Tue, Feb 03, 2026 at 06:07:00PM +0000, Liam Girdwood wrote:
> > On 2/3/26 06:27, Kuninori Morimoto wrote:
> 
> > > Whether having default volume or not should not mandatory, should be just
> > > option. We want to have flexible framework, like some board want to use same
> > > style as before (= setup full routing etc via amixer), and/or some board want
> > > to have default routing/volumes, etc.
> 
> > I think hiding any kcontrols or hard coding kcontrols that change audio
> > processing or routing will break all client use cases, yes this may be nice
> > on IoT where there is no sound server or userspace audio infra and very
> > simple audio is needed, but on client we need the soundserver e.g. Pipewire,
> > CRAS or audio HAL to configure and control the use case/policy.
> 
> Yeah, we need anything in this area to be some combination of opt in and
> focused more on trying to pick defaults so there's less need to write
> and distribute UCM configurations for trivial cases.  The things we can
> do safely for everyone are pretty limited, things like hiding controls
> that we know through routing to disconnected pins can never possibly be
> part of a valid path (I always wanted to do that...) for example.

That's a topic that has been discussed since many many years ago :)
Making all setups controllable via kconfig (that is user-space) is one
of key concepts in ASoC, but certainly that shows too much details to
anyone on the system.

Basically it should be relatively easy to implement a mechanism to
make kcontrols invisible, though; e.g. by introducing a new kcontrol
flag like SNDRV_CTL_ELEM_ACCESS_INVISIBLE, and some machine drivers or
codec drivers may set it up depending on the demands.
But justification to do that would become rather a bigger question.


thanks,

Takashi