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

[Geoffrey Lee]

On Fri, Jun 27, 2008 at 11:12:56AM +0200, Frank Kaiser wrote:
> Hello, Geoffrey
> 

Hi Frank

There are two possible solutions to your problem.  One is to not
care about the interrupt priorities in the hardware and configure
the interrupt priority at user-level.  You can do this by ensuring
that the user-level interrupt handler has the desired priorities.
e.g., if interrupt a has higher priority than interrupt b, you set
the interrupt handler for interrupt a to be higher than that b.  This
may cause short interruptions if a low priority interrupt comes in,
because the kernel will need to mask and EOI the interrupt.  This
is how we typically configure things.

The second option is to do it in hardware and hold off the ACK
until the software ack with InterruptControl().  In practice though,
you still need the hardware priority and the interrupt threads
for those priorities to be in lock-step.

Note that the kernel runs with interrupts disabled so it won't  be
preempted by other interrupts after doing an EOI for the timer.

	-gl



> 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
> 
> 

--