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 e
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 hrt
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
pa
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
https://ozlabs.org/m
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
xtime_lo
Paul Mackerras wrote:
> 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.
The xtime_lock is still grabbed by time_init()
>>example, god knows why it was p
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
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 lookin
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
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 pa
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 dec
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...
> The
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
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
Linuxppc-dev
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 i
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
Hello.
Paul Mackerras wrote:
>>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) i
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 pref
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);
>
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
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, 9
21 matches
Mail list logo
