Re: SMTC support status in latest git head.

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

Thank you, Stuart!  I've spotted some definite breakage to SMTC between 
those versions.  In arch/mips/include/asm/stackframe.h, someone moved 
the store of the Status register value in SAVE_SOME (line 169 or 204, 
depending on the version) from two instructions after the mfc0 to a 
point after the #ifdef for SMTC, presumably to get better pipelining of 
the register access.  Unfortunately, the v1 register is also used in the 
SMTC-specific fragment to save TCStatus, so the Status value gets 
clobbered before it gets stored.  This will eventually result in the 
Status register getting a TCStatus value, which has some bits on common, 
but isn't identical and sooner or later Bad Things will happen.

I'm a little surprised this wasn't caught by visual inspection of the patch.

Possible solutions would include reverting the store of the CP0_STATUS 
value to the block above the #ifdef, or, to retain whatever performance 
advantage was obtained by moving the store downward, to use v0/$2 
instead of v1/$3, as the staging register for the TCStatus value.  I'd 
lean toward the second option, but I'm not in a position to test and 
submit a patch just now.

             Regards,

             Kevin K.

On 12/23/10 1:09 PM, STUART VENTERS wrote:
> Kevin,
>
> I'm not sure if it's useful,
>     but finally I got the time to look at the two kernel versions Anoop pointed out.
>      works   2.6.32-stable with patch 804
>      works_not 2.6.33-stable
>
> greping for files with CONFIG_MIPS_MT_SMTC
>     and looking for timer interrupt related stuff found the following differences:
>
>
> arch/mips/include/asm/irq.h
> arch/mips/kernel/irq.c
>    do_IRQ
>
> arch/mips/include/asm/stackframe.h
>    SAVE_SOME SAVE_TEMP get/set_saved_sp
>
> arch/mips/include/asm/time.h
>    clocksource_set_clock
>
> arch/mips/kernel/process.c
>    cpu_idle
>
> arch/mips/kernel/smtc.c
>    __irq_entry
>    ipi_decode
>        SMTC_CLOCK_TICK
>
>
> Enclosed are the two subsets of files for a more expert look.
>
> I'll try to look in more detail after Christmas.
>
>
> Cheers,
>
> Stuart
>
>
>
>