To fix following compile errors for powermac and cell.
---
with PREEMPT_NONE
o arch/powerpc/kernel/head_64.S
include/asm-generic/bug.h: Assembler messages:
include/asm-generic/bug.h:19: Error: Unrecognized opcode: `extern'
o missing percpu related macros
arch/powerpc/mm/mem.c
In file included from include/asm/tlb.h:53,
from arch/powerpc/mm/mem.c:45:
include/asm-generic/tlb.h:50: error: parse error before "mmu_gathers"
include/asm-generic/tlb.h:50: warning: type defaults to `int' in
declaration of `DECLARE_PER_CPU_LOCKED'
etc.
o kernel/time/clockevents.c:82: error: conflicting types for
'timer_interrupt'
include/asm/hw_irq.h:14: error: previous declaration of
'timer_interrupt' was here
kernel/time/clockevents.c:82: error: conflicting types for
'timer_interrupt'
include/asm/hw_irq.h:14: error: previous declaration of
'timer_interrupt' was here
o kernel/built-in.o: In function `do_gettimeofday':
: multiple definition of `do_gettimeofday'
arch/powerpc/kernel/built-in.o:: first defined here
kernel/built-in.o: In function `.do_gettimeofday':
: multiple definition of `.do_gettimeofday'
arch/powerpc/kernel/built-in.o:: first defined here
/usr/local/sti/SDK0.29/bin/pu64-ld: Warning: size of symbol
`.do_gettimeofday' changed from 120 in arch/powerpc/kernel/built-in.o
to 372 in kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `.do_gettimeofday':
o arch/powerpc/kernel/built-in.o: In function `.do_gettimeofday':
: undefined reference to `.SCALE_XSEC'
with PREEMPT_RT
o arch/powerpc/platforms/powermac/.tmp_feature.o
arch/powerpc/platforms/powermac/feature.c
arch/powerpc/platforms/powermac/feature.c:65: error: conflicting types
for 'feature_lock'
include/asm/pmac_feature.h:381: error: previous declaration of
'feature_lock' was here
arch/powerpc/platforms/powermac/feature.c:65: error: conflicting types
for 'feature_lock'
include/asm/pmac_feature.h:381: error: previous declaration of
'feature_lock' was here
diff -rup -x CVS 2.6.16-rt17/arch/powerpc/kernel/time.c rt-powerpc/arch/powerpc/kernel/time.c
--- 2.6.16-rt17/arch/powerpc/kernel/time.c 2006-04-26 18:24:28.000000000 +0900
+++ rt-powerpc/arch/powerpc/kernel/time.c 2006-07-12 13:45:31.000000000 +0900
@@ -200,6 +200,7 @@ void udelay(unsigned long usecs)
}
EXPORT_SYMBOL(udelay);
+#ifndef CONFIG_GENERIC_TIME
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -223,6 +224,7 @@ static inline void __do_gettimeofday(str
xsec = temp_stamp_xsec + mulhdu(tb_ticks, temp_tb_to_xs);
sec = xsec / XSEC_PER_SEC;
usec = (unsigned long)xsec & (XSEC_PER_SEC - 1);
+#define SCALE_XSEC(xsec, max) (((xsec) * max) / XSEC_PER_SEC)
usec = SCALE_XSEC(usec, 1000000);
tv->tv_sec = sec;
@@ -254,6 +256,7 @@ void do_gettimeofday(struct timeval *tv)
}
EXPORT_SYMBOL(do_gettimeofday);
+#endif /* !CONFIG_GENERIC_TIME */
/*
* There are two copies of tb_to_xs and stamp_xsec so that no
diff -rup -x CVS 2.6.16-rt17/include/asm-generic/bug.h rt-powerpc/include/asm-generic/bug.h
--- 2.6.16-rt17/include/asm-generic/bug.h 2006-04-26 18:24:28.000000000 +0900
+++ rt-powerpc/include/asm-generic/bug.h 2006-06-08 17:18:06.000000000 +0900
@@ -16,7 +16,9 @@
#define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); } while(0)
#endif
+#ifndef __ASSEMBLY__
extern void __WARN_ON(const char *func, const char *file, const int line);
+#endif /* __ASSEMBLY__ */
#ifndef HAVE_ARCH_WARN_ON
#define WARN_ON(condition) do { \
diff -rup -x CVS 2.6.16-rt17/include/asm-powerpc/hardirq.h rt-powerpc/include/asm-powerpc/hardirq.h
--- 2.6.16-rt17/include/asm-powerpc/hardirq.h 2006-03-20 14:53:29.000000000 +0900
+++ rt-powerpc/include/asm-powerpc/hardirq.h 2006-06-08 17:18:42.000000000 +0900
@@ -11,7 +11,7 @@
* for uniformity.
*/
typedef struct {
- unsigned int __softirq_pending; /* set_bit is used on this */
+ unsigned int __softirq_pending; /* set_bit is not used on this */
unsigned int __last_jiffy_stamp;
} ____cacheline_aligned irq_cpustat_t;
diff -rup -x CVS 2.6.16-rt17/include/asm-powerpc/hw_irq.h rt-powerpc/include/asm-powerpc/hw_irq.h
--- 2.6.16-rt17/include/asm-powerpc/hw_irq.h 2006-04-26 18:24:28.000000000 +0900
+++ rt-powerpc/include/asm-powerpc/hw_irq.h 2006-07-12 13:55:15.000000000 +0900
@@ -11,7 +11,11 @@
#include <asm/ptrace.h>
#include <asm/processor.h>
-extern void timer_interrupt(struct pt_regs *);
+/*
+ * this conflicts w/ the declaration of 'timer_interrupt' in
+ * kernel/time/clockevents.c
+ */
+/* extern void timer_interrupt(struct pt_regs *); */
#ifdef CONFIG_PPC_ISERIES
diff -rup -x CVS 2.6.16-rt17/include/asm-powerpc/percpu.h rt-powerpc/include/asm-powerpc/percpu.h
--- 2.6.16-rt17/include/asm-powerpc/percpu.h 2006-03-20 14:53:29.000000000 +0900
+++ rt-powerpc/include/asm-powerpc/percpu.h 2006-06-08 21:03:28.000000000 +0900
@@ -18,11 +18,23 @@
/* Separate out the type, so (int[3], foo) works. */
#define DEFINE_PER_CPU(type, name) \
__attribute__((__section__(".data.percpu"))) __typeof__(type) per_cpu__##name
+#define DEFINE_PER_CPU_LOCKED(type, name) \
+ __attribute__((__section__(".data.percpu"))) spinlock_t per_cpu_lock__##name##_locked = SPIN_LOCK_UNLOCKED; \
+ __attribute__((__section__(".data.percpu"))) __typeof__(type) per_cpu__##name##_locked
/* var is in discarded region: offset to particular copy we want */
#define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset(cpu)))
#define __get_cpu_var(var) (*RELOC_HIDE(&per_cpu__##var, __my_cpu_offset()))
+#define per_cpu_lock(var, cpu) \
+ (*RELOC_HIDE(&per_cpu_lock__##var##_locked, __per_cpu_offset(cpu)))
+#define per_cpu_var_locked(var, cpu) \
+ (*RELOC_HIDE(&per_cpu__##var##_locked, __per_cpu_offset(cpu)))
+#define __get_cpu_lock(var, cpu) \
+ per_cpu_lock(var, cpu)
+#define __get_cpu_var_locked(var, cpu) \
+ per_cpu_var_locked(var, cpu)
+
/* A macro to avoid #include hell... */
#define percpu_modcopy(pcpudst, src, size) \
do { \
@@ -39,16 +51,27 @@ extern void setup_per_cpu_areas(void);
#define DEFINE_PER_CPU(type, name) \
__typeof__(type) per_cpu__##name
+#define DEFINE_PER_CPU_LOCKED(type, name) \
+ spinlock_t per_cpu_lock__##name##_locked = SPIN_LOCK_UNLOCKED; \
+ __typeof__(type) per_cpu__##name##_locked
#define per_cpu(var, cpu) (*((void)(cpu), &per_cpu__##var))
+#define per_cpu_var_locked(var, cpu) (*((void)(cpu), &per_cpu__##var##_locked))
#define __get_cpu_var(var) per_cpu__##var
+#define __get_cpu_lock(var, cpu) per_cpu_lock__##var##_locked
+#define __get_cpu_var_locked(var, cpu) per_cpu__##var##_locked
#endif /* SMP */
#define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
+#define DECLARE_PER_CPU_LOCKED(type, name) \
+ extern spinlock_t per_cpu_lock__##name##_locked; \
+ extern __typeof__(type) per_cpu__##name##_locked
#define EXPORT_PER_CPU_SYMBOL(var) EXPORT_SYMBOL(per_cpu__##var)
#define EXPORT_PER_CPU_SYMBOL_GPL(var) EXPORT_SYMBOL_GPL(per_cpu__##var)
+#define EXPORT_PER_CPU_LOCKED_SYMBOL_GPL(var) EXPORT_SYMBOL_GPL(per_cpu_lock__##var##_locked); EXPORT_SYMBOL_GPL(per_cpu__##var##_locked)
+
#else
#include <asm-generic/percpu.h>
diff -rup -x CVS 2.6.16-rt17/include/asm-powerpc/pmac_feature.h rt-powerpc/include/asm-powerpc/pmac_feature.h
--- 2.6.16-rt17/include/asm-powerpc/pmac_feature.h 2006-03-20 14:53:29.000000000 +0900
+++ rt-powerpc/include/asm-powerpc/pmac_feature.h 2006-05-10 13:52:58.000000000 +0900
@@ -378,7 +378,7 @@ extern struct macio_chip* macio_find(str
* Those are exported by pmac feature for internal use by arch code
* only like the platform function callbacks, do not use directly in drivers
*/
-extern spinlock_t feature_lock;
+extern raw_spinlock_t feature_lock;
extern struct device_node *uninorth_node;
extern u32 __iomem *uninorth_base;
diff -rup -x CVS 2.6.16-rt17/kernel/time/clockevents.c rt-powerpc/kernel/time/clockevents.c
--- 2.6.16-rt17/kernel/time/clockevents.c 2006-04-26 18:24:29.000000000 +0900
+++ rt-powerpc/kernel/time/clockevents.c 2006-07-12 13:58:28.000000000 +0900
@@ -29,6 +29,8 @@
#include <linux/percpu.h>
#include <linux/sysdev.h>
#include <linux/hrtimer.h>
+#include <linux/irq.h>
+#include <linux/profile.h>
#define MAX_CLOCK_EVENTS 4
Tsutomu OWA writes:
> diff -rup -x CVS 2.6.16-rt17/arch/powerpc/kernel/time.c rt-powerpc/arch/powerpc/kernel/time.c
> --- 2.6.16-rt17/arch/powerpc/kernel/time.c 2006-04-26 18:24:28.000000000 +0900
> +++ rt-powerpc/arch/powerpc/kernel/time.c 2006-07-12 13:45:31.000000000 +0900
> @@ -200,6 +200,7 @@ void udelay(unsigned long usecs)
> }
> EXPORT_SYMBOL(udelay);
>
> +#ifndef CONFIG_GENERIC_TIME
I would be very surprised if this is all that is required for
CONFIG_GENERIC_TIME to work correctly on powerpc. Have you verified
that the CONFIG_GENERIC_TIME stuff works correctly on powerpc and
provides all the features provided by the current implementation?
Paul.
Hi,
> On Fri, 11 Aug 2006 15:11:47 +1000
> Paul Mackerras <[email protected]> said:
> I would be very surprised if this is all that is required for
> CONFIG_GENERIC_TIME to work correctly on powerpc. Have you verified
> that the CONFIG_GENERIC_TIME stuff works correctly on powerpc and
> provides all the features provided by the current implementation?
Well, probably no as you say so.
What I did for CONFIG_GENERIC_TIME is just to fix a compile
error and to see if the kernel boots or not. As I mentioned,
it's experimental and is posted to see whether I'm moving in the
right direction or not.
I'm afraid I have not yet looked into any generic time related
features/implementations. Looks like generic time related things
should be on the ToDo list.
Thanks a lot for your response.
-- owa
On Fri, 2006-08-11 at 15:08 +0900, Tsutomu OWA wrote:
> > On Fri, 11 Aug 2006 15:11:47 +1000
> > Paul Mackerras <[email protected]> said:
>
> > I would be very surprised if this is all that is required for
> > CONFIG_GENERIC_TIME to work correctly on powerpc. Have you verified
> > that the CONFIG_GENERIC_TIME stuff works correctly on powerpc and
> > provides all the features provided by the current implementation?
>
> Well, probably no as you say so.
>
> What I did for CONFIG_GENERIC_TIME is just to fix a compile
> error and to see if the kernel boots or not. As I mentioned,
> it's experimental and is posted to see whether I'm moving in the
> right direction or not.
>
> I'm afraid I have not yet looked into any generic time related
> features/implementations. Looks like generic time related things
> should be on the ToDo list.
You might take a peek at the patch set here:
http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
CONFIG_GENERIC_TIME.
thanks
-john
> You might take a peek at the patch set here:
> http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
> CONFIG_GENERIC_TIME.
Afaik, as-is, this patch will remove updating of the various bits used
by the vDSO for userland gettimeofday without actually removing the vdso
itself. Thus, with a recent glibc, it will break gettimeofday,
clock_gettime, .... Pretty bad :)
Ben.
On Thu, 2006-08-17 at 01:38 +0200, Benjamin Herrenschmidt wrote:
> > You might take a peek at the patch set here:
> > http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
> > CONFIG_GENERIC_TIME.
>
> Afaik, as-is, this patch will remove updating of the various bits used
> by the vDSO for userland gettimeofday without actually removing the vdso
> itself. Thus, with a recent glibc, it will break gettimeofday,
> clock_gettime, .... Pretty bad :)
Hey Ben,
I appreciate your looking over my patch. You are correct, the
conversion is a bit rough and I've not yet been able to work on the
powerpc vDSO, although I'd like to get it working so any help or
suggestions would be appreciated (is there a reason the vDSO is written
in ASM?).
If you have any other concerns w/ that patch, or the generic timekeeping
code, please let me know and I'll do what I can to address them.
thanks
-john
> Hey Ben,
> I appreciate your looking over my patch. You are correct, the
> conversion is a bit rough and I've not yet been able to work on the
> powerpc vDSO, although I'd like to get it working so any help or
> suggestions would be appreciated (is there a reason the vDSO is written
> in ASM?).
>
> If you have any other concerns w/ that patch, or the generic timekeeping
> code, please let me know and I'll do what I can to address them.
Well, I've been wanting to look at your stuff and possibly do the
conversion for some time, provided we don't lose performances ... Our
current implementation is very optimized to avoid even memory barriers
in most cases and I doubt we'll be able to be as fine tuned using your
generic code, thus it's a tradeoff decision that we have to do. But
then, I need to look into the details before doing any final
statement :)
As for why the vDSO is in assembly, well... because it's kewl ? :) More
seriously, because it's much more simpler that way (and it's hand
optimized in a couple of places, though that would probably benefit
going through a proper scheduling analysis). The vDSO code has "special"
calling conventions (like the need to tweak cr.so, the non-use of the
TOC, the lack of procedure descriptors, symbols are offsets to the
functions, etc...) that makes it awkward to write it in C.
Ben
On Thu, 2006-08-17 at 02:26 +0200, Benjamin Herrenschmidt wrote:
> > Hey Ben,
> > I appreciate your looking over my patch. You are correct, the
> > conversion is a bit rough and I've not yet been able to work on the
> > powerpc vDSO, although I'd like to get it working so any help or
> > suggestions would be appreciated (is there a reason the vDSO is written
> > in ASM?).
> >
> > If you have any other concerns w/ that patch, or the generic timekeeping
> > code, please let me know and I'll do what I can to address them.
>
> Well, I've been wanting to look at your stuff and possibly do the
> conversion for some time, provided we don't lose performances ... Our
> current implementation is very optimized to avoid even memory barriers
> in most cases and I doubt we'll be able to be as fine tuned using your
> generic code, thus it's a tradeoff decision that we have to do. But
> then, I need to look into the details before doing any final
> statement :)
Ok, although do let me know if you see places where the generic code
could use any of the optimizations used in powerpc.
thanks
-john
> > Well, I've been wanting to look at your stuff and possibly do the
> > conversion for some time, provided we don't lose performances ... Our
> > current implementation is very optimized to avoid even memory barriers
> > in most cases and I doubt we'll be able to be as fine tuned using your
> > generic code, thus it's a tradeoff decision that we have to do. But
> > then, I need to look into the details before doing any final
> > statement :)
>
> Ok, although do let me know if you see places where the generic code
> could use any of the optimizations used in powerpc.
Difficult... but maybe. One of the main idea is that the 3 values used
for "calibration" (pre-mult offset, multiplier and post-mult offset) are
in a structure. There is an array of 2 of these and a pointer to the
"current" one. When changing those values, we update the "other" one,
wmb, then flip the pointer. The readers can then mostly be barrier-less
since there is a natural data dependency on the pointer.
Ben.
Sorry about the late response.
> On Fri, 11 Aug 2006 10:56:23 -0700, john stultz <[email protected]> wrote:
> You might take a peek at the patch set here:
> http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
> CONFIG_GENERIC_TIME.
Thank a lot for the info. I'll look into it (I need to read
timekeeping.txt first...)
BTW, do you have any plan to make it vsdo safe?
# I'm completely unfamiliar with vsdo :-X.
thanks
-- owa
Software Engineering Center, TOSHIBA.