PowerPC IRQ QU #2 Current Implementation of ISR low level code

[joel at OARcorp.com (joel at OARcorp.com)]

Jennifer and I will pick pieces out of the long message as we deal with
them.  Don't interpret too much into this. :)


On Tue, 18 May 1999, VALETTE Eric wrote:

> 
> 2) Current Implementation of ISR low level code
> -----------------------------------------------
> 
> I do not understand why the MSR EE flags is cleared
> again in exec/score/cpu/powerpc/irq_stubs.S
> 
> #if (PPC_USE_SPRG)
> 	mfmsr	r5          
> 	mfspr   r6, sprg2   
> #else	
>         lwz	r6,msr_initial(r11)
> 	lis     r5,~PPC_MSR_DISABLE_MASK at ha
>         ori     r5,r5,~PPC_MSR_DISABLE_MASK at l
> 	and	r6,r6,r5
> 	mfmsr	r5          
> #endif

This code is supposed to load the precalculated (in cpu.c) msr from cpu
initialization that should have exceptions disabled.  This is based on the
fact that the BSP is supposed to run with all exceptions disabled.  The
BSP is responsible for setting the initial value of the msr.

The two paths are supposed to be equivalent.  The sprg path just has to be
avoided if running with a ROM monitor/debugger that uses sprg's.

> Reading the doc, when a decrementer interrupt or an
> external interrupt is active, the MSR EE flag is already 
> cleared. BTW if exception/interrupt could occur, it would 
> trash SRR0 and SRR1. In fact the code may be useful to set
> MSR[RI] that re-enables exception processing. BTW I will need
> to set other value in MSR to handle interrupts :

I agree.

> 	a) I want the MSR[IR] and MSR[DR] to be set for
> 	performance reasons and also because I need DBAT 
> 	support to have access to PCI memory space as the
> 	interrupt controller is in the PCI space.

OK.  All of this can be done with the existing PPC port code.  The only
issues are that various tools (emulators, debuggers, etc.) break with
caching enabled.  The BAT initialization has also been left as a BSP
issue.

> Reading the code, I see others have the same kind of request :
> 
> /* SCE 980217
>  *
>  * We need address translation ON when we call our ISR routine
> 
> 	mtmsr	r5
> 
>  */

This code is actually disabled.  This is a junk comment from Steve Evans
of Radstone UK.  Their BSP ended up handling this.

> This is just another prof that even the lowest level 
> IRQ code is fundamentally board dependent and 
> not simply processor dependent especially when 
> the processor use external interrupt controller
> because it has a single interrupt request line... 

I agree with the need to more efficiently handle external IRQs.  And even
with the fact that compiling the irq code on a per BSP basis (more local
to the BSP) allows it to be tailored .. caching, SPRG usage, etc..

> Note that if you look at the PPC code high level interrupt 
> handling code, as the "set_vector" routine that really connects 
> the interrupt is in the BSP/startup/genpvec.c,
> the fact that IRQ handling is BSP specific is DE-FACTO 
> acknowledged.

set_vector always has been BSP specific.  It was originally created to
handle the ugliness of a PIC and mask register on the i960.  It can often
be shared which is what a lot of BSPs for simple boards do (see many m68k
BSPs).

> So please consider removing low level IRQ handling from 
> exec/score/cpu/* and only let there exception handling code... 
> Exceptions are usually only processor dependent and do
> not depend on external hardware mechanism to be masked or
> acknowledged or re-enabled (there are probably exception but ...) 

This only impacts the EE and any CPU model specific interrupts right?

> I have already done this for pc386 bsp but need to make it again.
> This time I will even propose an API.

I look forward to it.  It sounds like someone is interested in this on the
mips.


--joel