Interrupt prioritization on linux for ppc440

Shawn Jin shawnxjin at
Tue Apr 19 09:11:02 EST 2005

On 4/18/05, Eugene Surovegin <ebs at> wrote:
> On Mon, Apr 18, 2005 at 02:14:23PM -0700, Shawn Jin wrote:
> >
> > > What could be interesting, though, is to to make all 4xx IRQs
> > > critical, in this case we could use VR to quickly determine which IRQ
> > > was asserted, instead of current implementation when we use bit
> > > operations. Not sure, if performance gain is really worth the
> > > effort :)
> >
> > If we use VR to determine which IRQ was asserted, it's kind of
> > reverse. We usually fetch a handler by its IRQ number. It could
> > require to change irq_desc[] and request_irq().
> You seems don't undestand what I'm talking about. VR can help us with
> determining what IRQ was asserted. It has nothing to do with irq_desc.

I guess I understand your statement of using VR to quickly determin
IRQ number. (VR - VCR) >> 9 is the irq number if UIC0_SR0 has the
highest priority, which  is quicker than bit searching.

However there could be a possible problem when a 2nd critical
interrupt is asserted before the 1st one is served. Then fetching the
VR returns the address for the 2nd interrupt. Of course if UIC can
queue interrupts when calculating VRs, there wouldn't be such a


More information about the Linuxppc-embedded mailing list