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

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

[Oleksandr Tyshchenko]

[-- Attachment #1.1: Type: text/plain, Size: 844 bytes --]

Hi, all.

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?

Thank you.

-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com
<http://www.globallogic.com/>

[-- Attachment #1.2: Type: text/html, Size: 2620 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Julien Grall]

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

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

[Oleksandr Tyshchenko]

[-- Attachment #1.1: Type: text/plain, Size: 1903 bytes --]

On Fri, Oct 17, 2014 at 3:58 PM, Julien Grall <julien.grall@linaro.org>
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
<http://www.globallogic.com/>

[-- Attachment #1.2: Type: text/html, Size: 4884 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Julien Grall]

On 10/17/2014 05:12 PM, Oleksandr Tyshchenko wrote:
> On Fri, Oct 17, 2014 at 3:58 PM, Julien Grall <julien.grall@linaro.org
> <mailto:julien.grall@linaro.org>> 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

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

[Oleksandr Tyshchenko]

On Fri, Oct 17, 2014 at 7:22 PM, Julien Grall <julien.grall@linaro.org> wrote:
>
> On 10/17/2014 05:12 PM, Oleksandr Tyshchenko wrote:
> > On Fri, Oct 17, 2014 at 3:58 PM, Julien Grall <julien.grall@linaro.org
> > <mailto:julien.grall@linaro.org>> 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

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

[Julien Grall]

Hi Oleksandr,

On 10/20/2014 11:12 AM, Oleksandr Tyshchenko wrote:
> On Fri, Oct 17, 2014 at 7:22 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>
>> 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.

I gave a look to the Linux code and it looks like they have an
implementation based on jiffies to used when the timer is not
initialized. (see __loop_udelay in arch/arm/lib/delay.c).

I'm not sure if it's relevant to do exactly the same. But we could
implement a loop-based udelay when the timer is not correctly initialized.

Regards,

-- 
Julien Grall

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

[Oleksandr Tyshchenko]

On Mon, Oct 20, 2014 at 3:30 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Oleksandr,
Hi Julien

>
> On 10/20/2014 11:12 AM, Oleksandr Tyshchenko wrote:
>> On Fri, Oct 17, 2014 at 7:22 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>
>>> 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.
>
> I gave a look to the Linux code and it looks like they have an
> implementation based on jiffies to used when the timer is not
> initialized. (see __loop_udelay in arch/arm/lib/delay.c).
>
> I'm not sure if it's relevant to do exactly the same. But we could
> implement a loop-based udelay when the timer is not correctly initialized.
Completely agree.

>
> Regards,
>
> --
> Julien Grall



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com