Re: [PATCH v4 2/3] iio: adc: ti-ads1298: Fix incorrect timeout comment
From: mike.looijmans
Date: Mon May 11 2026 - 01:20:34 EST
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.
Actually it's not about fast/slow machine, it's about scheduler and load.- /* Cannot take longer than 40ms (250Hz) */I would say "lowest sample rate" so we know which rate it is talking about.
+ /* Cannot take longer than 4ms at the lowest rate (250Hz) */
ret = wait_for_completion_timeout(&priv->completion, msecs_to_jiffies(50));
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.
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@xxxxxxxx
W: www.topic.nl