[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: IPLs - One too many?
Matt Thomas wrote:
> I've been talking to Chris Gilbert for a while about eliminating nested
> interrupts in one or more of the ARM ports.
> Ignoring IPL_SOFT* IPLs for the moment, ARM currently has
> IPL_NONE < IPL_VM < IPL_SCHED < IPL_HIGH
> Since IPL_SCHED == IPL_CLOCK, once IPL_SCHED is reached you block
> clock interrupts. Since clock interrupts are the highest priority
> interrupts, you have basically blocked all interrupts. So there
> is little difference between IPL_HIGH and IPL_SCHED.
> So why have both? Can I just make IPL_HIGH == IPL_SCHED?
> This means I have three IPL value, IPL_NONE, IPL_VM, IPL_HIGH.
> And now I can directly map those to the ARM CPSR bits IF32_bits
> (IRQ, FIQ) as 00, 10, 11 so I can make IPL_NONE=0, IPL_VM=2, and
> IPL_HIGH=3 and have no reason to store a s/w copy of the IPL since
> the CPU status word will contain an encoding of it.
> Much/All of the IRQ/FIQ enable/disable in the kernel can then just
> become spl calls.
For those less familiar with ARM hardware, ARM cpus have two interrupt
lines, called IRQ and FIQ. FIQs have priority over IRQs.
Most recent ARM hardware (probably strongarm or later) has a PIC that
allows you to route device interrupts to one (or both) of the two CPU lines.
Currently all interrupts are routed to IRQ, and we have to handle nested
interrupts, so we don't block clock irqs, masking and unmasking things
in the PIC, all of which is added complexity and overhead.
If we only need interrupts at two levels, and the hardware supports it,
we can handle all the interrupt priorities in the hardware, and bypass
quite a bit of code (and hopefully give a performance gain)
From what I can tell the only arm platforms that obviously can't do
this, because the PICs aren't routable, are acorn32 and acorn26.
Main Index |
Thread Index |