Re: [PATCH] staging: fbtft: fb_watterott: fix usleep_range is preferred over udelay

On Sun, Nov 01, 2020 at 12:32:44PM +0200, Hassan Shahbazi wrote:

On Sun, Nov 01, 2020 at 07:39:48AM +0100, Greg KH wrote:

quoted

On Sun, Nov 01, 2020 at 02:20:10AM +0200, Hassan Shahbazi wrote:

quoted

Fix the checkpath.pl issue on fb_watterott.c. write_vmem and
write_vmem_8bit functions are within non-atomic context and can
safely use usleep_range.
see Documentation/timers/timers-howto.txt

Signed-off-by: Hassan Shahbazi <redacted>
---
 drivers/staging/fbtft/fb_watterott.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fbtft/fb_watterott.c b/drivers/staging/fbtft/fb_watterott.c
index 76b25df376b8..afcc86a17995 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;

@@ -124,7 +124,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);

How do you know that these ranges are ok?  Are you able to test these
changes with real hardware?

thanks,

greg k-h

No, I don't have the hardware to test with. I just used the current
value as the minimum and added an epsilon to it for the maximum
param.

It's best not to guess about this, sorry, you should have the hardware
to test this type of change.

thanks,

greg k-h