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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Jun 22, 2020, at 16:41 , Mark Brown <broonie@xxxxxxxxxx> wrote:
> 
> On Mon, Jun 22, 2020 at 04:32:46PM +0300, Pantelis Antoniou wrote:
>>> On Jun 22, 2020, at 15:04 , Mark Brown <broonie@xxxxxxxxxx> wrote:
> 
>>> No, you're encoding use case decisions into the DT here - for example
>>> your example will break use cases like ring tones and shutter sounds
>>> which should play through both speaker and headphones.  It's also
>>> setting volumes which may be inappropriate or may be not and interferes
>>> with userspace using those same physical volume controls.
> 
>> It is completely optional whether you use this functionality or not.
> 
> It's optional for whoever writes the DT and flashes it, it is not
> optional for whoever's doing the OS configuration - these may not be the
> same people.
> 
>> In that case you don’t use the automatic routing you merely set it to off
>> and everything works as before. Or you merely use the route setup for
>> the function from userspace.
> 
> Userspace shouldn't have to be fighting with the kernel for control of
> the device.
> 
>> The device in question is not a mobile phone so there is no requirement
>> to have speaker and headphone active at the same time. It is possible to
>> create a function that would be headphone+speaker active at the same time
>> for that case.
> 
> That may be true for your OS configuration but that doesn't mean that
> some other user of the same hardware won't want to do something that
> needs both simultaneously.

Let’s step back a bit and let me present the problem and what this is about.
Disregard the automatic function selection using external state inputs.

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.

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.

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

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.






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux