PATCH for SMTC: Fix Name Collision in _clockevent_init functions

Commit 779e7d41ad004946603da139da99ba775f74cb1c created a name collision in SMTC builds. The attached patch corrects this in a a not-too-terribly-ugly manner. Note that the SMTC case has to come first, because CEVT_R4K will also be true.

Regards,

Kevin K.

Looks ok but I won't apply it immediately to give Manuel a chance to comment.

Ralf

Hi Kevin, Ralf,

Oh, I'm sorry.

I'm curious: Is it required to use the CP0 counter for SMTC kernels, or could the SMTC-specific parts somehow be abstracted out and called by other timer backends? (for a hypothetical SMTC-enhanced Alchemy core)

It works for me (both alchemy and CP0 timers).

Thanks!
Manuel Lauss

Theoretically, one could, but it would require a major rewrite of cevt-smtc.c, which implements multiple virtual per-CPU one-shot timer interrupts multiplexed off a single timer interrupt source (the SMTC environment has a couple of quirks that make the generic timer broadcast code pretty useless). The concept could be applied to arbitrary counter-based interrupts, but for simplicity and performance, the code assumes MIPS32 Count/Compare, and to minimize redundant source code, it uses common functions with cevt-r4k.c wherever possible (that's why there are those #ifdef MIPS_MT_SMTC's in cevt-r4k.c).

Regards,

Kevin K.

The very special and odd SMTC time and interrupt code is required due to the special architecture of the processor. A MIPS MT-enabled core can have multiple VPEs and TCs. A TC is a thread context, basically just a register set and the bare minimum set of cp0 that is needed to be able to allow clever software to pretend a TC is a processor to applications. TCs are associated with VPEs. VPEs duplicate many more cp0 resources, including for example all TLB, interrupt-related registers - and count/compare.

This means for the VSMP kernel model (think of it as fairly similar to Intel's hyperthreading) each VPE (and VPEs are equivalent to processors as visible to Linux) has its own count/compare register. World is nice :imple and sane, the birds are singing and the skies are blue:

TC 0 -- VPE 0 TC 1 -- VPE 1

SMTC shows each TC into a processor. by the hardware architecture each TC is associated with a VPE. For example on a 2 VPE, 5 TC configuration which is fairly common:

TC 0 TC 4
\ \
TC 1 -- VPE 0 TC 5 -- VPE 1
/
TC 2

The count compare registers are part of the VPEs, that is count/compare suddenly have become shared resources. More complicated, the cp0 status and cause registers which also are cp0 resources are also per VPE and interrupts are delivered to a random (let's skip the details) TC of a VPE. To allow reliable delivery of timer interrupts to a processor the SMTC kernel has to do a few fairly ingeniously crazy software tricks which are complicated enough that we keep that code separated in its own cevt-smtc.c file.

Any other timer would suffer from similar issues. Interrupts would be delivered to a random TC associated with the VPE that is target of the interrupt and software might have to forward it. Also resource sharing might require some sort method to deal with the situation where there are fewer timers available than TCs.

Ralf