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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
>      D-57072 Siegen                       +49-271-771091-17
>      http://www.kernelconcepts.de/
>      HR Siegen, HR B 9613; GeschÃftsfÃhrer: Nils Faerber, Ole Reinhardt
>
>