Hello Thomas, David, Venkat,
On 05/16/2012 03:44 PM, Thomas Gleixner wrote:Your irq is using handle_percpu_irq() as the flow handler.
handle_percpu_irq() is a special flow handler which does not take the
irq descriptor lock for performance reasons. It's a single interrupt
number which has a percpu dev_id and can be handled on all cores in
parallel.
The interrupts need to be marked as such and requested with
request_percpu_irq(). Those interrupts are either marked as
NOAUTOENABLE or set up by the low level setup code, which runs on the
boot cpu with interrupt enabled.
Those interrupts are marked as percpu and can only be requested with
request_percpu_irq().
Could someone comment please, why exactly this happens in current linux-next for Octeon:
In arch/mips/cavium-octeon/octeon-irq.c MBOX IRQs are set up to be handled by handle_percpu_irq():
static void __init octeon_irq_init_ciu(void)
{
...
octeon_irq_set_ciu_mapping(OCTEON_IRQ_MBOX0, 0, 32, chip_mbox, handle_percpu_irq);
octeon_irq_set_ciu_mapping(OCTEON_IRQ_MBOX1, 0, 33, chip_mbox, handle_percpu_irq);
But in arch/mips/cavium-octeon/smp.c it's requested as normal IRQ:
void octeon_prepare_cpus(unsigned int max_cpus)
{
...
if (request_irq(OCTEON_IRQ_MBOX0, mailbox_interrupt,
IRQF_PERCPU | IRQF_NO_THREAD, "SMP-IPI",
mailbox_interrupt)) {
panic("Cannot request_irq(OCTEON_IRQ_MBOX0)");
}
Is it a bug, or some kind of special case?