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