Re: [Xenomai] Testing on Freescale i.MX6

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

On 05/07/2014 07:20 PM, Ralf Rösch wrote:
>
> Am 05.05.2014 13:44, schrieb Gilles Chanteperdrix:
>> Unfortunately, I have not experienced the high latencies myself,
>> probably because I tested the system without display. Anyway, from
>> what I understood, if you want good latencies, you have to disable the
>> L2 cache write-allocate policy.
>>
> which is default in >= 3.10?

It is modified in the git for 3.10, but the patch has not been generated 
I believe.

> I found a hack which solves my problem:
>
> diff --git a/arch/arm/kernel/ipipe_tsc.c b/arch/arm/kernel/ipipe_tsc.c
> index 4eb5050..f759a20 100644
> --- a/arch/arm/kernel/ipipe_tsc.c
> +++ b/arch/arm/kernel/ipipe_tsc.c
> @@ -132,6 +132,11 @@ void __init __ipipe_tsc_register(struct
> __ipipe_tscinfo *info)
>                              (unsigned long)(tsc_area + 0x80));
>           hard_local_irq_restore(flags);
>
> +#ifdef CONFIG_CPU_FREQ_GOV_PERFORMANCE
> +       if (registered)
> +               tsc_info.freq = 498000000;
> +#endif
> +
>           printk(KERN_INFO "I-pipe, %u.%03u MHz clocksource\n",
>                  tsc_info.freq / 1000000, (tsc_info.freq % 1000000) / 1000);
>           if (!registered)

To do the same thing cleanly, you should call ipipe_tsc_register again 
when the frequency changes, unfortunately, it does not fix the timer 
frequency, so, you will experience a lot of useless timer interrupts.
IOW, the problem is not really solved. The best workaround I found for 
the freescale kernel 3.0 is to start the processor directly with the 
target frequency (people want fast boots usually, so booting with the 
highest frequency makes more sense anyway), this also avoids having to 
enable cpufreq. Which is why I told you to look at this patch for the 
solution to your problem.

> In Kernel 3.10 (Freescale) I did not observe this type of error (i have
> tested for about 2 days).
> Do you know how much the max. latency could be involved when this sort
> of error is triggered?

This error probably has nothing to do with latency (interrupt latency or 
scheduling latency, as returned by cyclictest or the latency test as 
what we mean on this list when we say latency without precising latency 
of what). You may want to look at the freescale kernel to see if it does 
not have any patch regarding mmc.

>
> [3]
> BTW i have attached an other patch which might be helpful.

Thanks, will merge.



-- 
					    Gilles.