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 <[email protected]>
---
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
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 <[email protected]> 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 <[email protected]>
> ---
> 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
>
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 [email protected]
D-57072 Siegen +49-271-771091-17
http://www.kernelconcepts.de/
HR Siegen, HR B 9613; Geschäftsführer: Nils Faerber, Ole Reinhardt
Hello Mr. Simon,
On Sat, Dec 3, 2016 at 10:58 PM, Simon Budig
<[email protected]> 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 [email protected]
> D-57072 Siegen +49-271-771091-17
> http://www.kernelconcepts.de/
> HR Siegen, HR B 9613; Geschäftsführer: Nils Faerber, Ole Reinhardt
>
>