MMP2 Interrupt Controller forcing IRQ

[Chris Ball]

Hi Andrei,

On Mon, Sep 26 2011, Andrei E. Warkentin wrote:
> I have a question about the ICU controller in the XO 1.75. I was
> looking into porting over and extending the FIQ debugger onto the XO (which
> allows debugging wedged/deadlocked kernels), and was wondering if it
> was possible to force triggering a particular IRQ (not FIQ).
>
> It's a feature common to SoCs where you have many cores (uncoherent
> ones at that,
> such as an AP and a service/power/control core), and my understanding is that
> the MMP2 SoC is one of these - if I understand correctly, you can
> route an interrupt to the SP.

Here's a transcription of an explanation Mitch just gave:

It's certainly possible to route any given interrupt to either FIQ or
IRQ on either core.  It is possible for an instruction to cause an
interrupt/exception; that's how OFW does breakpoints.  At the CPU core
level, each core has exactly one IRQ and one FIQ, for a total of 4.
Each of the many hardware interrupt sources can be used to assert any
combination of those 4 interrupt signals.

What's wrong with using FIQs instead of IRQs for this purpose?

> Is this what the MMP2_ICU_SP_IRQ_SEL/MMP2_ICU_PJ4_IRQ_SEL/MMP2_ICU_PJ4_FIQ_SEL
> regs are for?

Those registers are read-only; they *report* which one of the many
hardware interrupts is currently selected for servicing, so that when an
interrupt hits a CPU core it can discover which one to service.  (It's
essentially a priority encoder/latch function.)

The way you choose to route a given hardware interrupt to the 3 possible
AP (PJ4) lines is by ICU_REG(4 * interrupt_number).  Routing to the
security processor is done differently.

Setting 0x10 in the routing register for interrupt_number routes it to
SP IRQ.  Setting 0x20 routes to PJ IRQ, setting 0x40 routes to PJ FIQ.
The lower 4 bits (mask 0xf) of the routing register set the priority,
from 0 (lowest) to 0xf (highest).  You also need to know the mapping
from hardware interrupt sources to interrupt_number, 0 <= interrupt_number
<= 63.  But there are more than 64 interrupt sources, so some are ORed --
numbers 4,5,17,35,51,55 have secondary control and status registers so
you can control the 2nd level muxing.

The Linux macros that correspond to the above are:
   * ICU_INT_CONF(n) -- the register for interrupt_number n
   * ICU_INT_CONF_MASK -- the priority bits, and
   * ICU_INT_CONF_{{AP,CP}_INT,IRQ} -- the routing bits

(Make sure to ignore the Linux code for pxa168/pxa910 -- we're pxa688.)

Hopefully that's enough to get you going, feel free to ask more specific
questions.  Thanks!

- Chris.
-- 
Chris Ball   <cjb at laptop.org>   <http://printf.net/>
One Laptop Per Child