[PATCH] Staging: fbtft: Replace udelay to usleep_range

[PATCH] Staging: fbtft: Replace udelay to usleep_range

[Bhagyashri Dighole]

Replace udelay to usleep_range function call with 10 microsecond range.
Detected by checkpatch.pl "CHECK: usleep_range is preferred over udelay".

Signed-off-by: Bhagyashri Dighole <digholebhagyashri@gmail.com>
---
 drivers/staging/fbtft/fb_agm1264k-fl.c |  2 +-
 drivers/staging/fbtft/fb_ra8875.c      |  4 ++--
 drivers/staging/fbtft/fb_tinylcd.c     |  2 +-
 drivers/staging/fbtft/fb_upd161704.c   | 18 +++++++++---------
 drivers/staging/fbtft/fb_watterott.c   |  4 ++--
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
index 8f27bd8..b2d19b1 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
 	dev_dbg(par->info->device, "%s()\n", __func__);
 
 	gpiod_set_value(par->gpio.reset, 0);
-	udelay(20);
+	usleep_range(20, 30);
 	gpiod_set_value(par->gpio.reset, 1);
 	mdelay(120);
 }
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 70b37fc..5f857ba 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -217,7 +217,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
 	}
 	len--;
 
-	udelay(100);
+	usleep_range(100, 110);
 
 	if (len) {
 		buf = (u8 *)par->buf;
@@ -238,7 +238,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
 
 	/* restore user spi-speed */
 	par->fbtftops.write = fbtft_write_spi;
-	udelay(100);
+	usleep_range(100, 110);
 }
 
 static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248..7a9f0e1 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -41,7 +41,7 @@ static int init_display(struct fbtft_par *par)
 		       0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
 	write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
 	write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
-	udelay(250);
+	usleep_range(250, 260);
 	write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
 
 	return 0;
diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
index 564a38e..b00161e 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -36,27 +36,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, 20);
 	write_reg(par, 0x0025, 0x003B);	/* amplitude setting */
 	write_reg(par, 0x0026, 0x0034);	/* amplitude setting */
-	udelay(10);
+	usleep_range(10, 20);
 	write_reg(par, 0x0027, 0x0004);	/* amplitude setting */
 	write_reg(par, 0x0052, 0x0025);	/* circuit setting 1 */
-	udelay(10);
+	usleep_range(10, 20);
 	write_reg(par, 0x0053, 0x0033);	/* circuit setting 2 */
 	write_reg(par, 0x0061, 0x001C);	/* adjustment V10 positive polarity */
-	udelay(10);
+	usleep_range(10, 20);
 	write_reg(par, 0x0062, 0x002C);	/* adjustment V9 negative polarity */
 	write_reg(par, 0x0063, 0x0022);	/* adjustment V34 positive polarity */
-	udelay(10);
+	usleep_range(10, 20);
 	write_reg(par, 0x0064, 0x0027);	/* adjustment V31 negative polarity */
-	udelay(10);
+	usleep_range(10, 20);
 	write_reg(par, 0x0065, 0x0014);	/* adjustment V61 negative polarity */
-	udelay(10);
+	usleep_range(10, 20);
 	write_reg(par, 0x0066, 0x0010);	/* adjustment V61 negative polarity */
 
 	/* Basical clock for 1 line (BASECOUNT[7:0]) number specified */
@@ -64,7 +64,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, 210);
 	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 */
diff --git a/drivers/staging/fbtft/fb_watterott.c b/drivers/staging/fbtft/fb_watterott.c
index 0a5206d..4bd0b86 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -84,7 +84,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, size_t len)
 			par->txbuf.buf, 10 + par->info->fix.line_length);
 		if (ret < 0)
 			return ret;
-		udelay(300);
+		usleep_range(300, 310);
 	}
 
 	return 0;
@@ -129,7 +129,7 @@ static int write_vmem_8bit(struct fbtft_par *par, size_t offset, size_t len)
 			par->txbuf.buf, 10 + par->info->var.xres);
 		if (ret < 0)
 			return ret;
-		udelay(700);
+		usleep_range(700, 710);
 	}
 
 	return 0;
-- 
2.7.4

Re: [Outreachy kernel] [PATCH] Staging: fbtft: Replace udelay to usleep_range

[Greg Kroah-Hartman]

On Sun, Mar 03, 2019 at 01:59:02PM +0530, Bhagyashri Dighole wrote:
> Replace udelay to usleep_range function call with 10 microsecond range.
> Detected by checkpatch.pl "CHECK: usleep_range is preferred over udelay".
> 
> Signed-off-by: Bhagyashri Dighole <digholebhagyashri@gmail.com>
> ---
>  drivers/staging/fbtft/fb_agm1264k-fl.c |  2 +-
>  drivers/staging/fbtft/fb_ra8875.c      |  4 ++--
>  drivers/staging/fbtft/fb_tinylcd.c     |  2 +-
>  drivers/staging/fbtft/fb_upd161704.c   | 18 +++++++++---------
>  drivers/staging/fbtft/fb_watterott.c   |  4 ++--
>  5 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
> index 8f27bd8..b2d19b1 100644
> --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
>  	dev_dbg(par->info->device, "%s()\n", __func__);
>  
>  	gpiod_set_value(par->gpio.reset, 0);
> -	udelay(20);
> +	usleep_range(20, 30);

How do you know that 30 is an acceptable value here?

Making this kind of change is tricky if you do not have the hardware
involved, as you are changing the functionality of the driver.  Look up
why checkpatch is asking you to make this change, perhaps that reason is
not relevant for these devices?

I can't take this type of change without testing on the hardware itself,
sorry.

greg k-h

Re: [Outreachy kernel] [PATCH] Staging: fbtft: Replace udelay to usleep_range

[Bhagyashri Dighole]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

Hi,
I have gone through "Documentation/timers/timers-howto.txt", It is
mentioned that we can put 10us-20us gap between min_range and max_range. In
above situation `udelay(20)` our min_range is 20 and max_range is 30.

I was not aware of the situation that we need to test it on hardware.

Thanks
Bhagyashri

On Sun, Mar 3, 2019 at 2:04 PM Greg Kroah-Hartman <
gregkh@linuxfoundation.org> wrote:

> On Sun, Mar 03, 2019 at 01:59:02PM +0530, Bhagyashri Dighole wrote:
> > Replace udelay to usleep_range function call with 10 microsecond range.
> > Detected by checkpatch.pl "CHECK: usleep_range is preferred over
> udelay".
> >
> > Signed-off-by: Bhagyashri Dighole <digholebhagyashri@gmail.com>
> > ---
> >  drivers/staging/fbtft/fb_agm1264k-fl.c |  2 +-
> >  drivers/staging/fbtft/fb_ra8875.c      |  4 ++--
> >  drivers/staging/fbtft/fb_tinylcd.c     |  2 +-
> >  drivers/staging/fbtft/fb_upd161704.c   | 18 +++++++++---------
> >  drivers/staging/fbtft/fb_watterott.c   |  4 ++--
> >  5 files changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
> b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > index 8f27bd8..b2d19b1 100644
> > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
> >       dev_dbg(par->info->device, "%s()\n", __func__);
> >
> >       gpiod_set_value(par->gpio.reset, 0);
> > -     udelay(20);
> > +     usleep_range(20, 30);
>
> How do you know that 30 is an acceptable value here?
>
> Making this kind of change is tricky if you do not have the hardware
> involved, as you are changing the functionality of the driver.  Look up
> why checkpatch is asking you to make this change, perhaps that reason is
> not relevant for these devices?
>
> I can't take this type of change without testing on the hardware itself,
> sorry.
>
> greg k-h
>

[-- Attachment #2: Type: text/html, Size: 2776 bytes --]

Re: [Outreachy kernel] [PATCH] Staging: fbtft: Replace udelay to usleep_range

[Greg Kroah-Hartman]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Sun, Mar 03, 2019 at 07:46:55PM +0530, Bhagyashri Dighole wrote:
> Hi,
> I have gone through "Documentation/timers/timers-howto.txt", It is
> mentioned that we can put 10us-20us gap between min_range and max_range. In
> above situation `udelay(20)` our min_range is 20 and max_range is 30.

That type of delay range can be set, yes, but what are you helping here?
Also, can the hardware really support this type of longer delay?  Some
hardware types can not as it is trying to rely on some sort of
semi-regular delays.  Or could the delay be shorter?  It's really hard
to know without knowing what the hardware is expecting and being able to
test it.

thanks,

greg k-h

Re: [Outreachy kernel] [PATCH] Staging: fbtft: Replace udelay to usleep_range

[Bhagyashri Dighole]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

I got the point.

Thanks

On Sun, Mar 3, 2019 at 7:57 PM Greg Kroah-Hartman <
gregkh@linuxfoundation.org> wrote:

>
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
>
> On Sun, Mar 03, 2019 at 07:46:55PM +0530, Bhagyashri Dighole wrote:
> > Hi,
> > I have gone through "Documentation/timers/timers-howto.txt", It is
> > mentioned that we can put 10us-20us gap between min_range and max_range.
> In
> > above situation `udelay(20)` our min_range is 20 and max_range is 30.
>
> That type of delay range can be set, yes, but what are you helping here?
> Also, can the hardware really support this type of longer delay?  Some
> hardware types can not as it is trying to rely on some sort of
> semi-regular delays.  Or could the delay be shorter?  It's really hard
> to know without knowing what the hardware is expecting and being able to
> test it.
>
> thanks,
>
> greg k-h
>

[-- Attachment #2: Type: text/html, Size: 1830 bytes --]

Re: [Outreachy kernel] [PATCH] Staging: fbtft: Replace udelay to usleep_range

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]



On Sun, 3 Mar 2019, Bhagyashri Dighole wrote:

> I got the point.

You have top posted again.  You need to put your response under the text
that it refers to, as I have done here.

julia

>
> Thanks
>
> On Sun, Mar 3, 2019 at 7:57 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>
>       A: http://en.wikipedia.org/wiki/Top_post
>       Q: Were do I find info about this thing called top-posting?
>       A: Because it messes up the order in which people normally read
>       text.
>       Q: Why is top-posting such a bad thing?
>       A: Top-posting.
>       Q: What is the most annoying thing in e-mail?
>
>       A: No.
>       Q: Should I include quotations after my reply?
>
>       http://daringfireball.net/2007/07/on_top
>
>       On Sun, Mar 03, 2019 at 07:46:55PM +0530, Bhagyashri Dighole
>       wrote:
>       > Hi,
>       > I have gone through "Documentation/timers/timers-howto.txt",
>       It is
>       > mentioned that we can put 10us-20us gap between min_range and
>       max_range. In
>       > above situation `udelay(20)` our min_range is 20 and max_range
>       is 30.
>
>       That type of delay range can be set, yes, but what are you
>       helping here?
>       Also, can the hardware really support this type of longer
>       delay?  Some
>       hardware types can not as it is trying to rely on some sort of
>       semi-regular delays.  Or could the delay be shorter?  It's
>       really hard
>       to know without knowing what the hardware is expecting and being
>       able to
>       test it.
>
>       thanks,
>
>       greg k-h
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visithttps://groups.google.com/d/msgid/outreachy-kernel/CAOMPgji0B8yCzT8gsF%2BPP
> EeCxdxSWOAX%3Dcf%2B6rwQ%2BwHMLXyXqA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>