Re: [PATCH v2 5/7] iio: adc: ti-ads1262: Add conversion delay support

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 06 Jul 2026 20:38:45 -0500
"Kurt Borja" <kuurtb@gmail.com> wrote:

> On Mon Jul 6, 2026 at 12:23 PM -05, Jonathan Cameron wrote:
> > On Mon, 6 Jul 2026 11:19:40 -0500
> > David Lechner <dlechner@baylibre.com> wrote:
> >  
> >> On 6/30/26 7:20 PM, Jonathan Cameron wrote:  
> >> > On Tue, 30 Jun 2026 13:44:49 -0500
> >> > David Lechner <dlechner@baylibre.com> wrote:
> >> >     
> >> >> On 6/30/26 12:23 PM, Kurt Borja wrote:    
> >> >>> On Mon Jun 29, 2026 at 7:50 PM -05, Jonathan Cameron wrote:      
> >> >>>> On Sun, 28 Jun 2026 00:36:06 -0500
> >> >>>> Kurt Borja <kuurtb@gmail.com> wrote:
> >> >>>>      
> >> >>>>> Expose the programmable conversion start delay as a per-channel
> >> >>>>> IIO_CHAN_INFO_CONVDELAY attribute.      
> >> >>>> Coversion delay was always a somewhere weird bit of ABI.
> >> >>>> What are the delays relative to in this case?
> >> >>>> Is this a device that does simultaneous sampling?  Pictures
> >> >>>> suggest otherwise, and convdelay is currently only defined
> >> >>>> in that case.  We might be able to extend it but it needs
> >> >>>> some thought.      
> >> >>>
> >> >>> The chip has a configurable internal conversion delay to allow for
> >> >>> external settling effects. See datasheet section 9.4.3 if you'd like a
> >> >>> bit more details.      
> >> >>
> >> >> Since this depends on external components, it sounds like it belongs
> >> >> in the devicetree. I have the same feature in the chip I am working
> >> >> on and was just looking at this and plan to add it to the ti,ads112c14
> >> >> devicetree patch.
> >> >>
> >> >> This delay only applies to a "new conversion", i.e. when certain config
> >> >> registers change, and not every conversion, so isn't like the convdelay
> >> >> attribute.    
> >> > 
> >> > See settling-time-us in adc.yaml.  I'd forgotten we had that ;)    
> >> 
> >> I got some more feedback on this and this may indeed be something we
> >> want to tune at runtime after all.
> >> 
> >> I'm not really sure where it fits in though. On AD112C14 that I am working
> >> on, the DELAY register value adds a delay (for settling time) in addition
> >> to some other intrinsic delays. I'm pretty sure ADS1262 is similar.  
> 
> It is! there is a fixed 52 usecs delay after starting conversions.
> 
> >> 
> >> So one question is do we want a usespace control to be the total delay
> >> or just the additional delay?
> >>   
> >
> > Total I think.
> >  
> >> And when the delay takes effect depends on other things. Normally the
> >> delay only happens before the first sample after any other parameters
> >> change. If we read the same channel again with the same config, then
> >> there won't be any added delay. But if input chopping is enabled, then
> >> this delay happens on every conversion.  
> >
> > Hmm. That is awkward.  I guess the best we could do is either to document
> > it as 'may be skipped if channel setup is unchanged either via explicit
> > channel or parameter change, or via chopping'.  I kind of think of chopping
> > as advanced channel sequencing - inX-inY being switched to inY-inX with a scale
> > *= -1.  
> 
> Thinking about it this way, shouldn't there be userspace control for the
> chopping stuff too? Something like in_voltageY_chop_type, similar to the
> filter type.

Good point.  Until this came up I was thinking that there was no disadvantage
to chopping if it made sense for what was being measured, but here we can
see we are trading off acquisition rate.  That might be something we can
stall for a follow up though as to me turning it off will 'mostly'
be the wrong thing to do and hence adding control of that a feature.

> 
> >  
> >> 
> >> I'm a bit on the fence of if we should extend the definition of convdelay
> >> for this or if we should propose a new settling time attribute. I'll have
> >> to think about it some more.  
> > Smells different enough that we shouldn't smash the two together.  
> >> 
> >> Maybe something like in_voltageY_calibsettlingtime?  
> >
> > calib might be reasonable if it was a tweak to a fixed settling time
> > and like other calib stuff would not necessarily have any scaling.
> >
> > If it's the whole thing and in seconds then in_voltageY_settlingtime 
> > should be enough I think.  
> 
> +1 for this. in_voltageY_settlingdelay might work too, as both our
> datasheets call it "delay".
> 
> >
> > Jonathan
> >  
> >>   
> >> >     
> >> >>    
> >> >>>
> >> >>> But you're right, I should at least also edit the ABI description of
> >> >>> this attribute. We can postpone this discussion for a future series.
> >> >>>       
> >> >>>>
> >> >>>> Jonathan      
> >> >>>       
> >> >>    
> >> >     
> >>   
>