[okl4-developer] OKL4 v2.1: Behaviour of the CONTINUATION macros/scheme

Frank Kaiser frank.kaiser at opensynergy.com
Thu Jun 26 18:00:30 EST 2008


Hello, Ashish

Theoretically that might be possible for interrupts installed by the
user, but due to the asynchronous IPC signalling of interrupts a call to
'config_interrupts()' would not be in the scope of the interrupt service
routine. And it won't work for interupts handled by the kernel. The EOI
signal has to be given at the end of the ISR, before control is returned
to normal program execution.

Thanks for your help attempt
Frank
> -----Original Message-----
> From: Ashish Bijlani [mailto:ashish.bijlani at gmail.com]
> Sent: Thursday, June 26, 2008 1:24 AM
> To: Frank Kaiser
> Cc: developer at okl4.org
> Subject: Re: [okl4-developer] OKL4 v2.1: Behaviour of the CONTINUATION
> macros/scheme
> 
> Can't you do it in config_interrupt function under ack_wait/ack
condition?
> 
> On Wed, Jun 25, 2008 at 11:56 AM, Frank Kaiser
> <frank.kaiser at opensynergy.com> wrote:
> > Hello
> >
> >
> >
> > I have a difficulty with the interrupt handling of the ARM platform.
The
> > central interrupt hamdler Platform::handle_interrupt() uses the
CONTINUATION
> > scheme in a way that it expects all called subhandlers to return to
the
> > place in 'traps.spp' from where it has been called. The problem is
that the
> > interrupt controller of my ATMEL AT91SAM9263 platform requires a
specific
> > end-of-interrupt operation before the interrupt context is left.
Since this
> > is platform-specific, I don't want to do this in 'traps.spp',
because this
> > file is platform-independent (i. e. it is generic for ARMv5). So I
prefer to
> > place the EOI operation in the platform specific 'interrupt.cc' and
make the
> > subhandlers call it before control returns to 'traps.spp'. I have
already
> > seen that one can declare his own CONTINUATION_FUNCTION(), and there
is a
> > function call_with_asm_continuation(), which seems to make the
function
> > given as 4th parameter to return to the function given as 3rd
parameter, but
> > it does not look as if this fully satisfies what is required for the
> > interrupt handler call chain.
> >
> > Any hint to solve my problem would be appreciated.
> >
> >
> >
> > Regards
> >
> > Frank
> >
> > _______________________________________________
> > Developer mailing list
> > Developer at okl4.org
> > https://lists.okl4.org/mailman/listinfo/developer
> >
> >



More information about the Developer mailing list