Re: [PATCH] staging: fbtft: fb_upd161704: replace udelay with usleep_range

[Nam Cao <namcao@linutronix.de>]

Ömer PALA <palaomer100@gmail.com> writes:
> Thank you for the feedback and review. I note the line-length
> formatting (~72 characters per line)
> for my future commit messages.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.

A crucial difference is that we can call udelay() in any context, but we
cannot call usleep_range() in atomic context. Thus, a test run with
CONFIG_DEBUG_ATOMIC_SLEEP enabled is recommended.

I don't know if non-deterministic delay is an issue, the datasheet would
need to be checked. But udelay() is not deterministic either, for
example the CPU may need to handle an external interrupt while the task
is calling udelay().

Nam