Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: David Lechner
Date: Sun Jun 21 2026 - 17:15:14 EST
On 6/21/26 1:41 PM, Jonathan Cameron wrote:
> On Mon, 15 Jun 2026 16:59:59 -0500
> "David Lechner (TI)" <dlechner@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxx>
>> +
>> +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.
>
>> +
>> + 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).
> 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.
>
>> + };
>> + };
>> + };
>
>