Hi
The P1020 manual states (in the PIC chapter) that in the "Internal Interrupt Destination" register, only 1 CPU (and not both) can be selected as the IRQ destination. How then can we achieve "interrupt spraying" for the PCI interrupt (we want interrupts to be sent alternately to CPU0 and CPU1). Also, we changed the code to ignore the MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the PIC_IIDRn register. This does seem to work. But we're not sure if we can rely on this behavior and whether it will cause other problems.
Any advice appreciated
Thanks
-gopal
Subject: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
=20
Hi
The P1020 manual states (in the PIC chapter) that in the "Internal
Interrupt Destination" register, only 1 CPU (and not both) can be
selected as the IRQ destination. How then can we achieve "interrupt
spraying" for the PCI interrupt (we want interrupts to be sent
alternately to CPU0 and CPU1). Also, =A0we changed the code to ignore the
MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the
PIC_IIDRn register. This does seem to work. But we're not sure if we can
rely on this behavior and whether it will cause other problems.
I suggest you to follow the UM. The note should be there for a reason alth=
ough personally I don't know what the specific problem will be.
Leo
On 06/10/2012 03:37 PM, Gopalakrishnan Raman wrote:
Hi
=20
The P1020 manual states (in the PIC chapter) that in the =93Internal
Interrupt Destination=94 register, only 1 CPU (and not both) can be
selected as the IRQ destination.
Right.
How then can we achieve =93interrupt
spraying=94 for the PCI interrupt (we want interrupts to be sent
alternately to CPU0 and CPU1).
You'll have to implement it in software by changing the destination each
time (and be careful to follow the documented sequence for making such
changes).
Why do you want to do this? Won't it cause a bunch of cache misses as
the IRQ-relevant data structures bounce between CPUs? Distributing
different devices' interrupts among multiple CPUs is probably good for
load balancing, but distributing a single device's interrupts may not be
so good.
Also, we changed the code to ignore the
MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the
PIC_IIDRn register. This does seem to work.
What specifically does it seem to do?
But we=92re not sure if we can
rely on this behavior and whether it will cause other problems.
You cannot rely on this. It is not a supported configuration.
-Scott