Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...
Gregory CLEMENT wrote: > 2007/6/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>: > > Gilles Chanteperdrix wrote: > > > BOUIN Alexandre wrote: > > > > We (Adeneo) are working on a ARM AT91 RTAI. We encountered > > some difficulties such tsc one : in periodic mode, we reload our timer > > automatically in order to avoid reprogramming it. TC timer increments a 16 > > byte register, which is not enough for a tsc (64 bytes). tsc need to be > > emulated on ARM. > > > > With oneshot mode, tsc is updating the 4 least significant > > bytes and then increments other bytes each time counter go back to zero > > value. > > > > > > > > With our periodic mode, timer reloads himself so we need > > to change tsc emulation by incrementing tsc like this : tsc += period. > > > > We made some evolutions on ipipe which will be applied to > > a hal patch. > > > > > > I intend to rework I-pipe tsc emulation for arms with a free-running > > > counter. In order to reduce the tsc read operations: > > > - it should use the (uninterruptible) ldm instruction to load the 64 > > > bits counter without masking interrupts; > > > - the 64 bits counter should not be updated at each read, but only from > > > time to time, the best place to do this is Linux timer interrupt. > > > > I never did the calculation before, but the TC free-running counter > > wraps every 40 milliseconds, so Linux timer interrupt is not often > > How do you get this 40 ms ? > For me TC free-running counter wraps every (2^16)/(MCK/32) > For AT91RM9200-EK MCK=59904000 so we get 35ms > For AT91SMA926x-EK MCK=99328000 so we get 21ms > I am wrong? It was a rough estimation. > > enough to update the 64 bits counter. The only safe place to update the > > 64 bits counter seems to be __ipipe_mach_acktimer. > > As Linux timer period is 10ms why do you think is not often enough ? Because when Linux has a lot of work to do, or when Xenomai has a lot of work to do, Linux timer may be delayed for more than 4 ticks. > > For AT91SAM926x what do you think of using PIT for emulating tsc, > (with PIT we can have a 32 bit counter) ? Good, if it helps reducing the overhead of ipipe_read_tsc. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...
2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>: > BOUIN Alexandre wrote: > > We (Adeneo) are working on a ARM AT91 RTAI. We encountered > some difficulties such tsc one : in periodic mode, we reload our timer > automatically in order to avoid reprogramming it. TC timer increments a 16 > byte register, which is not enough for a tsc (64 bytes). tsc need to be > emulated on ARM. > > With oneshot mode, tsc is updating the 4 least significant > bytes and then increments other bytes each time counter go back to zero value. > > > > With our periodic mode, timer reloads himself so we need to > change tsc emulation by incrementing tsc like this : tsc += period. > > We made some evolutions on ipipe which will be applied to a > hal patch. > > I intend to rework I-pipe tsc emulation for arms with a free-running > counter. In order to reduce the tsc read operations: > - it should use the (uninterruptible) ldm instruction to load the 64 > bits counter without masking interrupts; > - the 64 bits counter should not be updated at each read, but only from > time to time, the best place to do this is Linux timer interrupt. If 64 bits counter is not updated at each read, we still need to load it, read the current value of free-running counter, compare it to its last value when 64 bits counter was updated. If we don't do this we loose granularity. So the gain is only on not writing the 64 bits counter, or maybe I missed something ? -- Gregory CLEMENT Adeneo 2, chemin du Ruisseau - BP21 69136 Ecully Cedex France Tel : +33-4 72 18 08 40 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...
2007/6/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>: > Gilles Chanteperdrix wrote: > > BOUIN Alexandre wrote: > > > We (Adeneo) are working on a ARM AT91 RTAI. We encountered > some difficulties such tsc one : in periodic mode, we reload our timer > automatically in order to avoid reprogramming it. TC timer increments a 16 > byte register, which is not enough for a tsc (64 bytes). tsc need to be > emulated on ARM. > > > With oneshot mode, tsc is updating the 4 least significant > bytes and then increments other bytes each time counter go back to zero value. > > > > > > With our periodic mode, timer reloads himself so we need to > change tsc emulation by incrementing tsc like this : tsc += period. > > > We made some evolutions on ipipe which will be applied to a > hal patch. > > > > I intend to rework I-pipe tsc emulation for arms with a free-running > > counter. In order to reduce the tsc read operations: > > - it should use the (uninterruptible) ldm instruction to load the 64 > > bits counter without masking interrupts; > > - the 64 bits counter should not be updated at each read, but only from > > time to time, the best place to do this is Linux timer interrupt. > > I never did the calculation before, but the TC free-running counter > wraps every 40 milliseconds, so Linux timer interrupt is not often How do you get this 40 ms ? For me TC free-running counter wraps every (2^16)/(MCK/32) For AT91RM9200-EK MCK=59904000 so we get 35ms For AT91SMA926x-EK MCK=99328000 so we get 21ms I am wrong? > enough to update the 64 bits counter. The only safe place to update the > 64 bits counter seems to be __ipipe_mach_acktimer. As Linux timer period is 10ms why do you think is not often enough ? For AT91SAM926x what do you think of using PIT for emulating tsc, (with PIT we can have a 32 bit counter) ? -- Gregory CLEMENT Adeneo 2, chemin du Ruisseau - BP21 69136 Ecully Cedex France Tel : +33-4 72 18 08 40 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] AT91 patch duplicated code ...
2007/6/9, Gilles Chanteperdrix <[EMAIL PROTECTED]>: > Gregory CLEMENT wrote: > > 2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>: > > > BOUIN Alexandre wrote: > > > > > > > > > When we released our last version of > adeos-ipipe-2.6.19-arm-AT91.patch, we suggested to merge code for at91rm9200 > and at91sam926x. > > > > > These 2 code are split but quite similar, so we think it could be a > good idea. Are you OK for removing duplicated code ? > > > > > > If I have to choose between duplicating some Linux code in I-pipe code > > > and have some duplication in the I-pipe patch, I choose duplication in > > > the I-pipe patch. If you duplicate Linux code, you will have to avoid > > > forgetting to update this duplicate code when Linux code evolves. > > > > > > > Well the first mail wasn't very clear. I am going to explain what we > > have in mind. > > > > In Linux code for AT91 timer there are two files: at91sam926x_time.c > > and at91rm9200_time.c because AT91RM9200 and AT91SAM926x have > > different system timer: AT91RM9200 use AT91_ST peripheral and > > AT91SAM926x use AT91_PIT peripheral. > > I was somehow thinking that there was something else in at91xx_time.c > than what is enclosed in #ifdef CONFIG_IPIPE. I was wrong. > > Now, I have another question: is there no way to use the AT91_PIT > peripheral in one shot mode ? PIT is for Peridodic Interval Timer, and after reading the datasheet it seems that this peripheral is not made for one shot timer. All we can do is force PIT to stop after a reset but in all case when PIT reach the programmable overflow it reset. We can't use it a free running counter. > What is the resolution of this PIT ? The resolution of PIT is MCK/16 > In any case, please send a patch, this will make a real base for > discussion. Ok I will try to do that. -- Gregory CLEMENT Adeneo 2, chemin du Ruisseau - BP21 69136 Ecully Cedex France Tel : +33-4 72 18 08 40 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] periodic mode in adeos-ipipe for arm at91 ...
Gilles Chanteperdrix wrote: > BOUIN Alexandre wrote: > > We (Adeneo) are working on a ARM AT91 RTAI. We encountered some > difficulties such tsc one : in periodic mode, we reload our timer > automatically in order to avoid reprogramming it. TC timer increments a 16 > byte register, which is not enough for a tsc (64 bytes). tsc need to be > emulated on ARM. > > With oneshot mode, tsc is updating the 4 least significant > bytes and then increments other bytes each time counter go back to zero > value. > > > > With our periodic mode, timer reloads himself so we need to > change tsc emulation by incrementing tsc like this : tsc += period. > > We made some evolutions on ipipe which will be applied to a hal > patch. > > I intend to rework I-pipe tsc emulation for arms with a free-running > counter. In order to reduce the tsc read operations: > - it should use the (uninterruptible) ldm instruction to load the 64 > bits counter without masking interrupts; > - the 64 bits counter should not be updated at each read, but only from > time to time, the best place to do this is Linux timer interrupt. I never did the calculation before, but the TC free-running counter wraps every 40 milliseconds, so Linux timer interrupt is not often enough to update the 64 bits counter. The only safe place to update the 64 bits counter seems to be __ipipe_mach_acktimer. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH-STACK] LTTng update
Before I forget it: I uploaded a rebased version of my patch stack this morning, see http://www.rts.uni-hannover.de/rtaddon/patches This series also includes a new version of the LTTng patch for Xenomai. The patch moves the probe arming into a separate module, ltt-probe-xeno.ko, allowing the nucleus to be built into kernel again when LTTng is enabled. For now it is only one module, i.e. facility, so that it still matches with the lttv patch. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] AT91 patch duplicated code ...
Gregory CLEMENT wrote: > 2007/6/8, Gilles Chanteperdrix <[EMAIL PROTECTED]>: > > BOUIN Alexandre wrote: > > > > > > > When we released our last version of > > adeos-ipipe-2.6.19-arm-AT91.patch, we suggested to merge code for > > at91rm9200 and at91sam926x. > > > > These 2 code are split but quite similar, so we think it could be a > > good idea. Are you OK for removing duplicated code ? > > > > If I have to choose between duplicating some Linux code in I-pipe code > > and have some duplication in the I-pipe patch, I choose duplication in > > the I-pipe patch. If you duplicate Linux code, you will have to avoid > > forgetting to update this duplicate code when Linux code evolves. > > > > Well the first mail wasn't very clear. I am going to explain what we > have in mind. > > In Linux code for AT91 timer there are two files: at91sam926x_time.c > and at91rm9200_time.c because AT91RM9200 and AT91SAM926x have > different system timer: AT91RM9200 use AT91_ST peripheral and > AT91SAM926x use AT91_PIT peripheral. I was somehow thinking that there was something else in at91xx_time.c than what is enclosed in #ifdef CONFIG_IPIPE. I was wrong. Now, I have another question: is there no way to use the AT91_PIT peripheral in one shot mode ? What is the resolution of this PIT ? In any case, please send a patch, this will make a real base for discussion. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
