How to mask IRQ

[leonp at plris.com]

On Monday, 30 בMay 2005 11:51, Sergei Organov wrote:
> leonp at plris.com writes:
> > On Monday, 30 в▒May 2005 08:54, Thomas Doerfler wrote:
> > > Hello Leon,
> > >
> > > you are right, the general SIU interrupt dispatcher will restore the
> > > SIU mask register after the IRQ function returns. This is a general
> > > problem with the MPC8xx Interrupt Controller, you will find this
> > > behaviour in various operating systems. The SIU Mask Register actually
> > > belongs to the interrupt dispatcher and not to the specific interrupt
> > > handlers.
> > >
> > > Maybe it would be possible to introduce another "handler mask"
> > > variable, which would be applied to the mask value written to the SIU
> > > mask register in the dispatcher code? So the mask value would consist
> > > of the "standard" value given in the standard table (I think) plus the
> > > value in the mask variable (whatever operation is needed to "add" these
> > > two masks). And there could be a well-defined API extension to
> > > set/clear bits in this additional variable.
> >
> > Thanks, Thomas - this is exactly what I was thinking about.
> > I just was worried about the possible problems connected to the nested
> > interrupts.
> > As it is very difficult to test such a coincidences, I wanted to discuss
> > the idea itself and possible implementations on the list.
>
> It could be an alternative solution to throw away the idea of automatic
> management of nested interrupts and their priorities altogether. Instead
> of emulating priority IC in software, let the threads scheduler handle
> priorities by delegating most of the work from IRQ handlers level to the
> task level. This way you will have simple and fast IRQ dispatcher that
> won't touch IRQ masks at all allowing you to manage them whatever way
> you wish.
Well, speaking very general you may be write, but details always destroy the 
beauty...:-)

If you want to through away nested/multiple interrupts, IMHO it is not good 
solution in general (otherwise, nobody would invented them...:-) because of 
several reasons:
1. Interrupt latency is too expansive sometimes
2. Interrupt priorities are importand in some cases
3. Signaling to tasks from ISR's takes also significant (for some 
applications) time.

But if you speak about optimizing the irq.c code - this is something 
different...:-))


-- 
Leon M.Pollak