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

[Oleksandr Tyshchenko <oleksandr.tyshchenko@xxxxxxxxxxxxxxx>]

On Fri, Oct 17, 2014 at 7:22 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>
> On 10/17/2014 05:12 PM, Oleksandr Tyshchenko wrote:
> > On Fri, Oct 17, 2014 at 3:58 PM, Julien Grall <julien.grall@xxxxxxxxxx
> > <mailto:julien.grall@xxxxxxxxxx>> wrote:
> >     On 10/16/2014 04:10 PM, Oleksandr Tyshchenko wrote:
> >     Hi Oleksandr,
> >
> > Hi Julien.
>
> Hi Oleksandr,

 Hi Julien

>
> >
> >
> >     > 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().
>
> And platform_init_time() depends on platform_init.
>
> > I see that many platform
> > callbacks use dprintk to print error messages.
>
> early printk has been hooked in the console driver (and therefore
> dprintk) in Xen 4.5. So if early printk is enabled you would be able to
> see the message.

Ah, I looked how it was implemented in Xen 4.4.
ok.

>
> > 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().
>
> IHMO, this check is not useful. We would have catch it via the device
> tree because the timer wouldn't have been exposed. After the user is
> using the wrong device tree then...
>
>
> If we do want to keep this check, we could expand it and directly get
> the information from the coprocessor rather than boot_cpu_data.

 ok, it's clear.

>
> I'm wondering how Linux deal with the time when the timer is not
> initialized?

If I understood correctly the udelay() can works before timer initialized.

>
> Regards,
>
> --
> Julien Grall

-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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