How to mask IRQ

[Sergei Organov]

leonp at plris.com writes:

> 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...:-)

There is no such thing as the best solution for everything.

> If you want to through away nested/multiple interrupts, IMHO it is not good 
> solution in general (otherwise, nobody would invented them...:-)

1. They've been invented before (light-weight) threads got popularity, I
   think, and using them on the hardware that supports them seem to be
   natural. Forcibly implementing them in the software doesn't seem to
   be such a good idea, IMHO.

2. You've misunderstood me. I said "automatic" above. It means that
   instead of current solution that *forces* you to have nested
   prioritized interrupts you will have full control over interrupt
   management and it is *you* who will decide when you need nested
   interrupts and when not.

> because of several reasons:
>
> 1. Interrupt latency is too expansive sometimes

Not a problem as it's still under your control.

> 2. Interrupt priorities are importand in some cases.

Though I doubt it, if you indeed have such "some cases", you can always
do it in the application. BSP could provide you with helper functions
that you will call (or not) from ISR.

> 3. Signaling to tasks from ISR's takes also significant (for some 
>    applications) time.

Then don't signal. I didn't suggest to have no nested interrupts at all,
-- I suggested to let application enable them if they are indeed
required.

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

No, I speak about application design in general. The most helpful advice
I've ever got was K.I.S.S., -- "Keep It Simple, Stupid!".

-- 
Sergei.