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
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
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:
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 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.
There is some
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
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: send the
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.
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
> 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
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,
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 allow
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
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
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 base
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
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
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
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
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
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 the
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?
If it did,
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
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,
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
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
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
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
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
>
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:
>>
>>
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
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
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
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?
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
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
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
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).
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?
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
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
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
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 triggered
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 there any utility in
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
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?
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).
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, IIRC.
Wouldn't
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 work for
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
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?
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
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:
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.
You
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
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:
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
that
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 drivers
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
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
that we
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 transitions from
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 period
is
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,
since the
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 in
> > 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
>
> 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
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
+ * 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
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
+* 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
+*
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
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
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
[...]
@@
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
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
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
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
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
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
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
[...]
@@
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: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
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
+* 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
+*
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
+ * 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
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
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
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
1 - 100 of 102 matches
Mail list logo