diff mbox series

[2/2] ASoC: dt-bindings: simple-audio-mux: add mux-names property

Message ID 878qyrqbyt.wl-kuninori.morimoto.gx@renesas.com
State Superseded
Headers show
Series ASoC: simple-audio-mux: add mux-name | expand

Checks

Context Check Description
robh/checkpatch success
robh/patch-applied success
robh/dtbs-check warning build log
robh/dt-meta-schema success

Commit Message

Kuninori Morimoto June 27, 2024, 3:52 a.m. UTC
Current simple-audio-mux selects MUX by "Input 1" or "Input 2",
it is not user friendly. Adds new "mux-names" property and enable to
select MUX by own names.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 Documentation/devicetree/bindings/sound/simple-audio-mux.yaml | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Krzysztof Kozlowski June 27, 2024, 7:46 a.m. UTC | #1
On 27/06/2024 05:52, Kuninori Morimoto wrote:
> Current simple-audio-mux selects MUX by "Input 1" or "Input 2",
> it is not user friendly. Adds new "mux-names" property and enable to
> select MUX by own names.
> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  Documentation/devicetree/bindings/sound/simple-audio-mux.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
> index 9f319caf3db7..6e4018936887 100644
> --- a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
> +++ b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
> @@ -24,6 +24,10 @@ properties:
>      description: |
>        GPIOs used to select the input line.
>  
> +  mux-names:
> +    description: |
> +      Name of multiplexers. default is "Input 1", "Input 2"
> +

I have troubles with this binding... It seems driver expects only one
GPIO, but the binding allows any number. Similarly mux-names...

Anyway, this does not look like hardware description but rather
configuration of driver. What's wrong with input 1 or mux 1 or whatever
is there for default?

Also: extend the example.

Best regards,
Krzysztof
Mark Brown June 27, 2024, 11:45 a.m. UTC | #2
On Thu, Jun 27, 2024 at 09:46:29AM +0200, Krzysztof Kozlowski wrote:
> On 27/06/2024 05:52, Kuninori Morimoto wrote:

> > Current simple-audio-mux selects MUX by "Input 1" or "Input 2",
> > it is not user friendly. Adds new "mux-names" property and enable to
> > select MUX by own names.

> > +  mux-names:
> > +    description: |
> > +      Name of multiplexers. default is "Input 1", "Input 2"

> I have troubles with this binding... It seems driver expects only one
> GPIO, but the binding allows any number. Similarly mux-names...

> Anyway, this does not look like hardware description but rather
> configuration of driver. What's wrong with input 1 or mux 1 or whatever
> is there for default?

I would expect that when this driver is deployed it would mainly be for
selecting between things like microphone inputs that are defined and
labelled as part of the system hardware design.  Using numbered inputs
would *work* but it's not great for usability so I do see a use case for
labels.  Possibly we could figure something out by walking the graph but
that seems quite hard, possibly unreasonably so.
Kuninori Morimoto June 27, 2024, 11:08 p.m. UTC | #3
Hi Krzysztof, Mark

> > > Current simple-audio-mux selects MUX by "Input 1" or "Input 2",
> > > it is not user friendly. Adds new "mux-names" property and enable to
> > > select MUX by own names.
> 
> > > +  mux-names:
> > > +    description: |
> > > +      Name of multiplexers. default is "Input 1", "Input 2"
> 
> > I have troubles with this binding... It seems driver expects only one
> > GPIO, but the binding allows any number. Similarly mux-names...
> 
> > Anyway, this does not look like hardware description but rather
> > configuration of driver. What's wrong with input 1 or mux 1 or whatever
> > is there for default?
> 
> I would expect that when this driver is deployed it would mainly be for
> selecting between things like microphone inputs that are defined and
> labelled as part of the system hardware design.  Using numbered inputs
> would *work* but it's not great for usability so I do see a use case for
> labels.  Possibly we could figure something out by walking the graph but
> that seems quite hard, possibly unreasonably so.

Thank you for explaning, Mark

I noticed that the property naming is not so good.
I will fix property name and git-log, and re-post v2.

Thank you for your help !!

Best regards
---
Kuninori Morimoto
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
index 9f319caf3db7..6e4018936887 100644
--- a/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
+++ b/Documentation/devicetree/bindings/sound/simple-audio-mux.yaml
@@ -24,6 +24,10 @@  properties:
     description: |
       GPIOs used to select the input line.
 
+  mux-names:
+    description: |
+      Name of multiplexers. default is "Input 1", "Input 2"
+
   sound-name-prefix: true
 
 required: