On 01/06/11 12:23, Anoop P A wrote:
On Wed, 2011-01-05 at 11:23 -0800, Kevin D. Kissell wrote:
At this point, there shouldn't be a whole lot of SMTC-specific mystery
to get your timer running on the second VPE. You know it's taking
interrupts, because of the IPIs getting through, so in principle you
just need to run the chain of enables from the clock peripheral itself
through the CIC to the CPU core and the IM bits.
I hope we are almost there. I have made some progress with the debug . I
think you should be able to give better insight to the observation I
have made.
1. Without selecting CONFIG_MIPS_MT_SMTC_IM_BACKSTOP My kernel hangs in
calibration loop itself . ( I haven't looked further into this).
That suggests a problem with Status.IM initialization and/or
the handling of irq_hwmask[]. Do you mean that this is always
true, or only if VPE1 is being booted? You haven't mentioned it
before.
2. With CONFIG_MIPS_MT_SMTC_IM_BACKSTOP I found I am getting 3
VPE1-TIMER interrupt ( one for each TC of VPE1) .However this interrupts
are not getting carried till c0_compare_interrupt .
Would you expect them to? I thought you were using an outboard
timer and not the CP0 Compare interrupt.
do_IRQ call had a SMTC hook which is modifying tccontext ( To reduce
complexity I haven't selected SMTC affinity).
Once I disabled this call . I am seeing VPE1 timer interrupts and able
to boot completely without any issue's so far :).
So long as you've got the IM_BACKSTOP hack enabled, right?
Because otherwise, without that __DO_IRQ_SMTC_HOOK() invocation
/ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6
1: 171 727459 727561 727533 27 727446
727453 MIPS SMTC_IPI
6: 0 0 0 0 0 0
0 MIPS MSP CIC cascade
8: 0 0 0 0 0 0
0 MSP_CIC Softreset button
9: 0 0 0 0 0 0
0 MSP_CIC Standby switch
21: 0 0 0 0 0 0
0 MSP_CIC MSP PER cascade
25: 727507 484 11 0 0 0
0 MSP_CIC timer
27: 0 0 0 0 258 10
1 MSP_CIC serial
34: 0 0 0 0 727533 7
1 MSP_CIC timer
BTW following code in my cic init was setting hwmask.
/* initialize all the IRQ descriptors */
for (i = MSP_CIC_INTBASE ; i< MSP_CIC_INTBASE + 32 ; i++) {
set_irq_chip_and_handler(i,&msp_cic_irq_controller,
handle_level_irq);
#ifdef CONFIG_MIPS_MT_SMTC
irq_hwmask[i] = C_IRQ4;
#endif
}
I'm sure I've said this before, and it's in various comments in the SMTC
code, but remember, one of the main problems that the SMTC kernel
had to solve was to prevent all TCs of a VPE from "convoying" after every
interrupt. The way this is done is that the interrupt vector code, before
clearing EXL, masks off the Status.IM bit associated with the incoming
interrupt. Of course, to get another interrupt from the same source
(or collection of sources), that IM bit needs to be restored. The "correct"
mechanism for this is by having the appropriate irq_hwmask[] value set,
so that smtc_im_ack_irq(), which should be invoked on an irq "ack()"
(meaning that the source has been quenched and any new occurrence
should be considered a new interrupt), will restore the bit in Status.
This function got moved around a bit in the various SMTC prototypes,
but it proved least intrusive to put it into the xxx_mask_and_ack()
functions
for the interrupt controllers - see irq-msc01.c and i8259.c. If you haven't
done the same in any equivalent code for a different on-chip controller,
you'll definitely have problems.
The Backstop scheme works OK for peripheral interrupts that didn't
have an appropriate irq_hwmask[] value set up, but clock interrupts
don't follow the same code paths and can't depend on the backstop.
Regards,
Kevin K.
