Re: [PATCH v2 1/7] dt-bindings: iio: adc: Add TI ADS126x ADC family

["Kurt Borja" <kuurtb@gmail.com>]

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.
>> 
>> Each can configure it's own voltage reference source, the two excitation
>> current sources (IDAC), plus input and excitation channels rotation for
>> offset and IDAC mismatch cancellation. This lets the device drive and
>> ratiometrically measure RTDs and other resistive sensors.
>> 
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
>>  .../devicetree/bindings/iio/adc/ti,ads1262.yaml    | 309 +++++++++++++++++++++
>>  MAINTAINERS                                        |   6 +
>>  2 files changed, 315 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1262.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1262.yaml
>> new file mode 100644
>> index 0000000000000000..2f4e812ae2af135a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1262.yaml
>> @@ -0,0 +1,309 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/iio/adc/ti,ads1262.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI ADS1262/ADS1263 analog to digital converter
>> +
>> +maintainers:
>> +  - Kurt Borja <kuurtb@gmail.com>
>> +
>> +description: |
>> +  The ADS1262 and ADS1263 are 38.4-kSPS, delta-sigma (ΔΣ) ADCs with an
>> +  integrated PGA, reference, and internal fault monitors. The ADS1263 integrates
>> +  an auxiliary, 24-bit, ΔΣ ADC intended for background measurements.
>> +
>> +  Datasheets:
>> +    - ADS126x: https://www.ti.com/lit/ds/symlink/ads1262.pdf
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - const: ti,ads1262
>> +      - items:
>> +          - const: ti,ads1263
>> +          - const: ti,ads1262
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  '#address-cells':
>> +    const: 1
>> +
>> +  '#size-cells':
>> +    const: 0
>> +
>> +  spi-max-frequency:
>> +    maximum: 8000000
>> +
>> +  spi-cpha: true
>> +
>> +  interrupts:
>> +    description: Data ready (DRDY) interrupt line.
>> +    maxItems: 1
>
> Technically, there are two pins with the DRDY signal, so we should have
> two interrupts in order to be able to tell which one is wired up.

Oh you're right. I'll describe both here. I may not add support for it
though, at least until I complete everything else.

>
>> +
>> +  start-gpios:
>> +    description: Start conversion control.
>> +    maxItems: 1
>> +
>> +  reset-gpios:
>> +    maxItems: 1
>> +
>> +  dvdd-supply:
>> +    description: Digital power supply.
>> +
>> +  avdd-supply:
>> +    description: Analog power supply.
>> +
>> +  refp-supply:
>> +    description: External positive voltage reference.
>> +
>> +  refn-supply:
>> +    description: External negative voltage reference.
>> +
>
> Which pins are these? I see 4 possible external reference sources,
> but all go through the AINx pins. So I would expect:
>
> 	refp1-supply, refn1-supply, refp2-supply, refn2-supply,
> 	refp3-supply, refn3-supply, refp4-supply, refn4-supply

I tried to go for a simpler route, but I agree with this.

>
> Also, similar to the chip I am working on, I expect that these pins
> could be connected to a resistor rather than a voltage source, so
> could use additional bindings for that.

Sure!

>
>
>> +  ti,vbias:
>> +    $ref: /schemas/types.yaml#/definitions/flag
>> +    description: Enables the level-shift voltage on the AINCOM pin.
>
> VBIAS is a voltage source, so I would expect that to be modeled
> as a regulator provider. (If we do that REFOUT should be included
> as well.)

I didn't think about that, I agree.

>
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  '#io-channel-cells':
>> +    minimum: 1
>> +    maximum: 2
>> +
>> +  '#gpio-cells':
>> +    const: 2
>> +
>> +  gpio-controller: true
>> +
>> +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?

>
>> +      diff-channels:
>> +        description: |
>> +          Selects the analog input configuration for this channel. The first
>> +          value is the positive input and the second is the negative input.
>> +          The following values are available:
>> +          0: AIN0 pin
>> +          1: AIN1 pin
>> +          2: AIN2 pin
>> +          3: AIN3 pin
>> +          4: AIN4 pin
>> +          5: AIN5 pin
>> +          6: AIN6 pin
>> +          7: AIN7 pin
>> +          8: AIN8 pin
>> +          9: AIN9 pin
>> +          10: AINCOM pin
>
>> +          11: Temperature sensor monitor
>> +          12: Analog power supply monitor
>> +          13: Digital power supply monitor
>> +          14: TDAC test signal
>
> These are all internal signals, so not sure it makes sense to have
> them in the devicetree. It would make more sense to have fixed
> channels defined in the driver for these since they are always there.

Similar to the approach you took.

>
> We probably also need a separate property (a bool/flag?) to say that
> this channel is a TDAC output rather than an analog input. Although
> that is for testing, so maybe something to omit for now until we
> actually have an application that uses it (to make sure we get it
> right)?

Yes, I will add the monitor channel for this too. The users can adjust
voltage from debugfs. IMO that should be enough.

>
>
>> +          15: Float (open connection)
>
> How could we have a differential input with one or both pins open?
> Likely this will just be the setting for pins not specified as something
> else in the devicetree.

I should remove this too. Leaving the pins floating is necessary when
calibrating. I will add full automatic calibration on probe right after
this series.

[...]

>> +      ti,idac-chopping:
>
> I would call this ti,excitation-channel-chopping to match the excitation-channel
> property. Or since this isn't a generic property, call it ti,idac-rotation to
> match the datasheet.

Both are fine by me. I went with chopping based on what you said about
the term in your series.

>
>> +        $ref: /schemas/types.yaml#/definitions/flag
>> +        description:
>> +          Automatically swap the IDAC1 and IDAC2 connections of alternate
>> +          conversions. The ADC averages the alternate conversions to eliminate
>> +          IDAC mismatch.
>> +
>> +      ti,pga-bypass:
>> +        $ref: /schemas/types.yaml#/definitions/flag
>> +        description: Bypass the Programmable Gain Amplifier (PGA).
>
> Why would this need to be a DT property? I didn't read this datasheet
> too much, but in other chips I have seen there are usually rules that
> PGA has to be bypassed under certain conditions, but not others, so
> this seems like something for the driver to handle rather than the
> devicetree.

To be honest, I don't know what would be the application for this. AFAIK
when the PGA is bypassed the analog inputs are read unbuffered (?) In
that case shouldn't this belong DT?

[...]

-- 
Thanks,
 ~ Kurt