Sergei Shtylyov wrote:
Add PowerPC decrementer clock event driver.
Every effort has been made to support the different implementations of the
decrementer: the classic one (with 970 series variation), 40x and Book E
specific ones.
I had to make CONFIG_GENERIC_CLOCKEVENTS option selectable fo
This scales with the number of processors since there is one
decrementer per core (is it per thread on SMT chips?
I don't know).
One per core.
No, each thread has its own decrementer, but the timebase is shared.
Argh, of course you're right, I'm reading the wrong ISA
version again. Sorry.
Segher Boessenkool writes:
> > This scales with the number of processors since there is one
> > decrementer per core (is it per thread on SMT chips?
> > I don't know).
>
> One per core.
No, each thread has its own decrementer, but the timebase is shared.
Paul.
-
To unsubscribe from this list: s
This scales with the number of processors since there is one
decrementer per core (is it per thread on SMT chips?
I don't know).
One per core.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, May 18, 2007 at 05:52:45PM +0100, Matt Sealey wrote:
> Kumar Gala wrote:
> >
> > On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
> >>>
> >>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
> >>> easily.
>
On Sun, 2007-05-20 at 18:02 +0200, Segher Boessenkool wrote:
> > In fact, while it's never worded explicitely in the spec, it's always
> > been strongly in the "spirit" of the architecture that the timebase and
> > decrementer have a constant frequency.
>
> The architecture mentions varying time b
> So.. if we get enough clocksources into the tree, can any of those
> parts of the code be reworked to use clocksources/clockevents and
> hrtimers quickly and easily? I noticed the patch just posted does
> some of it.. but not as much as Ben just mentioned.
Well, some of these are expected to be
In fact, while it's never worded explicitely in the spec, it's always
been strongly in the "spirit" of the architecture that the timebase and
decrementer have a constant frequency.
The architecture mentions varying time base frequencies,
and how to deal with this, actually. It makes no
recommen
Benjamin Herrenschmidt wrote:
> On Sat, 2007-05-19 at 19:43 -0700, Daniel Walker wrote:
>
>> In terms of clocksources, gettimeofday() would have to switch to another
>> clocksource if the decrementer started to act that way .. That's why it
>> is possible to register more than one clocksource, to
On Sat, 2007-05-19 at 19:43 -0700, Daniel Walker wrote:
> In terms of clocksources, gettimeofday() would have to switch to another
> clocksource if the decrementer started to act that way .. That's why it
> is possible to register more than one clocksource, to allow for the
> switching. The decrem
On Sat, 2007-05-19 at 13:33 +1000, Paul Mackerras wrote:
> Daniel Walker writes:
>
> > On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> > > Well, the decrementer frequency may change, at least in theory (if
> > > the bus
> > > clock changes).
> >
> > Does that happen very often?
On 5/19/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
[Albert Cahalan]
> Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via
> MMCR0[TBSEL].
That's the performance monitor, which could very well be
in use already (for performance monitoring stuff, who
would have guessed).
It is t
Unfortunately, FIT exists only on Book E CPUs and MPC74xx aren't Book
E, IIUC.
By the name "FIT" perhaps, but MPC74xx has essentially
the same thing.
Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via
MMCR0[TBSEL].
That's the performance monitor, which could very well be
in use alre
Daniel Walker writes:
> On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> > Well, the decrementer frequency may change, at least in theory (if the
> > bus
> > clock changes).
>
> Does that happen very often?
If it did, gettimeofday would start reporting seriously wrong values,
si
Sergei Shtylyov writes:
> Yeah, the classic decrementer is programmed off-by-one.
Actually it's programmed off by slightly less than one half on
average, but it doesn't matter since the error doesn't accumulate.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 5/18/07, Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
Albert Cahalan wrote:
>>> Sure, but is there any utility in registering more than the
>>> decrementer on PPC?
>> Not yet. I'm not sure I know any other PPC CPU facility fitting
>> for clockevents. In theory, FIT could be used -- but its p
On Sat, 2007-05-19 at 01:49 +0200, Segher Boessenkool wrote:
> > I find it extremely silly to implement it as edge anyway. The EE line
> > is
> > level triggered, and having a mix of edge and level on the same
> > exception without a clean way to retrigger the DEC one other than
> > waiting one ti
I find it extremely silly to implement it as edge anyway. The EE line
is
level triggered, and having a mix of edge and level on the same
exception without a clean way to retrigger the DEC one other than
waiting one tick is just causing trouble.
It isn't edge triggered, it just automatically cle
On Fri, 2007-05-18 at 17:41 +0400, Sergei Shtylyov wrote:
> From the "PowerPC Operating Environment Architecture" that I've
> already
> quoated t follows that POWER4-compatible decremented exception *must*
> be edge
> triggered.
>
> > says that an exception is generated when the MSB transiti
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Fri, 18 May 2007 11:31:19 -0500
> I asked this earlier, but figured you might have a better insight.
> Is their value in having 'drivers' for more than one clock source?
> I'd say most (of not all) the PPC SoCs have timers on the system side
> tha
Thomas Gleixner wrote:
> On Fri, 2007-05-18 at 11:31 -0500, Kumar Gala wrote:
>> I asked this earlier, but figured you might have a better insight.
>> Is their value in having 'drivers' for more than one clock source?
>> I'd say most (of not all) the PPC SoCs have timers on the system side
Kumar Gala wrote:
>
> On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
>
>> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
>>>
>>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
>>> easily.
>>
>> There is some basic work for MPC5200 available:
>>
>> http://www.pengutr
On Fri, 2007-05-18 at 11:31 -0500, Kumar Gala wrote:
> I asked this earlier, but figured you might have a better insight.
> Is their value in having 'drivers' for more than one clock source?
> I'd say most (of not all) the PPC SoCs have timers on the system side
> that we could provide driv
On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
I guess the real question is, how high resolution does a high
resolution
timer need to be,
In the order of microseconds.
I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this
Hello.
Daniel Walker wrote:
Well, the decrementer frequency may change, at least in theory (if the bus
clock changes).
Does that happen very often?
Never, I hope. :-)
Daniel
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> Daniel Walker wrote:
>
> >>I haven't looked at all the new clock/timer code, is there any
> >>utility in having support for more than one clock source?
>
> > There is if the main clocksource has some issues where it can't be used.
>
>
I already have that stuff, but it only implements the decrementer (in fact
it's the patch submitted at the beginning of this thread).
I got it because I was far more interested in the GPIO handling..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Thomas Gleixner wrote:
Daniel Walker wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
There is if the main clocksource has some issues where it can't be used.
You mean, having more than one clocksource is *useful* in this case?
O
On Thu, 2007-05-17 at 13:17 -0500, Kumar Gala wrote:
>
> I haven't looked at all the new clock/timer code, is there any
> utility in having support for more than one clock source?
There is if the main clocksource has some issues where it can't be used.
On x86 there are lots of different issues
Hello.
Albert Cahalan wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in registering more than the
decrementer on PPC?
Not yet
On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
> >> I guess the real question is, how high resolution does a high resolution
> >> timer need to be,
> >
> >In the order of microseconds.
>
> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
> easily.
There is some basic
Sergei Shtylyov wrote:
> Hello.
>
Sure, but is there any utility in registering more than the
decrementer on PPC?
>
>>>Not yet. I'm not sure I know any other PPC CPU facility fitting
>>> for clockevents. In theory, FIT could be used -- but its period is
>>> measured in powers of 2
Hello, I wrote:
Yes, on some implementations there can be other conditions that
make a decrementer exception go away; there is no contradiction
here (thankfully). My wording was sloppy.
Some CPUs have the DEC exceptions basically edge triggered (yeah I know
for example?
it sucks). That
Hello.
Matt Sealey wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in registering more than the decrementer
on PPC?
Not
Hello.
Benjamin Herrenschmidt wrote:
Yes, on some implementations there can be other conditions that
make a decrementer exception go away; there is no contradiction
here (thankfully). My wording was sloppy.
Some CPUs have the DEC exceptions basically edge triggered (yeah I know
for examp
Sergei Shtylyov wrote:
> Hello.
>
> Kumar Gala wrote:
>
>>> Kumar Gala wrote:
>
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
>
>>>Of course, you may register as many as you like.
>
>> Sure, but is ther
On Fri, 2007-05-18 at 13:39 +0800, Dave Liu wrote:
> > > Yes, on some implementations there can be other conditions that
> > > make a decrementer exception go away; there is no contradiction
> > > here (thankfully). My wording was sloppy.
> >
> > Some CPUs have the DEC exceptions basically edge t
> > Yes, on some implementations there can be other conditions that
> > make a decrementer exception go away; there is no contradiction
> > here (thankfully). My wording was sloppy.
>
> Some CPUs have the DEC exceptions basically edge triggered (yeah I know
for example?
> it sucks). That's why,
>
> Yes, on some implementations there can be other conditions that
> make a decrementer exception go away; there is no contradiction
> here (thankfully). My wording was sloppy.
Some CPUs have the DEC exceptions basically edge triggered (yeah I know
it sucks). That's why, among others, the IRQ
Sergei Shtylyov writes:
Kumar Gala wrote:
[Sergei Shtylyov]
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in regist
Otherwise, when the contents of DEC0 change, the exception effects
of the Decrementer become consistent with the new contents of the
Decrementer reasonably soon after the change.
And that is guaranteed on all PowerPC as far as I can see.
The main thing is that a decrementer exception won't go
Segher Boessenkool wrote:
+ * We must write a positive value to the decrementer to clear
+ * the interrupt on the IBM 970 CPU series. In periodic mode,
+ * this happens when the decrementer gets reloaded later, but
+ * in one-shot mode, we have to do it here since an event handle
+ * We must write a positive value to the decrementer to clear
+ * the interrupt on the IBM 970 CPU series. In periodic mode,
+ * this happens when the decrementer gets reloaded later, but
+ * in one-shot mode, we have to do it here since an event
handler
+ * may skip loadin
Segher Boessenkool wrote:
+ * We must write a positive value to the decrementer to clear
+ * the interrupt on the IBM 970 CPU series. In periodic mode,
+ * this happens when the decrementer gets reloaded later, but
+ * in one-shot mode, we have to do it here since an event handle
+* We must write a positive value to the decrementer to clear
+* the interrupt on the IBM 970 CPU series. In periodic mode,
+* this happens when the decrementer gets reloaded later, but
+* in one-shot mode, we have to do it here since an event handler
+* ma
Hello.
Kumar Gala wrote:
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in registering more than the decremen
On May 17, 2007, at 1:26 PM, Sergei Shtylyov wrote:
Hello.
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in re
Hello.
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any utility
in having support for more than one clock source?
Of course, you may register as many as you like.
- k
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On May 17, 2007, at 1:07 PM, Sergei Shtylyov wrote:
Hello.
Kumar Gala wrote:
Index: linux-2.6/arch/powerpc/kernel/time.c
===
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
[...]
@@ -128,
Hello.
Kumar Gala wrote:
Index: linux-2.6/arch/powerpc/kernel/time.c
===
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
[...]
@@ -128,6 +129,83 @@ unsigned long ppc_tb_freq;
static u64 tb_
On May 17, 2007, at 12:42 PM, Sergei Shtylyov wrote:
Add PowerPC decrementer clock event driver.
Every effort has been made to support the different implementations
of the
decrementer: the classic one (with 970 series variation), 40x and
Book E
specific ones.
I had to make CONFIG_GENERIC
Add PowerPC decrementer clock event driver.
Every effort has been made to support the different implementations of the
decrementer: the classic one (with 970 series variation), 40x and Book E
specific ones.
I had to make CONFIG_GENERIC_CLOCKEVENTS option selectable for the
compatibility reasons -
52 matches
Mail list logo
