linux-mips
[Top] [All Lists]

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

To: Manuel Lauss <mano@roarinelk.homelinux.net>
Subject: Re: PATCH for SMTC: Fix Name Collision in _clockevent_init functions
From: "Kevin D. Kissell" <kevink@paralogos.com>
Date: Tue, 31 Mar 2009 18:22:32 +0200
Cc: Ralf Baechle <ralf@linux-mips.org>, Linux MIPS org <linux-mips@linux-mips.org>
In-reply-to: <20090331153213.GA11043@roarinelk.homelinux.net>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <49D1FA28.4030308@paralogos.com> <20090331131251.GC3804@linux-mips.org> <20090331153213.GA11043@roarinelk.homelinux.net>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)
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.

<Prev in Thread] Current Thread [Next in Thread>