Hello, I wrote:
The only thing I'm still unusre about is that deterministic accounting.
Could you point me at the patch which deals with this (at least for System
390
See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
Wait, how this is related to the hrtimer's
Sergei Shtylyov writes:
I've just realized that I've missed the call to account_process_time() in
the new timer_interrupt(). :-
Which is bogus. I had removed it in the version of the patch that I
posted in early September, but apparently it crept back in.
Anyway, this leads to each
Gabriel Paubert writes:
I'd really wish there were a guarantee of a minimum timebase
frequency, for anything above ~10MHz, we are splitting hairs
about an off-by-one error that never accumulates, but if systems
with very low TB freq exist, you have to be very careful.
Exactly. In looking
Hello.
Paul Mackerras wrote:
The xtime_lock is still grabbed by time_init()
Oops, I got distracted and hadn't finish the passage.
My patch got rid of this xtime_lock stuff -- but this was in a different
context, with all vDSO initialization code in between being killed by John's
Sergei Shtylyov writes:
BTW, why not handle the decrementer difference right in set_dec() where
we
already have #ifdef'ed code?
Excellent idea. Let's do that.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Sergei Shtylyov writes:
The xtime_lock is still grabbed by time_init()
That was left in there because we are setting sys_tz and do_gtod, and
do_gtod at least is only updated with the xtime_lock held. Of course,
at that early stage in the boot process, no lock is really needed, but
Hello.
Paul Mackerras wrote:
What problem do you see arising from this?
Timers firing too early.
Only if the minimum interrupt latency is less than 1 decrementer
tick. That seems pretty unlikely to me unless you have a very slow
timebase frequency.
Well, MPC8540 has 825 MHz CPU
On Fri, Oct 19, 2007 at 10:14:54AM +1000, Paul Mackerras wrote:
Sergei Shtylyov writes:
What problem do you see arising from this?
Timers firing too early.
Only if the minimum interrupt latency is less than 1 decrementer
tick. That seems pretty unlikely to me unless you have a
Paul Mackerras wrote:
BTW, while fixing that for classic PPC, but you've broke it for 40x /
book
E CPU which interrupt at 0. Congratulations. :-)
What problem do you see arising from this?
Timers firing too early.
Paul.
WBR, Sergei
___
Hello.
Paul Mackerras wrote:
Tony started from an earlier patch by John Stultz, not from your
patches.
Well, that I can believe, yet the clockevents patch has traces of my
former work, and looking at read_persisitent_time() it looks suspiciously
close to my version too...
There is
Sergei Shtylyov writes:
And now you have incomplete read_persistent_clock() implementation for
I don't see anything incomplete about it. If you do, feel free to
post a patch.
example, god knows why it was preferred to mine -- well, it also implemented
Your most recent post of your
Sergei Shtylyov writes:
What problem do you see arising from this?
Timers firing too early.
Only if the minimum interrupt latency is less than 1 decrementer
tick. That seems pretty unlikely to me unless you have a very slow
timebase frequency.
In fact what we should program the
Hello.
Paul Mackerras wrote:
I'd use (evt - 1) since the interrupt gets generated at 0x count,
not 0 (on classic CPUs). With you removing of the code that compensated for
See commit d968014b7280e2c447b20363e576999040ac72ef; I already fixed
that.
BTW, while fixing that for
Sergei Shtylyov writes:
Tony started from an earlier patch by John Stultz, not from your
patches.
Well, that I can believe, yet the clockevents patch has traces of my
former work, and looking at read_persisitent_time() it looks suspiciously
close to my version too...
There is
Sergei Shtylyov writes:
BTW, while fixing that for classic PPC, but you've broke it for 40x /
book
E CPU which interrupt at 0. Congratulations. :-)
What problem do you see arising from this?
Paul.
___
Linuxppc-dev mailing list
Hello.
Tony Breeds wrote:
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
I don't see my own signoff or at least a reference to my prior work in
this patch or even at -rt patch -- despite this code ha clearly borrowed from
it. And I'm not sure why this crippled version (lacking 40x/ Book E
Hello, I wrote:
@@ -797,6 +796,53 @@ void __init clocksource_init(void)
clock-name, clock-mult, clock-shift);
}
+static int decrementer_set_next_event(unsigned long evt,
+ struct clock_event_device *dev)
+{
+ set_dec(evt);
I'd use (evt -
Sergei Shtylyov writes:
I don't see my own signoff or at least a reference to my prior work in
this patch or even at -rt patch -- despite this code ha clearly borrowed from
it. And I'm not sure why this crippled version (lacking 40x/ Book E specific
clockevents implementation) is
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
Updated to remove a trivial FIXME left behind
arch/powerpc/Kconfig |3
arch/powerpc/kernel/smp.c |3
arch/powerpc/kernel/time.c | 134 +
include/asm-powerpc/time.h |1
4 files changed, 98
19 matches
Mail list logo
