[PATCH] PowerPC: clockevents and HRT support

[PATCH] PowerPC: clockevents and HRT support

[Sergei Shtylyov]

Add PowerPC decrementer clock event driver and enable HRT.
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 -- this option is not compatible with the PPC64
deterministic time accounting.

Thanks to Daniel Walker and Thomas Gleixner for suggestions they made...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

---
This patch has been reworked against 2.6.18-hrt-dyntick2 patchset and
tested on the classic and Book E 32-bit CPUs.

CONFIG_PPC_MULTIPLATFORM was the best option I was able to come up with
to cover machines built on 970 series CPU...

 arch/powerpc/Kconfig       |   13 ++++
 arch/powerpc/kernel/time.c |  121 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 133 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -281,7 +281,7 @@ config PPC_STD_MMU_32
 
 config VIRT_CPU_ACCOUNTING
 	bool "Deterministic task and CPU time accounting"
-	depends on PPC64
+	depends on PPC64 && !GENERIC_CLOCKEVENTS
 	default y
 	help
 	  Select this option to enable more accurate task and CPU time
@@ -599,6 +599,17 @@ config HIGHMEM
 	depends on PPC32
 
 source kernel/Kconfig.hz
+
+config GENERIC_CLOCKEVENTS
+	bool "Clock event devices support"
+	default n
+	help
+	  Enable support for the clock event devices necessary for the
+	  high-resolution timers and the tickless system support.
+	  NOTE: This is not compatible with the deterministic time accounting
+	  option on PPC64.
+
+source kernel/time/Kconfig
 source kernel/Kconfig.preempt
 source "fs/Kconfig.binfmt"
 
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
@@ -51,6 +51,7 @@
 #include <linux/rtc.h>
 #include <linux/jiffies.h>
 #include <linux/posix-timers.h>
+#include <linux/clockchips.h>
 
 #include <asm/io.h>
 #include <asm/processor.h>
@@ -124,6 +125,80 @@ unsigned long ppc_tb_freq;
 static u64 tb_last_jiffy __cacheline_aligned_in_smp;
 static DEFINE_PER_CPU(u64, last_jiffy);
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#define DECREMENTER_MAX 0xffffffff
+#else
+#define DECREMENTER_MAX 0x7fffffff /* setting MSB triggers an interrupt */
+#endif
+
+struct decrementer_device {
+       struct clock_event_device device;
+       int mode;
+};
+
+static void decrementer_set_next_event(unsigned long evt,
+				       struct clock_event_device *dev)
+{
+#if defined(CONFIG_40x)
+	mtspr(SPRN_PIT, evt);	/* 40x has a hidden PIT auto-reload register */
+#elif defined(CONFIG_BOOKE)
+	mtspr(SPRN_DECAR, evt); /* Book E  has separate auto-reload register */
+	set_dec(evt);
+#else
+	set_dec(evt - 1);	/* Classic decrementer interrupts at -1 */
+#endif
+}
+
+static void decrementer_set_mode(enum	clock_event_mode mode,
+				 struct clock_event_device *dev)
+{
+	struct decrementer_device *decrementer;
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+	u32 tcr = mfspr(SPRN_TCR);
+
+	if (mode == CLOCK_EVT_PERIODIC)
+		tcr |=  TCR_ARE;
+	else
+		tcr &= ~TCR_ARE;
+
+	mtspr(SPRN_TCR, tcr);
+#endif
+	decrementer = container_of(dev, struct decrementer_device, device);
+	decrementer->mode = mode;
+
+	if (mode == CLOCK_EVT_PERIODIC)
+		decrementer_set_next_event(tb_ticks_per_jiffy, dev);
+}
+
+static struct clock_event_device decrementer_template = {
+	.name		= "decrementer",
+	.capabilities	= CLOCK_CAP_PROFILE | CLOCK_CAP_UPDATE |
+			  CLOCK_CAP_NEXTEVT,
+	.shift		= 32,
+	.set_mode	= decrementer_set_mode,
+	.set_next_event	= decrementer_set_next_event,
+};
+
+static DEFINE_PER_CPU(struct decrementer_device, decrementers);
+
+static void register_decrementer(void)
+{
+	int cpu = smp_processor_id();
+	struct decrementer_device *decrementer = &per_cpu(decrementers, cpu);
+
+	decrementer->device = decrementer_template;
+
+	/* We only want do_timer() to be called on a boot CPU. */
+	if (cpu == boot_cpuid) 
+		decrementer->device.capabilities |= CLOCK_CAP_TICK;
+
+	register_local_clockevent(&decrementer->device);
+}
+
+#endif /* CONFIG_GENERIC_CLOCKEVENTS */
+
 #ifdef CONFIG_VIRT_CPU_ACCOUNTING
 /*
  * Factors for converting from cputime_t (timebase ticks) to
@@ -340,6 +415,9 @@ void snapshot_timebase(void)
 {
 	__get_cpu_var(last_jiffy) = get_tb();
 	snapshot_purr();
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+	register_decrementer();
+#endif
 }
 
 void __delay(unsigned long loops)
@@ -495,7 +573,28 @@ void timer_interrupt(struct pt_regs * re
 
 	irq_enter();
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#ifdef CONFIG_PPC_MULTIPLATFORM
+	/*
+	 * 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 loading the new value...
+	 */
+	if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_PERIODIC)
+		set_dec(DECREMENTER_MAX);
+#endif
+	/*
+	 * We can't disable the decrementer, so in the period between
+	 * CPU being marked offline and calling stop-self, it's taking
+	 * timer interrupts...
+	 */
+	if (!cpu_is_offline(cpu))
+		per_cpu(decrementers, cpu).device.event_handler(regs);
+#else
 	profile_tick(CPU_PROFILING, regs);
+#endif
 	calculate_steal_time();
 
 #ifdef CONFIG_PPC_ISERIES
@@ -510,6 +609,7 @@ void timer_interrupt(struct pt_regs * re
 		if (__USE_RTC() && per_cpu(last_jiffy, cpu) >= 1000000000)
 			per_cpu(last_jiffy, cpu) -= 1000000000;
 
+#ifndef CONFIG_GENERIC_CLOCKEVENTS
 		/*
 		 * We cannot disable the decrementer, so in the period
 		 * between this cpu's being marked offline in cpu_online_map
@@ -519,6 +619,7 @@ void timer_interrupt(struct pt_regs * re
 		 */
 		if (!cpu_is_offline(cpu))
 			account_process_time(regs);
+#endif
 
 		/*
 		 * No need to check whether cpu is offline here; boot_cpuid
@@ -531,14 +632,23 @@ void timer_interrupt(struct pt_regs * re
 		tb_next_jiffy = tb_last_jiffy + tb_ticks_per_jiffy;
 		if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
 			tb_last_jiffy = tb_next_jiffy;
+#ifndef CONFIG_GENERIC_CLOCKEVENTS
 			do_timer(1);
+#endif
 			timer_check_rtc();
 		}
 		write_sequnlock(&xtime_lock);
 	}
 	
 	next_dec = tb_ticks_per_jiffy - ticks;
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#if !defined(CONFIG_40x) && !defined(CONFIG_BOOKE)
+	if (per_cpu(decrementers, cpu).mode == CLOCK_EVT_PERIODIC)
+		set_dec(next_dec - 1);
+#endif
+#else
 	set_dec(next_dec);
+#endif
 
 #ifdef CONFIG_PPC_ISERIES
 	if (hvlpevent_is_pending())
@@ -787,8 +897,19 @@ void __init time_init(void)
 	tb_to_ns_scale = scale;
 	tb_to_ns_shift = shift;
 
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+	decrementer_template.mult = div_sc(ppc_tb_freq, NSEC_PER_SEC,
+					   decrementer_template.shift);
+	decrementer_template.max_delta_ns =
+		clockevent_delta2ns(DECREMENTER_MAX, &decrementer_template);
+	decrementer_template.min_delta_ns =
+		clockevent_delta2ns(0xf, &decrementer_template);
+
+	register_decrementer();
+#else
 	/* Not exact, but the timer interrupt takes care of this */
 	set_dec(tb_ticks_per_jiffy);
+#endif
 }
 
 #define FEBRUARY	2

Re: [PATCH] PowerPC: clockevents and HRT support

[Benjamin Herrenschmidt]

> +#ifdef CONFIG_PPC_MULTIPLATFORM
> +	/*
> +	 * 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 loading the new value...
> +	 */
> +	if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_PERIODIC)
> +		set_dec(DECREMENTER_MAX);
> +#endif

PPC_MULTIPLATFORM is going away soon (or will be set for all CPU types
in arch/powerpc). Just make up a macro at the top of the file around the
lines of

#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
#define PPC_BOOKE_DECREMENTER
#endif

And use #if(n)def PPC_BOOKE_DECREMENTER in the rest of the code.

Also, what's the problem with ppc64 deterministic accounting that you
can't fix it ?

Ben.

Re: [PATCH] PowerPC: clockevents and HRT support

[Sergei Shtylyov]

Hello.

Benjamin Herrenschmidt wrote:

>>+#ifdef CONFIG_PPC_MULTIPLATFORM
>>+	/*
>>+	 * 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 loading the new value...
>>+	 */
>>+	if (per_cpu(decrementers, cpu).mode != CLOCK_EVT_PERIODIC)
>>+		set_dec(DECREMENTER_MAX);
>>+#endif

> PPC_MULTIPLATFORM is going away soon (or will be set for all CPU types
> in arch/powerpc). Just make up a macro at the top of the file around the
> lines of

> #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> #define PPC_BOOKE_DECREMENTER
> #endif

> And use #if(n)def PPC_BOOKE_DECREMENTER in the rest of the code.

    That's not equivalent. What I wanted to cover with this option was 970 
weirdness of the decrementer interrupts being level triggered and effectively 
tied to the MSB of the decremeneter register...
    Also, 40x decrementer is not Book E compatible.

> Also, what's the problem with ppc64 deterministic accounting that you
> can't fix it ?

    Arch-specific accounting hooks which this feature makes use of can't be 
called from the generic clockevents code.

> Ben.

WBR, Sergei

Re: [PATCH] PowerPC: clockevents and HRT support

[Benjamin Herrenschmidt]

>     That's not equivalent. What I wanted to cover with this option was 970 
> weirdness of the decrementer interrupts being level triggered and effectively 
> tied to the MSB of the decremeneter register...
>     Also, 40x decrementer is not Book E compatible.

Well... Is this specific to the 970 or also happens on all
POWER4..5..6 ? (I don't remember off the top of my head). It should
probably be a runtime check then.

> > Also, what's the problem with ppc64 deterministic accounting that you
> > can't fix it ?
> 
>     Arch-specific accounting hooks which this feature makes use of can't be 
> called from the generic clockevents code.

Then the generic clockevent code will have to be fixed or powerpc not
ported to it.

Ben.

Re: [PATCH] PowerPC: clockevents and HRT support

[Sergei Shtylyov]

Hello.

Benjamin Herrenschmidt wrote:
>>    That's not equivalent. What I wanted to cover with this option was 970 
>>weirdness of the decrementer interrupts being level triggered and effectively 
>>tied to the MSB of the decremeneter register...
>>    Also, 40x decrementer is not Book E compatible.

> Well... Is this specific to the 970 or also happens on all
> POWER4..5..6 ? (I don't remember off the top of my head). It should
> probably be a runtime check then.

    I don't have the docs on POWER[456], so can't say anything.

>>>Also, what's the problem with ppc64 deterministic accounting that you
>>>can't fix it ?

>>    Arch-specific accounting hooks which this feature makes use of can't be 
>>called from the generic clockevents code.

> Then the generic clockevent code will have to be fixed or powerpc not
> ported to it.

    Whatever. I don't care about that feature. I did my best to solve this 
gracefully.

> Ben.

WBR, Sergei

Re: [PATCH] PowerPC: clockevents and HRT support

[Benjamin Herrenschmidt]

>     Whatever. I don't care about that feature. I did my best to solve this 
> gracefully.

Very typical of Montavista to not care about doing the right thing.

Ben

Re: [PATCH] PowerPC: clockevents and HRT support

[Mark A. Greer]

On Wed, Nov 08, 2006 at 11:18:51AM +1100, Benjamin Herrenschmidt wrote:
> 
> >     Whatever. I don't care about that feature. I did my best to solve this 
> > gracefully.
> 
> Very typical of Montavista to not care about doing the right thing.
> 
> Ben

Hmmm...

Re: [PATCH] PowerPC: clockevents and HRT support

[Paul Mackerras]

Sergei Shtylyov writes:

>     Arch-specific accounting hooks which this feature makes use of can't be 
> called from the generic clockevents code.

Which hooks specifically?

The deterministic accounting is an essential feature; there's no way
I'll accept a patch which disables it.

Paul.

Re: [PATCH] PowerPC: clockevents and HRT support

[Benjamin Herrenschmidt]

On Tue, 2006-11-07 at 18:19 -0700, Mark A. Greer wrote:
> On Wed, Nov 08, 2006 at 11:18:51AM +1100, Benjamin Herrenschmidt wrote:
> > 
> > >     Whatever. I don't care about that feature. I did my best to solve this 
> > > gracefully.
> > 
> > Very typical of Montavista to not care about doing the right thing.
> > 
> > Ben
> 
> Hmmm...

Yeah, ok, maybe not -everybody- there :-)

Ben.

Re: [PATCH] PowerPC: clockevents and HRT support

[Sergei Shtylyov]

Hello.

Benjamin Herrenschmidt wrote:

>>>>    Whatever. I don't care about that feature. I did my best to solve this 
>>>>gracefully.

>>>Very typical of Montavista to not care about doing the right thing.

    We also have schedule to follow.

>>Hmmm...

> Yeah, ok, maybe not -everybody- there :-)

    I think I'm among the least deserving such compliments here.

> Ben.

WBR, Sergei

Re: [PATCH] PowerPC: clockevents and HRT support

[Sergei Shtylyov]

Hello.

Paul Mackerras wrote:

>>    Arch-specific accounting hooks which this feature makes use of can't be 
>>called from the generic clockevents code.

> Which hooks specifically?

    You aren't saying you don't know your own code?
    Specifically, it's local account_process_time() function being called 
instead of updated_process_times() with CONFIG_VIRT_CPU_ACCOUNTING option on.

> The deterministic accounting is an essential feature; there's no way
> I'll accept a patch which disables it.

    I'm not talking you into accepting it in any way, this is just to keep 
people informed.
    And I left people a choice: they can either have fancy accounting or HRT, 
just not both at once. What's wrong with that?

> Paul.

WBR, Sergei

Re: [PATCH] PowerPC: clockevents and HRT support

[Paul Mackerras]

Sergei Shtylyov writes:

>     And I left people a choice: they can either have fancy accounting or HRT, 
> just not both at once. What's wrong with that?

_I_ want both at once. :)

Paul.

Re: [PATCH] PowerPC: clockevents and HRT support

[Sergei Shtylyov]

Hello.

Paul Mackerras wrote:
> Sergei Shtylyov writes:

>>    And I left people a choice: they can either have fancy accounting or HRT, 
>>just not both at once. What's wrong with that?

> _I_ want both at once. :)

    I think the usual rule is: "you want it, you do it". ;-)

    Seriously, we have neither time, not hardware, nor docs for the h/w this 
accounting option applies to. And coercing the generic clcokevents/hrtimers 
code into calling the arch hooks is serious design decision which I felt is 
better to be left to Thomas as a maintainer...

> Paul.

WBR, Sergei

Re: [PATCH] PowerPC: clockevents and HRT support

[Paul Mackerras]

Sergei Shtylyov writes:

>     I think the usual rule is: "you want it, you do it". ;-)

Sure!  And I will, at some point, if someone else doesn't do it
first.

My point is simply that as maintainer I won't accept a patch that
breaks an important feature, even if it adds another important
feature.

>     Seriously, we have neither time, not hardware, nor docs for the h/w this 
> accounting option applies to.

Really?  You're working on machines that don't have a timebase
register?  What powerpc chip doesn't have a timebase register, other
than the really old 601? :)  The timebase is all the hardware that is
needed.

> And coercing the generic clcokevents/hrtimers 
> code into calling the arch hooks is serious design decision which I felt is 
> better to be left to Thomas as a maintainer...

CONFIG_VIRT_CPU_ACCOUNTING is used, and needed, on powerpc and s390,
both of which also want to do dynticks.  If the current framework
can't cope with that, then it needs to be extended.

Paul.

Re: [PATCH] PowerPC: clockevents and HRT support

[Sergei Shtylyov]

Hello.

Paul Mackerras wrote:

>>    I think the usual rule is: "you want it, you do it". ;-)

> Sure!  And I will, at some point, if someone else doesn't do it
> first.

> My point is simply that as maintainer I won't accept a patch that
> breaks an important feature, even if it adds another important
> feature.

    It's too early to talk about the mainline acceptance of this patch ATM, 
while TOD vsyscalls are broken/removed by the GENERIC_TIME support patches 
(which are aboslutely needed for HRT as well).  We'll try to return to getting 
them straight when the time permits, but for now the HRT patchset is still in 
better form than it was for several months before that (not even compilable, 
and vsyscalls broken)...

>>    Seriously, we have neither time, not hardware, nor docs for the h/w this 
>>accounting option applies to.

> Really?  You're working on machines that don't have a timebase
> register?  What powerpc chip doesn't have a timebase register, other
> than the really old 601? :)  The timebase is all the hardware that is
> needed.

    If you look at arch/powerpc/Kconfig, you'll see that this option depends 
on PPC64 which basically says it all:  we have only 32-bit targets to care 
about ATM.  When it comes to 64-bit ones, we'll see... :-)

>>And coercing the generic clcokevents/hrtimers 
>>code into calling the arch hooks is serious design decision which I felt is 
>>better to be left to Thomas as a maintainer...

> CONFIG_VIRT_CPU_ACCOUNTING is used, and needed, on powerpc and s390,
> both of which also want to do dynticks.  If the current framework
> can't cope with that, then it needs to be extended.

    Well, why not make Linus "extend" update_process_times() for starters? :-)

> Paul.

WBR, Sergei