Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751998AbbLIQOX (ORCPT ); Wed, 9 Dec 2015 11:14:23 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:35555 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbbLIQOW (ORCPT ); Wed, 9 Dec 2015 11:14:22 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 9 Dec 2015 21:44:21 +0530 Message-ID: Subject: Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ? From: Aniroop Mathur To: Thomas Gleixner , Clemens Ladisch , John Stultz Cc: a.mathur@samsung.com, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3982 Lines: 85 Sorry for multiple emails as those were not in plain text so ignored by linux-kernel@vger.kernel.org Please consider this email for reply. On Wed, Dec 9, 2015 at 2:17 AM, Thomas Gleixner wrote: > On Tue, 8 Dec 2015, Aniroop Mathur wrote: >> On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner wrote: >> > The initialization process is hardly something critical, so why would >> > the delay need to be precise? What's the point of having data 10ms >> > earlier? >> >> As I know, the chip initialisation process is critical. >> Consider the case for an android mobile phone. When the phone is >> resumed from suspend state, all the earlier enabled devices need to >> be re-initialised. Normally, we have two sleeps during device >> initialisation and we need to re-initialize more than 25 devices on >> board. So if single msleep delays by 10 ms, then the android phone >> resume is delayed by 10*2*25 = 500 ms, which is quite a big time. >> >> Also more importantly, during booting the phone as well, if every >> device sleeps for extra 20 ms and we have to probe 25 devices, >> booting is delayed by 500 ms. > > You are optimizing for something which is simply stupid. WHY do you > need to (re)initialize all devices before you can do something useful? > > Just because Android is implemented that way? That's silly. > > If you really care about boot time / user experience you initialize > only the really important drivers in the boot/resume process and > initialize the reset in the background. It does not matter whether the > temperatur app shows the updated value one second later or not, but it > matters for the user that the GUI is functional. > In case of android suspend, first lcd and touch turns off, then system devices are turned off. The same process I found in laptop as well. I could see clearly, first lcd went off and then wifi light was off, bluetooth light was off, mouse light was off. In resume, reverse process is followed in both. So LCD is turned on at last. In my opinion, this makes sense as we do not want user to use the gui or perform any operation untill the system is ready to operate. So with this sequence we are able to save good time using usleep_range. In case of booting, as almost all devices are embedded in the android phone, so probe is called during booting. In every probe, I have seen the prevention code of checking chipID or some other prevention code. For this, chip is powered on and initialized, next i2c operation is performed to read slave address. If slave address does not match or i2c operation fails, then probe fails and chip is de-initialized. Also, if probe success, chip is de-initialized. So basically in probe, chip is always initialized and de-initialized finally. And in initialization part, we need to add delays. So saving time in initialization part can save good time in booting till home screen. >> My point is to use single consistent sleep api in driver code >> instead of two as we need to use it many places in a single driver >> code. This way, the code looks better. > > It's not about better. It's about using the right interfaces for the > right job. usleep_range() and msleep() use different facilities. As I > explained before: If you need a precise limit, use usleep_range(). If > not use msleep(). > Sure. I understand this part. However, my main concern is still not resolved clearly. Could you please update the answer to my earlier two queries: 1. If we choose usleep_range to acheive accuracy, are cpu and power usage of any concern in real sense ? 2. If we use msleep(40), is it possible that process could wake up after 60 ms or 70 ms or 100 ms or more ? BR, Aniroop Mathur > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/