mips64orion _CPU_ISR_Set_level

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

On Wed, 19 May 1999, Daniel Kelley wrote:

> > From joel at oarcorp.com  Tue May 18 10:52:12 1999
> > 
> > Take a look at what the i386 now does.  Eric Valette has been a strong
> > proponent of a different organization that allows BSPs to have more
> > control over the interrupt setup.  If this looks like what you need, then
> > we need to talk. :)
> > 
> 
> Yes, the i386 organization is a lot closer to what I am looking for, as far
> as interrupts go. 

What do you think will be required to get the mips port into a similar
organization.  

> I am still somewhat confused about _CPU_ISR_Set_level and how important is it 
> to support interrupt levels for the mips architecture. I see some architectures
> support multiple levels if the CPU allows an easy way to do so, otherwise it
> just enables and disables interrupts. I could certainly go either way, but I'm
> just not sure what the "best" way to go is, knowing that there is no one best way.

_CPU_ISR_Set_level does what it has to as best it can for a port. :)

The i386 just recognizes on and off as well.  THe set level implementation
for the i386 is this:

#define _CPU_ISR_Set_level( _new_level ) \
  { \
    if ( _new_level ) asm volatile ( "cli" ); \
    else              asm volatile ( "sti" ); \
  }

Basically RTEMS generically supports 256 levels only a subset of which
validly map onto anything in a particular port.  

At various times, the idea of a BSP provided hook to interpret the
undefined levels for a port has been discussed.

> So, we need to talk?

Yes.

Eric Valette did this to the i386 and is in the process of doing the same
thing to the PowerPC.  He has an API definition to go along with this now.  
How to move this architecture onto the mips is the question.

--joel