Interrupt prioritization on linux for ppc440

[Shawn Jin]

On 4/15/05, Eugene Surovegin <ebs at ebshome.net> wrote:
> I really think that if you need some special higher-priority IRQ
> context you'd better use RTAI or RTLinux. At least, they make clear
> (IIRC) that these IRQ contexts are special.

OK, I'll look into RTAI or RTLinux for priority issue.

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

VR can be calculated automatically provided that VCR is set. What
should be the vector base address? One possible way is similar to the
way how IVPR is set to interrupt_base in head_44x.S but leave the
actual interrupt handler blank, which will be filled in later with a
jump instruction which jumps to the actual ISR once a device driver
request its irq. This means that request_irq() needs to modify kernel
code. Kinda of dangerous, isn't it? This might be part of
infrastructure change you mentioned?

Regards,
-Shawn.