Re: ARM, time: alternative of using udelay() before init time

[Julien Grall <julien.grall@linaro.org>]

On 10/16/2014 04:10 PM, Oleksandr Tyshchenko wrote:
> Hi, all.

Hi Oleksandr,

> I have a question about using udelay() (located in arch/arm/time.c) in XEN.
> I have found out that I can't use this function before call
> init_xen_time(). Otherwise udelay() hangs,
> since get_s_time() returns wrong result.
> Even if we come from U-Boot with ARCH timer enabled (which also not
> always true) the global variable "cpu_khz" not initialized yet.
> 
> For example, a some UART driver has init_preirq callback where we need
> to call udelay(X) after changing baudrate before continuing init
> sequence. But we can't, since the console_init_preirq() called a bit
> early than init_xen_time().
> 
> So, could you please explain me is there other method I can use before
> init time subsystem. 
> Is the simple while loop the only way?

I would move the initialization of the timer earlier. But not earlier
than the creation of the internal device tree
(dt_unflatten_host_device_tree()).

IIRC there is no other dependency for this function. The only drawback
is the log of the timer won't be appear if early printk is not enabled.

I guess we could try to store earlyprintk data and dump them when the
UART is effectively enabled.

Regards,

-- 
Julien Grall