Detlef Vollmann wrote:
...
And I think you're correct, for Xenomai it will work.
Unfortunately I'm trying to do a general ipipe port for PXA.
I'm doing this for a polytech who wants to use this with their
students, and so they probably want to use it with other domain
on top of ipipe (rtai
Detlef Vollmann wrote:
Gilles Chanteperdrix wrote:
You can even do this in __ipipe_mach_set_dec, this avoid the need to
modify I-ipipe non-machine specific code. Something like:
void __ipipe_mach_set_dec(unsigned long delay)
{
if (delay 8)
Jan Kiszka wrote:
It's this piece of code always running under IRQ-lock?
No. ipipe_tune_timer() is a public ipipe interface and can
be called from everywhere.
The IRQ is marked pending for the receiving domain if
ipipe_trigger_irq() is called when that domain is stalled - and that
should
Detlef Vollmann wrote:
Jan Kiszka wrote:
It's this piece of code always running under IRQ-lock?
No. ipipe_tune_timer() is a public ipipe interface and can
be called from everywhere.
Oops, sorry. I was talking nonsense.
Yes, it is always running under IRQ-lock (and I'm doing the lock
Gilles Chanteperdrix wrote:
Detlef Vollmann wrote:
I'll just add another test after the update of OSMR0 for the
case that we got interrupted between the comparison and the
assignment. And in that (probably very rare) case I accept that
I loose a timer tick :-(
I do not see what
Gilles Chanteperdrix wrote:
You can even do this in __ipipe_mach_set_dec, this avoid the need to
modify I-ipipe non-machine specific code. Something like:
void __ipipe_mach_set_dec(unsigned long delay)
{
if (delay 8)
ipipe_trigger_irq(__ipipe_mach_timerint);
else
Detlef Vollmann wrote:
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.
Just out of curiosity: What is the technical background of this
Jan Kiszka wrote:
Detlef Vollmann wrote:
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.
Just out of curiosity: What is the
Detlef Vollmann wrote:
Jan Kiszka wrote:
Detlef Vollmann wrote:
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.
Just out of curiosity:
Detlef Vollmann wrote:
It's not so difficult to work around the problem for a single system.
What's difficult is to find a solution in a framework that wasn't
built with such a problem in mind.
Actually, all architectures have a delay below which they can not be
reprogrammed fast enough.
Stelian Pop wrote:
Le vendredi 30 juin 2006 à 08:29 +0200, Detlef Vollmann a écrit :
__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).
In your implementation for the Integrator you set timer_reload in
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?
What about the
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
Hello,
looking at the ARM Integrator patch (which seems to be something
like the reference port for ARM), I'm not really clear about some
of the code:
a) What's the difference between __ipipe_mach_ticks_per_jiffy
and LATCH?
b) Is there some (hidden, intended future) semantics of tscok?
14 matches
Mail list logo
