PATCH for SMTC: Fix Name Collision in _clockevent_init functions

PATCH for SMTC: Fix Name Collision in _clockevent_init functions

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

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.

Re: PATCH for SMTC: Fix Name Collision in _clockevent_init functions

[Ralf Baechle]

On Tue, Mar 31, 2009 at 01:10:32PM +0200, Kevin D. Kissell wrote:
> From: "Kevin D. Kissell" <kevink@paralogos.com>
> Date: Tue, 31 Mar 2009 13:10:32 +0200
> To: Linux MIPS org <linux-mips@linux-mips.org>
> Subject: PATCH for SMTC: Fix Name Collision in _clockevent_init functions
> Content-Type: multipart/mixed;
> 	boundary="------------070601030706030107070108"
> 
> 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.

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

  Ralf

Re: PATCH for SMTC: Fix Name Collision in _clockevent_init functions

[Manuel Lauss]

Hi Kevin, Ralf,

On Tue, Mar 31, 2009 at 03:12:51PM +0200, Ralf Baechle wrote:
> On Tue, Mar 31, 2009 at 01:10:32PM +0200, Kevin D. Kissell wrote:
> > From: "Kevin D. Kissell" <kevink@paralogos.com>
> > Date: Tue, 31 Mar 2009 13:10:32 +0200
> > To: Linux MIPS org <linux-mips@linux-mips.org>
> > Subject: PATCH for SMTC: Fix Name Collision in _clockevent_init functions
> > Content-Type: multipart/mixed;
> > 	boundary="------------070601030706030107070108"
> > 
> > Commit 779e7d41ad004946603da139da99ba775f74cb1c created a name collision
> > in SMTC builds.  The attached patch corrects this in a a

Oh, I'm sorry.


> > not-too-terribly-ugly manner.  Note that the SMTC case has to come
> > first, because CEVT_R4K will also be true.

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)


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

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

Thanks!
	Manuel Lauss

Re: PATCH for SMTC: Fix Name Collision in _clockevent_init functions

[Ralf Baechle]

On Tue, Mar 31, 2009 at 05:32:13PM +0200, Manuel Lauss wrote:
> From: Manuel Lauss <mano@roarinelk.homelinux.net>
> Date: Tue, 31 Mar 2009 17:32:13 +0200
> To: Ralf Baechle <ralf@linux-mips.org>,
> 	"Kevin D. Kissell" <kevink@paralogos.com>
> Cc: Linux MIPS org <linux-mips@linux-mips.org>
> Subject: Re: PATCH for SMTC: Fix Name Collision in _clockevent_init
> 	functions
> Content-Type: text/plain; charset=us-ascii
> 
> Hi Kevin, Ralf,
> 
> On Tue, Mar 31, 2009 at 03:12:51PM +0200, Ralf Baechle wrote:
> > On Tue, Mar 31, 2009 at 01:10:32PM +0200, Kevin D. Kissell wrote:
> > > From: "Kevin D. Kissell" <kevink@paralogos.com>
> > > Date: Tue, 31 Mar 2009 13:10:32 +0200
> > > To: Linux MIPS org <linux-mips@linux-mips.org>
> > > Subject: PATCH for SMTC: Fix Name Collision in _clockevent_init functions
> > > Content-Type: multipart/mixed;
> > > 	boundary="------------070601030706030107070108"
> > > 
> > > Commit 779e7d41ad004946603da139da99ba775f74cb1c created a name collision
> > > in SMTC builds.  The attached patch corrects this in a a
> 
> Oh, I'm sorry.
> 
> 
> > > not-too-terribly-ugly manner.  Note that the SMTC case has to come
> > > first, because CEVT_R4K will also be true.
> 
> 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)

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

Re: PATCH for SMTC: Fix Name Collision in _clockevent_init functions

[Kevin D. Kissell]

Manuel Lauss wrote:
> 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)
>   
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.