[PATCH] Input: touchscreen: edt_ft5x06 - change msleep to usleep_range for small msecs

[PATCH] Input: touchscreen: edt_ft5x06 - change msleep to usleep_range for small msecs

[Aniroop Mathur]

msleep(1~20) may not do what the caller intends, and will often sleep longer.
(~20 ms actual sleep for any value given in the 1~20ms range)
This is not the desired behaviour for many cases like device resume time,
device suspend time, device enable time, retry logic, etc.
Thus, change msleep to usleep_range for precise wakeups.

Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
---
 drivers/input/touchscreen/edt-ft5x06.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 703e295..379dd31 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -67,7 +67,7 @@
 #define EDT_SWITCH_MODE_RETRIES		10
 #define EDT_SWITCH_MODE_DELAY		5 /* msec */
 #define EDT_RAW_DATA_RETRIES		100
-#define EDT_RAW_DATA_DELAY		1 /* msec */
+#define EDT_RAW_DATA_DELAY		1000 /* usec */
 
 enum edt_ver {
 	M06,
@@ -664,7 +664,7 @@ static ssize_t edt_ft5x06_debugfs_raw_data_read(struct file *file,
 	}
 
 	do {
-		msleep(EDT_RAW_DATA_DELAY);
+		usleep_range(EDT_RAW_DATA_DELAY, EDT_RAW_DATA_DELAY + 100);
 		val = edt_ft5x06_register_read(tsdata, 0x08);
 		if (val < 1)
 			break;
-- 
2.6.2

Re: [PATCH] Input: touchscreen: edt_ft5x06 - change msleep to usleep_range for small msecs

[Aniroop Mathur]

Dear Simon Budig / Daniel Wagener / Lothar Waßmann,

Greetings!

I am Aniroop Mathur from Samsung R&D Institute, India.

I have submitted one patch as below for review to Linux Open Source.
The problem is that we do not have the hardware available with us to
test it and we would like to test it before actually applying it.
As you are the author of this driver, I am contacting you to request you to
provide your feedback upon this patch.

Also if you have the hardware available, could you please help to
test this patch on your hardware? or could you provide contact points
of individuals who could support to test it?

Thank you!

BR,
Aniroop Mathur

On Tue, Nov 29, 2016 at 12:11 AM, Aniroop Mathur <a.mathur@samsung.com> wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device suspend time, device enable time, retry logic, etc.
> Thus, change msleep to usleep_range for precise wakeups.
>
> Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
> ---
>  drivers/input/touchscreen/edt-ft5x06.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index 703e295..379dd31 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -67,7 +67,7 @@
>  #define EDT_SWITCH_MODE_RETRIES                10
>  #define EDT_SWITCH_MODE_DELAY          5 /* msec */
>  #define EDT_RAW_DATA_RETRIES           100
> -#define EDT_RAW_DATA_DELAY             1 /* msec */
> +#define EDT_RAW_DATA_DELAY             1000 /* usec */
>
>  enum edt_ver {
>         M06,
> @@ -664,7 +664,7 @@ static ssize_t edt_ft5x06_debugfs_raw_data_read(struct file *file,
>         }
>
>         do {
> -               msleep(EDT_RAW_DATA_DELAY);
> +               usleep_range(EDT_RAW_DATA_DELAY, EDT_RAW_DATA_DELAY + 100);
>                 val = edt_ft5x06_register_read(tsdata, 0x08);
>                 if (val < 1)
>                         break;
> --
> 2.6.2
>

Re: [PATCH] Input: touchscreen: edt_ft5x06 - change msleep to usleep_range for small msecs

[Simon Budig]

[-- Attachment #1.1: Type: text/plain, Size: 1860 bytes --]

Hello Mr, Mathur.

On 29/11/16 21:54, Aniroop Mathur wrote:
> I have submitted one patch as below for review to Linux Open Source.
> The problem is that we do not have the hardware available with us to
> test it and we would like to test it before actually applying it.
> As you are the author of this driver, I am contacting you to request you to
> provide your feedback upon this patch.
> 
> Also if you have the hardware available, could you please help to
> test this patch on your hardware? or could you provide contact points
> of individuals who could support to test it?

My first question regarding the patch is: What is your motivation for
doing this change? Did you actually encounter any problems with some
touch hardware? Or is this a part of a global search/replace mission
across the linux kernel?

The change is in a function that is pretty irrelevant for most users of
the driver: reading out raw sensor data, which is only available for
EDT's M06 models of the touchscreen. I am actually tempted to remove
this stuff, since it never really provided helpful for us in debugging
touch screen problems, and adds a certain amount of complexity to the
driver.

I don't have a setup for the hardware readily available at the moment,
so I can't currently help you there. But from reading the patch it seems
pretty harmless and from my point of view there is nothing that speaks
against incorporating that patch. On the other hand I don't see a lot
that speaks in favor of it.

*shrug*

Bye,
        Simon
-- 
     kernel concepts GmbH                 Simon Budig
     Sieghuetter Hauptweg 48              simon.budig@kernelconcepts.de
     D-57072 Siegen                       +49-271-771091-17
     http://www.kernelconcepts.de/
     HR Siegen, HR B 9613; Geschäftsführer: Nils Faerber, Ole Reinhardt



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH] Input: touchscreen: edt_ft5x06 - change msleep to usleep_range for small msecs

[Aniroop Mathur]

Hello Mr. Simon,

On Sat, Dec 3, 2016 at 10:58 PM, Simon Budig
<simon.budig@kernelconcepts.de> wrote:
> Hello Mr, Mathur.
>
> On 29/11/16 21:54, Aniroop Mathur wrote:
>> I have submitted one patch as below for review to Linux Open Source.
>> The problem is that we do not have the hardware available with us to
>> test it and we would like to test it before actually applying it.
>> As you are the author of this driver, I am contacting you to request you to
>> provide your feedback upon this patch.
>>
>> Also if you have the hardware available, could you please help to
>> test this patch on your hardware? or could you provide contact points
>> of individuals who could support to test it?
>
> My first question regarding the patch is: What is your motivation for
> doing this change? Did you actually encounter any problems with some
> touch hardware? Or is this a part of a global search/replace mission
> across the linux kernel?
>

Well firstly, I decided to change this as it is recommended and mentioned
in the kernel documentation to use usleep_range over msleep for 1 - 10
ms delays. Secondly, we found problems in response time in our sensor
drivers because there is need to give delays after some register initialization
to make the device work properly.and when we changed to usleep_range
we got decent results like first sensor data was generated faster than before
indeed. Since I work on input/iio device drivers so I decided to make same
changes in other input subsystem drivers as well.

> The change is in a function that is pretty irrelevant for most users of
> the driver: reading out raw sensor data, which is only available for
> EDT's M06 models of the touchscreen. I am actually tempted to remove
> this stuff, since it never really provided helpful for us in debugging
> touch screen problems, and adds a certain amount of complexity to the
> driver.
>
> I don't have a setup for the hardware readily available at the moment,
> so I can't currently help you there. But from reading the patch it seems
> pretty harmless and from my point of view there is nothing that speaks
> against incorporating that patch. On the other hand I don't see a lot
> that speaks in favor of it.
>
> *shrug*
>

I guess, reviewing the patch for this change should be okay. Thanks!

Since here we are using msleep(1) which is worse as it sleeps for
minimum two jiffies so 20 ms on HZ=100 system and we are doing here
100 retries if register reading fails. So as you can deduce usleep_range
will serve better here.
Explained originally here why to not use msleep for 1-20ms:
http://lkml.org/lkml/2007/8/3/250

BR,
Aniroop Mathur


> Bye,
>         Simon
> --
>      kernel concepts GmbH                 Simon Budig
>      Sieghuetter Hauptweg 48              simon.budig@kernelconcepts.de
>      D-57072 Siegen                       +49-271-771091-17
>      http://www.kernelconcepts.de/
>      HR Siegen, HR B 9613; Geschäftsführer: Nils Faerber, Ole Reinhardt
>
>

Re: [PATCH] Input: touchscreen: edt_ft5x06 - change msleep to usleep_range for small msecs

[Simon Budig]

[-- Attachment #1.1: Type: text/plain, Size: 774 bytes --]

On 03/12/16 19:17, Aniroop Mathur wrote:
> Since here we are using msleep(1) which is worse as it sleeps for
> minimum two jiffies so 20 ms on HZ=100 system and we are doing here
> 100 retries if register reading fails. So as you can deduce usleep_range
> will serve better here.
> Explained originally here why to not use msleep for 1-20ms:
> http://lkml.org/lkml/2007/8/3/250

Acked-by: Simon Budig <simon.budig@kernelconcepts.de>

Bye,
        Simon
-- 
     kernel concepts GmbH                 Simon Budig
     Sieghuetter Hauptweg 48              simon.budig@kernelconcepts.de
     D-57072 Siegen                       +49-271-771091-17
     http://www.kernelconcepts.de/
     HR Siegen, HR B 9613; Geschäftsführer: Nils Faerber, Ole Reinhardt



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH] Input: touchscreen: edt_ft5x06 - change msleep to usleep_range for small msecs

[Dmitry Torokhov]

On Wed, Jan 04, 2017 at 07:19:56PM +0100, Simon Budig wrote:
> On 03/12/16 19:17, Aniroop Mathur wrote:
> > Since here we are using msleep(1) which is worse as it sleeps for
> > minimum two jiffies so 20 ms on HZ=100 system and we are doing here
> > 100 retries if register reading fails. So as you can deduce usleep_range
> > will serve better here.
> > Explained originally here why to not use msleep for 1-20ms:
> > http://lkml.org/lkml/2007/8/3/250
> 
> Acked-by: Simon Budig <simon.budig@kernelconcepts.de>

Applied, thank you.

> 
> Bye,
>         Simon
> -- 
>      kernel concepts GmbH                 Simon Budig
>      Sieghuetter Hauptweg 48              simon.budig@kernelconcepts.de
>      D-57072 Siegen                       +49-271-771091-17
>      http://www.kernelconcepts.de/
>      HR Siegen, HR B 9613; Geschäftsführer: Nils Faerber, Ole Reinhardt
> 
> 




-- 
Dmitry