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

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

[Omer PALA]

Replace udelay() calls with usleep_range()
to avoid busy-waiting and allow the
scheduler to sleep during delays.

Signed-off-by: Omer PALA <palaomer100@gmail.com>
---
 drivers/staging/fbtft/fb_upd161704.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
index 7288140e7..f66dfad1d 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -32,27 +32,27 @@ static int init_display(struct fbtft_par *par)
 
 	/* oscillator start */
 	write_reg(par, 0x003A, 0x0001);	/*Oscillator 0: stop, 1: operation */
-	udelay(100);
+	usleep_range(100, 200);
 
 	/* y-setting */
 	write_reg(par, 0x0024, 0x007B);	/* amplitude setting */
-	udelay(10);
+	usleep_range(10, 50);
 	write_reg(par, 0x0025, 0x003B);	/* amplitude setting */
 	write_reg(par, 0x0026, 0x0034);	/* amplitude setting */
-	udelay(10);
+	usleep_range(10, 50);
 	write_reg(par, 0x0027, 0x0004);	/* amplitude setting */
 	write_reg(par, 0x0052, 0x0025);	/* circuit setting 1 */
-	udelay(10);
+	usleep_range(10, 50);
 	write_reg(par, 0x0053, 0x0033);	/* circuit setting 2 */
 	write_reg(par, 0x0061, 0x001C);	/* adjustment V10 positive polarity */
-	udelay(10);
+	usleep_range(10, 50);
 	write_reg(par, 0x0062, 0x002C);	/* adjustment V9 negative polarity */
 	write_reg(par, 0x0063, 0x0022);	/* adjustment V34 positive polarity */
-	udelay(10);
+	usleep_range(10, 50);
 	write_reg(par, 0x0064, 0x0027);	/* adjustment V31 negative polarity */
-	udelay(10);
+	usleep_range(10, 50);
 	write_reg(par, 0x0065, 0x0014);	/* adjustment V61 negative polarity */
-	udelay(10);
+	usleep_range(10, 50);
 	write_reg(par, 0x0066, 0x0010);	/* adjustment V61 negative polarity */
 
 	/* Basical clock for 1 line (BASECOUNT[7:0]) number specified */
@@ -60,7 +60,7 @@ static int init_display(struct fbtft_par *par)
 
 	/* Power supply setting */
 	write_reg(par, 0x0019, 0x0000);	/* DC/DC output setting */
-	udelay(200);
+	usleep_range(200, 300);
 	write_reg(par, 0x001A, 0x1000);	/* DC/DC frequency setting */
 	write_reg(par, 0x001B, 0x0023);	/* DC/DC rising setting */
 	write_reg(par, 0x001C, 0x0C01);	/* Regulator voltage setting */
-- 
2.55.0

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

[Nam Cao]

Omer PALA <palaomer100@gmail.com> writes:
> Replace udelay() calls with usleep_range()
> to avoid busy-waiting and allow the
> scheduler to sleep during delays.
>
> Signed-off-by: Omer PALA <palaomer100@gmail.com>

This change cannot be accepted unless it has been validated with
hardware.

Btw, I am curious why we have these udelay(). Can we remove them?

Nam

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

[Andy Shevchenko]

On Wed, Sep 16, 2026 at 12:39:28PM +0300, Omer PALA wrote:
> Replace udelay() calls with usleep_range()
> to avoid busy-waiting and allow the
> scheduler to sleep during delays.

First of all, too condensed commit message. We have as twice room on each line.
Second, do you understand the difference on what code is doing before and after
your change?

...

Please, instead of posting patches, read first, check email archives, understand
the code...

-- 
With Best Regards,
Andy Shevchenko

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

[Andy Shevchenko]

On Wed, Sep 16, 2026 at 11:53:55AM +0200, Nam Cao wrote:
> Omer PALA <palaomer100@gmail.com> writes:

...

> Btw, I am curious why we have these udelay(). Can we remove them?

Once again remind people that FBTFT works for both busses: SPI and parallel,
the latter one is usually GPIO-based and quite slow (I have one of the panel in
this mode, it gives me ~2-3fps at best on a 10y.o. x86_64 embedded device).

Maybe that's the reason? In any case, I think the datasheet on the panel should
answer the question.

-- 
With Best Regards,
Andy Shevchenko

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

[Ömer PALA]

On Wed, Sep 16, 2026 at 12:39:28PM +0300, Andy Shevchenko wrote:
Replace udelay() calls with usleep_range()to avoid busy-waiting and
allow thescheduler to sleep during delays.
First of all, too condensed commit message. We have as twice room on each line.

Hi Andy,

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.

Best regards,
Omer

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

[Nam Cao]

Ö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

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

[Ömer PALA]

Nam Cao writes:
> 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().

Hi Nam,

Thank you for clarifying the atomic context restrictions and pointing out
CONFIG_DEBUG_ATOMIC_SLEEP. That makes total sense, and I now see why udelay()
is mandatory here to prevent potential kernel panics in atomic paths.

I am dropping this patch series. Thanks again to everyone for the valuable
feedback!

Best regards,
Omer PALA

Nam Cao <namcao@linutronix.de>, 16 Eyl 2026 Çar, 15:50 tarihinde şunu yazdı:
>
> Ö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

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

[Andy Shevchenko]

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

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

[Andy Shevchenko]

On Wed, Feb 18, 2026 at 07:03:47PM +0100, tomasz.unger@yahoo.pl wrote:
> From: Tomasz Unger <tomasz.unger@yahoo.pl>

NAK.

-- 
With Best Regards,
Andy Shevchenko

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

[tomasz.unger]

From: Tomasz Unger <tomasz.unger@yahoo.pl>

Signed-off-by: Tomasz Unger <tomasz.unger@yahoo.pl>
---
 drivers/staging/fbtft/fb_upd161704.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
index c680160d6380..62862f021b28 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -32,27 +32,27 @@ static int init_display(struct fbtft_par *par)
 
 	/* oscillator start */
 	write_reg(par, 0x003A, 0x0001);	/*Oscillator 0: stop, 1: operation */
-	udelay(100);
+	usleep_range(100, 110);
 
 	/* y-setting */
 	write_reg(par, 0x0024, 0x007B);	/* amplitude setting */
-	udelay(10);
+	usleep_range(10, 12);
 	write_reg(par, 0x0025, 0x003B);	/* amplitude setting */
 	write_reg(par, 0x0026, 0x0034);	/* amplitude setting */
-	udelay(10);
+	usleep_range(10, 12);
 	write_reg(par, 0x0027, 0x0004);	/* amplitude setting */
 	write_reg(par, 0x0052, 0x0025);	/* circuit setting 1 */
-	udelay(10);
+	usleep_range(10, 12);
 	write_reg(par, 0x0053, 0x0033);	/* circuit setting 2 */
 	write_reg(par, 0x0061, 0x001C);	/* adjustment V10 positive polarity */
-	udelay(10);
+	usleep_range(10, 12);
 	write_reg(par, 0x0062, 0x002C);	/* adjustment V9 negative polarity */
 	write_reg(par, 0x0063, 0x0022);	/* adjustment V34 positive polarity */
-	udelay(10);
+	usleep_range(10, 12);
 	write_reg(par, 0x0064, 0x0027);	/* adjustment V31 negative polarity */
-	udelay(10);
+	usleep_range(10, 12);
 	write_reg(par, 0x0065, 0x0014);	/* adjustment V61 negative polarity */
-	udelay(10);
+	usleep_range(10, 12);
 	write_reg(par, 0x0066, 0x0010);	/* adjustment V61 negative polarity */
 
 	/* Basical clock for 1 line (BASECOUNT[7:0]) number specified */
@@ -60,7 +60,7 @@ static int init_display(struct fbtft_par *par)
 
 	/* Power supply setting */
 	write_reg(par, 0x0019, 0x0000);	/* DC/DC output setting */
-	udelay(200);
+	usleep_range(200, 220);
 	write_reg(par, 0x001A, 0x1000);	/* DC/DC frequency setting */
 	write_reg(par, 0x001B, 0x0023);	/* DC/DC rising setting */
 	write_reg(par, 0x001C, 0x0C01);	/* Regulator voltage setting */
-- 
2.53.0