Does fusion-0.7.2 support nested interrupts?

[Philippe Pétillon]

> -----Message d'origine-----
> De : Philippe Gerum [mailto:rpm at xenomai.org]
> Envoyé : vendredi 10 juin 2005 17:17
> À : Philippe Pétillon
> Cc : rtai at rtai.org
> Objet : Re: Does fusion-0.7.2 support nested interrupts?
>
>
> Philippe Pétillon wrote:
> > Do you think using a hw_unlock/hw_lock scheme in every ISR is
> practical? You
> > may, but I don't.
> >
>
> Using hw_unlock/hw_lock is not the proper way to do this, using
> xnlock_put_irqrestore()/xnlock_get_irqsave() is.

OK, if you prefer, but my software will never run on a SMP machine anyway.
Not everyone is using PCs!!!

>
> Maybe one should first ponder about the penalty of trashing the I-cache
> by taking another ISR compared to quickly getting out of the inner one
> which should be designed to have a bounded complexity and run fast
> anyway. Unless your do much of your work in the ISR, the latter is
> better wrt concurrency. In case the ISR does heavy processing, one may
> want to consider moving most of the complexity to a thread context.
>

I don't want to enter this kind of debate but I won't agree with you: cache
performances
are non-realtime issues, and if I need to respond to an event in a few
microsecs,
I really can't rely on other interrupts to be fast enough. I need to have my
interrupt at
the highest priority (hw PICs are done for that) and to be sure of the
maximum it latency.

> > Anyway, how would you do this in xnintr_irq_handler (the nested variable
> > makes me guess very much that it should be done there),
>
> No, it should be done in your ISR, not in the nucleus.
>
>   as the
> > IPIPE_STALL_FLAG is set in __adeos_sync_stage before entering
> the routine?
> > Of course the interrupts are re-enabled, but they do not reach
> the ISR level
> > because they are differred in __adeos_walk_pipeline?
>
> They won't be deferred. If the stage is unstalled while an interrupt
> occurs for the current domain, the interrupt log will be immediately
> synchronized by __adeos_walk_pipeline() on behalf of the current
> interrupt frame.
>

On the version I use (fusion-0.7.2, adeos r7c1/ppc ported on ARM), it is not
the case.
In __adeos_sync_stage, the line
"__set_bit(IPIPE_STALL_FLAG,&cpudata->status);" stalls the pipe
for my domain before trigerring the ISR, and after the ISR, the pipe is
unstalled.
If another interrupt occurs, it will be added to the pending list.
I just checked it with an ISR that triggers another one with higher
priority.

But maybe this has changed in newer version of adeos?


> >
> > -----Message d'origine-----
> > De : Philippe Gerum [mailto:rpm at xenomai.org]
> > Envoyé : vendredi 10 juin 2005 16:40
> > À : Philippe Pétillon
> > Cc : rtai at rtai.org
> > Objet : Re: Does fusion-0.7.2 support nested interrupts?
> >
> >
> > Philippe Pétillon wrote:
> >
> >>Hello!
> >>A small question about fusion-0.7.2.
> >>
> >>Does it support nested interrupts? If yes, how to enable it?
> >
> >
> > If your ISR re-enables interrupts, nesting will occur safely on top of
> > fusion's primary interrupt handler, since Adeos allows it too.
> >
> >
> >>If not, how do you think you can build a real-time system above it?
> >>
> >
> >
> > Read the code. Emacs is your friend.
> >
> >
> >>
> >>
> >>*Philippe Pétillon*
> >>SPiDCOM Technologies
> >>137, avenue du Général Leclerc
> >>92340 Bourg la Reine
> >>
> >>FRANCE
> >>
> >>
> >>
> >>Tel: +33 1 41 87 91 90
> >>
> >>email: philippe.petillon at spidcom.com
> >
> > <mailto:philippe.petillon at spidcom.com>
> >
> >>www.spidcom.com <http://www.spidcom.com/>
> >>
> >>
> >
> >
> > --
> >
> > Philippe.
> >
>
>
> --
>
> Philippe.
>