* How to build the kernel without any optimization?
From: Shawn Jin @ 2010-08-21 6:59 UTC (permalink / raw)
To: ppcdev
Hi,
I'm tracing the execution of ds1307_probe() and find that some of
variables or function arguments cannot be printed in gdb because they
are optimized out or not in the current context. This really gives
some headache. Is there a way to build the kernel without any
optimization? What gcc option shall I disable or add?
I already added the following to arch/powerpc/Makefile.
# Prevent GDB from jumping around in the code when trying to single step
ifeq ($(CONFIG_DEBUG_KERNEL),y)
KBUILD_CFLAGS += -fno-schedule-insns -fno-schedule-insns2
endif
Thanks,
-Shawn.
^ permalink raw reply
* Re: How to build the kernel without any optimization?
From: Nicholas Mc Guire @ 2010-08-21 7:31 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTinb9yJk10yE2nAT_exNaANHyFbAH59LOM=Jy7Oz@mail.gmail.com>
On Fri, 20 Aug 2010, Shawn Jin wrote:
> Hi,
>
> I'm tracing the execution of ds1307_probe() and find that some of
> variables or function arguments cannot be printed in gdb because they
> are optimized out or not in the current context. This really gives
> some headache. Is there a way to build the kernel without any
> optimization? What gcc option shall I disable or add?
>
> I already added the following to arch/powerpc/Makefile.
>
> # Prevent GDB from jumping around in the code when trying to single step
> ifeq ($(CONFIG_DEBUG_KERNEL),y)
> KBUILD_CFLAGS += -fno-schedule-insns -fno-schedule-insns2
> endif
>
much of the kernel can not be build without optimization - what you
can do though is slectively try to disable optimization for specific
files by putting
CFLAGS_REMOVE_objfilenam.o = -SOME_OPT
in the Makefile. I think that is safer than what you did above as this would
always depend on the order of options that ultimately get passed to gcc.
hofrat
^ permalink raw reply
* [PATCH] pmu: add compat_pmu_ioctl
From: Andreas Schwab @ 2010-08-21 21:32 UTC (permalink / raw)
To: linuxppc-dev
The ioctls are actually compatible, but due to historical mistake the
numbers differ between 32bit and 64bit.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
drivers/macintosh/via-pmu.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 35bc273..610f247 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2349,11 +2349,52 @@ static long pmu_unlocked_ioctl(struct file *filp,
return ret;
}
+#ifdef CONFIG_COMPAT
+#define PMU_IOC_GET_BACKLIGHT32 _IOR('B', 1, u32)
+#define PMU_IOC_SET_BACKLIGHT32 _IOW('B', 2, u32)
+#define PMU_IOC_GET_MODEL32 _IOR('B', 3, u32)
+#define PMU_IOC_HAS_ADB32 _IOR('B', 4, u32)
+#define PMU_IOC_CAN_SLEEP32 _IOR('B', 5, u32)
+#define PMU_IOC_GRAB_BACKLIGHT32 _IOR('B', 6, u32)
+
+static long compat_pmu_ioctl (struct file *filp, u_int cmd, u_long arg)
+{
+ switch (cmd) {
+ case PMU_IOC_SLEEP:
+ break;
+ case PMU_IOC_GET_BACKLIGHT32:
+ cmd = PMU_IOC_GET_BACKLIGHT;
+ break;
+ case PMU_IOC_SET_BACKLIGHT32:
+ cmd = PMU_IOC_SET_BACKLIGHT;
+ break;
+ case PMU_IOC_GET_MODEL32:
+ cmd = PMU_IOC_GET_MODEL;
+ break;
+ case PMU_IOC_HAS_ADB32:
+ cmd = PMU_IOC_HAS_ADB;
+ break;
+ case PMU_IOC_CAN_SLEEP32:
+ cmd = PMU_IOC_CAN_SLEEP;
+ break;
+ case PMU_IOC_GRAB_BACKLIGHT32:
+ cmd = PMU_IOC_GRAB_BACKLIGHT;
+ break;
+ default:
+ return -ENOIOCTLCMD;
+ }
+ return pmu_unlocked_ioctl(filp, cmd, arg);
+}
+#endif
+
static const struct file_operations pmu_device_fops = {
.read = pmu_read,
.write = pmu_write,
.poll = pmu_fpoll,
.unlocked_ioctl = pmu_unlocked_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_pmu_ioctl,
+#endif
.open = pmu_open,
.release = pmu_release,
};
--
1.7.2.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Andreas Schwab @ 2010-08-21 21:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc
Neither lfs nor stfs touch the fpscr, so remove the restore/save of it
around them.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/include/asm/kvm_fpu.h | 4 +-
arch/powerpc/include/asm/system.h | 4 +-
arch/powerpc/kernel/align.c | 4 +-
arch/powerpc/kernel/fpu.S | 10 -------
arch/powerpc/kvm/book3s_paired_singles.c | 44 +++++++++++++----------------
arch/powerpc/kvm/fpu.S | 8 -----
6 files changed, 26 insertions(+), 48 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_fpu.h b/arch/powerpc/include/asm/kvm_fpu.h
index c3d4f05..92daae1 100644
--- a/arch/powerpc/include/asm/kvm_fpu.h
+++ b/arch/powerpc/include/asm/kvm_fpu.h
@@ -82,7 +82,7 @@ FPD_THREE_IN(fmadd)
FPD_THREE_IN(fnmsub)
FPD_THREE_IN(fnmadd)
-extern void kvm_cvt_fd(u32 *from, u64 *to, u64 *fpscr);
-extern void kvm_cvt_df(u64 *from, u32 *to, u64 *fpscr);
+extern void kvm_cvt_fd(u32 *from, u64 *to);
+extern void kvm_cvt_df(u64 *from, u32 *to);
#endif
diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/system.h
index 6c294ac..0b3fe78 100644
--- a/arch/powerpc/include/asm/system.h
+++ b/arch/powerpc/include/asm/system.h
@@ -154,8 +154,8 @@ extern void enable_kernel_spe(void);
extern void giveup_spe(struct task_struct *);
extern void load_up_spe(struct task_struct *);
extern int fix_alignment(struct pt_regs *);
-extern void cvt_fd(float *from, double *to, struct thread_struct *thread);
-extern void cvt_df(double *from, float *to, struct thread_struct *thread);
+extern void cvt_fd(float *from, double *to);
+extern void cvt_df(double *from, float *to);
#ifndef CONFIG_SMP
extern void discard_lazy_cpu_state(void);
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index b876e98..8184ee9 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -889,7 +889,7 @@ int fix_alignment(struct pt_regs *regs)
#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
- cvt_df(&data.dd, (float *)&data.v[4], ¤t->thread);
+ cvt_df(&data.dd, (float *)&data.v[4]);
preempt_enable();
#else
return 0;
@@ -933,7 +933,7 @@ int fix_alignment(struct pt_regs *regs)
#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
- cvt_fd((float *)&data.v[4], &data.dd, ¤t->thread);
+ cvt_fd((float *)&data.v[4], &data.dd);
preempt_enable();
#else
return 0;
diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index fc8f5b1..e86c040 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -163,24 +163,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
/*
* These are used in the alignment trap handler when emulating
* single-precision loads and stores.
- * We restore and save the fpscr so the task gets the same result
- * and exceptions as if the cpu had performed the load or store.
*/
_GLOBAL(cvt_fd)
- lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
- MTFSF_L(0)
lfs 0,0(r3)
stfd 0,0(r4)
- mffs 0
- stfd 0,THREAD_FPSCR(r5) /* save new fpscr value */
blr
_GLOBAL(cvt_df)
- lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
- MTFSF_L(0)
lfd 0,0(r3)
stfs 0,0(r4)
- mffs 0
- stfd 0,THREAD_FPSCR(r5) /* save new fpscr value */
blr
diff --git a/arch/powerpc/kvm/book3s_paired_singles.c b/arch/powerpc/kvm/book3s_paired_singles.c
index 474f2e2..35a701f 100644
--- a/arch/powerpc/kvm/book3s_paired_singles.c
+++ b/arch/powerpc/kvm/book3s_paired_singles.c
@@ -159,7 +159,7 @@
static inline void kvmppc_sync_qpr(struct kvm_vcpu *vcpu, int rt)
{
- kvm_cvt_df(&vcpu->arch.fpr[rt], &vcpu->arch.qpr[rt], &vcpu->arch.fpscr);
+ kvm_cvt_df(&vcpu->arch.fpr[rt], &vcpu->arch.qpr[rt]);
}
static void kvmppc_inject_pf(struct kvm_vcpu *vcpu, ulong eaddr, bool is_store)
@@ -204,7 +204,7 @@ static int kvmppc_emulate_fpr_load(struct kvm_run *run, struct kvm_vcpu *vcpu,
/* put in registers */
switch (ls_type) {
case FPU_LS_SINGLE:
- kvm_cvt_fd((u32*)tmp, &vcpu->arch.fpr[rs], &vcpu->arch.fpscr);
+ kvm_cvt_fd((u32*)tmp, &vcpu->arch.fpr[rs]);
vcpu->arch.qpr[rs] = *((u32*)tmp);
break;
case FPU_LS_DOUBLE:
@@ -230,7 +230,7 @@ static int kvmppc_emulate_fpr_store(struct kvm_run *run, struct kvm_vcpu *vcpu,
switch (ls_type) {
case FPU_LS_SINGLE:
- kvm_cvt_df(&vcpu->arch.fpr[rs], (u32*)tmp, &vcpu->arch.fpscr);
+ kvm_cvt_df(&vcpu->arch.fpr[rs], (u32*)tmp);
val = *((u32*)tmp);
len = sizeof(u32);
break;
@@ -296,7 +296,7 @@ static int kvmppc_emulate_psq_load(struct kvm_run *run, struct kvm_vcpu *vcpu,
emulated = EMULATE_DONE;
/* put in registers */
- kvm_cvt_fd(&tmp[0], &vcpu->arch.fpr[rs], &vcpu->arch.fpscr);
+ kvm_cvt_fd(&tmp[0], &vcpu->arch.fpr[rs]);
vcpu->arch.qpr[rs] = tmp[1];
dprintk(KERN_INFO "KVM: PSQ_LD [0x%x, 0x%x] at 0x%lx (%d)\n", tmp[0],
@@ -314,7 +314,7 @@ static int kvmppc_emulate_psq_store(struct kvm_run *run, struct kvm_vcpu *vcpu,
u32 tmp[2];
int len = w ? sizeof(u32) : sizeof(u64);
- kvm_cvt_df(&vcpu->arch.fpr[rs], &tmp[0], &vcpu->arch.fpscr);
+ kvm_cvt_df(&vcpu->arch.fpr[rs], &tmp[0]);
tmp[1] = vcpu->arch.qpr[rs];
r = kvmppc_st(vcpu, &addr, len, tmp, true);
@@ -516,9 +516,9 @@ static int kvmppc_ps_three_in(struct kvm_vcpu *vcpu, bool rc,
WARN_ON(rc);
/* PS0 */
- kvm_cvt_df(&fpr[reg_in1], &ps0_in1, &vcpu->arch.fpscr);
- kvm_cvt_df(&fpr[reg_in2], &ps0_in2, &vcpu->arch.fpscr);
- kvm_cvt_df(&fpr[reg_in3], &ps0_in3, &vcpu->arch.fpscr);
+ kvm_cvt_df(&fpr[reg_in1], &ps0_in1);
+ kvm_cvt_df(&fpr[reg_in2], &ps0_in2);
+ kvm_cvt_df(&fpr[reg_in3], &ps0_in3);
if (scalar & SCALAR_LOW)
ps0_in2 = qpr[reg_in2];
@@ -529,7 +529,7 @@ static int kvmppc_ps_three_in(struct kvm_vcpu *vcpu, bool rc,
ps0_in1, ps0_in2, ps0_in3, ps0_out);
if (!(scalar & SCALAR_NO_PS0))
- kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
+ kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
/* PS1 */
ps1_in1 = qpr[reg_in1];
@@ -566,12 +566,12 @@ static int kvmppc_ps_two_in(struct kvm_vcpu *vcpu, bool rc,
WARN_ON(rc);
/* PS0 */
- kvm_cvt_df(&fpr[reg_in1], &ps0_in1, &vcpu->arch.fpscr);
+ kvm_cvt_df(&fpr[reg_in1], &ps0_in1);
if (scalar & SCALAR_LOW)
ps0_in2 = qpr[reg_in2];
else
- kvm_cvt_df(&fpr[reg_in2], &ps0_in2, &vcpu->arch.fpscr);
+ kvm_cvt_df(&fpr[reg_in2], &ps0_in2);
func(&vcpu->arch.fpscr, &ps0_out, &ps0_in1, &ps0_in2);
@@ -579,7 +579,7 @@ static int kvmppc_ps_two_in(struct kvm_vcpu *vcpu, bool rc,
dprintk(KERN_INFO "PS2 ps0 -> f(0x%x, 0x%x) = 0x%x\n",
ps0_in1, ps0_in2, ps0_out);
- kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
+ kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
}
/* PS1 */
@@ -615,13 +615,13 @@ static int kvmppc_ps_one_in(struct kvm_vcpu *vcpu, bool rc,
WARN_ON(rc);
/* PS0 */
- kvm_cvt_df(&fpr[reg_in], &ps0_in, &vcpu->arch.fpscr);
+ kvm_cvt_df(&fpr[reg_in], &ps0_in);
func(&vcpu->arch.fpscr, &ps0_out, &ps0_in);
dprintk(KERN_INFO "PS1 ps0 -> f(0x%x) = 0x%x\n",
ps0_in, ps0_out);
- kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
+ kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
/* PS1 */
ps1_in = qpr[reg_in];
@@ -671,7 +671,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, struct kvm_vcpu *vcpu)
#ifdef DEBUG
for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++) {
u32 f;
- kvm_cvt_df(&vcpu->arch.fpr[i], &f, &vcpu->arch.fpscr);
+ kvm_cvt_df(&vcpu->arch.fpr[i], &f);
dprintk(KERN_INFO "FPR[%d] = 0x%x / 0x%llx QPR[%d] = 0x%x\n",
i, f, vcpu->arch.fpr[i], i, vcpu->arch.qpr[i]);
}
@@ -796,8 +796,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, struct kvm_vcpu *vcpu)
vcpu->arch.fpr[ax_rd] = vcpu->arch.fpr[ax_ra];
/* vcpu->arch.qpr[ax_rd] = vcpu->arch.fpr[ax_rb]; */
kvm_cvt_df(&vcpu->arch.fpr[ax_rb],
- &vcpu->arch.qpr[ax_rd],
- &vcpu->arch.fpscr);
+ &vcpu->arch.qpr[ax_rd]);
break;
case OP_4X_PS_MERGE01:
WARN_ON(rcomp);
@@ -808,19 +807,16 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, struct kvm_vcpu *vcpu)
WARN_ON(rcomp);
/* vcpu->arch.fpr[ax_rd] = vcpu->arch.qpr[ax_ra]; */
kvm_cvt_fd(&vcpu->arch.qpr[ax_ra],
- &vcpu->arch.fpr[ax_rd],
- &vcpu->arch.fpscr);
+ &vcpu->arch.fpr[ax_rd]);
/* vcpu->arch.qpr[ax_rd] = vcpu->arch.fpr[ax_rb]; */
kvm_cvt_df(&vcpu->arch.fpr[ax_rb],
- &vcpu->arch.qpr[ax_rd],
- &vcpu->arch.fpscr);
+ &vcpu->arch.qpr[ax_rd]);
break;
case OP_4X_PS_MERGE11:
WARN_ON(rcomp);
/* vcpu->arch.fpr[ax_rd] = vcpu->arch.qpr[ax_ra]; */
kvm_cvt_fd(&vcpu->arch.qpr[ax_ra],
- &vcpu->arch.fpr[ax_rd],
- &vcpu->arch.fpscr);
+ &vcpu->arch.fpr[ax_rd]);
vcpu->arch.qpr[ax_rd] = vcpu->arch.qpr[ax_rb];
break;
}
@@ -1255,7 +1251,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, struct kvm_vcpu *vcpu)
#ifdef DEBUG
for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++) {
u32 f;
- kvm_cvt_df(&vcpu->arch.fpr[i], &f, &vcpu->arch.fpscr);
+ kvm_cvt_df(&vcpu->arch.fpr[i], &f);
dprintk(KERN_INFO "FPR[%d] = 0x%x\n", i, f);
}
#endif
diff --git a/arch/powerpc/kvm/fpu.S b/arch/powerpc/kvm/fpu.S
index cb34bbe..bf68d59 100644
--- a/arch/powerpc/kvm/fpu.S
+++ b/arch/powerpc/kvm/fpu.S
@@ -273,19 +273,11 @@ FPD_THREE_IN(fnmsub)
FPD_THREE_IN(fnmadd)
_GLOBAL(kvm_cvt_fd)
- lfd 0,0(r5) /* load up fpscr value */
- MTFSF_L(0)
lfs 0,0(r3)
stfd 0,0(r4)
- mffs 0
- stfd 0,0(r5) /* save new fpscr value */
blr
_GLOBAL(kvm_cvt_df)
- lfd 0,0(r5) /* load up fpscr value */
- MTFSF_L(0)
lfd 0,0(r3)
stfs 0,0(r4)
- mffs 0
- stfd 0,0(r5) /* save new fpscr value */
blr
--
1.7.2.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Problems with compiling ldstfp.S
From: Sean MacLennan @ 2010-08-22 6:00 UTC (permalink / raw)
To: linuxppc-dev
The new file ldstfp.S is getting pulled in on the Warp due to
CONFIG_KPROBES, but does not compile:
AS arch/powerpc/lib/ldstfp.o
arch/powerpc/lib/ldstfp.S: Assembler messages:
arch/powerpc/lib/ldstfp.S:84: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:96: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:111: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:123: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:138: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:150: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:165: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:177: Error: Unrecognized opcode: `mtmsrd'
make[1]: *** [arch/powerpc/lib/ldstfp.o] Error 1
The Warp has a 440EP processor which does have floating point. But it
looks like mtmsrd is only defined for PPC64.
I would hate to lose KPROBES, it has been a huge help.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] pmu: add compat_pmu_ioctl
From: Arnd Bergmann @ 2010-08-22 11:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andreas Schwab
In-Reply-To: <m2lj7zzm6w.fsf@igel.home>
On Saturday 21 August 2010 23:32:23 Andreas Schwab wrote:
> The ioctls are actually compatible, but due to historical mistake the
> numbers differ between 32bit and 64bit.
Looks good to me, but
> +#ifdef CONFIG_COMPAT
> +#define PMU_IOC_GET_BACKLIGHT32 _IOR('B', 1, u32)
> +#define PMU_IOC_SET_BACKLIGHT32 _IOW('B', 2, u32)
> +#define PMU_IOC_GET_MODEL32 _IOR('B', 3, u32)
> +#define PMU_IOC_HAS_ADB32 _IOR('B', 4, u32)
> +#define PMU_IOC_CAN_SLEEP32 _IOR('B', 5, u32)
> +#define PMU_IOC_GRAB_BACKLIGHT32 _IOR('B', 6, u32)
It would be nicer to use compat_size_t instead of u32 for annotation
purposes. Obviously both of them are defined as unsigned int, so
that is no functional change.
> + return pmu_unlocked_ioctl(filp, cmd, arg);
This should ideally use "(unsigned long)compat_ptr(arg)" instead of
just arg. Also doesn't matter on powerpc, but it's better to do
it the strict way.
Arnd
^ permalink raw reply
* [PATCH/v2] via-pmu: add compat_pmu_ioctl
From: Andreas Schwab @ 2010-08-22 16:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <201008221333.50575.arnd@arndb.de>
The ioctls are actually compatible, but due to historical mistake the
numbers differ between 32bit and 64bit.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
drivers/macintosh/via-pmu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 35bc273..2d17e76 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -45,6 +45,7 @@
#include <linux/syscalls.h>
#include <linux/suspend.h>
#include <linux/cpu.h>
+#include <linux/compat.h>
#include <asm/prom.h>
#include <asm/machdep.h>
#include <asm/io.h>
@@ -2349,11 +2350,52 @@ static long pmu_unlocked_ioctl(struct file *filp,
return ret;
}
+#ifdef CONFIG_COMPAT
+#define PMU_IOC_GET_BACKLIGHT32 _IOR('B', 1, compat_size_t)
+#define PMU_IOC_SET_BACKLIGHT32 _IOW('B', 2, compat_size_t)
+#define PMU_IOC_GET_MODEL32 _IOR('B', 3, compat_size_t)
+#define PMU_IOC_HAS_ADB32 _IOR('B', 4, compat_size_t)
+#define PMU_IOC_CAN_SLEEP32 _IOR('B', 5, compat_size_t)
+#define PMU_IOC_GRAB_BACKLIGHT32 _IOR('B', 6, compat_size_t)
+
+static long compat_pmu_ioctl (struct file *filp, u_int cmd, u_long arg)
+{
+ switch (cmd) {
+ case PMU_IOC_SLEEP:
+ break;
+ case PMU_IOC_GET_BACKLIGHT32:
+ cmd = PMU_IOC_GET_BACKLIGHT;
+ break;
+ case PMU_IOC_SET_BACKLIGHT32:
+ cmd = PMU_IOC_SET_BACKLIGHT;
+ break;
+ case PMU_IOC_GET_MODEL32:
+ cmd = PMU_IOC_GET_MODEL;
+ break;
+ case PMU_IOC_HAS_ADB32:
+ cmd = PMU_IOC_HAS_ADB;
+ break;
+ case PMU_IOC_CAN_SLEEP32:
+ cmd = PMU_IOC_CAN_SLEEP;
+ break;
+ case PMU_IOC_GRAB_BACKLIGHT32:
+ cmd = PMU_IOC_GRAB_BACKLIGHT;
+ break;
+ default:
+ return -ENOIOCTLCMD;
+ }
+ return pmu_unlocked_ioctl(filp, cmd, (unsigned long)compat_ptr(arg));
+}
+#endif
+
static const struct file_operations pmu_device_fops = {
.read = pmu_read,
.write = pmu_write,
.poll = pmu_fpoll,
.unlocked_ioctl = pmu_unlocked_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_pmu_ioctl,
+#endif
.open = pmu_open,
.release = pmu_release,
};
--
1.7.2.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH 13/26] KVM: PPC: Add feature bitmap for magic page
From: Avi Kivity @ 2010-08-22 16:42 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1282053481-18787-14-git-send-email-agraf@suse.de>
On 08/17/2010 04:57 PM, Alexander Graf wrote:
> We will soon add SR PV support to the shared page, so we need some
> infrastructure that allows the guest to query for features KVM exports.
>
> This patch adds a second return value to the magic mapping that
> indicated to the guest which features are available.
>
You need to make that feature controllable from userspace, to allow
new->old save/restore.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 00/26] KVM: PPC: Mid-August patch queue
From: Avi Kivity @ 2010-08-22 16:46 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1282053481-18787-1-git-send-email-agraf@suse.de>
On 08/17/2010 04:57 PM, Alexander Graf wrote:
> Howdy,
>
> This is my local patch queue with stuff that has accumulated over the last
> weeks on KVM for PPC with some last minute fixes, speedups and debugging help
> that I needed for the KVM Forum ;-).
>
> The highlights of this set are:
>
> - Converted most important debug points to tracepoints
> - Flush less PTEs (speedup)
> - Go back to our own hash (less duplicates)
> - Make SRs guest settable (speedup for 32 bit guests)
> - Remove r30/r31 restrictions from PV hooks (speedup!)
> - Fix random breakages
> - Fix random guest stalls
> - 440GP host support (Thanks Hollis!)
>
> Keep in mind that this is the first version that is stable on PPC32 hosts.
> All versions prior to this could occupy otherwise used segment entries and
> thus crash your machine :-).
>
> After finally meeting Avi again, we also agreed to give pulls a try. So
> here we go - this is my tree online:
>
> arch/powerpc/include/asm/kvm_book3s.h | 25 ++--
> arch/powerpc/include/asm/kvm_para.h | 3 +
> arch/powerpc/kernel/asm-offsets.c | 1 +
> arch/powerpc/kernel/kvm.c | 144 ++++++++++++++++++---
> arch/powerpc/kernel/kvm_emul.S | 75 +++++++++--
> arch/powerpc/kvm/44x.c | 3 +-
> arch/powerpc/kvm/44x_tlb.c | 1 +
> arch/powerpc/kvm/book3s.c | 54 ++++----
> arch/powerpc/kvm/book3s_32_mmu.c | 83 +++++++------
> arch/powerpc/kvm/book3s_32_mmu_host.c | 67 ++++++----
> arch/powerpc/kvm/book3s_64_mmu_host.c | 59 +++------
> arch/powerpc/kvm/book3s_emulate.c | 48 +++-----
> arch/powerpc/kvm/book3s_mmu_hpte.c | 38 ++----
> arch/powerpc/kvm/booke.c | 8 +-
> arch/powerpc/kvm/powerpc.c | 5 +-
> arch/powerpc/kvm/trace.h | 230 +++++++++++++++++++++++++++++++++
> 16 files changed, 614 insertions(+), 230 deletions(-)
Documentation/kvm/ppc-pv.txt +++++++++++++++++++++++++++
?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [PATCH] powerpc: mtmsrd not defined
From: Sean MacLennan @ 2010-08-22 22:09 UTC (permalink / raw)
To: linuxppc-dev
Let's try a patch to get the ball rolling.
ldstfp.S does not compile if mtmsrd not defined. But is it only defined
for BOOK3S_64. This defines mtmsrd to be mtmsr on all but BOOK3S_64.
This solves the compile problem... but I am not sure how to test it.
I am also not sure if this is the best place to define it. If the
mapping of mtmsrd to mtmsr is correct, maybe it should be in asm/reg.h?
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/lib/ldstfp.S b/arch/powerpc/lib/ldstfp.S
index f644863..df8a03b 100644
--- a/arch/powerpc/lib/ldstfp.S
+++ b/arch/powerpc/lib/ldstfp.S
@@ -17,6 +17,10 @@
#include <asm/asm-offsets.h>
#include <linux/errno.h>
+#ifndef CONFIG_PPC_BOOK3S_64
+#define mtmsrd mtmsr
+#endif
+
#define STKFRM (PPC_MIN_STKFRM + 16)
.macro extab instr,handler
Cheers,
Sean
^ permalink raw reply related
* Re: [PATCH] powerpc: mtmsrd not defined
From: Benjamin Herrenschmidt @ 2010-08-22 22:34 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20100822180958.6305f5b1@lappy.seanm.ca>
On Sun, 2010-08-22 at 18:09 -0400, Sean MacLennan wrote:
> Let's try a patch to get the ball rolling.
>
> ldstfp.S does not compile if mtmsrd not defined. But is it only defined
> for BOOK3S_64. This defines mtmsrd to be mtmsr on all but BOOK3S_64.
> This solves the compile problem... but I am not sure how to test it.
>
> I am also not sure if this is the best place to define it. If the
> mapping of mtmsrd to mtmsr is correct, maybe it should be in asm/reg.h?
I'd rather have a macro somewhere in ppc_asm.h (MTMSR ?) that does the
right thing. We might even already have one...
Cheers,
Ben.
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/arch/powerpc/lib/ldstfp.S b/arch/powerpc/lib/ldstfp.S
> index f644863..df8a03b 100644
> --- a/arch/powerpc/lib/ldstfp.S
> +++ b/arch/powerpc/lib/ldstfp.S
> @@ -17,6 +17,10 @@
> #include <asm/asm-offsets.h>
> #include <linux/errno.h>
>
> +#ifndef CONFIG_PPC_BOOK3S_64
> +#define mtmsrd mtmsr
> +#endif
> +
> #define STKFRM (PPC_MIN_STKFRM + 16)
>
> .macro extab instr,handler
>
> Cheers,
> Sean
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: mtmsrd not defined
From: Sean MacLennan @ 2010-08-22 22:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1282516494.22370.440.camel@pasglop>
On Mon, 23 Aug 2010 08:34:54 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I'd rather have a macro somewhere in ppc_asm.h (MTMSR ?) that does the
> right thing. We might even already have one...
We do.... here is a new, improved patch.
Replace the BOOK3S_64 specific mtmsrd with the generic MTMSRD macro.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/lib/ldstfp.S b/arch/powerpc/lib/ldstfp.S
index f644863..ce818a5 100644
--- a/arch/powerpc/lib/ldstfp.S
+++ b/arch/powerpc/lib/ldstfp.S
@@ -81,7 +81,7 @@ _GLOBAL(do_lfs)
mfmsr r6
ori r7,r6,MSR_FP
cmpwi cr7,r3,0
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
stfd fr0,STKFRM-16(r1)
@@ -93,7 +93,7 @@ _GLOBAL(do_lfs)
lfd fr0,STKFRM-16(r1)
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
@@ -108,7 +108,7 @@ _GLOBAL(do_lfd)
mfmsr r6
ori r7,r6,MSR_FP
cmpwi cr7,r3,0
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
stfd fr0,STKFRM-16(r1)
@@ -120,7 +120,7 @@ _GLOBAL(do_lfd)
lfd fr0,STKFRM-16(r1)
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
@@ -135,7 +135,7 @@ _GLOBAL(do_stfs)
mfmsr r6
ori r7,r6,MSR_FP
cmpwi cr7,r3,0
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
stfd fr0,STKFRM-16(r1)
@@ -147,7 +147,7 @@ _GLOBAL(do_stfs)
lfd fr0,STKFRM-16(r1)
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
@@ -162,7 +162,7 @@ _GLOBAL(do_stfd)
mfmsr r6
ori r7,r6,MSR_FP
cmpwi cr7,r3,0
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
stfd fr0,STKFRM-16(r1)
@@ -174,7 +174,7 @@ _GLOBAL(do_stfd)
lfd fr0,STKFRM-16(r1)
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
@@ -229,7 +229,7 @@ _GLOBAL(do_lvx)
oris r7,r6,MSR_VEC@h
cmpwi cr7,r3,0
li r8,STKFRM-16
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
stvx vr0,r1,r8
@@ -241,7 +241,7 @@ _GLOBAL(do_lvx)
lvx vr0,r1,r8
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
@@ -257,7 +257,7 @@ _GLOBAL(do_stvx)
oris r7,r6,MSR_VEC@h
cmpwi cr7,r3,0
li r8,STKFRM-16
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
stvx vr0,r1,r8
@@ -269,7 +269,7 @@ _GLOBAL(do_stvx)
lvx vr0,r1,r8
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
@@ -325,7 +325,7 @@ _GLOBAL(do_lxvd2x)
oris r7,r6,MSR_VSX@h
cmpwi cr7,r3,0
li r8,STKFRM-16
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
STXVD2X(0,r1,r8)
@@ -337,7 +337,7 @@ _GLOBAL(do_lxvd2x)
LXVD2X(0,r1,r8)
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
@@ -353,7 +353,7 @@ _GLOBAL(do_stxvd2x)
oris r7,r6,MSR_VSX@h
cmpwi cr7,r3,0
li r8,STKFRM-16
- mtmsrd r7
+ MTMSRD(r7)
isync
beq cr7,1f
STXVD2X(0,r1,r8)
@@ -365,7 +365,7 @@ _GLOBAL(do_stxvd2x)
LXVD2X(0,r1,r8)
4: PPC_LL r0,STKFRM+PPC_LR_STKOFF(r1)
mtlr r0
- mtmsrd r6
+ MTMSRD(r6)
isync
mr r3,r9
addi r1,r1,STKFRM
Cheers,
Sean
^ permalink raw reply related
* Re: [PATCH] powerpc: remove fpscr use from [kvm_]cvt_{fd,df}
From: Michael Neuling @ 2010-08-23 0:23 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Paul Mackerras, kvm-ppc
In-Reply-To: <m2hbinzlon.fsf@igel.home>
> Neither lfs nor stfs touch the fpscr, so remove the restore/save of it
> around them.
Do some 32 bit processors need this?
In 32 bit before the merge, we use to have code that did:
#if defined(CONFIG_4xx) || defined(CONFIG_E500)
#define cvt_fd without save/restore fpscr
#else
#define cvt_fd with save/restore fpscr
#end if
Kumar; does this ring any bells?
(The addition of this predates even bitkeeper)
Mikey
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
> ---
> arch/powerpc/include/asm/kvm_fpu.h | 4 +-
> arch/powerpc/include/asm/system.h | 4 +-
> arch/powerpc/kernel/align.c | 4 +-
> arch/powerpc/kernel/fpu.S | 10 -------
> arch/powerpc/kvm/book3s_paired_singles.c | 44 +++++++++++++---------------
-
> arch/powerpc/kvm/fpu.S | 8 -----
> 6 files changed, 26 insertions(+), 48 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_fpu.h b/arch/powerpc/include/asm/kv
m_fpu.h
> index c3d4f05..92daae1 100644
> --- a/arch/powerpc/include/asm/kvm_fpu.h
> +++ b/arch/powerpc/include/asm/kvm_fpu.h
> @@ -82,7 +82,7 @@ FPD_THREE_IN(fmadd)
> FPD_THREE_IN(fnmsub)
> FPD_THREE_IN(fnmadd)
>
> -extern void kvm_cvt_fd(u32 *from, u64 *to, u64 *fpscr);
> -extern void kvm_cvt_df(u64 *from, u32 *to, u64 *fpscr);
> +extern void kvm_cvt_fd(u32 *from, u64 *to);
> +extern void kvm_cvt_df(u64 *from, u32 *to);
>
> #endif
> diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/sys
tem.h
> index 6c294ac..0b3fe78 100644
> --- a/arch/powerpc/include/asm/system.h
> +++ b/arch/powerpc/include/asm/system.h
> @@ -154,8 +154,8 @@ extern void enable_kernel_spe(void);
> extern void giveup_spe(struct task_struct *);
> extern void load_up_spe(struct task_struct *);
> extern int fix_alignment(struct pt_regs *);
> -extern void cvt_fd(float *from, double *to, struct thread_struct *thread);
> -extern void cvt_df(double *from, float *to, struct thread_struct *thread);
> +extern void cvt_fd(float *from, double *to);
> +extern void cvt_df(double *from, float *to);
>
> #ifndef CONFIG_SMP
> extern void discard_lazy_cpu_state(void);
> diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
> index b876e98..8184ee9 100644
> --- a/arch/powerpc/kernel/align.c
> +++ b/arch/powerpc/kernel/align.c
> @@ -889,7 +889,7 @@ int fix_alignment(struct pt_regs *regs)
> #ifdef CONFIG_PPC_FPU
> preempt_disable();
> enable_kernel_fp();
> - cvt_df(&data.dd, (float *)&data.v[4], ¤t->thread)
;
> + cvt_df(&data.dd, (float *)&data.v[4]);
> preempt_enable();
> #else
> return 0;
> @@ -933,7 +933,7 @@ int fix_alignment(struct pt_regs *regs)
> #ifdef CONFIG_PPC_FPU
> preempt_disable();
> enable_kernel_fp();
> - cvt_fd((float *)&data.v[4], &data.dd, ¤t->thread);
> + cvt_fd((float *)&data.v[4], &data.dd);
> preempt_enable();
> #else
> return 0;
> diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
> index fc8f5b1..e86c040 100644
> --- a/arch/powerpc/kernel/fpu.S
> +++ b/arch/powerpc/kernel/fpu.S
> @@ -163,24 +163,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> /*
> * These are used in the alignment trap handler when emulating
> * single-precision loads and stores.
> - * We restore and save the fpscr so the task gets the same result
> - * and exceptions as if the cpu had performed the load or store.
> */
>
> _GLOBAL(cvt_fd)
> - lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
> - MTFSF_L(0)
> lfs 0,0(r3)
> stfd 0,0(r4)
> - mffs 0
> - stfd 0,THREAD_FPSCR(r5) /* save new fpscr value */
> blr
>
> _GLOBAL(cvt_df)
> - lfd 0,THREAD_FPSCR(r5) /* load up fpscr value */
> - MTFSF_L(0)
> lfd 0,0(r3)
> stfs 0,0(r4)
> - mffs 0
> - stfd 0,THREAD_FPSCR(r5) /* save new fpscr value */
> blr
> diff --git a/arch/powerpc/kvm/book3s_paired_singles.c b/arch/powerpc/kvm/book
3s_paired_singles.c
> index 474f2e2..35a701f 100644
> --- a/arch/powerpc/kvm/book3s_paired_singles.c
> +++ b/arch/powerpc/kvm/book3s_paired_singles.c
> @@ -159,7 +159,7 @@
>
> static inline void kvmppc_sync_qpr(struct kvm_vcpu *vcpu, int rt)
> {
> - kvm_cvt_df(&vcpu->arch.fpr[rt], &vcpu->arch.qpr[rt], &vcpu->arch.fpscr)
;
> + kvm_cvt_df(&vcpu->arch.fpr[rt], &vcpu->arch.qpr[rt]);
> }
>
> static void kvmppc_inject_pf(struct kvm_vcpu *vcpu, ulong eaddr, bool is_sto
re)
> @@ -204,7 +204,7 @@ static int kvmppc_emulate_fpr_load(struct kvm_run *run, s
truct kvm_vcpu *vcpu,
> /* put in registers */
> switch (ls_type) {
> case FPU_LS_SINGLE:
> - kvm_cvt_fd((u32*)tmp, &vcpu->arch.fpr[rs], &vcpu->arch.fpscr);
> + kvm_cvt_fd((u32*)tmp, &vcpu->arch.fpr[rs]);
> vcpu->arch.qpr[rs] = *((u32*)tmp);
> break;
> case FPU_LS_DOUBLE:
> @@ -230,7 +230,7 @@ static int kvmppc_emulate_fpr_store(struct kvm_run *run,
struct kvm_vcpu *vcpu,
>
> switch (ls_type) {
> case FPU_LS_SINGLE:
> - kvm_cvt_df(&vcpu->arch.fpr[rs], (u32*)tmp, &vcpu->arch.fpscr);
> + kvm_cvt_df(&vcpu->arch.fpr[rs], (u32*)tmp);
> val = *((u32*)tmp);
> len = sizeof(u32);
> break;
> @@ -296,7 +296,7 @@ static int kvmppc_emulate_psq_load(struct kvm_run *run, s
truct kvm_vcpu *vcpu,
> emulated = EMULATE_DONE;
>
> /* put in registers */
> - kvm_cvt_fd(&tmp[0], &vcpu->arch.fpr[rs], &vcpu->arch.fpscr);
> + kvm_cvt_fd(&tmp[0], &vcpu->arch.fpr[rs]);
> vcpu->arch.qpr[rs] = tmp[1];
>
> dprintk(KERN_INFO "KVM: PSQ_LD [0x%x, 0x%x] at 0x%lx (%d)\n", tmp[0],
> @@ -314,7 +314,7 @@ static int kvmppc_emulate_psq_store(struct kvm_run *run,
struct kvm_vcpu *vcpu,
> u32 tmp[2];
> int len = w ? sizeof(u32) : sizeof(u64);
>
> - kvm_cvt_df(&vcpu->arch.fpr[rs], &tmp[0], &vcpu->arch.fpscr);
> + kvm_cvt_df(&vcpu->arch.fpr[rs], &tmp[0]);
> tmp[1] = vcpu->arch.qpr[rs];
>
> r = kvmppc_st(vcpu, &addr, len, tmp, true);
> @@ -516,9 +516,9 @@ static int kvmppc_ps_three_in(struct kvm_vcpu *vcpu, bool
rc,
> WARN_ON(rc);
>
> /* PS0 */
> - kvm_cvt_df(&fpr[reg_in1], &ps0_in1, &vcpu->arch.fpscr);
> - kvm_cvt_df(&fpr[reg_in2], &ps0_in2, &vcpu->arch.fpscr);
> - kvm_cvt_df(&fpr[reg_in3], &ps0_in3, &vcpu->arch.fpscr);
> + kvm_cvt_df(&fpr[reg_in1], &ps0_in1);
> + kvm_cvt_df(&fpr[reg_in2], &ps0_in2);
> + kvm_cvt_df(&fpr[reg_in3], &ps0_in3);
>
> if (scalar & SCALAR_LOW)
> ps0_in2 = qpr[reg_in2];
> @@ -529,7 +529,7 @@ static int kvmppc_ps_three_in(struct kvm_vcpu *vcpu, bool
rc,
> ps0_in1, ps0_in2, ps0_in3, ps0_out);
>
> if (!(scalar & SCALAR_NO_PS0))
> - kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
> + kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
>
> /* PS1 */
> ps1_in1 = qpr[reg_in1];
> @@ -566,12 +566,12 @@ static int kvmppc_ps_two_in(struct kvm_vcpu *vcpu, bool
rc,
> WARN_ON(rc);
>
> /* PS0 */
> - kvm_cvt_df(&fpr[reg_in1], &ps0_in1, &vcpu->arch.fpscr);
> + kvm_cvt_df(&fpr[reg_in1], &ps0_in1);
>
> if (scalar & SCALAR_LOW)
> ps0_in2 = qpr[reg_in2];
> else
> - kvm_cvt_df(&fpr[reg_in2], &ps0_in2, &vcpu->arch.fpscr);
> + kvm_cvt_df(&fpr[reg_in2], &ps0_in2);
>
> func(&vcpu->arch.fpscr, &ps0_out, &ps0_in1, &ps0_in2);
>
> @@ -579,7 +579,7 @@ static int kvmppc_ps_two_in(struct kvm_vcpu *vcpu, bool r
c,
> dprintk(KERN_INFO "PS2 ps0 -> f(0x%x, 0x%x) = 0x%x\n",
> ps0_in1, ps0_in2, ps0_out);
>
> - kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
> + kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
> }
>
> /* PS1 */
> @@ -615,13 +615,13 @@ static int kvmppc_ps_one_in(struct kvm_vcpu *vcpu, bool
rc,
> WARN_ON(rc);
>
> /* PS0 */
> - kvm_cvt_df(&fpr[reg_in], &ps0_in, &vcpu->arch.fpscr);
> + kvm_cvt_df(&fpr[reg_in], &ps0_in);
> func(&vcpu->arch.fpscr, &ps0_out, &ps0_in);
>
> dprintk(KERN_INFO "PS1 ps0 -> f(0x%x) = 0x%x\n",
> ps0_in, ps0_out);
>
> - kvm_cvt_fd(&ps0_out, &fpr[reg_out], &vcpu->arch.fpscr);
> + kvm_cvt_fd(&ps0_out, &fpr[reg_out]);
>
> /* PS1 */
> ps1_in = qpr[reg_in];
> @@ -671,7 +671,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, str
uct kvm_vcpu *vcpu)
> #ifdef DEBUG
> for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++) {
> u32 f;
> - kvm_cvt_df(&vcpu->arch.fpr[i], &f, &vcpu->arch.fpscr);
> + kvm_cvt_df(&vcpu->arch.fpr[i], &f);
> dprintk(KERN_INFO "FPR[%d] = 0x%x / 0x%llx QPR[%d] = 0x%x\n"
,
> i, f, vcpu->arch.fpr[i], i, vcpu->arch.qpr[i]);
> }
> @@ -796,8 +796,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, str
uct kvm_vcpu *vcpu)
> vcpu->arch.fpr[ax_rd] = vcpu->arch.fpr[ax_ra];
> /* vcpu->arch.qpr[ax_rd] = vcpu->arch.fpr[ax_rb]; */
> kvm_cvt_df(&vcpu->arch.fpr[ax_rb],
> - &vcpu->arch.qpr[ax_rd],
> - &vcpu->arch.fpscr);
> + &vcpu->arch.qpr[ax_rd]);
> break;
> case OP_4X_PS_MERGE01:
> WARN_ON(rcomp);
> @@ -808,19 +807,16 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, s
truct kvm_vcpu *vcpu)
> WARN_ON(rcomp);
> /* vcpu->arch.fpr[ax_rd] = vcpu->arch.qpr[ax_ra]; */
> kvm_cvt_fd(&vcpu->arch.qpr[ax_ra],
> - &vcpu->arch.fpr[ax_rd],
> - &vcpu->arch.fpscr);
> + &vcpu->arch.fpr[ax_rd]);
> /* vcpu->arch.qpr[ax_rd] = vcpu->arch.fpr[ax_rb]; */
> kvm_cvt_df(&vcpu->arch.fpr[ax_rb],
> - &vcpu->arch.qpr[ax_rd],
> - &vcpu->arch.fpscr);
> + &vcpu->arch.qpr[ax_rd]);
> break;
> case OP_4X_PS_MERGE11:
> WARN_ON(rcomp);
> /* vcpu->arch.fpr[ax_rd] = vcpu->arch.qpr[ax_ra]; */
> kvm_cvt_fd(&vcpu->arch.qpr[ax_ra],
> - &vcpu->arch.fpr[ax_rd],
> - &vcpu->arch.fpscr);
> + &vcpu->arch.fpr[ax_rd]);
> vcpu->arch.qpr[ax_rd] = vcpu->arch.qpr[ax_rb];
> break;
> }
> @@ -1255,7 +1251,7 @@ int kvmppc_emulate_paired_single(struct kvm_run *run, s
truct kvm_vcpu *vcpu)
> #ifdef DEBUG
> for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++) {
> u32 f;
> - kvm_cvt_df(&vcpu->arch.fpr[i], &f, &vcpu->arch.fpscr);
> + kvm_cvt_df(&vcpu->arch.fpr[i], &f);
> dprintk(KERN_INFO "FPR[%d] = 0x%x\n", i, f);
> }
> #endif
> diff --git a/arch/powerpc/kvm/fpu.S b/arch/powerpc/kvm/fpu.S
> index cb34bbe..bf68d59 100644
> --- a/arch/powerpc/kvm/fpu.S
> +++ b/arch/powerpc/kvm/fpu.S
> @@ -273,19 +273,11 @@ FPD_THREE_IN(fnmsub)
> FPD_THREE_IN(fnmadd)
>
> _GLOBAL(kvm_cvt_fd)
> - lfd 0,0(r5) /* load up fpscr value */
> - MTFSF_L(0)
> lfs 0,0(r3)
> stfd 0,0(r4)
> - mffs 0
> - stfd 0,0(r5) /* save new fpscr value */
> blr
>
> _GLOBAL(kvm_cvt_df)
> - lfd 0,0(r5) /* load up fpscr value */
> - MTFSF_L(0)
> lfd 0,0(r3)
> stfs 0,0(r4)
> - mffs 0
> - stfd 0,0(r5) /* save new fpscr value */
> blr
> --
> 1.7.2.2
>
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 2/2] rwsem: Move powerpc atomic-long based implementation to asm-generic
From: David Miller @ 2010-08-23 4:39 UTC (permalink / raw)
To: benh; +Cc: torvalds, paulus, linux-kernel, sparclinux, akpm, linuxppc-dev
In-Reply-To: <1282281295.22370.401.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 20 Aug 2010 15:14:55 +1000
> Other architectures who support cmpxchg and atomic_long can
> use that directly.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: David S. Miller <davem@davemloft.net>
I'll move sparc64 over to this once it hits Linus's tree.
^ permalink raw reply
* Re: [PATCH/v2] via-pmu: add compat_pmu_ioctl
From: Arnd Bergmann @ 2010-08-23 8:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2hbimmxai.fsf_-_@igel.home>
On Sunday 22 August 2010, Andreas Schwab wrote:
> The ioctls are actually compatible, but due to historical mistake the
> numbers differ between 32bit and 64bit.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Please pull 'merge' branch of 4xx tree
From: Josh Boyer @ 2010-08-23 12:12 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Dave Kleikamp
Hi Ben,
The changes from Dave for 47x (with minor fix), and a device tree update
for the 460ex SATA driver that has been merged upstream now. Please
pull.
josh
The following changes since commit
e32e78c5ee8aadef020fbaecbe6fb741ed9029fd:
powerpc: fix build with make 3.82 (2010-08-09 14:14:05 +1000)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
merge
Dave Kleikamp (4):
powerpc/47x: Make sure mcsr is cleared before enabling machine
check interrupts
powerpc/47x: Remove redundant line from cputable.c
powerpc/4xx: Index interrupt stacks by physical cpu
powerpc/47x: Add an isync before the tlbivax instruction
Rupjyoti Sarmah (1):
powerpc/4xx: Device tree update for the 460ex DWC SATA
arch/powerpc/boot/dts/canyonlands.dts | 8 ++++++++
arch/powerpc/kernel/cputable.c | 1 -
arch/powerpc/kernel/head_44x.S | 4 ++++
arch/powerpc/kernel/irq.c | 16 +++++++++-------
arch/powerpc/kernel/setup_32.c | 9 +++++----
arch/powerpc/mm/tlb_nohash_low.S | 1 +
6 files changed, 27 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/4] Some 47x patches for the powerpc-4xx tree
From: Josh Boyer @ 2010-08-23 12:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Dave Kleikamp
In-Reply-To: <1282187997.22370.287.camel@pasglop>
On Thu, Aug 19, 2010 at 01:19:57PM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2010-08-18 at 11:45 -0500, Dave Kleikamp wrote:
>> Sorry! Forgot to change the subject.
>>
>> Shaggy
>>
>> On Wed, 2010-08-18 at 11:44 -0500, Dave Kleikamp wrote:
>> > Josh,
>> > Here are some bug fixes for the powerpc-4xx tree. It'd be nice if they
>> > could make it into 2.6.46.
>
>Yeah and I'm sure they can make it into 2.6.46... if you want to wait
>that long ! In the meantime, 2.6.36 will do :-)
Added the minor #include fix and sent them your way.
josh
^ permalink raw reply
* Re: 64-bit ppc rwsem
From: Arnd Bergmann @ 2010-08-23 13:44 UTC (permalink / raw)
To: linuxppc-dev
Cc: paulus, linux-kernel, sparclinux, akpm, torvalds, David Miller
In-Reply-To: <20100818.222925.233689776.davem@davemloft.net>
On Thursday 19 August 2010, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Thu, 19 Aug 2010 15:23:23 +1000
>
> > Similar here, but using atomic_long_t instead so it works for 32-bit too
> > for me. I suppose we could make that part common indeed.
> >
> > What about asm-generic/rwsem-atomic.h or rwsem-cmpxchg.h ?
>
> Using rwsem-cmpxchg.h sounds best I guess.
The implementation looks good for asm-generic, but there is now an asymmetry
between the spinlock and the atomic_long_t based version.
Maybe we can make them both do the same thing, either of
1. create include/linux/rwsem-cmpxchg.h and add an
#elif defined(CONFIG_RWSEM_GENERIC_ATOMIC) to include/linux/rwsem.h
2. move include/linux/rwsem-spinlock.h to include/asm-generic/ and
include that from all architectures that want the spinlock based version.
Further comments:
* Alpha has an optimization for the uniprocessor case, where the atomic
instructions get turned into nonatomic additions. The spinlock based
version uses no locks on UP but disables interrupts for reasons I don't
understand (nothing running at interrupt time should try to access an rwsem).
Should the generic version do the same as Alpha?
* Is there any architecture that would still benefit from having a separate
rwsem implementation? AFAICT all the remaining ones are just variations of
the same concept of using cmpxchg (or xadd in case of x86), which is what
atomics typically end up doing anyway.
Arnd
^ permalink raw reply
* Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
From: Arnd Bergmann @ 2010-08-23 13:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linuxppc-dev, Arnd Bergmann, Andreas Schwab
In-Reply-To: <m2tymqp7op.fsf@igel.home>
On Friday 20 August 2010, Andreas Schwab wrote:
> See arch/powerpc/platforms/cell/spu_callbacks.c.
>
> * 4. They are optional and we can't rely on them being
> * linked into the kernel. Unfortunately, the cond_syscall
> * helper does not work here as it does not add the necessary
> * opd symbols:
Right. I should blame the person that wrote this comment.
If only I could remember who that was.
Arnd
^ permalink raw reply
* [PATCH] powerpc/platforms: fix config dependency problem
From: Andreas Schwab @ 2010-08-23 17:36 UTC (permalink / raw)
To: linuxppc-dev
MPIC_U3_HT_IRQS is selected both by PPC_PMAC64 and PPC_MAPLE, but depends
on PPC_MAPLE, so a PPC_PMAC64-only config gets this warning:
warning: (PPC_PMAC64 && PPC_PMAC && POWER4 || PPC_MAPLE && PPC64 && PPC_BOOK3S) selects MPIC_U3_HT_IRQS which has unmet direct dependencies (PPC_MAPLE)
Fix that by removing the dependency on PPC_MAPLE.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
arch/powerpc/platforms/Kconfig | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index d1663db..81c9208 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -106,8 +106,7 @@ config MMIO_NVRAM
config MPIC_U3_HT_IRQS
bool
- depends on PPC_MAPLE
- default y
+ default n
config MPIC_BROKEN_REGREAD
bool
--
1.7.2.2
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: How to build the kernel without any optimization?
From: Shawn Jin @ 2010-08-23 18:18 UTC (permalink / raw)
To: Nicholas Mc Guire; +Cc: ppcdev
In-Reply-To: <20100821073116.GA1597@opentech.at>
>> I already added the following to arch/powerpc/Makefile.
>>
>> # Prevent GDB from jumping around in the code when trying to single step
>> ifeq ($(CONFIG_DEBUG_KERNEL),y)
>> KBUILD_CFLAGS =A0 =A0 =A0 =A0 =A0 +=3D -fno-schedule-insns -fno-schedule=
-insns2
>> endif
>>
>
> much of the kernel can not be build without optimization - what you
> can do though is slectively try to disable optimization for specific
> files by putting
>
> =A0CFLAGS_REMOVE_objfilenam.o =3D -SOME_OPT
>
> in the Makefile. I think that is safer than what you did above as this wo=
uld
> always depend on the order of options that ultimately get passed to gcc.
With this CLAGS_REMOVE, building the objfilenam.o uses only the
-SOME_OPT instead of the default CFLAGS defined? The most I found for
-SOME_OPT is the -pg.
Thanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: john stultz @ 2010-08-23 20:08 UTC (permalink / raw)
To: Richard Cochran
Cc: Rodolfo Giometti, Arnd Bergmann, netdev, devicetree-discuss,
linux-kernel, linuxppc-dev, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <20100819055518.GA4084@riccoc20.at.omicron.at>
Sorry for the slow response here, I got busy with other work at the end
of last week.
On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
> On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
> > On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> > > The timer/alarm stuff is "ancillary" and is not at all necessary. It
> > > is just a "nice to have." I will happily remove it, if it is too
> > > troubling for people.
> >
> > If there's a compelling argument for it, I'm interested to hear. But
> > again, it seems like just
> > yet-another-way-to-get-alarm/timer-functionality, so before we add an
> > extra API (or widen an existing API) I'd like to understand the need.
>
> We don't really need it, IMHO.
>
> But if we offer clockid_t CLOCK_PTP, then we get timer_settime()
> without any extra effort.
Sure. There are some clear parallels and the API seems to match, but
what I'm asking is: does it make sense from an overall API view that
application developers have to understand?
> > > I was emulating the posix interface. Instead I should use it directly.
> >
> > I'm definitely interested to see what you come up with here. I'm still
> > hesitant with adding a PTP clock_id, but extending the posix-clocks
> > interface in this way isn't unprecedented (see: CLOCK_SGI_CYCLE) I just
> > would like to make sure we don't end up with a clock_id namespace
> > littered with oddball clocks that were not well abstracted (see:
> > CLOCK_SGI_CYCLE :).
> >
> > For instance: imagine if instead of keeping the clocksource abstraction
> > internal to the timekeeping core, we exposed each clocksource to
> > userland via a clock_id. Every arch would have different ids, and each
> > arch might have multiple ids. Programming against that would be a huge
> > pain.
>
> The clockid_t CLOCK_PTP will be arch-neutral.
Sure, but are they conceptually neutral? There are other clock
synchronization algorithms out there. Will they need their own
similar-but-different clock_ids?
Look at the other clock ids and what the represent:
CLOCK_REALTIME : Wall time (possibly freq/offset corrected)
CLOCK_MONOTONIC: Monotonic time (possibly freq corrected).
CLOCK_PROCESS_CPUTIME_ID: Process cpu time.
CLOCK_THREAD_CPUTIME_ID: Thread cpu time.
CLOCK_MONOTONIC_RAW: Non freq corrected monotonic time.
CLOCK_REALTIME_COARSE: Tick granular wall time (filesystem timestamp)
CLOCK_MONOTONIC_COARSE: Tick granular monotonic time.
CLOCK_PTP that you're proposing doesn't seem to be at the same level of
abstraction. I'm not saying that this isn't the right place for it, but
can we take a step back from PTP and consider what your exposing in more
generic terms. In other words, could someone use the same
packet-timestamping hardware to implement a different non-PTP time
synchronization algorithm?
Further, if we're using PTP to synchoronize the system time, then there
shouldn't be any measurable difference between CLOCK_PTP and
CLOCK_REALTIME, no?
> > So in thinking about this, try to focus on what the new clock_id
> > provides that the other existing clockids do not? Are they at comparable
> > levels of abstraction? 15 years from now, are folks likely to still be
> > using it? Will it be maintainable? etc...
>
> Arnd convinced me that clockid_t=CLOCK_PTP is a good fit. My plan
> would be to introduce just one additional syscall:
>
> SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid,
> int, ppb, struct timespec __user *, ts)
>
> ppb - desired frequency adjustment in parts per billion
> ts - desired time step (or jump) in <sec,nsec> to correct
> a measured offset
>
> Arguably, this syscall might be useful for other clocks, too.
So yea, obviously the syscall should not be CLOCK_PTP specific, so we
would want it to be usable against CLOCK_REALTIME.
That said, the clock_adjtime your proposing does not seem to be
sufficient for usage by NTPd. So this suggests that it is not generic
enough.
> I think the ancillary features from PTP hardware clocks should be made
> available throught the sysfs. A syscall for these would end up very
> ugly, looking like an ioctl. Also, it is hard to see how these
> features relate to the more general idea of the clockid.
This may be a good approach, but be aware that adding stuff to sysfs
requires similar scrutiny as adding a syscall.
> In contrast, sysfs attributes will fit the need nicely:
>
> 1. enable or disable pps
> 2. enable or disable external timestamps
> 3. read out external timestamp
> 4. configure period for periodic output
Things to consider here:
Do having these options really make sense?
Why would we want pps disabled? And if that does make sense, would it
be better to do so via the existing pps interface instead of adding a
new ptp specific one?
Same for the timestamps and periodic output (ie: and how do they differ
from reading or setting a timer on CLOCK_PTP?)
> > > 1. Use Case: SW timestamping
> > The way I tend to see it: PTP is just one of the many ways to sync
> > system time.
>
> > > 2. Use Case: HW timestamping for industrial control
> > These specialized applications are part of what concerns me the most.
>
> PTP was not invented to just to get a computer's system time in the
> ball park. For that, NTP is good enough. Rather, some people want to
> use their computers for tasks that require close synchronization, like
> industrial control, audio/video streaming, and many others.
>
> Are you saying that we should not support such applications?
Of course not! Just because I'm reviewing and critiquing your work does
not mean our goals are incompatible.
> > For example, I can see some parallels between things like audio
> > processing, where you have a buffer consumed by the card at a certain
> > rate. Now, the card has its own crystal it uses to time its consumption,
> > so it has its own time domain, and could drift from system time. Thus
> > you want to trigger buffer-refill interrupts off of the audio card's
> > clock, not the system time which might run the risk of being late.
> >
> > But again, we don't expose the audio hardware clock to userland in the
> > same way we expose system time.
>
> This is a good example of the poverty (in regards to time
> synchronization) of our current systems.
>
> Lets say I want to build a surround sound audio system, using a set of
> distributed computers, each host connected to one speaker. How I can
> be sure that the samples in one channel (ie one host) pass through the
> DA converter at exactly the same time?
They won't be exactly the same, but to minimize any noticeable
difference we'd need each speaker/client-system that have their system
time closely synced. Then the server-system would need to send the
channel stream and frame times to each client. The clients would then
feed the audio frames to the audio card at the designated times.
This is a little high level and generic and of course, the devil's in
the details:
1) How is the system time synchronized across systems?
2) How is the error between the system time freq and the audio cards
rate addressed?
These are things that need to be addressed, but the high-level design is
what the applications should target, because it doesn't limit them to
the specifics of the details.
By suggesting the application be designed to use CLOCK_PTP, it limits
itself to systems with CLOCK_PTP hardware, and should the application be
ported to a different distributed system that's using RADclocks or some
other synchronization method, it won't function.
What the kernel needs to provide are ways to address #1 and #2 above,
but what the kernel needs to expose to userland should be minimal and
generic.
> > Again, my knowledge in the networking stack is pretty limited. But it
> > would seem that having an interface that does something to the effect of
> > "adjust the timestamp clock on the hardware that generated it from this
> > packet by Xppb" would feel like the right level of abstraction. Its
> > closely related to SO_TIMESTAMP, option right? Would something like
> > using the setsockopt/getsockopt interface with
> > SO_TIMESTAMP_ADJUST/OFFSET/SET/etc be reasonable?
>
> The clock and its adjustment have nothing to do with a network
> socket. The current PTP hacks floating around all add private ioctls
> to the MAC driver. That is the *wrong* way to do it.
Could you clarify on *why* that is the wrong approach?
Maybe this is where some of the confusion is coming from? The subtleties
of the more generic PTP algorithm and how the existence of PTP hardware
clocks change things are not clear to me. My understanding of ptp and
the networking details around it is limited, so your expertise is
appreciated. Might you consider covering some of this via a
Documentation/ptp/overview.txt file in a future version of your patch?
Here's a summary of what I understand:
So from:
http://en.wikipedia.org/wiki/Precision_Time_Protocol#Synchronization
We see the message exchange of Sync/Delay_Req/Delay_Resp, and the
calculation of the local offset from the server (and then a frequency
adjustment over time as offsets values are accumulated).
Without the hardware clock, this all of these messages and their
corresponding timestamps are likely created by PTPd, using clock_gettime
and then adjtimex() to correct for the calculated offset or freq
adjustment. No extra interfaces are necessary, and PTPd is syncing the
system time as accurately as it can. This is how the existing ptpd
projects on the web seem to function.
Now, with PTP hardware on the system, my understanding of what you're
trying to enable with your patches is that the PTP hardware does the
timestamping on both incoming and outgoing messages. PTPd then reads the
pre-timestamped messages, calculates the offset and freq correction, and
then feeds that back into the PTP hardware via your interface. No time
correction is done at all by PTPd.
Instead, you're proposing then to have a PPS signal emitted by the PTP
hardware (via the timer interface on that hardware, if I'm understanding
correctly). This PPS signal would then be picked up by something like
NTPd which would use it to correct the system time.
Questions:
1) When the PTP hardware is doing the timestamping, what API/interface
does PTPd use to get and send the Sync/Delay_req/Delay_Resp messages?
SO_TIMESTAMPed packets from a network device seems the obvious answer,
but your comments above about with regards to my SO_TIMESTAMP_ADJ idea
suggest there's something more subtle here.
2) You've mentioned multiple PTP hardware clocks are possible, but maybe
not practically useful. How does PTPd enumerate the existing clocks, and
know which devices to listen to for Sync/Delay_Resp messages?
The issue I'm trying to address here is the interface inconsistency
between the message timestamping interface (ie: likely from a packet,
possibly multiple sources) and the proposed CLOCK_PTP interface (with
only a single clock being exposed at a time, and that being controlled
by a sysfs interface).
My concerns:
1) Again, I'm not totally comfortable exposing the PTP hardware via the
posix-clocks/timers interface. I'm not dead set against it, but it just
doesn't seem right as a top-level abstraction.
I'm curious if its possible to do the PTP hardware offset/adjustment
calculation in a module internally to the kernel? That would allow the
PPS interface to still be used to sync the system time, and not expose
additional interfaces.
2) If this is a top-level interface, I'd prefer the inconsistency
between how the timestamped messages are received and the proposed
posix_clocks/timer interface be clarified.
For example: does the networking stack need to have the source clock_id
to use for SO_TIMESTAMPing be specified?
3) I still prefer the idea of keeping the PTP hardware adjustment API
close to the existing API to enable the SO_TIMESTAMPing. I realize you
disagree, but would like to understand better why.
thanks again,
-john
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: john stultz @ 2010-08-23 20:21 UTC (permalink / raw)
To: Richard Cochran
Cc: Rodolfo Giometti, Arnd Bergmann, netdev, devicetree-discuss,
linux-kernel, linuxppc-dev, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <20100819153847.GA10695@riccoc20.at.omicron.at>
On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > My point was that a syscall is better than an ioctl based interface here,
> > which I definitely still think. Given that John knows much more about
> > clocks than I do, we still need to get agreement on the question that
> > he raised, which is whether we actually need to expose this clock to the
> > user or not.
> >
> > If we can find a way to sync system time accurate enough with PTP and
> > PPS, user applications may not need to see two separate clocks at all.
>
> At the very least, one user application (the PTPd) needs to see the
> PTP clock.
>
> > > SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid,
> > > int, ppb, struct timespec __user *, ts)
> > >
> > > ppb - desired frequency adjustment in parts per billion
> > > ts - desired time step (or jump) in <sec,nsec> to correct
> > > a measured offset
> > >
> > > Arguably, this syscall might be useful for other clocks, too.
> >
> > This is a mix of adjtime and adjtimex with the addition of
> > the clkid parameter, right?
>
> Sort of, but not really. ADJTIME(3) takes an offset and slowly
> corrects the clock using a servo in the kernel, over hours.
>
> For this function, the offset passed in the 'ts' parameter will be
> immediately corrected, by jumping to the new time. This reflects the
> way that PTP works. After the first few samples, the PTPd has an
> estimate of the offset to the master and the rate difference. The PTPd
> can proceed in one of two ways.
>
> 1. If resetting the clock is not desired, then the clock is set to the
> maximum adjustment (in the right direction) until the clock time is
> close to the master's time.
>
> 2. The estimated offset is added to the current time, resulting in a
> jump in time.
>
> We need clock_adjtime(id, 0, ts) for the second case.
>
> > Have you considered passing a struct timex instead of ppb and ts?
>
> Yes, but the timex is not suitable, IMHO.
Could you expand on this?
Could we not add a adjustment mode ADJ_SETOFFSET or something that would
provide the instantaneous offset correction?
> > Is using ppb instead of the timex ppm required to get the accuracy
> > you want?
>
> That is one very good reason.
>
> Another is this: can you explain what the 20+ fields mean?
>
> Consider the field, freq. The comment says "frequency offset (scaled
> ppm)." To what is it scaled? The only way I know of to find out is to
> read the NTP code (which is fairly complex) and see what the unit
> really is meant to be. Ditto for the other fields.
>
> The timex structure reveals, AFAICT, the inner workings of the kernel
> clock servo. For PTP, we don't need or want the kernel servo. The PTPd
> has its own clock servo in user space.
You're right that the timex is a little crufty. But its legacy that we
will support indefinitely. So following the established interface helps
maintainability.
So if the clock_adjtime interface is needed, it would seem best for it
to be generic enough to support not only PTP, but also the NTP kernel
PLL.
In effect, this would make clock_adjtime(or clock_adjtimex) identical to
adjtimex, but only applicable to different CLOCK_ids. Additionally, it
would simplify the code for the CLOCK_REALTIME case as you could just
call directly into do_adjtimex().
Of course, extending adjtimex for ADJ_SETOFFSET would be needed first,
but that seems like a reasonable expansion of the interface that could
be used by more then just PTP.
thanks
-john
^ permalink raw reply
* Re: 64-bit ppc rwsem
From: Benjamin Herrenschmidt @ 2010-08-23 22:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, paulus, linux-kernel, sparclinux, akpm, torvalds,
David Miller
In-Reply-To: <201008231544.16422.arnd@arndb.de>
On Mon, 2010-08-23 at 15:44 +0200, Arnd Bergmann wrote:
>
> * Alpha has an optimization for the uniprocessor case, where the atomic
> instructions get turned into nonatomic additions. The spinlock based
> version uses no locks on UP but disables interrupts for reasons I don't
> understand (nothing running at interrupt time should try to access an rwsem).
> Should the generic version do the same as Alpha?
I've seen drivers in the past do trylocks at interrupt time ... tho I
agree it sucks.
> * Is there any architecture that would still benefit from having a separate
> rwsem implementation? AFAICT all the remaining ones are just variations of
> the same concept of using cmpxchg (or xadd in case of x86), which is what
> atomics typically end up doing anyway.
It depends how sensitive rwsems are.
The "generic" variant based on atomic's and cmpxchg on powerpc is
sub-optimal in the sense that it has stronger memory barriers that would
be necessary (atomic_inc_return for example has both acquire and
release).
But that vs. one more pile of inline asm, we decided it wasn't hot
enough a spot for us to care back then.
Cheers,
Ben.
^ permalink raw reply
* Re: 64-bit ppc rwsem
From: David Miller @ 2010-08-23 22:18 UTC (permalink / raw)
To: benh; +Cc: arnd, linuxppc-dev, paulus, linux-kernel, sparclinux, akpm,
torvalds
In-Reply-To: <1282600885.22370.453.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 24 Aug 2010 08:01:25 +1000
> On Mon, 2010-08-23 at 15:44 +0200, Arnd Bergmann wrote:
>>
>> * Alpha has an optimization for the uniprocessor case, where the atomic
>> instructions get turned into nonatomic additions. The spinlock based
>> version uses no locks on UP but disables interrupts for reasons I don't
>> understand (nothing running at interrupt time should try to access an rwsem).
>> Should the generic version do the same as Alpha?
>
> I've seen drivers in the past do trylocks at interrupt time ... tho I
> agree it sucks.
Recently there was a thread where this was declared absolutely illegal.
Maybe it was allowed, or sort-of worked before, and that's why it's
accounted for with IRQ disables in some implementations. I don't
know.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox