Re: [PATCH v2 7/7] iio: adc: Add ti-ads1263-adc2 driver

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 29 Jun 2026 11:38:26 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 6/28/26 3:08 PM, Kurt Borja wrote:
> > On Sun Jun 28, 2026 at 12:22 PM -05, David Lechner wrote:  
> >> On 6/28/26 12:36 AM, Kurt Borja wrote:  
> >>> The TI ADS1263 embeds a second 24-bit delta-sigma ADC (ADC2) with its
> >>> own input mux, reference, gain and sample-rate selection.
> >>>
> >>> Model ADC2 as a separate IIO device on the auxiliary bus: the ti-ads1262
> >>> SPI driver instantiates the auxiliary device and exports a small set of
> >>> TI_ADS1262-namespaced helpers for the conversion and register accesses
> >>> that must go through the shared bus. ADC2 channels are derived from the
> >>> parent's configured channels.
> >>>  
> >> Can these just be additional channels in the main iio device rather
> >> than a separate iio device?  
> > 
> > I guess we can do it, but wouldn't it be quite a mess? I think doing it
> > that way adds a lot of complexity: channel naming, available scan masks
> > (because both ADCs can be sampled at the same time), optimized software
> > sequencing would only work in ADC1 channels, ADC2 doesn't have a DRDY
> > IRQ, etc.  
> 
> Channel naming is easy, e.g. just add 100 to channel and channel2 for
> ADC1 and 200 for ADC2.
> 
> And if ADC2 is mostly for diagnostics, do we really care about trying
> to optimize it?
> 
> > 
> > IMO separating both drivers makes everything simpler, easier to
> > understand and easier to maintain in the future.
> >   
> 
> Sure, I don't have any strong objection to doing this way. We just
> usually try to avoid multiple IIO devices for a single chip. Although
> one of the exceptions to this is when a chip has independent cores.
> I guess this fits that description, although it is a little muddled due
> to sharing the same input pins, sensor bias, IDACs and probably a few
> other things - i.e. doing buffered reads on both cores at the same time
> requires a static IDAC output to avoid issues.

There are (I think) still some gaps in the multibuffer support.
Ideally we'd have long ago solved those, but without that (I think we
can't support different triggers for example) I'm not sure we could do
this as a single device if we support buffered capture.

The question that comes to mind is do the usecases for this 'debug'
ADC need that support?  If it were just sysfs then a single device
would be easy to do.  On the other side, splitting it is up later
isn't something we can easily retrofit.  There is precedence for
multiple devices like this for sensor hubs (also driven by the lack
of complete multibuffer support).  That doesn't hit all the isseus
here though as I can't immediately think of a case where properties
set for one iio_dev effect another (I didn't check though!)

To me the multidevice support is fine - particularly if it's optional
- so the sub driver can be skipped if someone doesn't care about
this extra ADC.

Thanks,

Jonathan