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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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,

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

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

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

Regards,

-- 
Julien Grall

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