The original SMTC code was written for MIPS kernels which guaranteed
that interrupts were never disabled when the WAIT instruction is executed.
It was later noted that going into WAIT with interrupts disabled is
desirable
in most MIPS implementations, and a patch was propagated which did this,
but also broke SMTC. There is a way to make SMTC work in spite of this,
and I had thought that it had been implemented, at least internally to MIPS,
but it may be that the necessary patch hasn't yet been written or
published.
The last time I checked, the WAIT-with-interrupts-off behavior was a
configuration
option. If that's true in the sources you're using, turn it off if
you're building
for SMTC. If you want further assistance, contact me by direct email.
Regards,
Kevin K.
Chung-Chi Lo wrote:
Hello,
My platform is MIPS 34K cpu core and Config7.WII=1.
If Config7.WII=1 and a TC is idle, the TC will execute "wait"
instruction with TCSTATUS.IXMT=1
to disable interrupt.
But in 34K, interrupts are not TC-specific. So some TCs will not get
real interrupts to break "wait"
instruction. Even in SMTC's IPI mechanism, the IPI mechanism is to
program TCRestart if target
TC is in the same VPE.
In function smtc_send_ipi, it detects if TC's interrupt is disabled,
then enqueue IPI message to
target TC's queue. So some TCs are always idle and cannot break "wait"
instruction. I don't know
if I miss something and please comment on this problem. Thanks.
if ((tcstatus & TCSTATUS_IXMT) != 0) {
/*
* Spin-waiting here can deadlock,
* so we queue the message for the target TC.
*/
write_tc_c0_tchalt(0);
UNLOCK_CORE_PRA();
.....
smtc_ipi_nq(&IPIQ[cpu], pipi);
}
--
Lino, Chung-Chi Lo
