Re: [PATCH v4 2/3] iio: adc: ti-ads1298: Fix incorrect timeout comment

[<mike.looijmans@topic.nl>]

On 10-05-2026 08:59, Andy Shevchenko wrote:
> On Sat, May 09, 2026 at 03:27:35PM -0500, David Lechner wrote:
>> On 5/9/26 10:19 AM, Md Shofiqul Islam wrote:
>>> At the lowest supported data rate of 250Hz, one conversion period is
>>> 4ms, not 40ms. Fix the comment to correctly reflect the timing.
>>> The 50ms timeout value itself is correct as a conservative margin.
> ...
>
>>> -	/* Cannot take longer than 40ms (250Hz) */
>>> +	/* Cannot take longer than 4ms at the lowest rate (250Hz) */
>>>   	ret = wait_for_completion_timeout(&priv->completion, msecs_to_jiffies(50));
>> I would say "lowest sample rate" so we know which rate it is talking about.
>>
>> However, there could be latency in the kernel delaying the interrupt from
>> firing. The kernel latency can be much larger (I've seen 100s of ms on old
>> single core ARM CPUs). So I think we should mention that in the comment as
>> well so that no one is tempted to set it to msecs_to_jiffies(5) (or 4). Even
>> if that works most of the time on a fast machine, we may need the longer
>> timeout on slower machines.
> Actually it's not about fast/slow machine, it's about scheduler and load.
> Even on the fast machine under heavy load the completion (if it's thread
> based) may take quite a significant time to be delivered. For the hard IRQ
> based completions it might be much better case, but nowadays it's more of
> a niche.

This particular driver uses hard IRQ for delivering the data. At the 
common sampling rate of 500 Hz, it generates interrupts at 1 kHz (each 
cycle needs one for the chip's data ready signal and one for the SPI 
controller).

Although this particular case is the "single read", so there's indeed 
more scheduling involved.

-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl