Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ?

[Aniroop Mathur]

On Dec 9, 2015 2:18 AM, "Thomas Gleixner" <tglx@xxxxxxxxxxxxx> wrote:
>
> On Tue, 8 Dec 2015, Aniroop Mathur wrote:
> > On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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