Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 21 Jun 2026 16:14:57 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 6/21/26 1:41 PM, Jonathan Cameron wrote:
> > On Mon, 15 Jun 2026 16:59:59 -0500
> > "David Lechner (TI)" <dlechner@baylibre.com> wrote:
> >   
> >> Add new bindings for ti,ads122c14 and similar devices.
> >>
> >> This is an ADC that is primarily intended for use with temperature
> >> sensors. There are a few unusual properties because of this. In
> >> particular, the reference voltage source and current output requirements
> >> can be different for each measurement, so these are included in the
> >> channel bindings.
> >>
> >> The REFP/REFN reference voltage is usually just connected to a resistor
> >> that is being driven by the ADC's current outputs, so there is special
> >> property for this case rather than requiring a regulator to be defined
> >> to represent that.
> >>
> >> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> >> have preferred an enum of strings).
> >>
> >> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>  
> > 
> > A few queries inline though I'm only just starting to get my head
> > around this device...
> > 
> > Thanks
> > 
> > Jonathan
> >   
> >> ---
> >>  .../devicetree/bindings/iio/adc/ti,ads112c14.yaml  | 224 +++++++++++++++++++++
> >>  MAINTAINERS                                        |   7 +
> >>  include/dt-bindings/iio/adc/ti,ads112c14.h         |  11 +
> >>  3 files changed, 242 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> new file mode 100644
> >> index 000000000000..dc7f37cad772
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> @@ -0,0 +1,224 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments' ADS112C14 and similar ADC chips
> >> +
> >> +description: |
> >> +  Supports the following Texas Instruments' ADC chips:
> >> +  - ADS112C14 (16-bit)
> >> +  - ADS122C14 (24-bit)
> >> +
> >> +  https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> >> +
> >> +  These chips are primarily designed for use with temperature sensors such as
> >> +  RTDs and thermocouples. The channel bindings reflect this in that each channel
> >> +  represents the conditions required to make a measurement rather than strictly
> >> +  just the physical input channels.
> >> +
> >> +maintainers:
> >> +  - David Lechner <dlechner@baylibre.com>
> >> +
> >> +unevaluatedProperties: false
> >> +
> >> +properties:
> >> +  compatible:
> >> +    enum:
> >> +      - ti,ads112c14
> >> +      - ti,ads122c14
> >> +
> >> +  reg:
> >> +    items:
> >> +      - minimum: 0x40
> >> +        maximum: 0x47
> >> +
> >> +  clocks:
> >> +    maxItems: 1
> >> +    description: Optional external clock connected to GPIO3 pin.
> >> +
> >> +  avdd-supply: true
> >> +  dvdd-supply: true
> >> +
> >> +  refp-supply: true
> >> +  refn-supply: true
> >> +
> >> +  refp-refn-resistor-ohms:
> >> +    description:
> >> +      The resistance of the external resistor between REFP and REFN when using
> >> +      resistor bridge driven by current outputs for RTD measurements.
> >> +
> >> +  interrupts:
> >> +    minItems: 1
> >> +    items:
> >> +      - description: FAULT interrupt (GPIO2 pin)
> >> +      - description: DRDY interrupt (GPIO3 pin)
> >> +
> >> +  interrupt-names:
> >> +    minItems: 1
> >> +    maxItems: 2
> >> +    items:
> >> +      enum: [fault, drdy]
> >> +
> >> +  gpio-controller: true
> >> +  '#gpio-cells':
> >> +    const: 2
> >> +
> >> +  '#address-cells':
> >> +    const: 1
> >> +
> >> +  '#size-cells':
> >> +    const: 0
> >> +
> >> +patternProperties:
> >> +  ^channel@[0-7]$:
> >> +    $ref: adc.yaml
> >> +
> >> +    unevaluatedProperties: false
> >> +
> >> +    properties:
> >> +      reg:
> >> +        maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
> >> +
> >> +      single-channel:
> >> +        maximum: 7
> >> +
> >> +      diff-channels:
> >> +        items:
> >> +          maximum: 7
> >> +
> >> +      bipolar:
> >> +        description:
> >> +          Set this flag if the differential input can be negative.  
> > 
> > I'd leave that description to adc.yaml   Maybe that doc could be improved though
> > given it basically says bipolar == bipolar mode ;)  
> 
> It seems not always obvious to me which properties from adc.yaml apply
> and which ones don't to a given ADC that makes use of it. So I was
> hoping to have some way of saying that bipolar is applicable to this
> chip. 

bipolar: true

should be enough I think.

> 
> >   
> >> +
> >> +      excitation-channels:
> >> +        description: AINx pins used as current output.
> >> +        $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +        minItems: 1
> >> +        maxItems: 2
> >> +        items:
> >> +          maximum: 7
> >> +
> >> +      excitation-current-microamp:  
> > 
> > There seem to be separate controls. Are their usecases where this needs
> > to be in array?  
> 
> I'll have to ask, but probably yes since there are separate controls
> so `maxItems: 2` would be appropriate.
> 
> >   
> >> +        description: The current output of the excitation channels in microamps.
> >> +        minimum: 1
> >> +        maximum: 1000
> >> +
> >> +      current-chopping:
> >> +        $ref: /schemas/types.yaml#/definitions/flag
> >> +        description:
> >> +          If provided, the two excitation channels are to be used with current
> >> +          chopping enabled.  
> > 
> > Can I have a reference for that? My initial read suggests it's the input channels  
> 
> No. :-)
> 
> I must have got two ideas mixed together in my head to come up with
> this. Clearly this should be `input-channel-rotation` or something like
> that (we discussed in another thread already). Also curious if you thing
> any of these properties are common enough to promote to adc.yaml or if we
> should just make them e.g. `ti,input-channel-rotation` (you might not have
> had time to read the threads on that yet).

It's turned up in a couple of drivers and the concept is fairly standard I think
so I'm fine with promoting this to a top level property if the definition can
be generic enough.

For a non TI example, the LTC2893 has this as well for it's thermistor settings.
It might be worth comparing the approach given here with what we have there.
In that case there are specific node types for different types of things that
are wired up with constraints on things like excitation currents.
It kind of constrains things to the sane known use cases.  However that is
partly because that device does (I think) more type specific handling than
we have here.



> 
> > that are chopped.  For GC_EN
> > "When enabled, the device automatically swaps
> > the analog inputs and takes the average of two consecutive conversions to
> > cancel the internal offset voltage"
> > 
> >   
> >> +
> >> +      ti,vref-source:
> >> +        description: |
> >> +          Indicates the source for the reference voltage for this channel.
> >> +          0 - Internal 2.5V reference
> >> +          1 - Internal 1.25V reference
> >> +          2 - External reference (REFP-REFN)
> >> +          3 - AVDD as reference
> >> +
> >> +          For convenience, macros for these values are available in
> >> +          dt-bindings/iio/adc/ti,ads112c14.h.
> >> +        $ref: /schemas/types.yaml#/definitions/uint32
> >> +        maximum: 3
> >> +        default: 0
> >> +
> >> +    dependencies:
> >> +      excitation-channels: [ excitation-current-microamp ]
> >> +      excitation-current-microamp: [ excitation-channels ]
> >> +      current-chopping: [ excitation-channels ]
> >> +
> >> +    oneOf:
> >> +      - required: [ single-channel ]
> >> +      - required: [ diff-channels ]  
> >   
> >> +examples:
> >> +  - |
> >> +    #include <dt-bindings/iio/adc/ti,ads112c14.h>
> >> +
> >> +    i2c {
> >> +        #address-cells = <1>;
> >> +        #size-cells = <0>;
> >> +
> >> +        adc@40 {
> >> +            compatible = "ti,ads112c14";
> >> +            reg = <0x40>;
> >> +
> >> +            avdd-supply = <&avdd>;
> >> +            dvdd-supply = <&dvdd>;
> >> +
> >> +            /* 3-Wire RTD: Two IDACs, One Measurement (AIN1-AIN2) */
> >> +
> >> +            refp-refn-resistor-ohms = <500>;
> >> +
> >> +            #address-cells = <1>;
> >> +            #size-cells = <0>;
> >> +
> >> +            channel@0 {
> >> +              reg = <0>;
> >> +              diff-channels = <1>, <2>;
> >> +              excitation-channels = <0>, <3>;
> >> +              excitation-current-microamp = <500>;
> >> +              current-chopping;
> >> +              ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> +              label = "rtd";
> >> +            };
> >> +        };
> >> +    };
> >> +  - |
> >> +    #include <dt-bindings/iio/adc/ti,ads112c14.h>
> >> +
> >> +    i2c {
> >> +        #address-cells = <1>;
> >> +        #size-cells = <0>;
> >> +
> >> +        adc@40 {
> >> +            compatible = "ti,ads112c14";
> >> +            reg = <0x40>;
> >> +
> >> +            avdd-supply = <&avdd>;
> >> +            dvdd-supply = <&dvdd>;
> >> +
> >> +            /* Resistive Bridge Measurement With a Thermistor for Temperature Compensation*/
> >> +
> >> +            refp-supply = <&avdd>;
> >> +
> >> +            #address-cells = <1>;
> >> +            #size-cells = <0>;
> >> +
> >> +            channel@0 {
> >> +              reg = <0>;
> >> +              diff-channels = <6>, <7>;
> >> +              bipolar;
> >> +              ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> +              label = "bridge";
> >> +            };
> >> +
> >> +            channel@1 {
> >> +              reg = <1>;
> >> +              diff-channels = <1>, <2>;
> >> +              ti,vref-source = <ADS112C14_VREF_SOURCE_INTERNAL_2_5V>;
> >> +              label = "thermistor";  
> > 
> > Hmm. I'm interested to see where this goes, but generally when we have
> > a thermistor we attempt to ultimately convert it to a temperature
> > channel and I'm not seeing info here to allow us to do that.  
> 
> Since the hardware doesn't have any special features for handling
> specific sensor types, it seems like a case of the driver trying to
> do things that the hardware doesn't do, which we generally try to
> avoid in the kernel.
> 
> For cases where we want a quick and easy (and not necessarily accurate)
> temperature conversion done in the kernel, we could make a generic thermistor
> analog front end binding and driver like we already have for RTDs and
> (linear) temperature transducers. This seems more sensible to me rather
> than having to re-implement such a thing in each ADC that could be used
> with a thermistor.

Agreed. That would cover this case.  I'll be honest I thought we had
one already ;)


> 
> >   
> >> +            };
> >> +        };
> >> +    };  
> > 
> >   
>