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

[Frank Kaiser]

Hello, Geoffrey

The Interrupt controller on the AT91SAM9263 supports 8 priority levels,
and interrupts can be nested. The special EOI signal serves to
acknowledge that an ISR of the given priority has terminated. Provided
that interrupts are enabled on core level and at the source, an
interrupt of a higher priority can interrupt the current ISR while one
of lower priority cannot. If I give EOI at the beginning of the ISR,
then the priority state is lost and a lower priority interrupt could
interrupt the current ISR leading to a priority inversion. This makes it
mandatory to put the EOI at the end of the ISR.
For the time being I am not addressing the user level interrupt handling
supported by the SYS_CALL 'config_interrupt', but the kernel interrupt
handling covered by function 'handler_interrupt()'. For instance, the
kernel scheduler 'PlatformSupport::schedule()' is driven by a periodic
interval timer and receives a 'continuation_t' object letting it
directly return to the address before which 'handler_interrupt()' is
called in traps.spp. I have to assure that the EOI signal is given after
the scheduler has terminated and before control returns to traps.spp.
My solution attempt is that I have written my own continuation function
which contains the EOI signal and then executes ACTIVATE_CONTINUATION()
with a 'continuation_t' object holding the return address of
'handler_interrupt()'. This is achieved by assigning ASM_CONTINUATION to
a persistent variable at the beginning of 'handler_interrupt()' while
the specific interrupt handlers receive my new continuation function. I
hope this will work.
Whether this will be a solution for user level interrupts depends on how
they work. When interrupts are signalled asynchronously thru IPC, then I
assume that the user code will never execute in an ISR context. The
right point for issuing EOI depends on the latency between the assertion
of the interrupt and the scheduling of the user code, about which I have
no clear picture yet.

Regards
Frank
> -----Original Message-----
> From: Geoffrey Lee [mailto:glee at ok-labs.com]
> Sent: Friday, June 27, 2008 9:29 AM
> To: Ashish Bijlani
> Cc: Frank Kaiser; developer at okl4.org
> Subject: Re: [okl4-developer] OKL4 v2.1: Behaviour of the
> CONTINUATIONmacros/scheme
> 
> On Thu, Jun 26, 2008 at 11:56:37AM -0500, Ashish Bijlani wrote:
> > Hi Frank,
> 
> 
> Hi Frank
> 
> When an interrupt is raised, the interrupt controller
> in OKL4 will mask and acknowledge the interrupt.  Control is
> then handed over to the registered interrupt handler in user-space.
> User-space signals that the interrupt has been handled by
> calling InterruptControl(), at which point the interrupt controller
> is asked to unmask the interrupt.
> 
> As Ashish points out, arch/ia32/pistachio/cpu/idt/src/intctrl-pic.cc
> provides a practical example of how you can implement this in OKL4.
> Are you using some sort of interrupt controller where it is not
possible to
> mask the interrupt and send an EOI before the interrupt has been
> handled by the hardware which raised the interrupt?
> 
> 	-gl
> 
> 
> >
> > You can look at "arch/ia32/pistachio/cpu/idt/src/intctrl-pic.cc" the
> > master.ack/slave.ack func sends platform (8259) specific EOI. Hope
it
> > helps. Lemme know if I'm missing something.1
> >
> > -a