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

[David Lechner]

On 6/30/26 7:20 PM, Jonathan Cameron wrote:
> On Tue, 30 Jun 2026 13:44:49 -0500
> David Lechner <dlechner@xxxxxxxxxxxx> 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@xxxxxxxxx> 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?

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.

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.

Maybe something like in_voltageY_calibsettlingtime?

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