| Message ID | 1480358514-2894-1-git-send-email-a.mathur@samsung.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
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 > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 > >
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;
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(-)