From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbcLCOjW (ORCPT ); Sat, 3 Dec 2016 09:39:22 -0500 Received: from saturn.retrosnub.co.uk ([178.18.118.26]:57088 "EHLO saturn.retrosnub.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164AbcLCOjU (ORCPT ); Sat, 3 Dec 2016 09:39:20 -0500 Subject: Re: [PATCH] IIO: Change msleep to usleep_range for small msecs To: Aniroop Mathur , Lars-Peter Clausen , Linus Walleij References: <1480132046-5406-1-git-send-email-a.mathur@samsung.com> <20161130144345epcms5p24751680d9fec0f33d5283db9e09410ca@epcms5p2> Cc: "knaack.h@gmx.de" , "pmeerw@pmeerw.net" , "linux-iio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , SAMUEL SEQUEIRA , Rahul Mahale , a.mathur@samsung.com From: Jonathan Cameron Message-ID: <37304261-5b26-c63e-2387-c13e3032ad0c@kernel.org> Date: Sat, 3 Dec 2016 09:00:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/12/16 19:07, Aniroop Mathur wrote: > On Wed, Nov 30, 2016 at 8:13 PM, Aniroop Mathur wrote: >> On 30 Nov 2016 19:05, "Lars-Peter Clausen" 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 >> > > 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). Thanks, Jonathan > > >> Thanks. >> >> BR, >> Aniroop Mathur