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 Fri, Jun 19, 2020 at 11:41:26PM +0200, Stephan Gerhold wrote:
> Hi Pantelis,
> 
> On Fri, Jun 19, 2020 at 10:38:30PM +0300, Pantelis Antoniou wrote:
> > Add a yaml device binding for the QCOM apq8039 sound complex driver.
> > 
> 
> Nice to see some activity to get sound working on another SoC!
> Thanks for documenting all these properties.

Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.

> > +  function-definition:
> > +    type: object
> > +    description: |
> > +      Functional configuration for the sound complex via a
> > +      simple control. allows fixed and dynamically constructed
> > +      function selection.
> > +
> > +    properties:
> > +      mixer-control:
> > +        $ref: /schemas/types.yaml#/definitions/string
> > +        description: |
> > +          Name of the exported alsa mix control.

This does *not* look like something that should be in a DT binding, it
is quite clearly OS specific.

> > +      system-list:
> > +        $ref: /schemas/types.yaml#/definitions/phandle-array
> > +        description: |
> > +          phandle(s) of the default, init and shutdown functions
> > +          Must be one of the declared ones in the function property.
> > +          The default function is the one selected by default on
> > +          startup (after the init function's sequence is executed).
> > +          On shutdown the shutdown function sequence will be executed.
> > +          Typically init and shutdown are the same and it's purpose
> > +          is to initialize the sound complex mixer controls to the
> > +          all off state, and be ready for a regular function selection.

> This looks much like a replacement for ALSA UCM and userspace audio jack
> detection coded into the device tree.

Very much so.  This is use case configuration and completely
inappropriate for DT.  DT should describe the hardware, the way the OS
intends to use the hardware is up to the OS.

> If you want to discuss ways to integrate mixer enable/disable sequences
> into the device tree, I suggest that you post your ideas separately as
> [RFC] with a more generic subject. That will make it more easy for
> everyone interested to share their thoughts.

> Right now it's quite hidden in a patch set where the subjects suggest
> that it's just a simple machine driver to glue some codecs together.

Indeed, I agree entirely.

Attachment: signature.asc
Description: PGP signature


[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