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

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

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.

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

-- 
Thanks,
 ~ Kurt