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

[Jonathan Cameron <jic23@kernel.org>]

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

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

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