Philippe Gerum wrote: > On Fri, 2006-10-20 at 12:33 +0200, Jan Kiszka wrote: >> While digging into a latency issue with multiple IRQs pending (patch >> will likely follow soon), I noticed that the replay order on x86 is the >> inverse of the hardware order. Instead of iterating from lowest IRQ >> number to highest, ipipe currently starts with the highest one. The >> attached patch fixes this. >> > > We want to give a priority boost to virtual IRQs over real ones, at > least for the root domain. Since virqs are high-numbered, bsrl has been
Hmm, are the virtual IRQs differently numbered on blackfin? Because there we have ffs behind __ipipe_ffnz. > used on purpose to scan the pending IRQ mask. Additionally, low-numbered > IRQs have higher priority only if you consider the ISA ones as managed > by the 8259. Bringing the APIC into the picture, the APIC-based timer > IRQ used by RTOSes over Adeos is a high-numbered one. Ok, so there is no simple way to emulate reality, thus we can simply leave it as it is. No problem. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
