Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753435AbbLII6K (ORCPT ); Wed, 9 Dec 2015 03:58:10 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:43628 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753281AbbLII6H (ORCPT ); Wed, 9 Dec 2015 03:58:07 -0500 X-AuditID: cbfee6a3-f79776d000001430-77-5667ed10842d Date: Wed, 09 Dec 2015 08:57:52 +0000 (GMT) From: Aniroop Mathur Subject: Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ? To: tglx@linutronix.de, clemens@ladisch.de Cc: aniroop.mathur@gmail.com, linux-kernel@vger.kernel.org Reply-to: a.mathur@samsung.com MIME-version: 1.0 X-MTR: 20151209081105640@a.mathur Msgkey: 20151209081105640@a.mathur X-EPLocale: en_US.windows-1252 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-MLAttribute: X-RootMTR: 20151209081105640@a.mathur X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N X-ConfirmMail: N,general Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 Message-id: <1119871408.470021449651471305.JavaMail.weblogic@epmlwas06d> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsVy+t/tfl2Bt+lhBrcmmVtc3jWHzYHR4/Mm uQDGKC6blNSczLLUIn27BK6M1o6LjAXL1CqedEU0MC5R7WLk5BASUJbYdfQoK4gtIWAi0Thn OZQtJnHh3nq2LkYuoJo5jBIzf11kBEmwCKhIrDo6jxnEZhPQkTi5/ysbiC0skCPxYO9CdhBb RMBMYs3dT0wgNrOAm8TjVzOA6jmABslJLJyUChLmFRCUODnzCQvELkWJZ6072EFKeAWUJG6+ rYcIy0ksmXqZCcLmlZjR/pQFJj7t6xpmCFta4vysDYwwJy/+/hgqzi9x7PYOqF4BialnDkLV qEls77kJZfNJrFn4lgWmftep5cwwu+5vmQvVKyGxteUJK8QnihJTuh+yQ9gGEkcWzWFF9wqv gIfE+qXPWSYwys5CkpqFpH0WknZkNQsYWVYxiqYWJBcUJ6VXGOsVJ+YWl+al6yXn525iBMfy s8U7GP+ftz7EKMDBqMTDe8ElPUyINbGsuDL3EKMEB7OSCO+y10Ah3pTEyqrUovz4otKc1OJD jNIcLErivLf3+YUJCaQnlqRmp6YWpBbBZJk4OKUaGJ3fmDad+svbyHDnqM30mtMSKvt2pz6J c5G8keb+ekaSUL93S3d3wEqxV/pCjT+60mf8YhTg+R5/4bBLZs2U9r1vd3nqf6n1mcR+nG/3 Mj4eN6ejuUdf7P2UfNVNQXfysfOWEzUORYcc/XHloNYKlkjXKbIxspZJK7v0enwObhfI0e+X 8NX2VWIpzkg01GIuKk4EALdqrYPhAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tB98wEFp023294 Content-Length: 3663 Lines: 75 On Dec 9, 2015 2:18 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 in 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. In case of booting, 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, 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. And so saving time in initialization part can save time of 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 incomplete. Could you please provide the answer to my earlier two queries: 1. If we choose usleep_range to acheive accuracy, are cpu and power usage of any concern? 2. If we use msleep(40), is it possible that process could wake up at 60 ms or 70 ms or 100 ms or more ? BR, Aniroop Mathur > Thanks, > > tglx????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?