Re: [Adeos-main] IMX25 timer access patch

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 04/20/2012 05:07 PM, Michael Trimarchi wrote:
> Hi Gilles
> 
> This is my version:
> 
> commit be8ccd4a39708cef6e67e4e00432d0207e596a76
> Author: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Date:   Wed Feb 23 01:38:09 2011 +0100
> 
>     forward port, rebase on 3.0-noarch, adeos-ipipe-3.0.13-arm-1.18-05
> 
> 
> on top of it I have my board patches and this commit for an error of the timer precision
> 
> commit fff6198ec1033e55d42cc24914b6b958365d7495
> Author: Mehnert, Torsten <T.Mehnert@domain.hid>
> Date:   Mon Aug 1 08:02:07 2011 +0000
> 
>     i.MX25 GPT clock fix: ensure correct the clock source
>     
>     Request for comment and commit.
>     
>     From: T. Mehnert <t.mehnert@domain.hid>
>     Date: Mon, 4 Jul 2011 15:53:30 +0200
>     Subject: [PATCH] i.MX25 GPT clock fix: ensure correct the clock source
>     
>     This patch ensures, that Linux will take the correct clock source (AHB_DIV)
>     for gpt in the ARM i.MX25 implementation. The currect code depends on the re
>     defaults of the CCM_MCR register. So on some boards it could happen that the
>     UPLL is used for clock source, which results in faulty time behavior in Linu
>     In this case all delays or sleeps will will be faktor 1.8 too long.
>     
>     Signed-off-by: Torsten Mehnert <t.mehnert@domain.hid>
>     Signed-off-by: Sascha Hauer <s.hauer@domain.hid>
> 
> 
> On 04/19/2012 12:55 PM, Gilles Chanteperdrix wrote:
>> On 04/19/2012 12:02 PM, Michael Trimarchi wrote:
>>> Hi,
>>>
>>> I will send a proper patch. Is it possible to include in the ipipe-arm branch?
>>>
>>> Michael
>>
>> Yes, OK. Please resend the patch to the xenomai-core, or adeos-main
>> mailing list, I see ipipe-arm is broken since at least 2.6.33. It
>> compiles but probably does not work.
>>
> 
> I'm still debugging my imx25 board, and I have problem with the timer. If I execute
> clocktest for xenomai after some while I have:
> 
> 
> now at 2897236425903 nsecs
> 
> cpu: 0
>  clock 0:
>   .base:       c04f26a8
>   .index:      0
>   .resolution: 1 nsecs
>   .get_time:   ktime_get
>   .offset:     0 nsecs
> active timers:
>  #0: <c04f2c00>, tick_sched_timer, S:01
>  # expires at 2889380000000-2889380000000 nsecs [in -7856425903 to -7856425903 nsecs]
>  #1: <c3aa1f38>, hrtimer_wakeup, S:01
>  # expires at 2889470961229-2889471011229 nsecs [in -7765464674 to -7765414674 nsecs]
>  #2: <c3a97f38>, hrtimer_wakeup, S:01
>  # expires at 2889508847229-2889508897229 nsecs [in -7727578674 to -7727528674 nsecs]
>  #3: <c0510648>, sched_rt_period_timer, S:01
>  # expires at 2890000000000-2890000000000 nsecs [in -7236425903 to -7236425903 nsecs]
>  #4: <c04f2d68>, watchdog_timer_fn, S:01
>  # expires at 2892070000002-2892070000002 nsecs [in -5166425901 to -5166425901 nsecs]
> 
> 
> And I don't have any tick from the i.Mx timer until they wrap again to be positive.
> Can you suggest some way to debug? Do you know what it can happen?

If you have CONFIG_MXC_IRQ_PRIO enabled, disable it, this option is
incompatible with xenomai.

-- 
					    Gilles.