On Sun, Mar 26, 2017 at 09:50:08PM -0400, Joshua Kinard wrote:
> Does anyone know if the R1x000 family of CPUs support the "wait" instruction?
> The 'check_wait' function in arch/mips/kernel/idle.c doesn't have a case for
> any of the R10K CPUs, and I can't find any specific guidance in the final R10K
> manual produced by Renesas, nor in the MIPS-IV instruction set. It appears
> this was added in MIPS-II, and the R4K CPUs use it, with one version for when
> interrupts are enabled, and one where they're disabled. Since a lot of CPUs
> tend to reuse R4K-compatible code, I wasn't sure.
Interesting, didn't know Renesas did another R10000 manual. Presumably
they only rebranded NEC's manual?
If you have any documentation to indicate a MIPS II CPU to support WAIT,
I'm interested. From all that I know the feature was introduced by the
R4600.
> Kinda-assuming it doesn't, since the R10K lacks any notion of reduced power
> operation.
The R10000 like many of the older MIPS CPU took a hardware-only approach
to low-power operation, that is there are no knobs, no instructions for
software to optimize the power consumption. That also means, no WAIT
instruction. Other bits of low-power support in R4x00-processors are
fake also, for example the c0_status.rp "reduced power" bit is documented
but fairly hidden erratas say it's not implemneted. So just throw in another
plutonium slab and all will be good ;-)
But back to the WAIT instruction. WAIT uses major opcode COP0 which has
bits 31..27 = 010000. Traditionally MIPS doesn't fully decode the minor
opcodes, so an unsupported WAIT instruction will not cause an Reserved
Instruction exception anyway because the COP0 opcode does exist.
So one could basically pretend WAIT did exist on all MIPS CPUs, even
R2000 even though it doesn't - but check_wait is paranoid and really
avoids WAIT unless it's officially supported and useful.
Another complexity is that WAIT instruction was defined for many years
to leave it to an implementation if the pipeline would ever restart
after a WAIT instruction was executed with interrupts disabled. This
is fairly braindead because in a typical idle loop of an OS such as Linux
for (;;) {
if (wait_available && !need_resched())
asm("wait");
schedule();
}
there is the race condition between checking need_resched() and
actually executing WAIT that need_resched() might change, so WAIT-mode
might be entered falsely causing a scheduling delay of up to one tick.
The solution is to disable interrupts like:
for (;;) {
disable_irq();
if (wait_available && !need_resched())
asm("wait");
enable_irq();
schedule();
}
But some MIPS CPUs might lockup for good if this is attempted ...
This turned out to be a longer writeup than I meant to because I
recognized much of this is not documented anywhere so I did elaborate
a bit and add it as a new wiki page:
https://www.linux-mips.org/wiki/WAIT_instruction
Ralf
