From: Stelian Pop <stelian.pop@domain.hid>
To: Detlef Vollmann <dv@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] Some questions about the ARM port (Integrator vs. PXA)
Date: Fri, 30 Jun 2006 10:53:41 +0200 [thread overview]
Message-ID: <1151657621.3060.26.camel@domain.hid> (raw)
In-Reply-To: <44A4C4CB.5F24DA68@domain.hid>
Le vendredi 30 juin 2006 à 08:29 +0200, Detlef Vollmann a écrit :
> Stelian Pop wrote:
> > Le jeudi 29 juin 2006 à 10:38 +0200, Detlef Vollmann a écrit :
>
> > > a) What's the difference between __ipipe_mach_ticks_per_jiffy
> > > and LATCH?
> >
> > As a matter of fact there is no difference.
> Does this mean that __ipipe_mach_ticks_per_jiffy never changes?
Indeed.
> What about the correlation between __ipipe_mach_set_dec() and
> __ipipe_mach_ticks_per_jiffy? __ipipe_mach_set_dec() seems
> to do a permanent change, and not only a one-time change.
__ipipe_mach_set_dec sets the *next* timer occurence. It functions in a
one-shot way (like a real decrementer, not a auto-reloading one).
> Is the Linux timer interrupt still only called after LATCH ticks?
IPipe doesn't do anything special to the timer (except for acking the
interrupt because this must be done early in some cases).
If Linux handles the timer, then nothing changes, the timer frequency is
LATCH.
If Xenomai handles the timer, then it is its responsability to propagate
the interrupt to Linux when it wants to (look for xnarch_relay_tick() in
Xenomai's nucleus).
> Now I have another question on this: on the PXA I have a hardware
> problem so that I must sometimes set the next match value to the
> match value after the next one, so effectively loosing one
> interrupt.
> If Linux is responsible for reprogramming the timer, I should tell
> ipipe about it, so that ipipe can tell any other domain.
> How can I do that?
If Linux is responsible for reprogramming the timer there is a good
chance there is no other domain, so it doesn't matter much :)
But you will have a problem when Xenomai takes upon the timer, because
its scheduler doesn't expect to lose timer ticks.
I can imagine adding a return code to __ipipe_mach_set_dec() which would
tell if the hardware has been programmed successfully or not, and in
this latter case Xenomai (or ipipe ?) would have to busy sleep until the
next (calculated) timer occurence... What do the experts think ?
Stelian.
--
Stelian Pop <stelian.pop@domain.hid>
next prev parent reply other threads:[~2006-06-30 8:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-29 8:38 [Xenomai-core] Some questions about the ARM port (Integrator vs. PXA) Detlef Vollmann
2006-06-29 14:46 ` Stelian Pop
2006-06-30 6:31 ` Detlef Vollmann
[not found] ` <44A4C4CB.5F24DA68@domain.hid>
2006-06-30 8:53 ` Stelian Pop [this message]
2006-07-03 5:56 ` Detlef Vollmann
2006-07-03 6:33 ` Jan Kiszka
2006-07-03 8:38 ` Detlef Vollmann
2006-07-03 9:37 ` Jan Kiszka
2006-07-03 12:39 ` Gilles Chanteperdrix
2006-07-03 13:00 ` Gilles Chanteperdrix
2006-07-04 6:43 ` Detlef Vollmann
2006-07-04 14:09 ` Jan Kiszka
2006-07-05 22:32 ` Detlef Vollmann
2006-07-05 22:42 ` Detlef Vollmann
2006-07-05 13:03 ` Gilles Chanteperdrix
2006-07-05 23:44 ` Detlef Vollmann
2006-07-06 7:15 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1151657621.3060.26.camel@domain.hid \
--to=stelian.pop@domain.hid \
--cc=dv@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.