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

Hello Mr. Simon,

On Sat, Dec 3, 2016 at 10:58 PM, Simon Budig
[off-list ref] wrote:

Hello Mr, Mathur.

On 29/11/16 21:54, Aniroop Mathur wrote:

quoted

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