From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Marcelo Schmitt <marcelo.schmitt@analog.com>,
<linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-gpio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<lars@metafoo.de>, <Michael.Hennerich@analog.com>,
<dlechner@baylibre.com>, <nuno.sa@analog.com>, <andy@kernel.org>,
<robh@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<linus.walleij@linaro.org>, <brgl@bgdev.pl>
Subject: Re: [PATCH v4 01/11] dt-bindings: iio: adc: Add AD4170
Date: Mon, 9 Jun 2025 16:44:25 +0100 [thread overview]
Message-ID: <20250609164425.00007a13@huawei.com> (raw)
In-Reply-To: <aEb9uRx_2Hdh0PzX@debian-BULLSEYE-live-builder-AMD64>
On Mon, 9 Jun 2025 12:28:57 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> On 06/07, Jonathan Cameron wrote:
> > On Mon, 2 Jun 2025 08:36:24 -0300
> > Marcelo Schmitt <marcelo.schmitt@analog.com> wrote:
> >
> > > Add device tree documentation for AD4170 and similar sigma-delta ADCs.
> > > The AD4170 is a 24-bit, multichannel, sigma-delta ADC.
> > >
> ...
> > > +
> > > +$defs:
> > > + reference-buffer:
> > > + description: |
> > > + Enable precharge buffer, full buffer, or skip reference buffering of
> > > + the positive/negative voltage reference. Because the output impedance
> > > + of the source driving the voltage reference inputs may be dynamic, RC
> >
> > RC?
>
> Stands for the combination of resistive and capacitive elements in the path
> between the reference supply output and AD4170 REFINn± inputs.
Ah. My head wasn't in the right space at all. RC is common enough term but
I'd still spell it out here as DC is very near as is ADC and the C is different
in all 3 cases :)
resistance/capacitance (RC)
or something along those lines should do the job.
>
> Datasheet Figure 76 shows an example with only capacitive elements, but it could
> have resistive elements too.
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad4170-4.pdf#unique_75_Connect_42_ID8013
>
> I will rephrase to make that clearer. This is probably too long and detailed
> description for a dt property. I can't figure out how to put that in a more
> concise and meaningful way, though.
>
> >
> > > + combinations of those inputs can cause DC gain errors if the reference
> > > + inputs go unbuffered into the ADC. Enable reference buffering if the
> > > + provided reference source has dynamic high impedance output. Note the
> > > + absolute voltage allowed on REFINn+ and REFINn- inputs is from
> > > + AVSS - 50 mV to AVDD + 50 mV when the reference buffers are disabled
> > > + but narrows to AVSS to AVDD when reference buffering is enabled or in
> > > + precharge mode. The valid options for this property are:
> > > + 0: Reference precharge buffer.
> > > + 1: Full reference buffering.
> > > + 2: Bypass reference buffers (buffering disabled).
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + enum: [0, 1, 2]
> > > + default: 1
> >
> ...
> > > +
> > > + adi,excitation-current-0-microamp:
> > > + description:
> > > + Excitation current in microamperes to be applied to pin specified in
> > > + adi,excitation-pin-0 while this channel is active.
> > > + enum: [0, 10, 50, 100, 250, 500, 1000, 1500]
> >
> > What motivated mix of using $ref and here where there is a lot of repetition?
> > I don't mind which approach is used, but a mix seems the worst option.
> >
>
> Because
> $defs:
> ...
> adi,excitation-current-n-microamp:
> description:
> Excitation current in microamperes to be applied to pin specified in
> adi,excitation-pin-0 while this channel is active.
> enum: [0, 10, 50, 100, 250, 500, 1000, 1500]
> default: 0
>
> patternProperties:
> ...
> adi,excitation-current-0-microamp:
> $ref: '#/$defs/adi,excitation-current-n-microamp'
>
>
> triggers dt_binding_check warn:
> patternProperties:^channel@[0-9a-f]$:properties:adi,excitation-current-0-microamp: '$ref' should not be valid under {'const': '$ref'}
> hint: Standard unit suffix properties don't need a type $ref
Fair enough!
J
>
>
> Thanks,
> Marcelo
>
next prev parent reply other threads:[~2025-06-09 15:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-02 11:34 [PATCH v4 00/11] iio: adc: Add support for AD4170 series of ADCs Marcelo Schmitt
2025-06-02 11:36 ` [PATCH v4 01/11] dt-bindings: iio: adc: Add AD4170 Marcelo Schmitt
2025-06-02 12:23 ` Rob Herring (Arm)
2025-06-02 20:52 ` Marcelo Schmitt
2025-06-07 16:33 ` Jonathan Cameron
2025-06-07 16:45 ` Jonathan Cameron
2025-06-09 15:28 ` Marcelo Schmitt
2025-06-09 15:44 ` Jonathan Cameron [this message]
2025-06-02 11:36 ` [PATCH v4 02/11] iio: adc: Add basic support for AD4170 Marcelo Schmitt
2025-06-02 14:55 ` Andy Shevchenko
2025-06-02 16:54 ` Marcelo Schmitt
2025-06-03 8:27 ` Andy Shevchenko
2025-06-03 12:02 ` Marcelo Schmitt
2025-06-03 13:43 ` Andy Shevchenko
2025-06-07 16:59 ` Jonathan Cameron
2025-06-03 14:00 ` kernel test robot
2025-06-02 11:37 ` [PATCH v4 03/11] iio: adc: ad4170: Add support for calibration gain Marcelo Schmitt
2025-06-02 12:54 ` Andy Shevchenko
2025-06-02 11:37 ` [PATCH v4 04/11] iio: adc: ad4170: Add support for calibration bias Marcelo Schmitt
2025-06-02 11:38 ` [PATCH v4 05/11] iio: adc: ad4170: Add digital filter and sample frequency config support Marcelo Schmitt
2025-06-02 11:38 ` [PATCH v4 06/11] iio: adc: ad4170: Add support for buffered data capture Marcelo Schmitt
2025-06-07 17:06 ` Jonathan Cameron
2025-06-09 20:39 ` Marcelo Schmitt
2025-06-02 11:39 ` [PATCH v4 07/11] iio: adc: ad4170: Add clock provider support Marcelo Schmitt
2025-06-02 11:39 ` [PATCH v4 08/11] iio: adc: ad4170: Add GPIO controller support Marcelo Schmitt
2025-06-02 11:39 ` [PATCH v4 09/11] iio: adc: ad4170: Add support for internal temperature sensor Marcelo Schmitt
2025-06-02 11:40 ` [PATCH v4 10/11] iio: adc: ad4170: Add support for weigh scale and RTD sensors Marcelo Schmitt
2025-06-07 17:15 ` Jonathan Cameron
2025-06-02 11:40 ` [PATCH v4 11/11] iio: adc: ad4170: Add timestamp channel 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=20250609164425.00007a13@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=brgl@bgdev.pl \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=marcelo.schmitt@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;
as well as URLs for NNTP newsgroup(s).