Re: [Xen-devel] ARM, time: alternative of using udelay() before init time

[Oleksandr Tyshchenko <oleksandr.tyshchenko@xxxxxxxxxxxxxxx>]

On Fri, Oct 17, 2014 at 3:58 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:

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

Hi Oleksandr,

Hi Julien.Â

Thank you for your comment.

Â

> 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.

Â

Sounds good. I also thought about it.

Unfortunately, there are other dependencies:

init_xen_time() callsÂplatform_init_time(). I see that many platform callbacks useÂdprintk to print error messages.

Also init_xen_time() checks cpu_has_gentimer feature, but global variable boot_cpu_data which contains this info initialized a bit later inÂprocessor_id().

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

Regards,

--
Julien Grall

--

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel