Re: [PATCH 1/2] dt-bindings: sound: Device tree bindings for the apq8039 sound complex

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]

On Mon, Jun 22, 2020 at 05:04:16PM +0300, Pantelis Antoniou wrote:

> The problem is that for sound card that is composed of a number of component
> like this one a pretty non trivial setting of controls must be done.

> Tt is not atypical for a card like this the set of control being a dozen
> or so, with some requiring even more.

> Someone has to do them, be it the kernel or userspace.

This is super standard stuff, it's why UCM (and the Android equivalent)
exist.  There is nothing here that's remarkable or new here, *please*
look at existing solutions before proposing new stuff and (as Stephan
suggested) please don't try to sneak major changes in how things work
into otherwise routine patches.

> Instead of having userspace do it, bundle everything in DT so that everything
> can be set in one go, and without having the user-space engineer read the
> a few 10-100 pages of reference manuals.

Very often in embedded systems the people doing the tuning include
hardware and acoustic engineers for whom dealing with the flexibility of
the device is not an issue but having to reflash and reboot the system
to test out changes is a substantial inconvenience.  I've seen how happy
they can be with userspace configuration options allowing them to speed
up their workflows.  For end users it doesn't really make a huge
difference if the configuration is delivered as part of the firmware or
as part of userspace.

> This is arguably a hardware setting (eg. the set of configuration parameters
> that enables routing sound to speaker).

In all but the simplest systems there are several, frequently many,
options available for even seemingly simple tasks like routing audio to
the speaker.  Deciding between these is something that's well within the
bounds of userspace configurability, it's not like there's only one way
to do things and there may be tradeoffs to be made or combinations of
things to be considered (eg, will we have to mix additional streams in
or route the audio to additional outputs later?).  Transitions between
use cases are also very much part of this, they can often be worked out
automatically but not always.

> Now this is not going to perfect for all cases; some cases are very complicated
> and indeed user-space has to be engaged and perform the configuration.
> This mechanism does not preclude it.

Having multiple uncoordinated mechanisms for doing the same thing in the
same system makes the system more complicated.  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]