Re: [PATCH v4 0/8] iio: adc: new ti-ads112c14 driver

[Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>]

On Tue, 14 Jul 2026 18:21:22 -0500
David Lechner <dlechner@baylibre.com> wrote:

> This adds support for TI ADS112C14 and ADS122C14 ADC chips.
> 

Applied with a couple of tweaks applied as called out in replies
to individual patches.

I thought about bouncing it back to you, but the changes were minor and
I really want to reduce the number of series in process!

Pushed out as testing. Please check it + maybe give those remaining
comments from Sashiko another look.  I think we are fine, but best
to be sure.

Jonathan


> The closest thing we've seen to this in the kernel already is ads124s08.
> However, that has a completely different register map and the DT
> bindings are incomplete and the driver is extremely basic. So I've just
> started from scratch here.
> 
> We've also had a similar submission recently for ADS1220 [1]. That chip
> is in a similar situation to ads124s08 in that it has a different
> register map (but the submitted DT bindings are better than the ones for
> ads124s08, even if still a bit incomplete). And literally as I was
> writing the previous sentence, another series [2]  was sent for yet
> another similar family of chips (ADS1262). That one is even more complex
> in the feature set than the ones I am working on.
> 
> [1]: https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
> [2]: https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
> 
> All of these chips have in common that they are designed for use with
> RTDs and thermocouples and so they look very similar to each other in
> terms of wiring and feature set, even if the register maps are
> different. They are in the gray area where we could either keep them
> separate because they are just different enough, or we could do like
> we've done before with ad_sigma_delta and have a bit of an abstraction
> layer for the register differences and otherwise try to share as much
> code as possible. Normally, I would lean towards keeping them separate,
> but in this case, I'm considering trying to share code because the
> devicetree bindings for the inputs is complex and is going to be mostly
> the same across all of these chips.
> 
> After seeing Kurt's v2 though (that doesn't attempt to share code), it
> seems like the chips are different enough that sharing code might be
> more complicated/messy than I initially thought. So I'm happy to keep
> going that route.
> 
> This series includes just basic support for reading single measurements
> from the ADC and gain selection via the scale attribute. I plan to
> follow this up with additional series to add support for buffered reads,
> filtering/oversampling configuration, event support, gpio controller
> support, burnout support, DRDY interrupt support, DELAY support, CRC
> checking, external clock support.
> 
> The most interesting part about this (that I alluded to above) is the
> way channels are handled. These are multipling ADCs with differential
> and single-ended inputs. But what sets them apart from other similar
> chips is that since they are designed for use with RTDs, there can also
> be a current output required to excite the RTD and this current output
> might be different for different channels. So the way I conceptualized
> the channels is that the devicetree specifies the conditions needed
> to take a particular measurement rather than being purely a physical
> channel.
> 
> This makes things more flexible, but does make the driver a bit more
> complex. For example, knowing when the current output needs to be
> enabled or disabled. For now, I have chosen a lazy-enable where they
> are not turned on until the first measurement is taken that requires
> them, but then they stay on until another measurement is taken that
> doesn't require them. This can lead to some oddness with the diagnostic
> channels that may be measuring something that indirectly requires the
> current output (i.e. the external reference voltage when it is connected
> to a resistor rather than a power supply). This means you need to take
> a measurement that requires the current output to be enabled before the
> diagnostic channels will give accurate readings.
> 
> I have also pushed a branch to [3] that contains the start of some
> documentation for this driver that can give some more insight into how
> the implementation works. It still needs some work and also documents
> some things that haven't been implemented yet, so I haven't included it
> in this series yet.
> 
> [3]: https://github.com/dlech/linux/blob/b4/iio-adc-ti-ads122c14/Documentation/iio/ads112c14.rst
> 
> Signed-off-by: David Lechner <dlechner@baylibre.com>
> ---
> Changes in v4:
> - Kept the review tags on dt-bindings patchs, but made some changes to
>   a few of them that are worth a quick look again just in case.
> - This didn't come up in review of this series, but in other mails on
>   the list, Jonathan has been commenting on improper use of claiming
>   direct mode, so I have added a mutex instead.
> - Fixed use of 64-bit scale storage on big-endian.
> - Removed burnout code (saving for later series).
> - Most other changes were minor/cosmetic. More details in each patch.
> - Link to v3: https://patch.msgid.link/20260710-iio-adc-ti-ads122c14-v3-0-746d52cbf1d0@baylibre.com
> 
> Changes in v3:
> - Mostly cosmetic changes and a few bug fixes to address review feedback.
> - See individual patches for details of changes.
> - Link to v2: https://patch.msgid.link/20260625-iio-adc-ti-ads122c14-v2-0-ceb9b0b561cb@baylibre.com
> 
> Changes in v2:
> - Added patches for adding properties to adc.yaml.
> - Some of these are coming from: https://lore.kernel.org/linux-iio/20260622-new-channel-props-v2-0-aafd5369f253@gmail.com/
> - For now, I have stuck with one channel per single-channel pin or
>   diff-channels pin pair rather than some of the other ideas that were
>   discussed. Handling burn out current enable will be handled in a later
>   series. I'm leaning towards something like the _burnoutraw attribute
>   that Jonathan suggested.
> - See individual patches for details of changes (mostly renaming DT
>   properties, fixing some driver bugs and style issues).
> - Link to v1: https://patch.msgid.link/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com
> 
> ---
> David Lechner (TI) (5):
>       dt-bindings: iio: adc: add input-chopping property
>       dt-bindings: iio: adc: add ti,ads122c14
>       iio: adc: add ti-ads112c14 driver
>       iio: adc: ti-ads112c14: implement gain on internal short SYS_MON channel
>       iio: adc: ti-ads112c14: add measurement channel support
> 
> Kurt Borja (3):
>       dt-bindings: iio: adc: Add reference-sources property
>       dt-bindings: iio: adc: Add excitation current sources properties
>       dt-bindings: iio: adc: Add burn-out current properties
> 
>  Documentation/devicetree/bindings/iio/adc/adc.yaml |   41 +
>  .../devicetree/bindings/iio/adc/ti,ads112c14.yaml  |  217 ++++
>  MAINTAINERS                                        |    7 +
>  drivers/iio/adc/Kconfig                            |   12 +
>  drivers/iio/adc/Makefile                           |    1 +
>  drivers/iio/adc/ti-ads112c14.c                     | 1206 ++++++++++++++++++++
>  6 files changed, 1484 insertions(+)
> ---
> base-commit: aa58ecc73466d0cb8c418de98e2225490bf600e3
> change-id: 20260514-iio-adc-ti-ads122c14-d0b92479334e
> 
> Best regards,
> --  
> David Lechner (TI) <dlechner@baylibre.com>
>