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 (r
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
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
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:
> 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_
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)
>> ipipe_trigger_irq(__ip
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
Gilles Chanteperdrix wrote:
> 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 wh
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.
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.
>> Ju
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:
>>> 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
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
__i
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.
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 jeudi 29 juin 2006 à 10:38 +0200, Detlef Vollmann a écrit :
> Hello,
Hi,
>
> 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
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?
17 matches
Mail list logo
