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

[Thomas Gleixner]

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.
 
> 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().
 
Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/