From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: ARM, time: alternative of using udelay() before init time Date: Fri, 17 Oct 2014 13:58:42 +0100 Message-ID: <54411282.7000204@linaro.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Oleksandr Tyshchenko , "xen-devel@lists.xen.org" Cc: Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.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