Re: [PATCH] staging: fbtft: fb_upd161704: replace udelay with usleep_range
From: Andy Shevchenko
Date: Wed Sep 16 2026 - 11:24:34 EST
On Wed, Sep 16, 2026 at 03:08:06PM +0300, Ömer PALA wrote:
> On Wed, Sep 16, 2026 at 12:39:28PM +0300, Andy Shevchenko wrote:
...
> Second, do you understand the difference on what
> code is doing before and after your change?
> I understand that udelay() provides deterministic, busy-wait timing required for
> hardware register initialization, whereas usleep_range() introduces scheduler
> overhead and non-deterministic delays.
> Out of technical curiosity regarding the driver IC: theoretically, if we knew
> the exact window between the hardware lock/stabilization
> time (min) and the internal state-machine timeout (max) from the datasheet,
> would a range like usleep_range(min, max) be acceptable,
> or does scheduler wake-up latency make it too risky for
> timing-critical init sequences without hardware validation?
> I will drop this patch series.
It's not only about timings, longer sleeps most likely are fine, the main
problem is atomicity.
...
Note, your reply is malformed. Choose proper tools to communicate in
the Linux kernel mailing lists.
--
With Best Regards,
Andy Shevchenko