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 <c...@laptop.org> <http://printf.net/> One Laptop Per Child _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel