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

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

On Mon Jun 29, 2026 at 8:00 PM -05, Jonathan Cameron wrote:
> 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.

It wouldn't be the end of the world, but it would be confusing without
some documentation or without relying on channel labels.

>> 
>> And if ADC2 is mostly for diagnostics, do we really care about trying
>> to optimize it?

Oh I meant the ADC1 optimization, the ADC2 has no optimization
considerations.

>> 
>> > 
>> > 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.

Yes, the IDAC stuff is the most annoying detail. The datasheet claims:

	All input configurations (channel select, IDAC, level-shift,
	sensor bias) are available to ADC2.

and is technically true, but IDAC configuration is not independent so
it's really up to the driver to make it "available" to ADC2.

My approach for now is to not support the IDACs in the ADC2. This makes
sense for me because I can set a static IDAC output on ADC1 and sample
ADC2 on the side.

I can support it later though, shouldn't be too hard. When ADC1 is
sampling just one channel we can -EBUSY, when there's more than one
channel reads are already synchronized so we can just switch the IDAC
without much trouble.

>
> 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

IMO the ability to buffer read ADC2 at a much lower trigger rate is not
_absolutely necessary_ but it's still very confortable. And although the
code simplification is not that HUGE, it's still significant to me.

> 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!)

All channel properties are independent, except for the IDAC stuff
described above. As for the Sensor Bias (burn-out current stuff), if we
end up only having sysfs sampling (_burnoutraw) then it's not really a
problem.

>
> 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

-- 
Thanks,
 ~ Kurt