Re: [PATCH] IIO: Change msleep to usleep_range for small msecs

[Aniroop Mathur]

On Sat, Dec 3, 2016 at 2:30 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> On 02/12/16 19:07, Aniroop Mathur wrote:
>> On Wed, Nov 30, 2016 at 8:13 PM, Aniroop Mathur <a.mathur@xxxxxxxxxxx> wrote:
>>> On 30 Nov 2016 19:05, "Lars-Peter Clausen" <lars@xxxxxxxxxx> wrote:
>>>  >
>>>  > On 11/27/2016 11:51 AM, Jonathan Cameron wrote:
>>>  > > On 26/11/16 03:47, Aniroop Mathur 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, data reading time, etc.
>>>  > >> Thus, change msleep to usleep_range for precise wakeups.
>>>  > >>
>>>  > >> Signed-off-by: Aniroop Mathur <a.mathur@xxxxxxxxxxx>
>>>  > > As these need individual review by the various original authors and driver maintainers to
>>>  > > establish the intent of the sleep, it would have been better to have done a series of
>>>  > > patches (one per driver) with the relevant maintainers cc'd on the ones that they care about.
>>>  > >
>>>  > > Most of these are ADI parts looked after by Lars though so perhaps wait for his comments
>>>  > > before respining.
>>>  >
>>>  > I agree with what Jonathan said. For most of these extending the maximum
>>>  > sleep time a bit further is ok.
>>>  >
>>>
>>> Well, its right that sleep a bit further is okay but this patch is not trying
>>> to solve any major bug. This patch is only trying to make the wake up more
>>> precise than before. So like with msleep(1), process could sleep for 20 ms
>>> so this patch only making the making the process to sleep for 1 ms as
>>> mentioned in the parameter. So I think, changing to usleep_range is only
>>> advantageous and does not cause any harm here.
>>> We have also applied the same change in enable/disable/suspend/resume
>>> functions in accel, gyro, mag, etc drivers and found decent results like the
>>> first sesor data is generated much faster than before so response time
>>> increased. This is critical as  sensor can run at a rate of 200Hz / 5ms or
>>> even more now a days in new devices. We even applied in probe as doing the
>>> same in many drivers contribute to a little saving overall in kernel boot up.
>>> Also, it is recommended and mentioned in kernel documentation to use
>>> usleep_range for 1-10 ms.
>>> Sources -
>>> https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
>>> https://lkml.org/lkml/2007/8/3/250
>>>
>>
>>
>> Hello Mr. Jonathan / Mr. Lars / All,
>>
>>
>> Would you kindly update further about this change?
> Hi Aniroop,
>
> Quite a few of us only manage to get to kernel patches once or twice a week
> (in my case only on weekends most weeks).
>
> Anyhow, I've applied this patch as is.  I don't necessarily think the change
> is that important in the probe paths, but as you said it does little harm.
>
> So what the heck ;)
>
> Applied to the togreg branch of iio.git which I'll push out as testing
> once I have a net connection (currently on a train).
>

This sounds great !! Thanks a lot :)

BR,
Aniroop Mathur

> Thanks,
>
> Jonathan
>>
>>
>>> Thanks.
>>>
>>> BR,
>>> Aniroop Mathur
>