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.
