From: Jonathan Cameron <jic23@kernel.org>
To: Conor Dooley <conor@kernel.org>
Cc: Marcelo Schmitt <marcelo.schmitt1@gmail.com>,
Marcelo Schmitt <marcelo.schmitt@analog.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org, michael.hennerich@analog.com,
nuno.sa@analog.com, eblanc@baylibre.com, dlechner@baylibre.com,
andy@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, corbet@lwn.net
Subject: Re: [PATCH v2 7/8] dt-bindings: iio: adc: adi,ad4030: Add ADAQ4216 and ADAQ4224
Date: Sat, 27 Sep 2025 16:33:33 +0100 [thread overview]
Message-ID: <20250927163333.55d94113@jic23-huawei> (raw)
In-Reply-To: <20250921-unadvised-uninjured-cdd7a6e6f326@spud>
On Sun, 21 Sep 2025 23:20:01 +0100
Conor Dooley <conor@kernel.org> wrote:
> On Fri, Sep 19, 2025 at 06:12:05PM -0300, Marcelo Schmitt wrote:
> > On 09/19, Conor Dooley wrote:
> > > On Thu, Sep 18, 2025 at 02:39:29PM -0300, Marcelo Schmitt wrote:
> > > > ADAQ4216 and ADAQ4224 are similar to AD4030 except that ADAQ devices have a
> > > > PGA (programmable gain amplifier) that scales the input signal prior to it
> > > > reaching the ADC inputs. The PGA is controlled through a couple of pins (A0
> > > > and A1) that set one of four possible signal gain configurations.
> > > >
> > > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > > ---
> > > > Change log v1 -> v2
> > > > - Use pattern to specify devices that require gain related properties.
> > > > - Disallow gain related properties for devices that don't come with embedded PGA.
> > > > - Documented VDDH and VDD_FDA supplies for ADAQ4216 and ADAQ4224.
> > > > - Updated PGA gain constants.
> > > >
> > > > .../bindings/iio/adc/adi,ad4030.yaml | 65 +++++++++++++++++--
> > > > 1 file changed, 60 insertions(+), 5 deletions(-)
> > > >
> > ...
> > > >
> > > > + pga-gpios:
> > > > + description:
> > > > + A0 and A1 pins for gain selection. For devices that have PGA configuration
> > > > + input pins, pga-gpios should be defined if adi,gain-milli is absent.
> > > > + minItems: 2
> > > > + maxItems: 2
> > > > +
> > > > + adi,pga-value:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > >
> > > How come this is "value" rather than "gain"?
> >
> > Because, for this one, I drew inspiration from ad7191 bindings [1] in the hopes
> > of avoiding creating new properties or using discontinued/deprecated
> > nomenclature [2].
> >
> > The thing is, we now have ADC chips coming with PGA circuitry in front of ADC
> > inputs. Those PGAs are usually set/configured through hardware connections
> > (e.g. dedicated GPIOs or pin-strapped) and have been described in dt-bindings.
> > Though, since these added PGAs don't follow a pattern with respect to the
> > provided gain, different properties began to appear. ad7380 and ad4000 use
> > adi,gain-milli to describe PGA gain [3, 4], ad7191 uses adi,pga-value and,
> > more recently, adaq7768-1 has been proposed with adi,aaf-gain-bp [5].
> > adaq7768-1 is arguably a slightly different case since the signal gain stems
> > from an anti-aliasing filter, but it nevertheless results in signal attenuation
> > much like some PGAs.
> >
> > I personally like the -milli (or even -permille) nomenclature because 4 digits
> > have been more than enough to describe the gains (at least so far). Though, I
> > acknowledge the base points suffix (-bp) which is documented in
> > property-units.yaml [6]. The only thing I don't like much about -bp for
> > describing PGA gain is that PGA gains are often described in terms of unitless
> > scale factors, while bp implies the value to be described as a percent.
> >
> > Anyways, whatever property name is chosen, it will probably be better settle to
> > something rather than arguing about property names each time a new ADC comes
> > with an integrated PGA.
>
> If PGA gains are common, then ye it would make sense to have a standard
> property. I guess one of the problems with doing so is that there isn't
> a standard/common binding for adcs themselves, so without making one
> it'd involve reviewers pushing people to the standard one. I suppose the
> current adc.yaml could be made into adc-channel.yaml and adc.yaml
> repurposed. I bet there are more properties than just PGA gain that
> could go there.
>
> My personal objection to "pga-value" is that it doesn't communicate by
> itself what aspect of the pga it actually controls. I don't really care
> what "unit" qualifier is used that much or if one is used at all. That's
> more of a thing for yourself and other IIO developers to handle.
>
> Part of me is bothered though that all these gains are not in dB! But
> I'd imagine there are not really any ADCs where the registers don't
> deal in unitless gain and using dB would be nothing more than an
> additional headache for software developers.
To me this problem isn't really about PGAs at all. What it is really
about is cases where a pin on a chip is either tied to a gpio or pin strapped.
Can we provide a solution at that layer?
i.e. A way to say this GPIO input is tied high so you can't control it
but you can still read what it's current value is. Maybe there is already
a clean way to do this.
Jonathan
>
> > [1] Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml
> > [2] https://lore.kernel.org/linux-iio/510f6efb-ada3-4848-ac8e-16fa5d1b5284@kernel.org/
> > [3] Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
> > [4] Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml
> > [5] https://lore.kernel.org/linux-iio/46842d4cf2c1149bd64188f94c60ce5e4f3b2beb.1757001160.git.Jonathan.Santos@analog.com/
> > [6] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml
> >
> > >
> > > > + description: |
> > > > + Should be present if PGA control inputs are pin-strapped. The values
> > > > + specify the gain per mille. For example, 333 means the input signal is
> > > > + scaled by a 0.333 factor (i.e. attenuated to one third of it's original
> > > > + magnitude). Possible values:
> > > > + Gain 333 (A1=0, A0=0)
> > > > + Gain 555 (A1=0, A0=1)
> > > > + Gain 2222 (A1=1, A0=0)
> > > > + Gain 6666 (A1=1, A0=1)
> > > > + If defined, pga-gpios must be absent.
> > > > + enum: [333, 555, 2222, 6666]
> > > > +
> >
> > Thanks,
> > Marcelo
next prev parent reply other threads:[~2025-09-27 15:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 17:37 [PATCH v2 0/8] Add SPI offload support to AD4030 Marcelo Schmitt
2025-09-18 17:37 ` [PATCH v2 1/8] iio: adc: ad4030: Fix _scale value for common-mode channels Marcelo Schmitt
2025-09-18 19:32 ` David Lechner
2025-09-20 10:36 ` Jonathan Cameron
2025-09-18 17:38 ` [PATCH v2 2/8] dt-bindings: iio: adc: adi,ad4030: Reference spi-peripheral-props Marcelo Schmitt
2025-09-18 19:39 ` David Lechner
2025-09-19 17:29 ` Conor Dooley
2025-09-19 19:53 ` Marcelo Schmitt
2025-09-20 9:33 ` Jonathan Cameron
2025-09-19 17:33 ` Conor Dooley
2025-09-18 17:38 ` [PATCH v2 3/8] Documentation: iio: ad4030: Add double PWM SPI offload doc Marcelo Schmitt
2025-09-18 19:50 ` David Lechner
2025-09-18 17:38 ` [PATCH v2 4/8] dt-bindings: iio: adc: adi,ad4030: Add PWM Marcelo Schmitt
2025-09-18 19:51 ` David Lechner
2025-09-19 17:34 ` Conor Dooley
2025-09-18 17:38 ` [PATCH v2 5/8] iio: adc: ad4030: Use BIT macro to improve code readability Marcelo Schmitt
2025-09-18 17:39 ` [PATCH v2 6/8] iio: adc: ad4030: Add SPI offload support Marcelo Schmitt
2025-09-19 8:21 ` Nuno Sá
2025-09-20 9:42 ` Jonathan Cameron
2025-09-20 14:43 ` David Lechner
2025-09-22 20:54 ` David Lechner
2025-09-23 15:27 ` Marcelo Schmitt
2025-09-23 16:03 ` David Lechner
2025-09-24 20:23 ` kernel test robot
2025-09-18 17:39 ` [PATCH v2 7/8] dt-bindings: iio: adc: adi,ad4030: Add ADAQ4216 and ADAQ4224 Marcelo Schmitt
2025-09-19 17:36 ` Conor Dooley
2025-09-19 21:12 ` Marcelo Schmitt
2025-09-21 22:20 ` Conor Dooley
2025-09-27 15:33 ` Jonathan Cameron [this message]
2025-09-18 17:39 ` [PATCH v2 8/8] iio: adc: ad4030: Add support for " Marcelo Schmitt
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=20250927163333.55d94113@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=eblanc@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=marcelo.schmitt@analog.com \
--cc=michael.hennerich@analog.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
/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