Re: [PATCH v2 1/7] dt-bindings: iio: adc: Add TI ADS126x ADC family
From: Kurt Borja
Date: Sun Jul 26 2026 - 15:49:30 EST
On Tue Jun 30, 2026 at 7:28 PM -05, Jonathan Cameron wrote:
> On Tue, 30 Jun 2026 13:38:30 -0500
> David Lechner <dlechner@xxxxxxxxxxxx> wrote:
>
>> On 6/30/26 12:14 PM, Kurt Borja wrote:
>> > On Mon Jun 29, 2026 at 11:43 AM -05, David Lechner wrote:
>> >> On 6/29/26 11:27 AM, Kurt Borja wrote:
>> >>> On Mon Jun 29, 2026 at 9:21 AM -05, David Lechner wrote:
>> >>>> On 6/28/26 2:12 PM, Kurt Borja wrote:
>> >>>>> On Sun Jun 28, 2026 at 10:45 AM -05, David Lechner wrote:
>> >>>>>> On 6/28/26 12:36 AM, Kurt Borja wrote:
>> >>>>>>> The ADS1262 and ADS1263 are 32-bit, 38.4-kSPS delta-sigma ADCs with an
>> >>>>>>> integrated PGA, internal reference, excitation and burn-out current
>> >>>>>>> sources for sensor biasing and diagnostics. The ADS1263 adds a second,
>> >>>>>>> 24-bit delta-sigma ADC (ADC2) for background measurements.
>> >>>>>>>
>> >>>>
>> >>>> ...
>> >>>>
>> >>>>>>> +
>> >>>>>>> +patternProperties:
>> >>>>>>> + "^channel@[0-9]+$":
>> >>>>>>> + $ref: /schemas/iio/adc/adc.yaml#
>> >>>>>>> + unevaluatedProperties: false
>> >>>>>>> +
>> >>>>>>> + properties:
>> >>>>>>> + reg:
>> >>>>>>> + maxItems: 1
>> >>>>>>> +
>> >>>>>>
>> >>>>>> If we want to allow single-ended/pseudo-differential inputs, then we should
>> >>>>>> also allow single-channel (positive pin) and common-mode-channel (negative
>> >>>>>> pin) properties.
>> >>>>>>
>> >>>>>> This will also require additional common-mode-<N>-supply properties to allow
>> >>>>>> for the negative pin connected to something other than GND.
>> >>>>>
>> >>>>> Ah interesting. Why the N though? wouldn't a single supply connected to
>> >>>>> AINCOM be enough here?
>> >>>>
>> >>>> In theory, any AINx could be a common mode input by connecting it to
>> >>>> a constant voltage supply.
>> >>>
>> >>> Technically yes, but there is a pin named AINCOM intended for this
>> >>> purpose. Can we do a simplification here? I propose having
>> >>>
>> >>> common-mode-channel:
>> >>> /* AINCOM pin */
>> >>> const: 10
>> >>>
>> >>> That way we would only need one common-mode-supply. Would that be okay?
>> >>>
>> >>
>> >> Ideally, we shouldn't limit how the chip can be wired up in the devicetree
>> >> bindings. It doesn't mean that we have to implement everything in the driver
>> >> though.
>
> I'm a bit confused on this. Arguably you could wire up any side of a differential
> pair to a common mode signal, but we haven't had this binding applied more generally
> than cases where their is a setup where the intent is a shared common (shielding
> on cable in some cases IIRC).
>
> So why is this case special? I see AIN_COM can be wired up to an internal vbias
> but other than that it looks like any other AINX input.
Hi,
I forgot to respond to this email!
As you said, there is nothing special about AINCOM, it's just like any
other input. That's why David suggested to have a common-mode-N-supply
for each input.
I implemented this of course, but I still have doubts because there is
no precedent for something like this in IIO. I understand the logic, but
I'll personally be inclined to drop it. If there is no further
discussion I'll keep the 10 common-mode supplies.
I'm finishing v3 and I'll submit it in a couple of days.
>
> Jonathan
>
>> >
>> > Makes sense.
>> >
>> > I just have a doubt: In the ADS112c14 bindings, is there a specific
>> > reason why you didn't describe common-mode-<N>-supply?
>> >
>>
>> For singled-ended inputs on ADS112c14, there is an internal
>> connection to GND, so it isn't possible to have a pseudo-
>> differential input like that. I guess technically, it could
>> still be possible, but wasn't a typical wiring described in
>> the datasheet like it is on ADS1263.
>>
--
Thanks,
~ Kurt