On Tue, 14 Jun 2016 21:35:17 +0530
Afzal Mohammed [off-list ref] wrote:

Hi,

On Mon, Jun 13, 2016 at 05:24:09PM +0200, Alexandre Belloni wrote:

quoted

On 11/06/2016 at 00:30:36 +0200, Arnd Bergmann wrote :  

quoted

quoted

Does this have to be called that early? It seems wasteful to always
call udelay() here, when these are functions that are normally
allowed to sleep.  

quoted

So I've tested it and something like that would work:

	if (system_state < SYSTEM_RUNNING)
		udelay(osc->startup_usec);
	else
		usleep_range(osc->startup_usec, osc->startup_usec + 1);

But I'm afraid it would be the first driver to actually do something
like that (however, it is already the only driver trying to sleep).   

tglx has suggested to modify clock core to handle a somewhat similar
kind of scenario (probably should work here too) and avoid driver
changes,

http://lkml.kernel.org/r/alpine.DEB.2.11.1606061448010.28031 at nanos

Oh, interesting. Definitely a better solution than this custom check.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com