changes to the core Nios2 RTEMS IIC model

[Hill, Jeff]

> This is weird the IENABLE register is restored in the low level code,
> but the context switch doesn't touch the IENABLE register.  
> mean that the outer most level is disabled if the interrupt leads to a
> context switch?

I completely agree, in hindsight :), that this could be an issue. 
I will submit a patch for your review, separate from the symbol naming 
and source formatting patch after considering this matter carefully.  

Thanks for your review, I am guessing that your wisdom here
may have saved some considerable hours in the debugger on my end.

Best regards,

Jeff

> -----Original Message-----
> From: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
> Sent: Wednesday, August 15, 2012 10:53 AM
> To: Hill, Jeff
> Cc: RTEMS; rtemsdev at ixo.de; ruppe at kth.se
> Subject: Re: changes to the core Nios2 RTEMS IIC model
> 
> On 15/08/12 16:41, Hill, Jeff wrote:
> > Hello Sebastian,
> >
> >> some more comments regarding the thread stack usage of ISRs.
> >>
> >> On 14/08/12 03:05, Hill, Jeff wrote:
> >>> __attribute__ ((section (".text_hotspot")))
> >>> void __ISR_Handler ( void )
> >>> {
> >>>
> >> [...]
> >>
> >> The code that calls __ISR_Handler() will save the volatile context on
> >> the thread stack, right?
> > correct
> >
> >>>     if ( _ISR_Nest_level == 0) {
> >>> #   if( CPU_HAS_SOFTWARE_INTERRUPT_STACK == TRUE)
> >>>         stack_ptr = _old_stack_ptr;
> >>> #   endif
> >>>
> >>>       if ( !_Thread_Dispatch_in_critical_section() ) {
> >>>         if ( _Thread_Is_dispatch_necessary () ) {
> >>>           _CPU_ISR_Enable ( isrCookie );
> >> What does the _CPU_ISR_Enable() here?  Will it really enable the
> >> interrupts?
> > The _CPU_ISR_Enable will of course _globally_ enable interrupts in the
> Nios2
> > status register.
> 
> The name _CPU_ISR_Enable() might be a bit misleading since it restores
> only the state in isrCookie.
> 
> >> In case it enables interrupts then the code that calls
> >> __ISR_Handler() will save a volatile context on the thread stack (it is
> >> now the second).  In case the interrupt is pending a long time (some
> >> sort of error) or you have a bad sequence of interrupts, then this can
> >> stack several times and blow your thread stack.
> >>
> > With the IIC the interrupt's priority is defined by its bit position
> > in the ipending  and ienable register.
> >
> > Note that this is the Nios2 with internal interrupt controller so a
> > particular interrupt will not occur unless it is _also_ enabled in the
> > Nios2 ienable register, and as I mentioned in my previous
> > mail the interrupts of equal or lower priority are previously disabled
> > by the following code that writes to the Nios2 ienable register. We will
> > not start a new interrupt context for the same or lower priority
> interrupt
> > with the IIC unless it is _also_ enabled in the ienable register;
> therefore
> > the interrupt contexts will nest only 32 deep.
> 
> This is weird the IENABLE register is restored in the low level code,
> but the context switch doesn't touch the IENABLE register.  Does this
> mean that the outer most level is disabled if the interrupt leads to a
> context switch?
> 
> This seems to be a bit asymmetric.  For example this is the EIC code:
> 
> http://git.rtems.org/rtems/tree/cpukit/score/cpu/nios2/nios2-eic-rsie-low-
> level.S
> 
> Here you enable/disable the interrupts directly around the handler.
> 
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
> Phone   : +49 89 18 90 80 79-6
> Fax     : +49 89 18 90 80 79-9
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.