Re: [Xenomai] s3c24xx with clocksource/clockevent (kernel 3.2.21)

[Romain Naour <romain.naour@openwide.fr>]

Le 19/10/2012 14:18, Gilles Chanteperdrix a écrit :
> On 10/19/2012 12:19 PM, Romain Naour wrote:
>> Hi Gilles,
>>
>> First, I followed your advice and I converted the timers to
>> clocksouce/clockevent framework.
>>> Other things which could be done for s3c24xx are:
>>> - convert the timers to clocksource/clockevent: since this platform is
>>> the only one not to use clocksource/clockevent, we have to keep code
>>> around for this case in xenomai-forge which could be removed. Having two
>>> different timers for clocksource and clockevent would allow to avoid the
>>> tsc emulation based on the decrementer, which I am not sure is really
>>> reliable since the conversion to CONFIG_IPIPE_ARM_KUSER_TSC.
>> I had to reduce timers frequency to 4,21MHz in order to produce an
>> timer's overflow every 15,5ms.
As timers are previously used to produce an IRQ at 200Hz, some board use 
an external 12MHz signal to clock the timers.
So it is not possible to reduce the overflow period... (use_tclk1_12() 
== 1).
I need to check if I can use internal clock instead.
> For such overflow period, I would recommend running __ipipe_update_tsc
> in the acktimer routine.
What is the recommended frequency for the TSC timer?
I can reduce timers frequency to 1MHz in order to have a longer overflow 
period.
>> At 8,45Mhz it does not work.
>> Thanks to this, I am able to activate hrtimer on Linux :)
>>
>> Secondly, I adapted the code for Adeos (Xenomai 2.6.1).
>> But I'm not sure about the tsc emulation...
>> Should I keep using the IPIPE_TSC_TYPE_DECREMENTER ?
>> Do you think we need something like
>> IPIPE_TSC_TYPE_FREERUNNING_COUNTDOWN_16 ?
> The type should correspond to the type of the hardware timer you are
> using, I do not know if you are using the decrementer as clocksource, or
> a separate freerunning countdown timer, so, I can not answer.
There are five 16bits down counter (decrementer) timers in the s3c2440.
I'm using the timer 3 as clocksource with auto-reload mode (reload value 
is 0xFFFF).
(Which is not exactly an free-running down counter...)
Timer 4 is the clockevent.
> You should run tsc -w to see if the tsc is wrapping correctly.
tsc -w with latency test in parallel (test-tsc.txt):
min: 0, max: 14, avg: 0.923722 -> 0.218956 us
it's good.
>> In order to adjust scheduling latency, I set /proc/xenomai/latency to 0
>> But I still have negative latency
>>
>> (test-latency.txt)
>> # echo 0 >/proc/xenomai/latency
>> # latency
>> == Sampling period: 1000 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat
>> best|--lat worst
>> RTD|     -0.238|     16.592|     57.599|       0|     0| -0.238|     57.599
>> RTD|      5.925|     16.829|     83.911|       0|     0| -0.238|     83.911
>> RTD|      5.688|     16.829|     78.696|       0|     0| -0.238|     83.911
>> RTD|      5.688|     16.829|     80.355|       0|     0| -0.238|     83.911
>> RTD|      5.925|     17.066|     75.140|       0|     0| -0.238|     83.911
>> RTD|     -0.712|     18.251|     84.622|       0|     0| -0.712|     84.622
>> RTD|      5.925|     16.829|     76.088|       0|     0| -0.712|     84.622
>> RTD|      5.688|     16.829|     73.481|       0|     0| -0.712|     84.622
>> ...
>>
>> Can you tell me If this seems good.
> You can look at /proc/xenomai/timer to see if the timer calibration does
> not give a too large value.
# cat /proc/xenomai/timer
status=on+watchdog:setup=3555:clock=126115699801:timerdev=s3c24xx_event_timer:clockdev=ipipe_tsc

Setup = nklatency = 3555 (ns)
>   As a general advice, the "set_next_event"
> callback should make as few register accesses as possible, sometimes
> register accesses may be slow.
I understand, but I have to do a "manual update" to reload the timer 
with a new value.
Which requires 1 read and 3 write.
>> Finally, I add a last patch because I had a problem with the debug port.
>> The Tx IRQ was not unmasked by root domain in some circumstances.
>> Therefore, the debug console hangs when you type "dmesg", "ls"...
>> kernel 2.6.38.8 is not affected by this bug, but i found It with kernel
>> 3.0.36.
> That is a nice work, however working with 3.0 was maybe not the best
> choice. Please:
> - upgrade to the latest linux version (3.7) and post your patches
> (converting to clockevent/clocksource) on the linux arm kernel mailing
> list, you will probably go over several iterations before the patches
> are accepted;
> - when they are accepted, backport them to the latest version of the
> I-pipe kernel (it is currently 3.4, but could be 3.5 soon).
>
> Note that moving the clockevent/clocksource code to 3.7 is probably not
> a lot of work, and getting this work integrated in mainline means that
> you can benefit from other people using and testing the code you wrote.
>
> We currently have an up to date documentation on how to port the I-pipe
> patch to a new arm board for such recent versions:
> http://xenomai.org/index.php/I-pipe-core:ArmPorting
>
Thank you very much, I appreciate your comment.
I'll try to do that, I'm preparing 3.7-rc1 kernel for my mini2440.

Until now, I used the latest supported kernel 3.2.21 with Xenomai 2.6.1.
Without rework timer system with clocksource and clockevent,
I need to set "s3c2410_itimer.min_delay_ticks" value 
(s3c24xx_fix_itimer.patch)
Otherwise the timer hangs.
And also, the last patch of my previous mail.

Regards,
Romain
-------------- next part --------------
# ./tsc -w
ARM: counter wrap time: 1 seconds
Checking tsc for 1 minute(s)
min: 0, max: 12, avg: 0.924279
min: 0, max: 13, avg: 0.923064
min: 0, max: 8, avg: 0.923259
min: 0, max: 8, avg: 0.924853
min: 0, max: 10, avg: 0.924099
min: 0, max: 10, avg: 0.923186
min: 0, max: 13, avg: 0.923514
min: 0, max: 11, avg: 0.924487
min: 0, max: 8, avg: 0.923202
min: 0, max: 13, avg: 0.923552
min: 0, max: 7, avg: 0.922993
min: 0, max: 11, avg: 0.923254
min: 0, max: 12, avg: 0.9238
min: 0, max: 11, avg: 0.92347
min: 0, max: 7, avg: 0.923207
min: 0, max: 12, avg: 0.923048
min: 0, max: 8, avg: 0.923853
min: 0, max: 12, avg: 0.923297
min: 0, max: 12, avg: 0.924282
min: 0, max: 7, avg: 0.923173
min: 0, max: 12, avg: 0.924477
min: 0, max: 10, avg: 0.925115
min: 0, max: 10, avg: 0.923965
min: 0, max: 12, avg: 0.922714
min: 0, max: 13, avg: 0.924288
min: 0, max: 8, avg: 0.924375
min: 0, max: 8, avg: 0.924003
min: 0, max: 11, avg: 0.923907
min: 0, max: 11, avg: 0.923686
min: 0, max: 12, avg: 0.923409
min: 0, max: 8, avg: 0.923861
min: 0, max: 8, avg: 0.923181
min: 0, max: 11, avg: 0.923351
min: 0, max: 7, avg: 0.923782
min: 0, max: 12, avg: 0.923809
min: 0, max: 13, avg: 0.923599
min: 0, max: 8, avg: 0.922992
min: 0, max: 8, avg: 0.924291
min: 0, max: 14, avg: 0.923375
min: 0, max: 12, avg: 0.923681
min: 0, max: 12, avg: 0.923767
min: 0, max: 10, avg: 0.922629
min: 0, max: 8, avg: 0.922909
min: 0, max: 8, avg: 0.923569
min: 0, max: 8, avg: 0.923693
min: 0, max: 12, avg: 0.923474
min: 0, max: 11, avg: 0.924789
min: 0, max: 7, avg: 0.923447
min: 0, max: 8, avg: 0.924191
min: 0, max: 10, avg: 0.924278
min: 0, max: 10, avg: 0.924057
min: 0, max: 12, avg: 0.923687
min: 0, max: 10, avg: 0.923998
min: 0, max: 7, avg: 0.92359
min: 0, max: 8, avg: 0.923864
min: 0, max: 7, avg: 0.92408
min: 0, max: 12, avg: 0.923517
min: 0, max: 13, avg: 0.924131
min: 0, max: 12, avg: 0.923814
min: 0, max: 13, avg: 0.924085
min: 0, max: 14, avg: 0.923722 -> 0.218956 us
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-0004_s3c24xx_fix_itimer.patch
Type: text/x-patch
Size: 493 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20121020/240341d4/attachment.bin>