[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to mask IRQ



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.

My first Idea was to provide some return value from the user ISR handler. This 
value (if not zero) designates the "new", "append" mask bits that need to be 
added.
As I was able to understand, the best place to do this is to adjust the oldMak 
value before it is used to restore the ppc_cached_irq_mask.

As both the SIMASK in SIU and CIMR in CPM have the 31-st bit unused, it may be 
used to designate the desired type (mask/unmask) of operation.

Please, comment.

>
> wkr,
> Thomas.
>
> leonp@plris.com schrieb:
> >>>Hmmm, may be I miss something.
> >>>The dispatcher code I see in general looks like:
> >>>
> >>>void C_dispatch_irq_handler (CPU_Interrupt_frame *frame, unsigned int
> >>>excNum) {
> >>>register unsigned oldMask;                  /* old siu pic masks */
> >>>.......
> >>>    oldMask = ppc_cached_irq_mask;
> >>>    ppc_cached_irq_mask = oldMask & SIU_IvectMask[irq];
> >>
> >><== the SIU_IvectMask[irq] is what I mean as currently it mask only the
> >>current interrupt but could maks others. See comment in the table
> >>initialization. In fact I was wrong I my first message the mak
> >>possibility is currently at SIU level via this table.  Could be also
> >>done at CPM but have no more doucmentation handy...
> >
> > Well, it must be my poor english...:-)
> >
> > I want to stop to receive the IRQ5 & IRQ4 interrupts at all till some
> > other event occurs, which may be reenable them.
> >
> > This decision of masking IRQ4-5 I can take only inside the ISR of the
> > IRQ5.
> >
> > If I mask something inside the ISR, it is erased by the mask restoration
> > immediately after my ISR function.
> > If I call some IRQ handling functions, it will be considered only on the
> > next interrupt occurrence.
> >
> > Where am i wrong?

-- 
Dr.Leon M.Pollak
Director
PLR Information Systems Ltd.