How to mask IRQ

[Sergei Organov]

Thomas Doerfler <Thomas.Doerfler at imd-systems.de> writes:
> Hello Sergei,
> 
> I have read the current discussion and what I do not yet understand in
> your approach is how you manage interrupts between the "off the shelf"
> BSP drivers and the application specific interrupts.

The short answer is: I don't, but please see below.

> When you "manually manage" IRQ masks in the interrupt handlers, they
> get more and more board specific and writing portable drivers might
> get more difficult.

Sure portable drivers shouldn't use board-specific things directly,
though they can call API routine(s)/macro(s) when they think it's OK to
enable other interrupts, and call another API routine at exit if they
called the first one. In the current implementation, these two routines
are effectively always called before and after calling user ISR making
it impossible for ISR to decide the right policy for itself. My way,
most ISRs could well avoid the overhead of whatever PIC emulation the
BSP creator considered to be useful. Do you really think you need all
that mess in an ISR that reads 1 byte from an UART and puts it into a
buffer?

On the other hand, board/application-specific drivers are free to do
whatever they wish to the IRQ masks and global interrupt enable bit.

Basically my suggestion is to shift from "you will handle interrupts the
way I believe is right" to "you have an API and it's up to you to decide
on the interrupt management policy".

It's similar to the FPU usage in ISRs, -- you can do it if you wish, but
you must call fpu context save/restore routines manually.

> All in all I think that, although your approach looks promising, it
> would require (another) major rework of the RTEMS interrupt API.
> We already have two APIs now and I think for RTEMS it is a bad idea to
> get a third one.

IMHO RTEMS doesn't yet have suitable interrupts API. If you talk about
old/new exception processing variants in the PowerPC port, that's
another story only weakly related to the RTEMS as a whole.

> I think the initial request from Leon should be considered, to extend
> the "new exception processing" API with some means to disable/enable
> certain interrupt controller inputs either from application level
> (well, we already have that, I think) or from within an interrupt
> handler. IMHO

That's the simplest thing to implement, I think. Being practical, the
new exception processing code is there and it works, so IMHO it should
be fixed the way you suggest, otherwise it limits application policies
too seriously.

The problem is that it increases complexity even more and adds overhead
to all the ISR handlers, even to the majority of them that don't use the
feature. But it's impossible to fix flawed design in implementation,
period.

> it would be nice if any interrupt handler can enable/disable the
> request input of any other interrupt source, therefore I would
> recommend not to use a special return value to manage this, but
> function calls to manage this.

I even think that there already are functions that are intended to
manage this. The only thing to fix is their behavior when they are
called from ISR. The implementation that first comes to my mind follows.

The "emulated" PIC will have 2 registers, current interrupt level (or
mask filled up to the current interrupt level), and an interrupt mask
register. The IRQ enable/disable routines will change emulated interrupt
mask register, and common ISR entry/exit code will manage the interrupt
level register. Current actual value of the real hardware register
should be calculated from the above two and written to the hardware
register at every change of one of the emulated registers. All the
modifications and write to hardware register should obviously be done at
interrupts disabled. Makes sense?

> 
> Any comments?

Well, I've already stated my opinion: the interrupts management in the
new exception processing is too heavy and too complicated for no obvious
gain. That's why I still use the old one.

-- 
Sergei.