public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Saravana Kannan <saravanak@kernel.org>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
Date: Fri, 10 Apr 2026 09:52:42 +0200	[thread overview]
Message-ID: <20260410095242.0826fe7e@bootlin.com> (raw)
In-Reply-To: <CAL_JsqK4SHQS6MciQpLSrGWo2knqs7-eB3yoAv2J54bSfW-Lxg@mail.gmail.com>

Hi Rob, Mark,

On Thu, 9 Apr 2026 10:00:55 -0500
Rob Herring <robh@kernel.org> wrote:

...

> 
> > > If not, then gain-range could be expressed using gain-points instead.  
> >
> > Do you have in mind something like the following?
> >   gain-range = <0 (-300)>, <3 600>;
> >
> > defining the range from -3dB to +6dB with GPIOs value 0 for -3dB and 3 for +6dB.  
> 
> Yes, but since you can have reserved values, that won't work.

In that case gpio-points can be used.

The other solution will be to allow multiple ranges:

   gpios    Gain
   0b000 -> -6dB
   0b001 -> -3dB
   0b010 -> 0dB
   0b011 -> Reserved
   0b100 -> +3dB
   0b101 -> +6dB
   other -> Reserved

This could be described as
  gain-ranges = <0 (-600)>, <2 0>,
                <4 300>, <5 600>;

As a side note, this will probably add quite a lot of complexity to handle
multiple ranges in the driver. If too complex, the driver will handle only
one range and returns -ENOTSUPP if multiple ranges (more than one) are used.

Is that something acceptable?


...
> > > > +    description: |
> > > > +      List of the gain labels attached to the combination of GPIOs controlling
> > > > +      the gain. The first label is related to the gain value 0, the second label
> > > > +      is related to the gain value 1 and so on.
> > > > +
> > > > +      With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > > > +      Assuming that gain value set the hardware according to the following
> > > > +      table:
> > > > +
> > > > +         GPIOs | Hardware
> > > > +         value | amplification
> > > > +         ------+--------------
> > > > +           0   | Low
> > > > +           1   | Middle
> > > > +           2   | High
> > > > +           3   | Max
> > > > +         ------+--------------
> > > > +
> > > > +      The description using gain labels can be:
> > > > +        gain-labels = "Low", "Middle", "High", "Max";  
> > >
> > > Do we need to allow these to be anything? It's going to get hard to come
> > > up with 2^32 names.  
> >
> > Well, "Normal" / "Boost" can make sense on some hardware.
> >
> > I don't think we need to restrict labels to a list of known label here.  
> 
> As long as the names are meaningless to software.
> 
> >
> > Of course 2^32 names is obviously a lot. What could be the limit?  
> 
> I would guess at 8 or more, it's just going to be gain1, gain2, etc.
> or something similar constructed from the gain values.

I suppose that gpio-points or gpio-ranges are going to be used instead
of labels at 8 or more.

With a lot number of GPIOs involved, I am not sure that using labels makes
sense even from the hardware point of view.

The 3 possible descriptions (gpio-points, gpio-range(s), gpio-labels) are
mutually exclusive. Depending on the hardware designed, one of them has to
be chosen.

Of course, you can describe 256 labels but does it make sense in that case
with alternative available ?

> 
> > ...
> >  
> > > > +
> > > > +    /* A mutable amplifier without any gain control */
> > > > +    amplifier4 {
> > > > +        compatible = "audio-gpio-amp";
> > > > +        vdd-supply = <&regulator>;
> > > > +        mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;  
> > >
> > > This case is just simple-amplifier...  
> >
> > No, simple-amplifier uses 'enable' and not 'mute'.  
> 
> Yes, I know...
> 
> > We can have the amplifier enabled ('enable' GPIO active) as it is
> > used and a switch driven by an other GPIO to mute / un-mute the
> > amplifier output.  
> 
> But you have no 'enable' GPIO here. To me, enable just looks like
> inverted mute. If there's some electrical difference, I can't tell
> what that is from either binding.

A known physical component handle by simple-amplifier is the dio2125.

According to its datasheet:
  Pop-free power up is ensured by keeping the EN (shutdown pin) low during
  power down. The EN pin should be kept low EN pin high to achieve pop-less
  power up

The 'enable' gpio should be used when power is established or remove.

The mute gpio handle an output switch:

           +---------+   op-amp output
           | dio2125 +-------------------o
           |         |                        o---- Amplifier feature output
 enable ---+         |                ,--o  ^
           |         |                |     |
           +---------+                v     |
                                     GND    |
                                            |
 mute --------------------------------------'


The mute signal switches on/off the dio2125 output while the dio2125 is
active (powered uup) and so its enable pin is driven high.


I can add an 'enable' GPIO here to handle it in the same way as it is handled in the 
simple-amplifier (dio2125 use case).

> 
> I guess my point was that really we could deprecate simple-amplifier
> binding because this one can handle it and more. But I'm not
> suggesting we do that yet.
> 

Best regards,
Hervé

  parent reply	other threads:[~2026-04-10  7:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 10:16 [PATCH 0/4] ASoC: Add support for GPIOs driven amplifiers Herve Codina
2026-03-30 10:16 ` [PATCH 1/4] of: Introduce of_property_read_s32_index() Herve Codina
2026-04-08  0:21   ` Rob Herring (Arm)
2026-03-30 10:16 ` [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier Herve Codina
2026-04-08 12:29   ` Rob Herring
2026-04-08 13:14     ` Mark Brown
2026-04-08 17:09     ` Herve Codina
2026-04-09 15:00       ` Rob Herring
2026-04-09 15:26         ` Mark Brown
2026-04-10  8:03           ` Herve Codina
2026-04-10 10:28             ` Mark Brown
2026-04-10  7:52         ` Herve Codina [this message]
2026-03-30 10:16 ` [PATCH 3/4] ASoC: codecs: " Herve Codina
2026-03-30 10:16 ` [PATCH 4/4] MAINTAINERS: Add the ASoC gpio amplifier entry Herve Codina
2026-03-30 15:08 ` [PATCH 0/4] ASoC: Add support for GPIOs driven amplifiers Mark Brown
2026-03-30 15:39   ` Herve Codina
2026-03-30 15:48     ` Mark Brown
2026-03-30 16:41       ` Herve Codina
2026-04-05 17:00         ` Christophe Leroy (CS GROUP)
2026-04-06 14:08           ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260410095242.0826fe7e@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=robh@kernel.org \
    --cc=saravanak@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox