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

[jennifer at oar3remote.oarcorp.com (jennifer at oar3remote.oarcorp.com)]

On Fri, 21 May 1999, VALETTE Eric wrote:

> >>>>> "jennifer" == jennifer  <jennifer at oar3remote.oarcorp.com> writes:
> 
> jennifer> If you look at the MSR Bit Settings table 2-B of PPC Programming
> jennifer> Environments Guide, the setting the EE bit to 0 delays recongnition of
> jennifer> external interrupts and decrementer exception conditions.
> 
> jennifer> I agree that on my system, the EE bit is already cleared at this point,
> jennifer> but do you have any information that all power pc implementations must do
> jennifer> this?
> 
> According to motorola doc (Prog Env for 32 bit mic =>MPCFPE32B/AD 1/97 rev 1), 
> chapter 6.27 (6.4.5) external Interrupt the EE bit in MSR is cleared...

Power PC may be 32 or 64 bit, someone please correct me if I'm wrong, but
I don't think this documentation would cover any power pc implementation.

> jennifer>  According to table 6-6 for all predefined power pc interrupts this
> jennifer> is true, but each processor may difine its unique new interrupts.  I fall
> jennifer> on the side that it's better safe, unless you can find some information
> jennifer> that all implementations must do this.  To me, the amount of time it
> jennifer> takes to the clear the bit is not worth makeing a big deal over. 
> 
> I do not mind changing MSR as I also must do it for enabling caches. I do mind 
> that MSR[RI] is not corrrectly handled as described in 4.3.3 of the mpc750
> manual...

I don't have acces to the manual that you are refering to, From the power
pc manual chapter "6.3 Process Switching" states that the operating
system should handle MSR[RI] in each exception handler it should set
MSR[RI] when enough state information has been saved that a machine check
or system reset exception can reconstruct the previous state.  This is
assured by the calculation of the_context->msr in cpu.c.  This is the
value that is saved in the special purpose register (one path) or gotten
directly from memory (the other path). 

> 
> jennifer> I agree that this depends on the bsp, but the defination should be
> jennifer> at a higher level than the bsp. For example there are currently 3
> jennifer> bsp's that use the 603e processor.  They should share the same macro
> jennifer> to enable and disable caching.
> >> 
> >> Not so sure : on mcp750, there is a second level cache L2 controlled by L2CR registers.
> >> The correct value for L2CR is BSP dependend as it contains things depending
> >> on board specific timing/config (L2 RAM type, L2 output hold, L2 Clock ratio,...)
> >> 
> >> >From this we can deduce :
> >> 
> >> - The correct place ultimate place for enabling the cache is in the BSP,
> >> and should be called BSP_processor_cache_enable,
> >> - On processor where the value does not depend on BSP, the implementation can be
> >> generic and could be found in libcpu/mpc603/mmu/cachexxxx
> 
> jennifer> Ok, the correct way for your variation of the processor is on the BSP.
> jennifer> I'm just saying varient commonalities should be allowed above the bsb.
> jennifer> The cache macros could be named ppc_603e_cache_enable and
> jennifer> ppc_603e_cache_disable,  but you shouldn't be forced to redefine them at
> jennifer> every bsp of the same varient.
> 
> Yes but generic code should use "BSP_processor_cache_enable" and not CPU_cache_enable...

All variations are not going to follow the same rules, you should be able
to name something 603e specific without requiring other variations to have
an equivalent call.  The name ppc_603e states that this is true for all
603e varations of the power pc, not that all power pc implementations use
this.


Jennifer