Re: SMTC support status in latest git head.

["Kevin D. Kissell" <kevink@paralogos.com>]

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.