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

[Andy Shevchenko]

On Mon, May 11, 2026 at 07:20:04AM +0200, mike.looijmans@xxxxxxxx wrote:
> 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:

...

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

Does it set completion done at the interrupt handler?

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

Still, there are cases like PREEMPT_RT and threadirqs that makes this all
threaded.

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

-- 
With Best Regards,
Andy Shevchenko