RE: [PATCH V3 1/2] powerpc/85xx: Add QE common init functions

2013-09-10 Thread Xie Xiaobo-R63061
Hi,

Thank you very much. I will submit updated patch soon.

Best Regards
Xie Xiaobo
-Original Message-
From: Wood Scott-B07421 
Sent: Friday, September 06, 2013 11:25 PM
To: Xie Xiaobo-R63061
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org
Subject: Re: [PATCH V3 1/2] powerpc/85xx: Add QE common init functions

On Fri, 2013-09-06 at 04:52 -0500, Xie Xiaobo-R63061 wrote:
> Hi Scott,
> 
> I already remove these code from the P1025TWR platform file(see the 2/2 
> patch). Do you means I also need to remove these codes from the others 
> platforms and use the common call instead? 
> Thank you.

Yes.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: big latency while under HV

2013-09-10 Thread Diana Craciun

Hi,

Just to be on the same page, are you using the Freescale Embedded 
Hypervisor provided with the Freescale SDK or other embedded hypervisor?


Anyway, the question is not much related with the Linux kernel, so you 
should probably redirect your question to Freescale support. You can 
reach Freescale support at supp...@freescale.com.


Diana

On 09/09/2013 06:19 PM, Ivan Krivonos wrote:

Hi,

i`m working on the embedded hypervisor targeting QorIQ platforms (p3041/p4080).
I have working prototype starting custom RTOS on just single core in the guest
space. What I see is the big latency (up to 3 times more) in RTOS running atop
of HV comparing to RTOS running bare-metal. I`m using lmbench utility.
It shows

nteger mul: 3.48 nanoseconds
integer div: 30.44 nanoseconds
integer mod: 13.92 nanoseconds
int64 bit: 1.75 nanoseconds
int64 add: 1.42 nanoseconds
int64 mul: 6.95 nanoseconds
HV:hvpriv_count 6
int64 div: 447.56 nanoseconds
int64 mod: 385.42 nanoseconds
float add: 7.12 nanoseconds
float mul: 6.95 nanoseconds
float div: 33.05 nanoseconds
double add: 7.11 nanoseconds
double mul: 8.70 nanoseconds
double div: 57.36 nanoseconds
float bogomflops: 46.98 nanoseconds
double bogomflops: 73.09 nanoseconds

The bare-metal results are 3x better. Does anybody have any ideas on what
may be the source of such latency ? I forward all the exceptions to
the guest w/o
affecting HV. Only hvpriv is processed, it takes not more than 2 bus cycles.
Sorry for poor english
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support

2013-09-10 Thread Xie Xiaobo-R63061
Hi Scott,

I discuss it with Liu Shengzhou again. I tried interrupts = <1 1 0 0> instead 
of interrupts = <1 1> on P1025TWR, and it's OK. So I will add 2 cells for the 
interrupts property. Thank you.

Best Regards
Xie Xiaobo
-Original Message-
From: Wood Scott-B07421 
Sent: Friday, September 06, 2013 11:26 PM
To: Xie Xiaobo-R63061
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; 
ga...@kernel.crashing.org; Johnston Michael-R49610
Subject: Re: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support

On Fri, 2013-09-06 at 05:01 -0500, Xie Xiaobo-R63061 wrote:
> Hi Scott,
> 
> Thanks for your reminding and advice.
> 
> I discuss this with Liu Shengzhou(the first person that remind me 
> #interrupt-cells is 4), he advised removing the interrupts property 
> from the phy node, because the mdio used the poll way preferentially.

I don't follow... if the PHYs have interrupts, why would we prefer to poll?

In any case, the device tree describes the hardware, not how you'd prefer to 
use it.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 4/6] KVM: PPC: Store FP/VSX/VMX state in thread_fp/vr_state structures

2013-09-10 Thread Paul Mackerras
This uses struct thread_fp_state and struct thread_vr_state to store
the floating-point, VMX/Altivec and VSX state, rather than flat arrays.
This makes transferring the state to/from the thread_struct simpler
and allows us to unify the get/set_one_reg implementations for the
VSX registers.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/include/asm/kvm_host.h  |  12 +--
 arch/powerpc/kernel/asm-offsets.c|  11 +-
 arch/powerpc/kvm/book3s.c|  38 +--
 arch/powerpc/kvm/book3s_hv.c |  42 
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  |   4 +-
 arch/powerpc/kvm/book3s_paired_singles.c | 169 +++
 arch/powerpc/kvm/book3s_pr.c |  63 +---
 arch/powerpc/kvm/booke.c |   8 +-
 arch/powerpc/kvm/powerpc.c   |   4 +-
 9 files changed, 131 insertions(+), 220 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 3328353..e2a2a81 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -406,8 +406,7 @@ struct kvm_vcpu_arch {
 
ulong gpr[32];
 
-   u64 fpr[32];
-   u64 fpscr;
+   struct thread_fp_state fp;
 
 #ifdef CONFIG_SPE
ulong evr[32];
@@ -416,12 +415,7 @@ struct kvm_vcpu_arch {
u64 acc;
 #endif
 #ifdef CONFIG_ALTIVEC
-   vector128 vr[32];
-   vector128 vscr;
-#endif
-
-#ifdef CONFIG_VSX
-   u64 vsr[64];
+   struct thread_vr_state vr;
 #endif
 
 #ifdef CONFIG_KVM_BOOKE_HV
@@ -608,6 +602,8 @@ struct kvm_vcpu_arch {
 #endif
 };
 
+#define VCPU_FPR(vcpu, i)  (vcpu)->arch.fp.fpr[i][TS_FPROFFSET]
+
 /* Values for vcpu->arch.state */
 #define KVMPPC_VCPU_NOTREADY   0
 #define KVMPPC_VCPU_RUNNABLE   1
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 9049197..4c1609f 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -424,14 +424,11 @@ int main(void)
DEFINE(VCPU_GUEST_PID, offsetof(struct kvm_vcpu, arch.pid));
DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
DEFINE(VCPU_VRSAVE, offsetof(struct kvm_vcpu, arch.vrsave));
-   DEFINE(VCPU_FPRS, offsetof(struct kvm_vcpu, arch.fpr));
-   DEFINE(VCPU_FPSCR, offsetof(struct kvm_vcpu, arch.fpscr));
+   DEFINE(VCPU_FPRS, offsetof(struct kvm_vcpu, arch.fp.fpr));
+   DEFINE(VCPU_FPSCR, offsetof(struct kvm_vcpu, arch.fp.fpscr));
 #ifdef CONFIG_ALTIVEC
-   DEFINE(VCPU_VRS, offsetof(struct kvm_vcpu, arch.vr));
-   DEFINE(VCPU_VSCR, offsetof(struct kvm_vcpu, arch.vscr));
-#endif
-#ifdef CONFIG_VSX
-   DEFINE(VCPU_VSRS, offsetof(struct kvm_vcpu, arch.vsr));
+   DEFINE(VCPU_VRS, offsetof(struct kvm_vcpu, arch.vr.vr));
+   DEFINE(VCPU_VSCR, offsetof(struct kvm_vcpu, arch.vr.vscr));
 #endif
DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, arch.xer));
DEFINE(VCPU_CTR, offsetof(struct kvm_vcpu, arch.ctr));
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 700df6f..6ca11a3 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -508,10 +508,10 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, 
struct kvm_one_reg *reg)
break;
case KVM_REG_PPC_FPR0 ... KVM_REG_PPC_FPR31:
i = reg->id - KVM_REG_PPC_FPR0;
-   val = get_reg_val(reg->id, vcpu->arch.fpr[i]);
+   val = get_reg_val(reg->id, VCPU_FPR(vcpu, i));
break;
case KVM_REG_PPC_FPSCR:
-   val = get_reg_val(reg->id, vcpu->arch.fpscr);
+   val = get_reg_val(reg->id, vcpu->arch.fp.fpscr);
break;
 #ifdef CONFIG_ALTIVEC
case KVM_REG_PPC_VR0 ... KVM_REG_PPC_VR31:
@@ -519,16 +519,27 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, 
struct kvm_one_reg *reg)
r = -ENXIO;
break;
}
-   val.vval = vcpu->arch.vr[reg->id - KVM_REG_PPC_VR0];
+   val.vval = vcpu->arch.vr.vr[reg->id - KVM_REG_PPC_VR0];
break;
case KVM_REG_PPC_VSCR:
if (!cpu_has_feature(CPU_FTR_ALTIVEC)) {
r = -ENXIO;
break;
}
-   val = get_reg_val(reg->id, vcpu->arch.vscr.u[3]);
+   val = get_reg_val(reg->id, vcpu->arch.vr.vscr.u[3]);
break;
 #endif /* CONFIG_ALTIVEC */
+#ifdef CONFIG_VSX
+   case KVM_REG_PPC_VSR0 ... KVM_REG_PPC_VSR31:
+   if (cpu_has_feature(CPU_FTR_VSX)) {
+   long int i = reg->id - KVM_REG_PPC_VSR0;
+   val.vsxval[0] = vcpu->arch.fp.fpr[i][0];
+ 

[PATCH 0/6] powerpc: Unify FP/VMX/VSX state handling between KVM and main kernel

2013-09-10 Thread Paul Mackerras
Currently on powerpc we store and access floating-point and vector
state in various ad-hoc arrays in places such as the thread_struct and
the kvm_vcpu_arch struct.  This leads to code duplication for the code
that transfers this state between CPU registers and memory, and leads
to double-copying in the case of PR KVM, where we copy state from the
kvm_vcpu_arch struct to the thread_struct, and then load it up into
CPU registers from the thread_struct.

To simplify all this, this patch series defines a struct for storing
FP/VSX state including FPSCR, and a struct for storing vector state
(VMX/Altivec) including VSCR.  These structs then get used in both the
thread_struct and the kvm_vcpu_arch struct, enabling us to use common
functions for loading and storing the CPU register state, and avoid
double copying.  The benefit can be seen in that the series deletes
330 more lines than it adds.

This series will also help greatly in implementing the support in KVM
for saving and restoring transactional register state on POWER8.

This series is against the "queue" branch of the kvm.git tree.  I used
that as a base because it has pulled in Linus' tree recently and thus
has the most recent powerpc code from Ben H's next branch as well as
the latest KVM code.

Paul.

 arch/powerpc/include/asm/kvm_book3s.h|   3 -
 arch/powerpc/include/asm/kvm_host.h  |  12 +--
 arch/powerpc/include/asm/ppc_asm.h   |  95 ++---
 arch/powerpc/include/asm/processor.h |  47 +
 arch/powerpc/include/asm/sfp-machine.h   |   2 +-
 arch/powerpc/include/asm/switch_to.h |   2 -
 arch/powerpc/kernel/align.c  |   6 +-
 arch/powerpc/kernel/asm-offsets.c|  36 +++
 arch/powerpc/kernel/fpu.S|  84 +++
 arch/powerpc/kernel/ppc_ksyms.c  |   4 +
 arch/powerpc/kernel/process.c|  15 ++-
 arch/powerpc/kernel/ptrace.c |  49 -
 arch/powerpc/kernel/ptrace32.c   |  11 +-
 arch/powerpc/kernel/signal_32.c  |  72 ++---
 arch/powerpc/kernel/signal_64.c  |  29 +++---
 arch/powerpc/kernel/tm.S |  41 
 arch/powerpc/kernel/traps.c  |  10 +-
 arch/powerpc/kernel/vecemu.c |   6 +-
 arch/powerpc/kernel/vector.S |  77 +++---
 arch/powerpc/kvm/book3s.c|  38 +--
 arch/powerpc/kvm/book3s_exports.c|   4 -
 arch/powerpc/kvm/book3s_hv.c |  42 
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  |  82 ---
 arch/powerpc/kvm/book3s_paired_singles.c | 169 +++
 arch/powerpc/kvm/book3s_pr.c | 145 +-
 arch/powerpc/kvm/book3s_rmhandlers.S |  47 -
 arch/powerpc/kvm/booke.c |  21 
 arch/powerpc/kvm/booke.h |   5 +-
 arch/powerpc/kvm/powerpc.c   |   4 +-
 29 files changed, 414 insertions(+), 744 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/6] powerpc: Provide for giveup_fpu/altivec to save state in alternate location

2013-09-10 Thread Paul Mackerras
This provides a facility which is intended for use by KVM, where the
contents of the FP/VSX and VMX (Altivec) registers can be saved away
to somewhere other than the thread_struct when kernel code wants to
use floating point or VMX instructions.  This is done by providing a
pointer in the thread_struct to indicate where the state should be
saved to.  The giveup_fpu() and giveup_altivec() functions test these
pointers and save state to the indicated location if they are non-NULL.
Note that the MSR_FP/VEC bits in task->thread.regs->msr are still used
to indicate whether the CPU register state is live, even when an
alternate save location is being used.

This also provides load_fp_state() and load_vr_state() functions, which
load up FP/VSX and VMX state from memory into the CPU registers, and
corresponding store_fp_state() and store_vr_state() functions, which
store FP/VSX and VMX state into memory from the CPU registers.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/include/asm/processor.h |  7 +++
 arch/powerpc/kernel/asm-offsets.c|  2 ++
 arch/powerpc/kernel/fpu.S| 25 -
 arch/powerpc/kernel/ppc_ksyms.c  |  4 
 arch/powerpc/kernel/process.c|  7 +++
 arch/powerpc/kernel/vector.S | 29 +++--
 6 files changed, 71 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index 92f709d..8bc9d66 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -212,6 +212,7 @@ struct thread_struct {
 #endif
 #endif
struct thread_fp_state  fp_state;
+   struct thread_fp_state  *fp_save_area;
int fpexc_mode; /* floating-point exception mode */
unsigned intalign_ctl;  /* alignment handling control */
 #ifdef CONFIG_PPC64
@@ -230,6 +231,7 @@ struct thread_struct {
unsigned long   trap_nr;/* last trap # on this thread */
 #ifdef CONFIG_ALTIVEC
struct thread_vr_state vr_state;
+   struct thread_vr_state *vr_save_area;
unsigned long   vrsave;
int used_vr;/* set if process has used altivec */
 #endif /* CONFIG_ALTIVEC */
@@ -359,6 +361,11 @@ extern int set_endian(struct task_struct *tsk, unsigned 
int val);
 extern int get_unalign_ctl(struct task_struct *tsk, unsigned long adr);
 extern int set_unalign_ctl(struct task_struct *tsk, unsigned int val);
 
+extern void load_fp_state(struct thread_fp_state *fp);
+extern void store_fp_state(struct thread_fp_state *fp);
+extern void load_vr_state(struct thread_vr_state *vr);
+extern void store_vr_state(struct thread_vr_state *vr);
+
 static inline unsigned int __unpack_fe01(unsigned long msr_bits)
 {
return ((msr_bits & MSR_FE0) >> 10) | ((msr_bits & MSR_FE1) >> 8);
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 38ebe36..9049197 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -90,9 +90,11 @@ int main(void)
 #endif
DEFINE(THREAD_FPEXC_MODE, offsetof(struct thread_struct, fpexc_mode));
DEFINE(THREAD_FPSTATE, offsetof(struct thread_struct, fp_state));
+   DEFINE(THREAD_FPSAVEAREA, offsetof(struct thread_struct, fp_save_area));
DEFINE(FPSTATE_FPSCR, offsetof(struct thread_fp_state, fpscr));
 #ifdef CONFIG_ALTIVEC
DEFINE(THREAD_VRSTATE, offsetof(struct thread_struct, vr_state));
+   DEFINE(THREAD_VRSAVEAREA, offsetof(struct thread_struct, vr_save_area));
DEFINE(THREAD_VRSAVE, offsetof(struct thread_struct, vrsave));
DEFINE(THREAD_USED_VR, offsetof(struct thread_struct, used_vr));
DEFINE(VRSTATE_VSCR, offsetof(struct thread_vr_state, vscr));
diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index 34b96e6..4dca05e 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -81,6 +81,26 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
 
 /*
+ * Load state from memory into FP registers including FPSCR.
+ * Assumes the caller has enabled FP in the MSR.
+ */
+_GLOBAL(load_fp_state)
+   lfd fr0,FPSTATE_FPSCR(r3)
+   MTFSF_L(fr0)
+   REST_32FPVSRS(0, R4, R3)
+   blr
+
+/*
+ * Store FP state into memory, including FPSCR
+ * Assumes the caller has enabled FP in the MSR.
+ */
+_GLOBAL(store_fp_state)
+   SAVE_32FPVSRS(0, R4, R3)
+   mffsfr0
+   stfdfr0,FPSTATE_FPSCR(r3)
+   blr
+
+/*
  * This task wants to use the FPU now.
  * On UP, disable FP for the task which had the FPU previously,
  * and save its floating-point registers in its thread_struct.
@@ -172,9 +192,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
PPC_LCMPI   0,r3,0
beqlr-  /* if no previous owner, done */
addir3,r3,THREAD/* want THREAD of task */
+   PPC_LL  r6,THREAD_FPSAVEAREA(r3)
PPC_LL  r5,PT_

[PATCH 1/6] powerpc: Put FP/VSX and VR state into structures

2013-09-10 Thread Paul Mackerras
This creates new 'thread_fp_state' and 'thread_vr_state' structures
to store FP/VSX state (including FPSCR) and Altivec/VSX state
(including VSCR), and uses them in the thread_struct.  In the
thread_fp_state, the FPRs and VSRs are represented as u64 rather
than double, since we rarely perform floating-point computations
on the values, and this will enable the structures to be used
in KVM code as well.  Similarly FPSCR is now a u64 rather than
a structure of two 32-bit values.

This takes the offsets out of the macros such as SAVE_32FPRS,
REST_32FPRS, etc.  This enables the same macros to be used for normal
and transactional state, enabling us to delete the transactional
versions of the macros.   This also removes the unused do_load_up_fpu
and do_load_up_altivec, which were in fact buggy since they didn't
create large enough stack frames to account for the fact that
load_up_fpu and load_up_altivec are not designed to be called from C
and assume that their caller's stack frame is an interrupt frame.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/include/asm/ppc_asm.h | 95 +++---
 arch/powerpc/include/asm/processor.h   | 40 +++---
 arch/powerpc/include/asm/sfp-machine.h |  2 +-
 arch/powerpc/kernel/align.c|  6 +--
 arch/powerpc/kernel/asm-offsets.c  | 25 +++--
 arch/powerpc/kernel/fpu.S  | 59 +
 arch/powerpc/kernel/process.c  |  8 ++-
 arch/powerpc/kernel/ptrace.c   | 49 +-
 arch/powerpc/kernel/ptrace32.c | 11 ++--
 arch/powerpc/kernel/signal_32.c| 72 +-
 arch/powerpc/kernel/signal_64.c| 29 ++-
 arch/powerpc/kernel/tm.S   | 41 ---
 arch/powerpc/kernel/traps.c| 10 ++--
 arch/powerpc/kernel/vecemu.c   |  6 +--
 arch/powerpc/kernel/vector.S   | 50 ++
 arch/powerpc/kvm/book3s_pr.c   | 36 ++---
 arch/powerpc/kvm/booke.c   | 19 ---
 17 files changed, 200 insertions(+), 358 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index 5995457..140f670 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -98,123 +98,40 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
 #define REST_8GPRS(n, base)REST_4GPRS(n, base); REST_4GPRS(n+4, base)
 #define REST_10GPRS(n, base)   REST_8GPRS(n, base); REST_2GPRS(n+8, base)
 
-#define SAVE_FPR(n, base)  stfdn,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define SAVE_FPR(n, base)  stfdn,8*TS_FPRWIDTH*(n)(base)
 #define SAVE_2FPRS(n, base)SAVE_FPR(n, base); SAVE_FPR(n+1, base)
 #define SAVE_4FPRS(n, base)SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
 #define SAVE_8FPRS(n, base)SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
 #define SAVE_16FPRS(n, base)   SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
 #define SAVE_32FPRS(n, base)   SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
-#define REST_FPR(n, base)  lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base)  lfd n,8*TS_FPRWIDTH*(n)(base)
 #define REST_2FPRS(n, base)REST_FPR(n, base); REST_FPR(n+1, base)
 #define REST_4FPRS(n, base)REST_2FPRS(n, base); REST_2FPRS(n+2, base)
 #define REST_8FPRS(n, base)REST_4FPRS(n, base); REST_4FPRS(n+4, base)
 #define REST_16FPRS(n, base)   REST_8FPRS(n, base); REST_8FPRS(n+8, base)
 #define REST_32FPRS(n, base)   REST_16FPRS(n, base); REST_16FPRS(n+16, base)
 
-#define SAVE_VR(n,b,base)  li b,THREAD_VR0+(16*(n));  stvx n,base,b
+#define SAVE_VR(n,b,base)  li b,16*(n);  stvx n,base,b
 #define SAVE_2VRS(n,b,base)SAVE_VR(n,b,base); SAVE_VR(n+1,b,base)
 #define SAVE_4VRS(n,b,base)SAVE_2VRS(n,b,base); SAVE_2VRS(n+2,b,base)
 #define SAVE_8VRS(n,b,base)SAVE_4VRS(n,b,base); SAVE_4VRS(n+4,b,base)
 #define SAVE_16VRS(n,b,base)   SAVE_8VRS(n,b,base); SAVE_8VRS(n+8,b,base)
 #define SAVE_32VRS(n,b,base)   SAVE_16VRS(n,b,base); SAVE_16VRS(n+16,b,base)
-#define REST_VR(n,b,base)  li b,THREAD_VR0+(16*(n)); lvx n,base,b
+#define REST_VR(n,b,base)  li b,16*(n); lvx n,base,b
 #define REST_2VRS(n,b,base)REST_VR(n,b,base); REST_VR(n+1,b,base)
 #define REST_4VRS(n,b,base)REST_2VRS(n,b,base); REST_2VRS(n+2,b,base)
 #define REST_8VRS(n,b,base)REST_4VRS(n,b,base); REST_4VRS(n+4,b,base)
 #define REST_16VRS(n,b,base)   REST_8VRS(n,b,base); REST_8VRS(n+8,b,base)
 #define REST_32VRS(n,b,base)   REST_16VRS(n,b,base); REST_16VRS(n+16,b,base)
 
-/* Save/restore FPRs, VRs and VSRs from their checkpointed backups in
- * thread_struct:
- */
-#define SAVE_FPR_TRANSACT(n, base) stfd n,THREAD_TRANSACT_FPR0+\
-   8*TS_FPRWIDTH*(n)(base)
-#define SAVE_2FPRS_TRANSACT(n, base)   SAVE_FPR_TRANSACT(n, base); \
-   SAVE_FPR_TRANSACT(n+1, base)
-#define SAVE_4FPRS_TRANSACT(n, base)   SAVE_2FPRS_TRANSACT(n, bas

[PATCH 5/6] KVM: PPC: Book3S: Load/save FP/VMX/VSX state directly to/from vcpu struct

2013-09-10 Thread Paul Mackerras
Now that we have the vcpu floating-point and vector state stored in
the same type of struct as the main kernel uses, we can load that
state directly from the vcpu struct instead of having extra copies
to/from the thread_struct.  Similarly, when the guest state needs to
be saved, we can have it saved it directly to the vcpu struct by
setting the current->thread.fp_save_area and current->thread.vr_save_area
pointers.  That also means that we don't need to back up and restore
userspace's FP/vector state.  This all makes the code simpler and
faster.

Note that it's not necessary to save or modify current->thread.fpexc_mode,
since nothing in KVM uses or is affected by its value.  Nor is it
necessary to touch used_vr or used_vsr.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/kvm/book3s_pr.c | 72 ++--
 arch/powerpc/kvm/booke.c | 16 --
 arch/powerpc/kvm/booke.h |  4 ++-
 3 files changed, 19 insertions(+), 73 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 90be91c..5eae919 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -462,16 +462,16 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr)
 * both the traditional FP registers and the added VSX
 * registers into thread.fp_state.fpr[].
 */
-   if (current->thread.regs->msr & MSR_FP)
+   if (t->regs->msr & MSR_FP)
giveup_fpu(current);
-   vcpu->arch.fp = t->fp_state;
+   t->fp_save_area = NULL;
}
 
 #ifdef CONFIG_ALTIVEC
if (msr & MSR_VEC) {
if (current->thread.regs->msr & MSR_VEC)
giveup_altivec(current);
-   vcpu->arch.vr = t->vr_state;
+   t->vr_save_area = NULL;
}
 #endif
 
@@ -556,22 +556,20 @@ static int kvmppc_handle_ext(struct kvm_vcpu *vcpu, 
unsigned int exit_nr,
 #endif
 
if (msr & MSR_FP) {
-   t->fp_state = vcpu->arch.fp;
-   t->fpexc_mode = 0;
enable_kernel_fp();
-   load_fp_state(&t->fp_state);
+   load_fp_state(&vcpu->arch.fp);
+   t->fp_save_area = &vcpu->arch.fp;
}
 
if (msr & MSR_VEC) {
 #ifdef CONFIG_ALTIVEC
-   t->vr_state = vcpu->arch.vr;
-   t->vrsave = -1;
enable_kernel_altivec();
-   load_vr_state(&t->vr_state);
+   load_vr_state(&vcpu->arch.vr);
+   t->vr_save_area = &vcpu->arch.vr;
 #endif
}
 
-   current->thread.regs->msr |= msr;
+   t->regs->msr |= msr;
vcpu->arch.guest_owned_ext |= msr;
kvmppc_recalc_shadow_msr(vcpu);
 
@@ -592,11 +590,11 @@ static void kvmppc_handle_lost_ext(struct kvm_vcpu *vcpu)
 
if (lost_ext & MSR_FP) {
enable_kernel_fp();
-   load_fp_state(¤t->thread.fp_state);
+   load_fp_state(&vcpu->arch.fp);
}
if (lost_ext & MSR_VEC) {
enable_kernel_altivec();
-   load_vr_state(¤t->thread.vr_state);
+   load_vr_state(&vcpu->arch.vr);
}
current->thread.regs->msr |= lost_ext;
 }
@@ -1067,17 +1065,9 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
 int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
 {
int ret;
-   struct thread_fp_state fp;
-   int fpexc_mode;
 #ifdef CONFIG_ALTIVEC
-   struct thread_vr_state vr;
unsigned long uninitialized_var(vrsave);
-   int used_vr;
 #endif
-#ifdef CONFIG_VSX
-   int used_vsr;
-#endif
-   ulong ext_msr;
 
/* Check if we can run the vcpu at all */
if (!vcpu->arch.sane) {
@@ -1099,33 +1089,22 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct 
kvm_vcpu *vcpu)
goto out;
}
 
-   /* Save FPU state in stack */
+   /* Save FPU state in thread_struct */
if (current->thread.regs->msr & MSR_FP)
giveup_fpu(current);
-   fp = current->thread.fp_state;
-   fpexc_mode = current->thread.fpexc_mode;
 
 #ifdef CONFIG_ALTIVEC
-   /* Save Altivec state in stack */
-   used_vr = current->thread.used_vr;
-   if (used_vr) {
-   if (current->thread.regs->msr & MSR_VEC)
-   giveup_altivec(current);
-   vr = current->thread.vr_state;
-   vrsave = current->thread.vrsave;
-   }
+   /* Save Altivec state in thread_struct */
+   if (current->thread.regs->msr & MSR_VEC)
+   giveup_altivec(current);
 #endif
 
 #ifdef CONFIG_VSX
-   /* Save VSX state in stack */
-   used_vsr = current->thread.used_vsr;
-   if (used_vsr && (current->thread.regs->msr & MSR_VSX))
+   /* Save VSX state in thread_struct */
+   if (current->thread.regs->msr & MSR_VSX)
__giveup_vsx(current);
 #endif
 
-   /* Reme

[PATCH 3/6] KVM: PPC: Use load_fp/vr_state rather than load_up_fpu/altivec

2013-09-10 Thread Paul Mackerras
The load_up_fpu and load_up_altivec functions were never intended to
be called from C, and do things like modifying the MSR value in their
callers' stack frames, which are assumed to be interrupt frames.  In
addition, on 32-bit Book S they require the MMU to be off.

This makes KVM use the new load_fp_state() and load_vr_state() functions
instead of load_up_fpu/altivec.  This means we can remove the assembler
glue in book3s_rmhandlers.S, and potentially fixes a bug on Book E,
where load_up_fpu was called directly from C.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/include/asm/kvm_book3s.h |  3 ---
 arch/powerpc/include/asm/switch_to.h  |  2 --
 arch/powerpc/kvm/book3s_exports.c |  4 ---
 arch/powerpc/kvm/book3s_pr.c  | 18 +-
 arch/powerpc/kvm/book3s_rmhandlers.S  | 47 ---
 arch/powerpc/kvm/booke.h  |  3 ++-
 6 files changed, 14 insertions(+), 63 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index fa19e2f..173cd31 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -175,9 +175,6 @@ extern long kvmppc_hv_get_dirty_log(struct kvm *kvm,
 
 extern void kvmppc_entry_trampoline(void);
 extern void kvmppc_hv_entry_trampoline(void);
-extern void kvmppc_load_up_fpu(void);
-extern void kvmppc_load_up_altivec(void);
-extern void kvmppc_load_up_vsx(void);
 extern u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst);
 extern ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst);
 extern int kvmppc_h_pr(struct kvm_vcpu *vcpu, unsigned long cmd);
diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index 2be5618..91a6b74 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -25,10 +25,8 @@ static inline void save_tar(struct thread_struct *prev)
 static inline void save_tar(struct thread_struct *prev) {}
 #endif
 
-extern void load_up_fpu(void);
 extern void enable_kernel_fp(void);
 extern void enable_kernel_altivec(void);
-extern void load_up_altivec(struct task_struct *);
 extern int emulate_altivec(struct pt_regs *);
 extern void __giveup_vsx(struct task_struct *);
 extern void giveup_vsx(struct task_struct *);
diff --git a/arch/powerpc/kvm/book3s_exports.c 
b/arch/powerpc/kvm/book3s_exports.c
index 7057a02..7ba5f78 100644
--- a/arch/powerpc/kvm/book3s_exports.c
+++ b/arch/powerpc/kvm/book3s_exports.c
@@ -24,9 +24,5 @@
 EXPORT_SYMBOL_GPL(kvmppc_hv_entry_trampoline);
 #else
 EXPORT_SYMBOL_GPL(kvmppc_entry_trampoline);
-EXPORT_SYMBOL_GPL(kvmppc_load_up_fpu);
-#ifdef CONFIG_ALTIVEC
-EXPORT_SYMBOL_GPL(kvmppc_load_up_altivec);
-#endif
 #endif
 
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index c0b48f96..3c52b08 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -586,7 +586,8 @@ static int kvmppc_handle_ext(struct kvm_vcpu *vcpu, 
unsigned int exit_nr,
 #endif
t->fp_state.fpscr = vcpu->arch.fpscr;
t->fpexc_mode = 0;
-   kvmppc_load_up_fpu();
+   enable_kernel_fp();
+   load_fp_state(&t->fp_state);
}
 
if (msr & MSR_VEC) {
@@ -594,7 +595,8 @@ static int kvmppc_handle_ext(struct kvm_vcpu *vcpu, 
unsigned int exit_nr,
memcpy(t->vr_state.vr, vcpu->arch.vr, sizeof(vcpu->arch.vr));
t->vr_state.vscr = vcpu->arch.vscr;
t->vrsave = -1;
-   kvmppc_load_up_altivec();
+   enable_kernel_altivec();
+   load_vr_state(&t->vr_state);
 #endif
}
 
@@ -617,10 +619,14 @@ static void kvmppc_handle_lost_ext(struct kvm_vcpu *vcpu)
if (!lost_ext)
return;
 
-   if (lost_ext & MSR_FP)
-   kvmppc_load_up_fpu();
-   if (lost_ext & MSR_VEC)
-   kvmppc_load_up_altivec();
+   if (lost_ext & MSR_FP) {
+   enable_kernel_fp();
+   load_fp_state(¤t->thread.fp_state);
+   }
+   if (lost_ext & MSR_VEC) {
+   enable_kernel_altivec();
+   load_vr_state(¤t->thread.vr_state);
+   }
current->thread.regs->msr |= lost_ext;
 }
 
diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S 
b/arch/powerpc/kvm/book3s_rmhandlers.S
index 8f7633e..7e8bb58 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -188,51 +188,4 @@ _GLOBAL(kvmppc_entry_trampoline)
mtsrr1  r6
RFI
 
-#if defined(CONFIG_PPC_BOOK3S_32)
-#define STACK_LR   INT_FRAME_SIZE+4
-
-/* load_up_xxx have to run with MSR_DR=0 on Book3S_32 */
-#define MSR_EXT_START  \
-   PPC_STL r20, _NIP(r1);  \
-   mfmsr   r20;\
-   LOAD_REG_IMMEDIATE(r3, MSR_DR|MSR_EE);  \
-   andcr3,r20,

[PATCH 6/6] KVM: PPC: Book3S HV: Use load/store_fp_state functions in HV guest entry/exit

2013-09-10 Thread Paul Mackerras
This modifies kvmppc_load_fp and kvmppc_save_fp to use the generic
FP/VSX and VMX load/store functions instead of open-coding the
FP/VSX/VMX load/store instructions.  Since kvmppc_load/save_fp don't
follow C calling conventions, we make them private symbols within
book3s_hv_rmhandlers.S.

Signed-off-by: Paul Mackerras 
---
 arch/powerpc/kernel/asm-offsets.c   |  2 -
 arch/powerpc/kvm/book3s_hv_rmhandlers.S | 82 -
 2 files changed, 18 insertions(+), 66 deletions(-)

diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 4c1609f..7982870 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -425,10 +425,8 @@ int main(void)
DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
DEFINE(VCPU_VRSAVE, offsetof(struct kvm_vcpu, arch.vrsave));
DEFINE(VCPU_FPRS, offsetof(struct kvm_vcpu, arch.fp.fpr));
-   DEFINE(VCPU_FPSCR, offsetof(struct kvm_vcpu, arch.fp.fpscr));
 #ifdef CONFIG_ALTIVEC
DEFINE(VCPU_VRS, offsetof(struct kvm_vcpu, arch.vr.vr));
-   DEFINE(VCPU_VSCR, offsetof(struct kvm_vcpu, arch.vr.vscr));
 #endif
DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, arch.xer));
DEFINE(VCPU_CTR, offsetof(struct kvm_vcpu, arch.ctr));
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index f5f2396..b5183ed 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1102,7 +1102,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
 
/* save FP state */
mr  r3, r9
-   bl  .kvmppc_save_fp
+   bl  kvmppc_save_fp
 
/* Increment yield count if they have a VPA */
ld  r8, VCPU_VPA(r9)/* do they have a VPA? */
@@ -1591,7 +1591,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_206)
std r31, VCPU_GPR(R31)(r3)
 
/* save FP state */
-   bl  .kvmppc_save_fp
+   bl  kvmppc_save_fp
 
/*
 * Take a nap until a decrementer or external interrupt occurs,
@@ -1767,7 +1767,9 @@ kvm_no_guest:
  * Save away FP, VMX and VSX registers.
  * r3 = vcpu pointer
  */
-_GLOBAL(kvmppc_save_fp)
+kvmppc_save_fp:
+   mflrr30
+   mr  r31,r3
mfmsr   r5
ori r8,r5,MSR_FP
 #ifdef CONFIG_ALTIVEC
@@ -1782,42 +1784,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 #endif
mtmsrd  r8
isync
-#ifdef CONFIG_VSX
-BEGIN_FTR_SECTION
-   reg = 0
-   .rept   32
-   li  r6,reg*16+VCPU_FPRS
-   STXVD2X(reg,R6,R3)
-   reg = reg + 1
-   .endr
-FTR_SECTION_ELSE
-#endif
-   reg = 0
-   .rept   32
-   stfdreg,reg*8+VCPU_FPRS(r3)
-   reg = reg + 1
-   .endr
-#ifdef CONFIG_VSX
-ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX)
-#endif
-   mffsfr0
-   stfdfr0,VCPU_FPSCR(r3)
-
+   addir3,r3,VCPU_FPRS
+   bl  .store_fp_state
 #ifdef CONFIG_ALTIVEC
 BEGIN_FTR_SECTION
-   reg = 0
-   .rept   32
-   li  r6,reg*16+VCPU_VRS
-   stvxreg,r6,r3
-   reg = reg + 1
-   .endr
-   mfvscr  vr0
-   li  r6,VCPU_VSCR
-   stvxvr0,r6,r3
+   addir3,r31,VCPU_VRS
+   bl  .store_vr_state
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 #endif
mfspr   r6,SPRN_VRSAVE
stw r6,VCPU_VRSAVE(r3)
+   mtlrr30
mtmsrd  r5
isync
blr
@@ -1826,8 +1803,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
  * Load up FP, VMX and VSX registers
  * r4 = vcpu pointer
  */
-   .globl  kvmppc_load_fp
 kvmppc_load_fp:
+   mflrr30
+   mr  r31,r4
mfmsr   r9
ori r8,r9,MSR_FP
 #ifdef CONFIG_ALTIVEC
@@ -1842,40 +1820,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
 #endif
mtmsrd  r8
isync
-   lfd fr0,VCPU_FPSCR(r4)
-   MTFSF_L(fr0)
-#ifdef CONFIG_VSX
-BEGIN_FTR_SECTION
-   reg = 0
-   .rept   32
-   li  r7,reg*16+VCPU_FPRS
-   LXVD2X(reg,R7,R4)
-   reg = reg + 1
-   .endr
-FTR_SECTION_ELSE
-#endif
-   reg = 0
-   .rept   32
-   lfd reg,reg*8+VCPU_FPRS(r4)
-   reg = reg + 1
-   .endr
-#ifdef CONFIG_VSX
-ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX)
-#endif
-
+   addir3,r4,VCPU_FPRS
+   bl  .load_fp_state
 #ifdef CONFIG_ALTIVEC
 BEGIN_FTR_SECTION
-   li  r7,VCPU_VSCR
-   lvx vr0,r7,r4
-   mtvscr  vr0
-   reg = 0
-   .rept   32
-   li  r7,reg*16+VCPU_VRS
-   lvx reg,r7,r4
-   reg = reg + 1
-   .endr
+   addir3,r31,VCPU_VRS
+   bl  .load_vr_state
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 #endif
lwz r7,VCPU_VRSAVE(r4)
mtspr   SPRN_VRSAVE,r7
+   mtlrr30
+   mr  r4,r31
blr
-- 
1.8.4.rc3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes

2013-09-10 Thread Sudeep KarkadaNagesha
On 10/09/13 03:44, Shawn Guo wrote:
> On Mon, Sep 09, 2013 at 04:24:18PM +0100, Sudeep KarkadaNagesha wrote:
>> Hi Shawn,
>>
>> Ok. But I am bit suspicious about devm_clk_get(cpu_dev, NULL).
>> I don't understand completely as how the clock are registered(whether
>> with dev_id or with connection_id).
> 
> As the connection_id of devm_clk_get() call here is NULL, the clock
> lookup should be registered with a proper dev_id in clk_register_clkdev()
> call.  And that's what you have seen with imx and shmobile code.
> 
>
>> A quick grep revealed that i.mx and shmobile is using conection id while
>> registering.
> 
> They are using dev_id.
> 
Yes correct. I misunderstood, was expecting caller to pass dev and clk
layer extract dev_name so that even when device name is changed the clk
registration need not be changed.

>> If the clock is registered with connection id and retrieved
>> with cpu_dev(now dev_id is cpu0 and not cpufreq-cpu0), IIUC that would
>> break. If we pass pdev->dev for clk_get, it should be fine but again
>> IIUC it breaks highbank which gets all the information from DT.
> 
> If the clock lookup is from DT, we should be just fine, since it will
> work as long as the DT node with 'clocks' property (/cpus/cpu@0 in this
> case) is attached to the struct device pointer of devm_clk_get() call.
> 
This can be ignored if we are registering with "cpu0" as below in your
patch.

>> So only solution I can think of is to continue to have the code
>> assigning (&pdev->dev)->of_node with cpu device node which is not clean
>> and arguable as incorrect since there is no DT node for cpufreq-cpu0.
>> I don't have a strong opinion though.
>>
>> Let me know how would you like to fix this.
> 
> So we only need to change all clkdev registration to use "cpu0" as
> dev_id intstead of "cpufreq-cpu0.0", something like below.
> 
> And for imx, it should work even without the changes, because we have
> device tree lookup ready there, and those clk_register_clkdev() calls
> can just be removed now.  But I prefer to include the change and leave
> the cleanup to another patch for keeping the change log clear.
> 
Ok makes sense, do you want me to include this patch also as fix.
I can send a series to fix this if you OK:
1. Fix in cpufreq-cpu0
2. Fix in i.MX driver and platform file
3. Patch below

Regards,
Sudeep

> 
> ---8<--
> 
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index c3cfa41..c6b40f3 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -285,7 +285,7 @@ int __init mx27_clocks_init(unsigned long fref)
>   clk_register_clkdev(clk[ata_ahb_gate], "ata", NULL);
>   clk_register_clkdev(clk[rtc_ipg_gate], NULL, "imx21-rtc");
>   clk_register_clkdev(clk[scc_ipg_gate], "scc", NULL);
> - clk_register_clkdev(clk[cpu_div], NULL, "cpufreq-cpu0.0");
> + clk_register_clkdev(clk[cpu_div], NULL, "cpu0");
>   clk_register_clkdev(clk[emi_ahb_gate], "emi_ahb" , NULL);
>  
>   mxc_timer_init(MX27_IO_ADDRESS(MX27_GPT1_BASE_ADDR), MX27_INT_GPT1);
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c 
> b/arch/arm/mach-imx/clk-imx51-imx53.c
> index 1a56a33..de1964c 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -328,7 +328,7 @@ static void __init mx5_clocks_common_init(unsigned long 
> rate_ckil,
>   clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1");
>   clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "imx-ssi.2");
>   clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma");
> - clk_register_clkdev(clk[cpu_podf], NULL, "cpufreq-cpu0.0");
> + clk_register_clkdev(clk[cpu_podf], NULL, "cpu0");
>   clk_register_clkdev(clk[iim_gate], "iim", NULL);
>   clk_register_clkdev(clk[dummy], NULL, "imx2-wdt.0");
>   clk_register_clkdev(clk[dummy], NULL, "imx2-wdt.1");
> diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c 
> b/arch/arm/mach-shmobile/clock-r8a73a4.c
> index 8ea5ef6..5bd2e85 100644
> --- a/arch/arm/mach-shmobile/clock-r8a73a4.c
> +++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
> @@ -555,7 +555,7 @@ static struct clk_lookup lookups[] = {
>   CLKDEV_CON_ID("pll2h",  &pll2h_clk),
>  
>   /* CPU clock */
> - CLKDEV_DEV_ID("cpufreq-cpu0",   &z_clk),
> + CLKDEV_DEV_ID("cpu0",   &z_clk),
>  
>   /* DIV6 */
>   CLKDEV_CON_ID("zb", &div6_clks[DIV6_ZB]),
> diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c 
> b/arch/arm/mach-shmobile/clock-sh73a0.c
> index 1942eae..c92c023 100644
> --- a/arch/arm/mach-shmobile/clock-sh73a0.c
> +++ b/arch/arm/mach-shmobile/clock-sh73a0.c
> @@ -616,7 +616,7 @@ static struct clk_lookup lookups[] = {
>   CLKDEV_DEV_ID("smp_twd", &twd_clk), /* smp_twd */
>  
>   /* DIV4 clocks */
> - CLKDEV_DEV_ID("cpufreq-cpu0", &div4_clks[DIV4_Z]),
> + CLKDEV_DEV_ID("cpu0", &div4_clks[DIV4_Z]),
>  
>   /* DIV6 clocks */
>   CLKDEV_CON_ID("

Re: [PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes

2013-09-10 Thread Shawn Guo
On Tue, Sep 10, 2013 at 11:56:17AM +0100, Sudeep KarkadaNagesha wrote:
> > So we only need to change all clkdev registration to use "cpu0" as
> > dev_id intstead of "cpufreq-cpu0.0", something like below.
> > 
> > And for imx, it should work even without the changes, because we have
> > device tree lookup ready there, and those clk_register_clkdev() calls
> > can just be removed now.  But I prefer to include the change and leave
> > the cleanup to another patch for keeping the change log clear.
> > 
> Ok makes sense, do you want me to include this patch also as fix.
> I can send a series to fix this if you OK:
> 1. Fix in cpufreq-cpu0
> 2. Fix in i.MX driver and platform file
> 3. Patch below

Yes, please.  Thanks.

Shawn

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH -V3] powerpc: Fix possible deadlock on page fault

2013-09-10 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

 stack_grow_into/14082 is trying to acquire lock:
  (&mm->mmap_sem){++}, at: [] .might_fault+0x78/0xe0

 but task is already holding lock:
  (&mm->mmap_sem){++}, at: [] .do_page_fault+0x24c/0x910

 other info that might help us debug this:
  Possible unsafe locking scenario:

CPU0

   lock(&mm->mmap_sem);
   lock(&mm->mmap_sem);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 1 lock held by stack_grow_into/14082:
  #0:  (&mm->mmap_sem){++}, at: [] 
.do_page_fault+0x24c/0x910

 stack backtrace:
 CPU: 21 PID: 14082 Comm: stack_grow_into Not tainted 3.10.0-10.el7.ppc64.debug 
#1
 Call Trace:
 [c003d396b850] [c0016e7c] .show_stack+0x7c/0x1f0 (unreliable)
 [c003d396b920] [c0813fc8] .dump_stack+0x28/0x3c
 [c003d396b990] [c0124b90] .__lock_acquire+0x1640/0x1800
 [c003d396bab0] [c012570c] .lock_acquire+0xac/0x250
 [c003d396bb80] [c0206d54] .might_fault+0xa4/0xe0
 [c003d396bbf0] [c07ffe2c] .do_page_fault+0x2ec/0x910
 [c003d396be30] [c00092e8] handle_page_fault+0x10/0x30

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/mm/fault.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8726779..1d1f2ec 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
int trap = TRAP(regs);
int is_exec = trap == 0x400;
int fault;
-   int rc = 0;
+   int rc = 0, store_update_sp = 0;
 
 #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/*
@@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned 
long address,
 
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
 
+   /*
+* We want to do this outside mmap_sem, because reading code around nip
+* can result in fault, which will cause a deadlock when called with
+* mmap_sem held
+*/
+   if (user_mode(regs))
+   store_update_sp = store_updates_sp(regs);
+
/* When running in the kernel we expect faults to occur only to
 * addresses in user space.  All other faults represent errors in the
 * kernel and should generate an OOPS.  Unfortunately, in the case of an
@@ -345,8 +353,7 @@ retry:
 * between the last mapped region and the stack will
 * expand the stack rather than segfaulting.
 */
-   if (address + 2048 < uregs->gpr[1]
-   && (!user_mode(regs) || !store_updates_sp(regs)))
+   if (address + 2048 < uregs->gpr[1] && !store_update_sp)
goto bad_area;
}
if (expand_stack(vma, address))
-- 
1.8.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/p1010rdb:update phy node in dts

2013-09-10 Thread Kumar Gala

On Sep 10, 2013, at 12:50 AM, Zhao Qiang wrote:

> Update phy node according to new P1010RDB-PB board.
> 
> Signed-off-by: Shengzhou Liu 
> Signed-off-by: Zhao Qiang 
> ---
> arch/powerpc/boot/dts/p1010rdb.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)

What about the old boards?

- k

> 
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi 
> b/arch/powerpc/boot/dts/p1010rdb.dtsi
> index 7fc3402..8c675bf 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dtsi
> +++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
> @@ -199,7 +199,7 @@
> 
>   mdio@24000 {
>   phy0: ethernet-phy@0 {
> - interrupts = <3 1 0 0>;
> + interrupts = <0 1 0 0>;
>   reg = <0x1>;
>   };
> 
> @@ -209,7 +209,7 @@
>   };
> 
>   phy2: ethernet-phy@2 {
> - interrupts = <2 1 0 0>;
> + interrupts = <1 1 0 0>;
>   reg = <0x2>;
>   };
> 
> -- 
> 1.8.0
> 
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] fbdev/ps3fb: fix section mismatch warning for ps3fb_probe

2013-09-10 Thread Geert Uytterhoeven
On Tue, Sep 10, 2013 at 6:46 PM, Vladimir Murzin  wrote:
> diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> index dbfe2c1..b269abd 100644
> --- a/drivers/video/ps3fb.c
> +++ b/drivers/video/ps3fb.c
> @@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
> .fb_compat_ioctl = ps3fb_ioctl
>  };
>
> -static struct fb_fix_screeninfo ps3fb_fix __initdata = {
> +static struct fb_fix_screeninfo ps3fb_fix = {
> .id =   DEVICE_NAME,
> .type = FB_TYPE_PACKED_PIXELS,
> .visual =   FB_VISUAL_TRUECOLOR,

Fixed before by Geoff, but never applied:
http://marc.info/?l=linux-fbdev&m=136914132618389&w=3

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] fbdev/ps3fb: fix section mismatch warning for ps3fb_probe

2013-09-10 Thread Vladimir Murzin
On Tue, Sep 10, 2013 at 06:56:33PM +0200, Geert Uytterhoeven wrote:
> On Tue, Sep 10, 2013 at 6:46 PM, Vladimir Murzin  wrote:
> > diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
> > index dbfe2c1..b269abd 100644
> > --- a/drivers/video/ps3fb.c
> > +++ b/drivers/video/ps3fb.c
> > @@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
> > .fb_compat_ioctl = ps3fb_ioctl
> >  };
> >
> > -static struct fb_fix_screeninfo ps3fb_fix __initdata = {
> > +static struct fb_fix_screeninfo ps3fb_fix = {
> > .id =   DEVICE_NAME,
> > .type = FB_TYPE_PACKED_PIXELS,
> > .visual =   FB_VISUAL_TRUECOLOR,
> 
> Fixed before by Geoff, but never applied:
> http://marc.info/?l=linux-fbdev&m=136914132618389&w=3

Great! Hope some day it will ;)

Sorry for the noise
Vladimir

> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/3] powerpc: export cpu_to_chip_id

2013-09-10 Thread Vladimir Murzin
While cross-building for PPC64 I've got

ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

mtip32xx refer to topology_physical_package_id, which stands for
cpu_to_chip-id.

Make cpu_to_chip-id (and topology_physical_package_id) available for
external users.

Signed-off-by: Vladimir Murzin 
---
 arch/powerpc/kernel/smp.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 442d8e2..1d9c1c2 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu)
of_node_put(np);
return of_get_ibm_chip_id(np);
 }
+EXPORT_SYMBOL_GPL(cpu_to_chip_id);
 
 /* Helper routines for cpu to core mapping */
 int cpu_core_index_of_thread(int cpu)
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/6] powerpc: Put FP/VSX and VR state into structures

2013-09-10 Thread Alexander Graf

On 10.09.2013, at 05:20, Paul Mackerras wrote:

> This creates new 'thread_fp_state' and 'thread_vr_state' structures
> to store FP/VSX state (including FPSCR) and Altivec/VSX state
> (including VSCR), and uses them in the thread_struct.  In the
> thread_fp_state, the FPRs and VSRs are represented as u64 rather
> than double, since we rarely perform floating-point computations
> on the values, and this will enable the structures to be used
> in KVM code as well.  Similarly FPSCR is now a u64 rather than
> a structure of two 32-bit values.
> 
> This takes the offsets out of the macros such as SAVE_32FPRS,
> REST_32FPRS, etc.  This enables the same macros to be used for normal
> and transactional state, enabling us to delete the transactional
> versions of the macros.   This also removes the unused do_load_up_fpu
> and do_load_up_altivec, which were in fact buggy since they didn't
> create large enough stack frames to account for the fact that
> load_up_fpu and load_up_altivec are not designed to be called from C
> and assume that their caller's stack frame is an interrupt frame.
> 
> Signed-off-by: Paul Mackerras 

I like the idea of this patch. However this really needs an ack from Ben (or 
get applied by him). I also found the patch pretty large and subtile, so 
there's a good chance I missed a register overwrite if there was any :).

> ---
> arch/powerpc/include/asm/ppc_asm.h | 95 +++---
> arch/powerpc/include/asm/processor.h   | 40 +++---
> arch/powerpc/include/asm/sfp-machine.h |  2 +-
> arch/powerpc/kernel/align.c|  6 +--
> arch/powerpc/kernel/asm-offsets.c  | 25 +++--
> arch/powerpc/kernel/fpu.S  | 59 +
> arch/powerpc/kernel/process.c  |  8 ++-
> arch/powerpc/kernel/ptrace.c   | 49 +-
> arch/powerpc/kernel/ptrace32.c | 11 ++--
> arch/powerpc/kernel/signal_32.c| 72 +-
> arch/powerpc/kernel/signal_64.c| 29 ++-
> arch/powerpc/kernel/tm.S   | 41 ---
> arch/powerpc/kernel/traps.c| 10 ++--
> arch/powerpc/kernel/vecemu.c   |  6 +--
> arch/powerpc/kernel/vector.S   | 50 ++
> arch/powerpc/kvm/book3s_pr.c   | 36 ++---
> arch/powerpc/kvm/booke.c   | 19 ---
> 17 files changed, 200 insertions(+), 358 deletions(-)
> 
> 

[...]

> diff --git a/arch/powerpc/include/asm/sfp-machine.h 
> b/arch/powerpc/include/asm/sfp-machine.h
> index 3a7a67a..d89beab 100644
> --- a/arch/powerpc/include/asm/sfp-machine.h
> +++ b/arch/powerpc/include/asm/sfp-machine.h
> @@ -125,7 +125,7 @@
> #define FP_EX_DIVZERO (1 << (31 - 5))
> #define FP_EX_INEXACT (1 << (31 - 6))
> 
> -#define __FPU_FPSCR  (current->thread.fpscr.val)
> +#define __FPU_FPSCR  (current->thread.fp_state.fpscr)
> 
> /* We only actually write to the destination register
>  * if exceptions signalled (if any) will not trap.
> diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
> index a27ccd5..eaa16bc 100644
> --- a/arch/powerpc/kernel/align.c
> +++ b/arch/powerpc/kernel/align.c
> @@ -660,7 +660,7 @@ static int emulate_vsx(unsigned char __user *addr, 
> unsigned int reg,
>   if (reg < 32)
>   ptr = (char *) ¤t->thread.TS_FPR(reg);
>   else
> - ptr = (char *) ¤t->thread.vr[reg - 32];
> + ptr = (char *) ¤t->thread.vr_state.vr[reg - 32];
> 
>   lptr = (unsigned long *) ptr;
> 
> @@ -897,7 +897,7 @@ int fix_alignment(struct pt_regs *regs)
>   return -EFAULT;
>   }
>   } else if (flags & F) {
> - data.dd = current->thread.TS_FPR(reg);
> + data.ll = current->thread.TS_FPR(reg);

I don't understand this change. Could you please explain?

>   if (flags & S) {
>   /* Single-precision FP store requires conversion... */
> #ifdef CONFIG_PPC_FPU
> @@ -975,7 +975,7 @@ int fix_alignment(struct pt_regs *regs)
>   if (unlikely(ret))
>   return -EFAULT;
>   } else if (flags & F)
> - current->thread.TS_FPR(reg) = data.dd;
> + current->thread.TS_FPR(reg) = data.ll;
>   else
>   regs->gpr[reg] = data.ll;
> 

[...]

> diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
> index 7b60b98..d781ca5 100644
> --- a/arch/powerpc/kernel/tm.S
> +++ b/arch/powerpc/kernel/tm.S
> @@ -12,16 +12,15 @@
> #include 
> 
> #ifdef CONFIG_VSX
> -/* See fpu.S, this is very similar but to save/restore checkpointed 
> FPRs/VSRs */
> -#define __SAVE_32FPRS_VSRS_TRANSACT(n,c,base)\
> +/* See fpu.S, this is borrowed from there */
> +#define __SAVE_32FPRS_VSRS(n,c,base) \

Should this really be in tm.S with its new name?


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinf

Re: [PATCH 2/6] powerpc: Provide for giveup_fpu/altivec to save state in alternate location

2013-09-10 Thread Alexander Graf

On 10.09.2013, at 05:21, Paul Mackerras wrote:

> This provides a facility which is intended for use by KVM, where the
> contents of the FP/VSX and VMX (Altivec) registers can be saved away
> to somewhere other than the thread_struct when kernel code wants to
> use floating point or VMX instructions.  This is done by providing a
> pointer in the thread_struct to indicate where the state should be
> saved to.  The giveup_fpu() and giveup_altivec() functions test these
> pointers and save state to the indicated location if they are non-NULL.
> Note that the MSR_FP/VEC bits in task->thread.regs->msr are still used
> to indicate whether the CPU register state is live, even when an
> alternate save location is being used.
> 
> This also provides load_fp_state() and load_vr_state() functions, which
> load up FP/VSX and VMX state from memory into the CPU registers, and
> corresponding store_fp_state() and store_vr_state() functions, which
> store FP/VSX and VMX state into memory from the CPU registers.
> 
> Signed-off-by: Paul Mackerras 
> ---
> arch/powerpc/include/asm/processor.h |  7 +++
> arch/powerpc/kernel/asm-offsets.c|  2 ++
> arch/powerpc/kernel/fpu.S| 25 -
> arch/powerpc/kernel/ppc_ksyms.c  |  4 
> arch/powerpc/kernel/process.c|  7 +++
> arch/powerpc/kernel/vector.S | 29 +++--
> 6 files changed, 71 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/processor.h 
> b/arch/powerpc/include/asm/processor.h
> index 92f709d..8bc9d66 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -212,6 +212,7 @@ struct thread_struct {
> #endif
> #endif
>   struct thread_fp_state  fp_state;
> + struct thread_fp_state  *fp_save_area;

Why do you need these pointers? Couldn't you handle everything you need through 
preempt notifiers?


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/3] powerpc: fix section mismatch warning for prom_rtas_call

2013-09-10 Thread Vladimir Murzin
While cross-building for PPC64 I've got

WARNING: vmlinux.o(.text.unlikely+0x1ba): Section mismatch in
reference from the function .prom_rtas_call() to the variable
.init.data:dt_string_start The function .prom_rtas_call() references
the variable __initdata dt_string_start.  This is often because
.prom_rtas_call lacks a __initdata annotation or the annotation of
dt_string_start is wrong.

WARNING: vmlinux.o(.meminit.text+0xeb0): Section mismatch in reference
from the function .free_area_init_core.isra.47() to the function
.init.text:.set_pageblock_order() The function __meminit
.free_area_init_core.isra.47() references a function __init
.set_pageblock_order().  If .set_pageblock_order is only used by
.free_area_init_core.isra.47 then annotate .set_pageblock_order with a
matching annotation.

Fix it by proper annotation of prom_rtas_call.

Signed-off-by: Vladimir Murzin 
---
 arch/powerpc/kernel/prom_init.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 7b6391b..12e656f 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1297,7 +1297,8 @@ static void __init prom_query_opal(void)
prom_opal_align = 0x1;
 }
 
-static int prom_rtas_call(int token, int nargs, int nret, int *outputs, ...)
+static int __init prom_rtas_call(int token, int nargs, int nret,
+int *outputs, ...)
 {
struct rtas_args rtas_args;
va_list list;
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 3/3] fbdev/ps3fb: fix section mismatch warning for ps3fb_probe

2013-09-10 Thread Vladimir Murzin
While cross-building for PPC64 I've got

WARNING: drivers/video/built-in.o(.text+0x9f9ca): Section mismatch in
reference from the function .ps3fb_probe() to th e variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix.  This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.

WARNING: drivers/video/built-in.o(.text+0x9f9d2): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix.  This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.

WARNING: drivers/built-in.o(.text+0xe222a): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix.  This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.

WARNING: drivers/built-in.o(.text+0xe2232): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix.  This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.

WARNING: vmlinux.o(.text+0x561d4a): Section mismatch in reference from
the function .ps3fb_probe() to the variable .init.data:ps3fb_fix The
function .ps3fb_probe() references the variable __initdata ps3fb_fix.
This is often because .ps3fb_probe lacks a __initdata annotation or
the annotation of ps3fb_fix is wrong.

Mismatch was introduced with 48c68c4f "Drivers: video: remove __dev*
attributes."

Remove __init data annotation from ps3fb_fix.

Signed-off-by: Vladimir Murzin 
---
 drivers/video/ps3fb.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index dbfe2c1..b269abd 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -952,7 +952,7 @@ static struct fb_ops ps3fb_ops = {
.fb_compat_ioctl = ps3fb_ioctl
 };
 
-static struct fb_fix_screeninfo ps3fb_fix __initdata = {
+static struct fb_fix_screeninfo ps3fb_fix = {
.id =   DEVICE_NAME,
.type = FB_TYPE_PACKED_PIXELS,
.visual =   FB_VISUAL_TRUECOLOR,
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 5/6] KVM: PPC: Book3S: Load/save FP/VMX/VSX state directly to/from vcpu struct

2013-09-10 Thread Alexander Graf

On 10.09.2013, at 05:22, Paul Mackerras wrote:

> Now that we have the vcpu floating-point and vector state stored in
> the same type of struct as the main kernel uses, we can load that
> state directly from the vcpu struct instead of having extra copies
> to/from the thread_struct.  Similarly, when the guest state needs to
> be saved, we can have it saved it directly to the vcpu struct by
> setting the current->thread.fp_save_area and current->thread.vr_save_area
> pointers.  That also means that we don't need to back up and restore
> userspace's FP/vector state.  This all makes the code simpler and
> faster.
> 
> Note that it's not necessary to save or modify current->thread.fpexc_mode,
> since nothing in KVM uses or is affected by its value.  Nor is it
> necessary to touch used_vr or used_vsr.
> 
> Signed-off-by: Paul Mackerras 
> ---
> arch/powerpc/kvm/book3s_pr.c | 72 ++--
> arch/powerpc/kvm/booke.c | 16 --
> arch/powerpc/kvm/booke.h |  4 ++-
> 3 files changed, 19 insertions(+), 73 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index 90be91c..5eae919 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -462,16 +462,16 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr)
>* both the traditional FP registers and the added VSX
>* registers into thread.fp_state.fpr[].
>*/
> - if (current->thread.regs->msr & MSR_FP)
> + if (t->regs->msr & MSR_FP)
>   giveup_fpu(current);

If you make a second version of this call that also gets a state area as 
parameter, you don't need the pointer in the thread struct anymore, no? Or do 
you? Ah, you want to be able to grab the FPU for in-kernel FPU using code, so 
it needs to be seamless.

Fiar enough - pointer it is then :).


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 6/6] KVM: PPC: Book3S HV: Use load/store_fp_state functions in HV guest entry/exit

2013-09-10 Thread Alexander Graf

On 10.09.2013, at 05:22, Paul Mackerras wrote:

> This modifies kvmppc_load_fp and kvmppc_save_fp to use the generic
> FP/VSX and VMX load/store functions instead of open-coding the
> FP/VSX/VMX load/store instructions.  Since kvmppc_load/save_fp don't
> follow C calling conventions, we make them private symbols within
> book3s_hv_rmhandlers.S.
> 
> Signed-off-by: Paul Mackerras 
> ---
> arch/powerpc/kernel/asm-offsets.c   |  2 -
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 82 -
> 2 files changed, 18 insertions(+), 66 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/asm-offsets.c 
> b/arch/powerpc/kernel/asm-offsets.c
> index 4c1609f..7982870 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -425,10 +425,8 @@ int main(void)
>   DEFINE(VCPU_GPRS, offsetof(struct kvm_vcpu, arch.gpr));
>   DEFINE(VCPU_VRSAVE, offsetof(struct kvm_vcpu, arch.vrsave));
>   DEFINE(VCPU_FPRS, offsetof(struct kvm_vcpu, arch.fp.fpr));
> - DEFINE(VCPU_FPSCR, offsetof(struct kvm_vcpu, arch.fp.fpscr));
> #ifdef CONFIG_ALTIVEC
>   DEFINE(VCPU_VRS, offsetof(struct kvm_vcpu, arch.vr.vr));
> - DEFINE(VCPU_VSCR, offsetof(struct kvm_vcpu, arch.vr.vscr));
> #endif
>   DEFINE(VCPU_XER, offsetof(struct kvm_vcpu, arch.xer));
>   DEFINE(VCPU_CTR, offsetof(struct kvm_vcpu, arch.ctr));
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
> b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index f5f2396..b5183ed 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1102,7 +1102,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
> 
>   /* save FP state */
>   mr  r3, r9
> - bl  .kvmppc_save_fp
> + bl  kvmppc_save_fp
> 
>   /* Increment yield count if they have a VPA */
>   ld  r8, VCPU_VPA(r9)/* do they have a VPA? */
> @@ -1591,7 +1591,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_206)
>   std r31, VCPU_GPR(R31)(r3)
> 
>   /* save FP state */
> - bl  .kvmppc_save_fp
> + bl  kvmppc_save_fp
> 
>   /*
>* Take a nap until a decrementer or external interrupt occurs,
> @@ -1767,7 +1767,9 @@ kvm_no_guest:
>  * Save away FP, VMX and VSX registers.
>  * r3 = vcpu pointer
>  */
> -_GLOBAL(kvmppc_save_fp)
> +kvmppc_save_fp:
> + mflrr30
> + mr  r31,r3

Please note somewhere that e30 and r31 get clobbered by this function.

>   mfmsr   r5
>   ori r8,r5,MSR_FP
> #ifdef CONFIG_ALTIVEC
> @@ -1782,42 +1784,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> #endif
>   mtmsrd  r8
>   isync
> -#ifdef CONFIG_VSX
> -BEGIN_FTR_SECTION
> - reg = 0
> - .rept   32
> - li  r6,reg*16+VCPU_FPRS
> - STXVD2X(reg,R6,R3)
> - reg = reg + 1
> - .endr
> -FTR_SECTION_ELSE
> -#endif
> - reg = 0
> - .rept   32
> - stfdreg,reg*8+VCPU_FPRS(r3)
> - reg = reg + 1
> - .endr
> -#ifdef CONFIG_VSX
> -ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX)
> -#endif
> - mffsfr0
> - stfdfr0,VCPU_FPSCR(r3)
> -
> + addir3,r3,VCPU_FPRS
> + bl  .store_fp_state
> #ifdef CONFIG_ALTIVEC
> BEGIN_FTR_SECTION
> - reg = 0
> - .rept   32
> - li  r6,reg*16+VCPU_VRS
> - stvxreg,r6,r3
> - reg = reg + 1
> - .endr
> - mfvscr  vr0
> - li  r6,VCPU_VSCR
> - stvxvr0,r6,r3
> + addir3,r31,VCPU_VRS
> + bl  .store_vr_state
> END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> #endif
>   mfspr   r6,SPRN_VRSAVE
>   stw r6,VCPU_VRSAVE(r3)
> + mtlrr30
>   mtmsrd  r5
>   isync
>   blr
> @@ -1826,8 +1803,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
>  * Load up FP, VMX and VSX registers
>  * r4 = vcpu pointer
>  */
> - .globl  kvmppc_load_fp
> kvmppc_load_fp:
> + mflrr30
> + mr  r31,r4

here too. It's also worth noting in the header comment that r4 is preserved 
(unlike what you'd expect from the C ABI).


Alex

>   mfmsr   r9
>   ori r8,r9,MSR_FP
> #ifdef CONFIG_ALTIVEC
> @@ -1842,40 +1820,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> #endif
>   mtmsrd  r8
>   isync
> - lfd fr0,VCPU_FPSCR(r4)
> - MTFSF_L(fr0)
> -#ifdef CONFIG_VSX
> -BEGIN_FTR_SECTION
> - reg = 0
> - .rept   32
> - li  r7,reg*16+VCPU_FPRS
> - LXVD2X(reg,R7,R4)
> - reg = reg + 1
> - .endr
> -FTR_SECTION_ELSE
> -#endif
> - reg = 0
> - .rept   32
> - lfd reg,reg*8+VCPU_FPRS(r4)
> - reg = reg + 1
> - .endr
> -#ifdef CONFIG_VSX
> -ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX)
> -#endif
> -
> + addir3,r4,VCPU_FPRS
> + bl  .load_fp_state
> #ifdef CONFIG_ALTIVEC
> BEGIN_FTR_SECTION
> - li  r7,VCPU_VSCR
> - lvx vr0,r7,r4
> - mtvscr  vr0
> - reg = 0
> - .rept   32
> - li  r7,reg*16+VCPU_VRS
> - lvx reg,r7,r4
> - reg = reg + 1
> - .endr
> + addir3,r31,VCPU_VRS
> + bl  .load_vr_s

Re: [PATCH] powerpc: Export cpu_to_chip_id() to fix build error

2013-09-10 Thread Benjamin Herrenschmidt
On Mon, 2013-09-09 at 18:37 -0700, Guenter Roeck wrote:
> powerpc allmodconfig build fails with:
> 
> ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> 
> The problem was introduced with commit 15863ff3b (powerpc: Make chip-id
> information available to userspace).

Thanks, I'll send that to Linus asap.

Ben.

> Export the missing symbol.
> 
> Cc: Vasant Hegde 
> Cc: Shivaprasad G Bhat 
> Signed-off-by: Guenter Roeck 
> ---
>  arch/powerpc/kernel/smp.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 442d8e2..8e59abc 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu)
>   of_node_put(np);
>   return of_get_ibm_chip_id(np);
>  }
> +EXPORT_SYMBOL(cpu_to_chip_id);
>  
>  /* Helper routines for cpu to core mapping */
>  int cpu_core_index_of_thread(int cpu)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

2013-09-10 Thread Benjamin Herrenschmidt
On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
> On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> > Hi all,
> >
> > powerpc allmodconfig build on the latest upstream kernel results in:
> >
> > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> >
> > This is due to commit 15863ff3b (powerpc: Make chip-id information 
> > available to userspace).
> > Not surprising, as cpu_to_chip_id() is not exported.
> >
> Apart from the above error, I have a concern on the patch, purely based on 
> the commit message.
> (to be honest, I am not familiar with the ppc architecture)
> 
> Commit message of 15863ff3b has the following text.
> 
> **
> So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
> was always default (-1) on ppc64 architecture.
> 
> Now, some systems have an ibm,chip-id property in the cpu nodes in
> the device tree. On these systems, we now use this information to
> display physical_package_id
> **
> 
> Shouldn't the new definition of "topology_physical_package_id" apply only to 
> those systems supporting ibm,chip-id property?

There should be no negative side effect (appart from the missing
EXPORT_SYMBOL of course). If the property is not found in the
device-tree, the new function returns -1, so it should work fine on all
systems.

Cheers,
Ben.

> 
> > Reverting this commit fixes the problem. Any good idea how to fix it 
> > for real ?
> >
> > Guenter
> > -- 
> > To unsubscribe from this list: send the line "unsubscribe 
> > linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [v3] powerpc/mpc85xx: Update the clock device tree nodes

2013-09-10 Thread Scott Wood
On Mon, 2013-08-26 at 21:49 -0500, Tang Yuantian-B29983 wrote:
> > > > > + };
> > > > > + pll1: pll1@820 {
> > > > > + #clock-cells = <1>;
> > > > > + reg = <0x820>;
> > > > > + compatible = "fsl,core-pll-clock";
> > > > > + clocks = <&clockgen>;
> > > > > + clock-output-names = "pll1", "pll1-div2", "pll1-
> > div4";
> > > > > + };
> > > >
> > > > Please leave a blank line between properties and nodes, and between
> > nodes.
> > > >
> > > OK, will add.
> > >
> > > > What does reg represent?  Where is the binding for this?
> > > >
> > > > The compatible is too vague.
> > > Reg is register offset.
> > 
> > With no size?
> 
> No size is needed.

Yes, it is.  Register blocks have size -- even if it's just a single
register.

> > > It is too later to change since the clock driver is merged for months
> > > although I sent this patch first.
> > 
> > It should not have gone in without an approved binding.  It seems it went
> > in via Mike Turquette (why is a non-ARM-specific tree using linux-arm-
> > kernel as its list, BTW?).  No ack from Ben, Kumar, or me is shown in the
> > commit.
> The Linux common clock framework is not ARM specific. Any other arch can use 
> it.

Sure, it just seemed an odd choice of mailing list for something that
isn't ARM-specific.

> > In any case, you can preserve compatibility with existing trees without
> > using this compatible in new trees.  The driver can check for both
> > compatibles, with a comment indicating that "fsl,core-mux-clock" is
> > deprecated and for compatibility only.
> It is sub-clock node, is it really necessary to think about compatibility?
> I think that's the node clockgen's responsibility.

It describes registers, so yes, you need to consider compatibility.  A
clock provider is not responsible for figuring out how to program
devices that consume its clocks, nor should it make any assumptions
about such devices.
 
> > > Besides, it is not too bad because other arch use the similar name.
> > 
> > I don't follow.  This is a specific Freescale register interface, not a
> > general concept.
> > 
> > In any case, which "similar names" are you referring to?  A search in
> > arch/arm/boot/dts for "mux" with "clk" or "clock" turns up
> > "allwinner,sun4i-apb1-mux-clk" which is much more specific than
> > "fsl,core-mux-clock".
> Ok, I will change the compatible string.
> Do you think "fsl,ppc-core-*" is ok?

No.  How about "fsl,qoriq-chassis1-*" (for e500mc/e5500) and
fsl,qoriq-chassis2-*" (for e6500)?

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/7] powerpc/mpc85xx: Fix EDAC address capture

2013-09-10 Thread Scott Wood
On Fri, 2013-09-06 at 08:43 -0700, York Sun wrote:
> Extend err_addr to cover 64 bits for DDR errors.
> 
> Signed-off-by: York Sun 
> Reviewed-by: Fleming Andrew-AFLEMING 
> Tested-by: Fleming Andrew-AFLEMING 
> ---
>  drivers/edac/mpc85xx_edac.c |   10 +++---
>  drivers/edac/mpc85xx_edac.h |1 +
>  2 files changed, 8 insertions(+), 3 deletions(-)

EDAC patches should go via the linux-edac list and maintainer.

BTW, were those "reviewed-by" and "tested-by" added by Andy manually, or
are they from gerrit?  If the latter, please strip them before sending
upstream.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/7] i2c/rtc-ds3232: Fix irq for probing

2013-09-10 Thread Scott Wood
On Fri, 2013-09-06 at 08:43 -0700, York Sun wrote:
> Driver shouldn't request irq when irq = 0. It is returned from parsing
> device tree. 0 means no interrupt.
> 
> Signed-off-by: York Sun 
> Reviewed-by: Zang Tiefei-R61911 
> Reviewed-by: Fleming Andrew-AFLEMING 
> Tested-by: Fleming Andrew-AFLEMING 
> ---
>  drivers/rtc/rtc-ds3232.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This should go via the i2c list and maintainer.  It's not a PPC patch at
all.

Please do not lump unrelated patches into a single patchset.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 7/7] powerpc/b4860emu: Add device tree file for b4860emu

2013-09-10 Thread Scott Wood
On Fri, 2013-09-06 at 08:43 -0700, York Sun wrote:
> B4860EMU is a emualtor target with minimum peripherals. It is based on
> B4860QDS and trimmed down most peripherals due to either not modeled or
> lack of board level connections. The main purpose of this minimum dts is
> to speed up booting on emulator.
> 
> Signed-off-by: York Sun 
> Reviewed-by: Wood Scott-B07421 
> Reviewed-by: Fleming Andrew-AFLEMING 
> Tested-by: Fleming Andrew-AFLEMING 

I did not give a reviewed-by in this context.  Please strip gerrit tags
before posting.

> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2";

It's "fsl,qoriq-clockgen-2.0" now.

Please be careful with copy-and-paste patches like this -- make sure
that it's up-to-date with what you copied from.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Power PC Build problem

2013-09-10 Thread Scott Wood
On Wed, 2013-09-04 at 13:07 +1000, Jason Rennie wrote:
> But when I try building it with the latest buildroot (2013.08) and I
> configure the kernel (3.10.10) I get one of two things. If I don't
> include specific settings for physmap compat support (Device Drivers
> -> MTD Support -> Mapping drivers for chip access) then I get a kernel
> panic when it can't mount the root filesystem as follows 
[snip]
> --- 
> and when I do include the physmap settings 
> 
> <*> Flash device in physical memory map 
>  [*]   Physmap compat support 
>   (0xFF00) Physical start address of flash mapping 
>   (0x100) Physical length of flash mapping 
>   (2) Bank width in octets 
> 
> which I took from the earlier build and do seem to be right, it does
> the following. 
>  
> f0011a00.serial: ttyCPM0 at MMIO 0xc505ea00 (irq = 40) is a CPM UART 
> f0011a60.serial: ttyCPM1 at MMIO 0xc5060a60 (irq = 43) is a CPM UART 
> brd: module loaded 
> physmap platform flash device: 0100 at ff00 
> Machine check in kernel mode. 
> Caused by (from SRR1=49030): Transfer error ack signal 
> Oops: Machine check, sig: 7 [#1] 
> PREEMPT Freescale MPC8272 ADS 
> Modules linked in: 
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.10 #12 
> task: c383 ti: c3832000 task.ti: c3832000 
> NIP: c01a5da8 LR: c01a6200 CTR: c01a60cc 
> REGS: c3833c00 TRAP: 0200   Not tainted  (3.10.10) 
> MSR: 00049030   CR: 2222  XER:  
> 
> GPR00: c01a59a0 c3833cb0 c383  c39c0e24 c3833cf8 0002
> 0aaa 
> GPR08: c508  0002 0002 4224  c000406c
>  
> GPR16:   c39c0e24 c02c9ff4 0001 c02c8d30 c02c9fe8
> c0356e23 
> GPR24: c02c8d78 0001  0001 c03b89d8  c39c0e24
> c3833cf8 
> NIP [c01a5da8] jedec_reset+0x124/0x448 
> LR [c01a6200] jedec_probe_chip+0x134/0x1050 
> Call Trace: 
> [c3833cb0] [c002d900] call_usermodehelper_exec+0x154/0x160
> (unreliable) 
> [c3833cf0] [c01a59a0] mtd_do_chip_probe+0x78/0x34c 
> [c3833d70] [c01a73a8] physmap_flash_probe+0x1ec/0x30c 
> [c3833db0] [c01996c8] driver_probe_device+0xb8/0x1f4 
> [c3833dd0] [c0197a64] bus_for_each_drv+0x60/0xa8 
> [c3833e00] [c01995d8] device_attach+0x7c/0x94 
> [c3833e20] [c0198ac4] bus_probe_device+0x34/0xac 
> [c3833e40] [c0196f94] device_add+0x3d4/0x570 
> [c3833e80] [c019acd0] platform_device_add+0x164/0x1dc 
> [c3833ea0] [c039a438] physmap_init+0x34/0x50 
> [c3833ec0] [c0003acc] do_one_initcall+0xdc/0x180 
> [c3833ef0] [c0386bcc] kernel_init_freeable+0x11c/0x1c0 
> [c3833f30] [c0004088] kernel_init+0x1c/0xf4 
> [c3833f40] [c000d3a8] ret_from_kernel_thread+0x5c/0x64 
> Instruction dump: 
> 5529063e 7d2839ae 4824 2f8a0002 40be0010 5529043e 7d283b2e
> 4810 
> 2f8a0004 409e0324 7d28392e 7c0004ac <81250008> 8105000c 81440018
> 7d6849d6 
> ---[ end trace 06e97f39189bf8ef ]--- 
> 
> Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0007 
> 
> Rebooting in 1 seconds.. 
>  
> I assume it is crashing when it tries to probe the flash chips? 
> 
> I'm at a loss to work out what I am doing wrong here. Can anybody
> offer any pointers? 

It sounds like the address you're specifying for flash is incorrect.
You shouldn't need to specify it this way; the information is in the
device tree (and for mpc8272ads the device tree says it's at
0xff80).

Do you have CONFIG_MTD_PHYSMAP_OF enabled?

BTW, I don't see how this is a "build problem".

-Scott




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

2013-09-10 Thread Guenter Roeck
On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
> > On 09/08/2013 5:28 PM, Guenter Roeck wrote:
> > > Hi all,
> > >
> > > powerpc allmodconfig build on the latest upstream kernel results in:
> > >
> > > ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
> > >
> > > This is due to commit 15863ff3b (powerpc: Make chip-id information 
> > > available to userspace).
> > > Not surprising, as cpu_to_chip_id() is not exported.
> > >
> > Apart from the above error, I have a concern on the patch, purely based on 
> > the commit message.
> > (to be honest, I am not familiar with the ppc architecture)
> > 
> > Commit message of 15863ff3b has the following text.
> > 
> > **
> > So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
> > was always default (-1) on ppc64 architecture.
> > 
> > Now, some systems have an ibm,chip-id property in the cpu nodes in
> > the device tree. On these systems, we now use this information to
> > display physical_package_id
> > **
> > 
> > Shouldn't the new definition of "topology_physical_package_id" apply only 
> > to those systems supporting ibm,chip-id property?
> 
> There should be no negative side effect (appart from the missing
> EXPORT_SYMBOL of course). If the property is not found in the
> device-tree, the new function returns -1, so it should work fine on all
> systems.
> 
Good. I submitted a patch doing just that yesterday or so.
Hope you'll accept it ;).

Thanks,
Guenter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property

2013-09-10 Thread Scott Wood
On Fri, 2013-09-06 at 16:05 +0800, Mingkai Hu wrote:
> Re-organize the SPI partitions and use the same SPI flash memory
> map for most of the platforms which have 16MB SPI flash mounted.
[snip]
> Based on 'next' branch on git tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
> 
>  arch/powerpc/boot/dts/bsc9131rdb.dtsi  | 35 -
>  arch/powerpc/boot/dts/c293pcie.dts | 35 -
>  arch/powerpc/boot/dts/mpc8536ds.dtsi   | 12 +-
>  arch/powerpc/boot/dts/p1010rdb.dtsi| 40 
> --
>  arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 24 +---
>  arch/powerpc/boot/dts/p1020rdb-pd.dts  | 34 -
>  arch/powerpc/boot/dts/p1020rdb.dtsi| 23 ---
>  arch/powerpc/boot/dts/p1021mds.dts | 17 +++
>  arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 32 +--
>  arch/powerpc/boot/dts/p1022ds.dtsi | 21 +-
>  arch/powerpc/boot/dts/p1023rds.dts | 10 ++---
>  arch/powerpc/boot/dts/p1024rdb.dtsi| 40 
> --
>  arch/powerpc/boot/dts/p1025rdb.dtsi| 23 +--
>  arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 40 
> --
>  arch/powerpc/boot/dts/p2020rdb.dts | 38 ++--
>  arch/powerpc/boot/dts/p2041rdb.dts | 12 +-
>  arch/powerpc/boot/dts/p3041ds.dts  | 12 +-
>  arch/powerpc/boot/dts/p4080ds.dts  | 12 +-
>  arch/powerpc/boot/dts/p5020ds.dts  | 12 +-
>  arch/powerpc/boot/dts/p5040ds.dts  | 13 ++-

What happens to exsting users whose flash is laid out the existing way,
when they upgrade to these device trees?

We really should not be putting partition layout info in the device tree
to begin with...

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/6] powerpc: Put FP/VSX and VR state into structures

2013-09-10 Thread Paul Mackerras
On Tue, Sep 10, 2013 at 12:07:46PM -0500, Alexander Graf wrote:
> 
> On 10.09.2013, at 05:20, Paul Mackerras wrote:
> > @@ -897,7 +897,7 @@ int fix_alignment(struct pt_regs *regs)
> > return -EFAULT;
> > }
> > } else if (flags & F) {
> > -   data.dd = current->thread.TS_FPR(reg);
> > +   data.ll = current->thread.TS_FPR(reg);
> 
> I don't understand this change. Could you please explain?

It's simply that the type which we use to store the FPR values is now
an unsigned integer type rather than a floating-point type.  If I
didn't make this change, the compiler would try to convert that
unsigned integer value into a floating-point value, which we don't
want.

> > --- a/arch/powerpc/kernel/tm.S
> > +++ b/arch/powerpc/kernel/tm.S
> > @@ -12,16 +12,15 @@
> > #include 
> > 
> > #ifdef CONFIG_VSX
> > -/* See fpu.S, this is very similar but to save/restore checkpointed 
> > FPRs/VSRs */
> > -#define __SAVE_32FPRS_VSRS_TRANSACT(n,c,base)  \
> > +/* See fpu.S, this is borrowed from there */
> > +#define __SAVE_32FPRS_VSRS(n,c,base)   \
> 
> Should this really be in tm.S with its new name?

Do you mean, could I merge it with __SAVE_32FPVSRS from fpu.S, put it
in ppc_asm.h and avoid having two very similar macros defined in
different places?  Yes I could, and that's a good idea.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/6] powerpc: Provide for giveup_fpu/altivec to save state in alternate location

2013-09-10 Thread Paul Mackerras
On Tue, Sep 10, 2013 at 12:12:47PM -0500, Alexander Graf wrote:
> 
> On 10.09.2013, at 05:21, Paul Mackerras wrote:
> 
> > @@ -212,6 +212,7 @@ struct thread_struct {
> > #endif
> > #endif
> > struct thread_fp_state  fp_state;
> > +   struct thread_fp_state  *fp_save_area;
> 
> Why do you need these pointers? Couldn't you handle everything you need 
> through preempt notifiers?

As you note in your review of a later patch, no, I need the pointer so
that if in-kernel code wants to use FP or VSX, potentially in the
context of this same process, it knows where to save the FP/VSX state
away to.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH][RFC][v2] pci: fsl: rework PCIe driver compatible with Layerscape

2013-09-10 Thread Scott Wood
On Wed, 2013-08-28 at 18:42 +0800, Minghuan Lian wrote:
> The Freescale's Layerscape series processors will use ARM cores.
> The LS1's PCIe controllers is the same as T4240's. So it's better
> the PCIe controller driver can support PowerPC and ARM
> simultaneously. This patch is for this purpose. It derives
> the common functions from arch/powerpc/sysdev/fsl_pci.c to
> drivers/pci/host/pcie-fsl.c and leaves several platform-dependent
> functions which should be implemented in platform files.
> 
> Signed-off-by: Minghuan Lian 
> ---
> Based on upstream master 3.11-rc7
> The function has been tested on MPC8315ERDB MPC8572DS P5020DS P3041DS
> and T4240QDS boards 
> 
> Change log:
> v2:
> 1. Use 'pci' instead of 'pcie' in new file name and file contents. 
> 2. Use iowrite32be()/iowrite32() instead of out_be32/le32()
> 3. Fix ppc_md.dma_set_mask setting
> 4. Synchronizes host->first_busno and pci->first_busno.
> 5. Fix PCI IO space settings
> 6. Some small changes according to Scott's comments.

Could you please split this into two patches, where one moves the code,
and the other makes changes to it?

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.

2013-09-10 Thread Scott Wood
On Thu, 2013-09-05 at 15:51 +1000, Stephen Chivers wrote:
> Add support for the Motorola/Emerson MVME5100 Single Board Computer.
> 
> The MVME5100 is a 6U form factor VME64 computer with:
> 
>   - A single MPC7410 or MPC750 CPU
>   - A HAWK Processor Host Bridge (CPU to PCI) and
> MultiProcessor Interrupt Controller (MPIC)
>   - Up to 500Mb of onboard memory
>   - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
>   - Two 16550 compatible UARTS
>   - Two Intel E100 Fast Ethernets
>   - Two PCI Mezzanine Card (PMC) Slots
>   - PPCBug Firmware
> 
> The HAWK PHB/MPIC is compatible with the MPC10x devices.
> 
> There is no onboard disk support. This is usually provided by
> installing a PMC in the first PMC slot.
> 
> This patch revives the board support, it was present in early 2.6
> series kernels. The board support in those days was by Matt Porter of
> MontaVista Software.
> 
> CSC Australia has around 31 of these boards in service. The kernel in use
> for the boards is based on 2.6.31. The boards are operated without disks
> from a file server. 
> 
> This patch is based on linux-3.11-rc7 and has been boot tested.
> 
> V1->V2:
>   Address comments by Kular Gama and Scott Wood.
>   Minor adjustment to platforms/embedded6xx/Kconfig to ensure
>   correct indentation where possible.
> 
> Signed-off-by: Stephen Chivers 
> ---

Some comments below, and please run checkpatch.pl, but the next version
can probably be non-RFC if you're happy with it.

> + PowerPC,7410 {
> + device_type = "cpu";
> + reg = <0x0>;
> + /* Following required by dtc but not used */
> + d-cache-line-size = <32>;
> + i-cache-line-size = <32>;
> + i-cache-size = <32768>;
> + d-cache-size = <32768>;
> + timebase-frequency = <2500>;
> + clock-frequency = <5>;
> +bus-frequency = <1>;
> + };

Whitespace on bus-frequency

> + mpic: interrupt-controller@f3f8 {
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
> + device_type = "open-pic";
> + compatible = "chrp,open-pic";
> + interrupt-controller;
> + reg = <0xf3f8 0x4>;
> + };
> +
> + };

No blank line before }

> +CONFIG_CMDLINE_BOOL=y
> +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"

I take it there's no way to pass a command line in from whatever loader
this board uses... but you could put it in the dts instead.

Did you ever figure out the problem with the combined defconfig?

> + help
> +  This option enables support for the Motorola (now Emerson) MVME5100
> +   board.

Whitespace

> +/* Board register addresses. */
> +#define  BOARD_STATUS_REG0xfef88080
> +#define  BOARD_MODFAIL_REG   0xfef88090
> +#define  BOARD_MODRST_REG0xfef880a0
> +#define  BOARD_TBEN_REG  0xfef880c0
> +#define BOARD_SW_READ_REG0xfef880e0
> +#define  BOARD_GEO_ADDR_REG  0xfef880e8
> +#define  BOARD_EXT_FEATURE1_REG  0xfef880f0
> +#define  BOARD_EXT_FEATURE2_REG  0xfef88100

Use a space rather than a tab after #define.

> +static unsigned int pci_membase;

phys_addr_t

> +static void mvme5100_restart(char *cmd)
> +{
> + u_char  *restart;

Is all that tabbing before "*restart" really necessary?

> + restart = ioremap(BOARD_MODRST_REG, 4);
> + local_irq_disable();
> + mtmsr(mfmsr() | MSR_IP);
> +
> + out_8((u_char *) restart, 0x01);

If ioremap() fails you'll panic here.

In any case, you should map things at boot time.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.

2013-09-10 Thread Stephen N Chivers
Scott Wood  wrote on 09/11/2013 09:47:27 AM:

> From: Scott Wood 
> To: Stephen N Chivers/AUS/CSC@CSC
> Cc: Chris Proctor/AUS/CSC@CSC, , 
> , 
> Date: 09/11/2013 09:47 AM
> Subject: Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for
> Motorola/Emerson MVME5100.
> 
> On Thu, 2013-09-05 at 15:51 +1000, Stephen Chivers wrote:
> > Add support for the Motorola/Emerson MVME5100 Single Board Computer.
> > 
> > The MVME5100 is a 6U form factor VME64 computer with:
> > 
> >- A single MPC7410 or MPC750 CPU
> >- A HAWK Processor Host Bridge (CPU to PCI) and
> >  MultiProcessor Interrupt Controller (MPIC)
> >- Up to 500Mb of onboard memory
> >- A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> >- Two 16550 compatible UARTS
> >- Two Intel E100 Fast Ethernets
> >- Two PCI Mezzanine Card (PMC) Slots
> >- PPCBug Firmware
> > 
> > The HAWK PHB/MPIC is compatible with the MPC10x devices.
> > 
> > There is no onboard disk support. This is usually provided by
> > installing a PMC in the first PMC slot.
> > 
> > This patch revives the board support, it was present in early 2.6
> > series kernels. The board support in those days was by Matt Porter of
> > MontaVista Software.
> > 
> > CSC Australia has around 31 of these boards in service. The kernel in 
use
> > for the boards is based on 2.6.31. The boards are operated without 
disks
> > from a file server. 
> > 
> > This patch is based on linux-3.11-rc7 and has been boot tested.
> > 
> > V1->V2:
> >Address comments by Kular Gama and Scott Wood.
> >Minor adjustment to platforms/embedded6xx/Kconfig to ensure
> >   correct indentation where possible.
> > 
> > Signed-off-by: Stephen Chivers 
> > ---
> 
> Some comments below, and please run checkpatch.pl, but the next version
> can probably be non-RFC if you're happy with it.
Ok.
> 
> > +  PowerPC,7410 {
> > + device_type = "cpu";
> > + reg = <0x0>;
> > + /* Following required by dtc but not used */
> > + d-cache-line-size = <32>;
> > + i-cache-line-size = <32>;
> > + i-cache-size = <32768>;
> > + d-cache-size = <32768>;
> > + timebase-frequency = <2500>;
> > + clock-frequency = <5>;
> > +bus-frequency = <1>;
> > +  };
> 
> Whitespace on bus-frequency
Ok. Will fix.
> 
> > +  mpic: interrupt-controller@f3f8 {
> > + #interrupt-cells = <2>;
> > + #address-cells = <0>;
> > + device_type = "open-pic";
> > + compatible = "chrp,open-pic";
> > + interrupt-controller;
> > + reg = <0xf3f8 0x4>;
> > +  };
> > +
> > +   };
> 
> No blank line before }
Ok. Will be fixed.
> 
> > +CONFIG_CMDLINE_BOOL=y
> > +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
> 
> I take it there's no way to pass a command line in from whatever loader
> this board uses... but you could put it in the dts instead.
>
It can be done by reading the NVRAM/RTC (M48T37) and "overriding" the
DTS specification. But I wanted to keep things simple to start
with.

Putting the default command line in the DTS is required to support
a combined "defconfig" (pp6xx_defconfig) and I know it does work.
So I will do that.

> Did you ever figure out the problem with the combined defconfig?
Not really. But I have been forced to think about that as a new
project will be using some PMCs with 8250 UARTS (PCI) and they are
another way that the console moves from the debug port on the front
panel to somewhere else.

It is very likely that the HAWK UARTS will have to be registered as
platform devices by the board support file itself.

> 
> > +   help
> > +  This option enables support for the Motorola (now 
> Emerson) MVME5100
> > + board.
> 
> Whitespace
Ok.
> 
> > +/* Board register addresses. */
> > +#define   BOARD_STATUS_REG   0xfef88080
> > +#define   BOARD_MODFAIL_REG   0xfef88090
> > +#define   BOARD_MODRST_REG   0xfef880a0
> > +#define   BOARD_TBEN_REG  0xfef880c0
> > +#define BOARD_SW_READ_REG   0xfef880e0
> > +#define   BOARD_GEO_ADDR_REG   0xfef880e8
> > +#define   BOARD_EXT_FEATURE1_REG   0xfef880f0
> > +#define   BOARD_EXT_FEATURE2_REG   0xfef88100
> 
> Use a space rather than a tab after #define.
Ok.
> 
> > +static unsigned int pci_membase;
> 
> phys_addr_t
Ok.
> 
> > +static void mvme5100_restart(char *cmd)
> > +{
> > +   u_char *restart;
> 
> Is all that tabbing before "*restart" really necessary?
Will fix.
> 
> > +   restart = ioremap(BOARD_MODRST_REG, 4);
> > +   local_irq_disable();
> > +   mtmsr(mfmsr() | MSR_IP);
> > +
> > +   out_8((u_char *) restart, 0x01);
> 
> If ioremap() fails you'll panic here.
Ok. Will do in mvme5100_setup_arch.
> 
> In any case, you should map things at boot time.
> 
> -Scott
Thanks,
Stephen.
> 
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH v2 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.

2013-09-10 Thread Benjamin Herrenschmidt
On Tue, 2013-09-10 at 18:47 -0500, Scott Wood wrote:

> No blank line before }
> 
> > +CONFIG_CMDLINE_BOOL=y
> > +CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
> 
> I take it there's no way to pass a command line in from whatever loader
> this board uses... but you could put it in the dts instead.

No, please don't put that in the device-tree. Somebody might want
different settings, this is typically what .config is for.

> Did you ever figure out the problem with the combined defconfig?
> 
> > +   help
> > +  This option enables support for the Motorola (now Emerson) 
> > MVME5100
> > + board.
> 
> Whitespace
> 
> > +/* Board register addresses. */
> > +#defineBOARD_STATUS_REG0xfef88080
> > +#defineBOARD_MODFAIL_REG   0xfef88090
> > +#defineBOARD_MODRST_REG0xfef880a0
> > +#defineBOARD_TBEN_REG  0xfef880c0
> > +#define BOARD_SW_READ_REG  0xfef880e0
> > +#defineBOARD_GEO_ADDR_REG  0xfef880e8
> > +#defineBOARD_EXT_FEATURE1_REG  0xfef880f0
> > +#defineBOARD_EXT_FEATURE2_REG  0xfef88100
> 
> Use a space rather than a tab after #define.
> 
> > +static unsigned int pci_membase;
> 
> phys_addr_t
> 
> > +static void mvme5100_restart(char *cmd)
> > +{
> > +   u_char  *restart;
> 
> Is all that tabbing before "*restart" really necessary?
> 
> > +   restart = ioremap(BOARD_MODRST_REG, 4);
> > +   local_irq_disable();
> > +   mtmsr(mfmsr() | MSR_IP);
> > +
> > +   out_8((u_char *) restart, 0x01);
> 
> If ioremap() fails you'll panic here.
> 
> In any case, you should map things at boot time.
> 
> -Scott
> 
> 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property

2013-09-10 Thread Hu Mingkai-B21284


> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 11, 2013 7:33 AM
> To: Hu Mingkai-B21284
> Cc: linuxppc-...@ozlabs.org
> Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions
> property
> 
> On Fri, 2013-09-06 at 16:05 +0800, Mingkai Hu wrote:
> > Re-organize the SPI partitions and use the same SPI flash memory map
> > for most of the platforms which have 16MB SPI flash mounted.
> [snip]
> > Based on 'next' branch on git tree:
> > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
> >
> >  arch/powerpc/boot/dts/bsc9131rdb.dtsi  | 35 --
> ---
> >  arch/powerpc/boot/dts/c293pcie.dts | 35 --
> ---
> >  arch/powerpc/boot/dts/mpc8536ds.dtsi   | 12 +-
> >  arch/powerpc/boot/dts/p1010rdb.dtsi| 40 --
> 
> >  arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 24 +---
> > arch/powerpc/boot/dts/p1020rdb-pd.dts  | 34 ---
> --
> >  arch/powerpc/boot/dts/p1020rdb.dtsi| 23 ---
> >  arch/powerpc/boot/dts/p1021mds.dts | 17 +++
> >  arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 32 +-
> -
> >  arch/powerpc/boot/dts/p1022ds.dtsi | 21 +-
> >  arch/powerpc/boot/dts/p1023rds.dts | 10 ++---
> >  arch/powerpc/boot/dts/p1024rdb.dtsi| 40 --
> 
> >  arch/powerpc/boot/dts/p1025rdb.dtsi| 23 +--
> >  arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 40 --
> 
> >  arch/powerpc/boot/dts/p2020rdb.dts | 38 ++
> --
> >  arch/powerpc/boot/dts/p2041rdb.dts | 12 +-
> >  arch/powerpc/boot/dts/p3041ds.dts  | 12 +-
> >  arch/powerpc/boot/dts/p4080ds.dts  | 12 +-
> >  arch/powerpc/boot/dts/p5020ds.dts  | 12 +-
> >  arch/powerpc/boot/dts/p5040ds.dts  | 13 ++-
> 
> What happens to exsting users whose flash is laid out the existing way,
> when they upgrade to these device trees?
> 

The SPI flash layout should be mapping the new device tree.

If the existing device tree is used to deploy the SPI flash, the following 
issues
must be run into as the commit message described:

1. Kernel images would be overlapped with U-Boot image.
2. Kernel images would be overlapped with FMAN ucode.
3. Saving environment variables will crash the kernel image.

> We really should not be putting partition layout info in the device tree
> to begin with...
> 
OK, I will remove the layout diagram in the commit message.

Thanks,
Mingkai
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V3 1/6] powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC)

2013-09-10 Thread Preeti U Murthy
From: Srivatsa S. Bhat 

The IPI handlers for both PPC_MSG_CALL_FUNC and PPC_MSG_CALL_FUNC_SINGLE map to
a common implementation - generic_smp_call_function_single_interrupt(). So, we
can consolidate them and save one of the IPI message slots, (which are precious,
since only 4 of those slots are available).

So, implement the functionality of PPC_MSG_CALL_FUNC using
PPC_MSG_CALL_FUNC_SINGLE itself and release its IPI message slot, so that it
can be used for something else in the future, if desired.

Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Preeti U Murthy 
---

 arch/powerpc/include/asm/smp.h  |2 +-
 arch/powerpc/kernel/smp.c   |   12 +---
 arch/powerpc/platforms/cell/interrupt.c |2 +-
 arch/powerpc/platforms/ps3/smp.c|2 +-
 4 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 48cfc85..a632b6e 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -117,7 +117,7 @@ extern int cpu_to_core_id(int cpu);
  *
  * Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
  * in /proc/interrupts will be wrong!!! --Troy */
-#define PPC_MSG_CALL_FUNCTION   0
+#define PPC_MSG_UNUSED 0
 #define PPC_MSG_RESCHEDULE  1
 #define PPC_MSG_CALL_FUNC_SINGLE   2
 #define PPC_MSG_DEBUGGER_BREAK  3
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..bc41e9f 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -111,9 +111,9 @@ int smp_generic_kick_cpu(int nr)
 }
 #endif /* CONFIG_PPC64 */
 
-static irqreturn_t call_function_action(int irq, void *data)
+static irqreturn_t unused_action(int irq, void *data)
 {
-   generic_smp_call_function_interrupt();
+   /* This slot is unused and hence available for use, if needed */
return IRQ_HANDLED;
 }
 
@@ -144,14 +144,14 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
 }
 
 static irq_handler_t smp_ipi_action[] = {
-   [PPC_MSG_CALL_FUNCTION] =  call_function_action,
+   [PPC_MSG_UNUSED] =  unused_action, /* Slot available for future use */
[PPC_MSG_RESCHEDULE] = reschedule_action,
[PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
 };
 
 const char *smp_ipi_name[] = {
-   [PPC_MSG_CALL_FUNCTION] =  "ipi call function",
+   [PPC_MSG_UNUSED] =  "ipi unused",
[PPC_MSG_RESCHEDULE] = "ipi reschedule",
[PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
[PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
@@ -221,8 +221,6 @@ irqreturn_t smp_ipi_demux(void)
all = xchg(&info->messages, 0);
 
 #ifdef __BIG_ENDIAN
-   if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNCTION)))
-   generic_smp_call_function_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
@@ -265,7 +263,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
unsigned int cpu;
 
for_each_cpu(cpu, mask)
-   do_message_pass(cpu, PPC_MSG_CALL_FUNCTION);
+   do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
 }
 
 #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
diff --git a/arch/powerpc/platforms/cell/interrupt.c 
b/arch/powerpc/platforms/cell/interrupt.c
index 2d42f3b..28166e4 100644
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -213,7 +213,7 @@ static void iic_request_ipi(int msg)
 
 void iic_request_IPIs(void)
 {
-   iic_request_ipi(PPC_MSG_CALL_FUNCTION);
+   iic_request_ipi(PPC_MSG_UNUSED);
iic_request_ipi(PPC_MSG_RESCHEDULE);
iic_request_ipi(PPC_MSG_CALL_FUNC_SINGLE);
iic_request_ipi(PPC_MSG_DEBUGGER_BREAK);
diff --git a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
index 4b35166..488f069 100644
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -74,7 +74,7 @@ static int __init ps3_smp_probe(void)
* to index needs to be setup.
*/
 
-   BUILD_BUG_ON(PPC_MSG_CALL_FUNCTION!= 0);
+   BUILD_BUG_ON(PPC_MSG_UNUSED   != 0);
BUILD_BUG_ON(PPC_MSG_RESCHEDULE   != 1);
BUILD_BUG_ON(PPC_MSG_CALL_FUNC_SINGLE != 2);
BUILD_BUG_ON(PPC_MSG_DEBUGGER_BREAK   != 3);

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V3 0/6] cpuidle/ppc: Enable broadcast support for deep idle states

2013-09-10 Thread Preeti U Murthy
On PowerPC, when CPUs enter deep idle states, their local timers get
switched off. An external clock device needs to programmed to wake them
up at their next timer event.
On PowerPC, we do not have an external device equivalent to HPET,
which is currently used on architectures like x86 under the same scenario.
Instead we assign the local timer of one of the CPUs to do this job.

This patchset is an attempt to hook onto the existing timer broadcast
framework in the kernel by using the local timer of one of the CPUs to do the
job of the external clock device.

On expiry of this device, the broadcast framework today has the infrastructure
to send ipis to all such CPUs whose local timers have expired. Hence the term
"broadcast" and the ipi sent is called the broadcast ipi.

This patch series is ported ontop of 3.11-rc7 + the cpuidle driver backend
for power posted by Deepthi Dharwar recently.
http://comments.gmane.org/gmane.linux.ports.ppc.embedded/63556

Changes in V3:

1. Fix the way in which a broadcast ipi is handled on the idling cpus. Timer
handling on a broadcast ipi is being done now without missing out any timer
stats generation.

2. Fix a bug in the programming of the hrtimer meant to do broadcast. Program
it to trigger at the earlier of a "broadcast period", and the next wakeup
event. By introducing the "broadcast period" as the maximum period after
which the broadcast hrtimer can fire, we ensure that we do not miss
wakeups in corner cases.

3. On hotplug of a broadcast cpu, trigger the hrtimer meant to do broadcast
to fire immediately on the new broadcast cpu. This will ensure we do not miss
doing a broadcast pending in the nearest future.

4. Change the type of allocation from GFP_KERNEL to GFP_NOWAIT while
initializing bc_hrtimer since we are in an atomic context and cannot sleep.

5. Use the broadcast ipi to wakeup the newly nominated broadcast cpu on
hotplug of the old instead of smp_call_function_single(). This is because we
are interrupt disabled at this point and should not be using
smp_call_function_single or its children in this context to send an ipi.

6. Move GENERIC_CLOCKEVENTS_BROADCAST to arch/powerpc/Kconfig.

7. Fix coding style issues.

Changes in V2: https://lkml.org/lkml/2013/8/14/239

1. Dynamically pick a broadcast CPU, instead of having a dedicated one.
2. Remove the constraint of having to disable tickless idle on the broadcast
CPU by queueing a hrtimer dedicated to do broadcast.

V1 posting: https://lkml.org/lkml/2013/7/25/740.

The patchset has been tested for stability in idle and during multi threaded
ebizzy runs.

Many thanks to Ben H, Frederic Weisbecker, Li Yang, Srivatsa S. Bhat and
Vaidyanathan Srinivasan for all their comments and suggestions so far.

---

Preeti U Murthy (4):
  cpuidle/ppc: Split timer_interrupt() into timer handling and interrupt 
handling routines
  cpuidle/ppc: Add basic infrastructure to support the broadcast framework 
on ppc
  cpuidle/ppc: Introduce the deep idle state in which the local timers stop
  cpuidle/ppc: Nominate new broadcast cpu on hotplug of the old

Srivatsa S. Bhat (2):
  powerpc: Free up the IPI message slot of ipi call function 
(PPC_MSG_CALL_FUNC)
  powerpc: Implement broadcast timer interrupt as an IPI message


 arch/powerpc/Kconfig|1 
 arch/powerpc/include/asm/smp.h  |3 -
 arch/powerpc/include/asm/time.h |4 +
 arch/powerpc/kernel/smp.c   |   23 +++-
 arch/powerpc/kernel/time.c  |  143 --
 arch/powerpc/platforms/cell/interrupt.c |2 
 arch/powerpc/platforms/ps3/smp.c|2 
 drivers/cpuidle/cpuidle-ibm-power.c |  172 +++
 scripts/kconfig/streamline_config.pl|0 
 9 files changed, 307 insertions(+), 43 deletions(-)
 mode change 100644 => 100755 scripts/kconfig/streamline_config.pl

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V3 3/6] cpuidle/ppc: Split timer_interrupt() into timer handling and interrupt handling routines

2013-09-10 Thread Preeti U Murthy
On PowerPC, when CPUs enter deep idle states, their local timers get
switched off. The local timer is called the decrementer. An external clock
device needs to programmed to wake them up at their next timer event.
On PowerPC, we do not have an external device equivalent to HPET,
which is currently used on architectures like x86 under the same scenario.
Instead we assign the local timer of one of the CPUs to do this job.

On expiry of this timer, the broadcast framework today has the infrastructure
to send ipis to all such CPUs whose local timers have expired.

When such an ipi is received, the cpus in deep idle should handle their
expired timers. It should be as though they were woken up from a
timer interrupt itself. Hence this external ipi serves as an emulated timer
interrupt for the cpus in deep idle.

Therefore ideally on ppc, these cpus should call timer_interrupt() which
is the interrupt handler for a decrementer interrupt. But timer_interrupt()
also contains routines which are usually performed in an interrupt handler.
These are not required to be done in this scenario as the external interrupt
handler takes care of them.

Therefore split up timer_interrupt() into routines performed during regular
interrupt handling and __timer_interrupt(), which takes care of running local
timers and collecting time related stats. Now on a broadcast ipi, call
__timer_interrupt().

Signed-off-by: Preeti U Murthy 
---

 arch/powerpc/kernel/time.c |   69 
 1 file changed, 37 insertions(+), 32 deletions(-)

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 0dfa0c5..eb48291 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -478,6 +478,42 @@ void arch_irq_work_raise(void)
 
 #endif /* CONFIG_IRQ_WORK */
 
+static void __timer_interrupt(void)
+{
+   struct pt_regs *regs = get_irq_regs();
+   u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
+   struct clock_event_device *evt = &__get_cpu_var(decrementers);
+   u64 now;
+
+   __get_cpu_var(irq_stat).timer_irqs++;
+   trace_timer_interrupt_entry(regs);
+
+   if (test_irq_work_pending()) {
+   clear_irq_work_pending();
+   irq_work_run();
+   }
+
+   now = get_tb_or_rtc();
+   if (now >= *next_tb) {
+   *next_tb = ~(u64)0;
+   if (evt->event_handler)
+   evt->event_handler(evt);
+   } else {
+   now = *next_tb - now;
+   if (now <= DECREMENTER_MAX)
+   set_dec((int)now);
+   }
+
+#ifdef CONFIG_PPC64
+   /* collect purr register values often, for accurate calculations */
+   if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+   struct cpu_usage *cu = &__get_cpu_var(cpu_usage_array);
+   cu->current_tb = mfspr(SPRN_PURR);
+   }
+#endif
+   trace_timer_interrupt_exit(regs);
+}
+
 /*
  * timer_interrupt - gets called when the decrementer overflows,
  * with interrupts disabled.
@@ -486,8 +522,6 @@ void timer_interrupt(struct pt_regs * regs)
 {
struct pt_regs *old_regs;
u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
-   struct clock_event_device *evt = &__get_cpu_var(decrementers);
-   u64 now;
 
/* Ensure a positive value is written to the decrementer, or else
 * some CPUs will continue to take decrementer exceptions.
@@ -510,8 +544,6 @@ void timer_interrupt(struct pt_regs * regs)
 */
may_hard_irq_enable();
 
-   __get_cpu_var(irq_stat).timer_irqs++;
-
 #if defined(CONFIG_PPC32) && defined(CONFIG_PMAC)
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
@@ -520,34 +552,7 @@ void timer_interrupt(struct pt_regs * regs)
old_regs = set_irq_regs(regs);
irq_enter();
 
-   trace_timer_interrupt_entry(regs);
-
-   if (test_irq_work_pending()) {
-   clear_irq_work_pending();
-   irq_work_run();
-   }
-
-   now = get_tb_or_rtc();
-   if (now >= *next_tb) {
-   *next_tb = ~(u64)0;
-   if (evt->event_handler)
-   evt->event_handler(evt);
-   } else {
-   now = *next_tb - now;
-   if (now <= DECREMENTER_MAX)
-   set_dec((int)now);
-   }
-
-#ifdef CONFIG_PPC64
-   /* collect purr register values often, for accurate calculations */
-   if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
-   struct cpu_usage *cu = &__get_cpu_var(cpu_usage_array);
-   cu->current_tb = mfspr(SPRN_PURR);
-   }
-#endif
-
-   trace_timer_interrupt_exit(regs);
-
+   __timer_interrupt();
irq_exit();
set_irq_regs(old_regs);
 }

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V3 2/6] powerpc: Implement broadcast timer interrupt as an IPI message

2013-09-10 Thread Preeti U Murthy
From: Srivatsa S. Bhat 

For scalability and performance reasons, we want the broadcast IPIs
to be handled as efficiently as possible. Fixed IPI messages
are one of the most efficient mechanisms available - they are faster
than the smp_call_function mechanism because the IPI handlers are fixed
and hence they don't involve costly operations such as adding IPI handlers
to the target CPU's function queue, acquiring locks for synchronization etc.

Luckily we have an unused IPI message slot, so use that to implement
broadcast timer interrupts efficiently.

Signed-off-by: Srivatsa S. Bhat 
[Changelog modified by pre...@linux.vnet.ibm.com]
Signed-off-by: Preeti U Murthy 
---

 arch/powerpc/include/asm/smp.h  |3 ++-
 arch/powerpc/include/asm/time.h |1 +
 arch/powerpc/kernel/smp.c   |   19 +++
 arch/powerpc/kernel/time.c  |4 
 arch/powerpc/platforms/cell/interrupt.c |2 +-
 arch/powerpc/platforms/ps3/smp.c|2 +-
 scripts/kconfig/streamline_config.pl|0 
 7 files changed, 24 insertions(+), 7 deletions(-)
 mode change 100644 => 100755 scripts/kconfig/streamline_config.pl

diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index a632b6e..22f6d63 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -117,7 +117,7 @@ extern int cpu_to_core_id(int cpu);
  *
  * Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
  * in /proc/interrupts will be wrong!!! --Troy */
-#define PPC_MSG_UNUSED 0
+#define PPC_MSG_TIMER  0
 #define PPC_MSG_RESCHEDULE  1
 #define PPC_MSG_CALL_FUNC_SINGLE   2
 #define PPC_MSG_DEBUGGER_BREAK  3
@@ -194,6 +194,7 @@ extern struct smp_ops_t *smp_ops;
 
 extern void arch_send_call_function_single_ipi(int cpu);
 extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
+extern void arch_send_tick_broadcast(const struct cpumask *mask);
 
 /* Definitions relative to the secondary CPU spin loop
  * and entry point. Not all of them exist on both 32 and
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index c1f2676..4e35282 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -28,6 +28,7 @@ extern struct clock_event_device decrementer_clockevent;
 struct rtc_time;
 extern void to_tm(int tim, struct rtc_time * tm);
 extern void GregorianDay(struct rtc_time *tm);
+extern void decrementer_timer_interrupt(void);
 
 extern void generic_calibrate_decr(void);
 
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index bc41e9f..d3b7014 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,9 +112,9 @@ int smp_generic_kick_cpu(int nr)
 }
 #endif /* CONFIG_PPC64 */
 
-static irqreturn_t unused_action(int irq, void *data)
+static irqreturn_t timer_action(int irq, void *data)
 {
-   /* This slot is unused and hence available for use, if needed */
+   decrementer_timer_interrupt();
return IRQ_HANDLED;
 }
 
@@ -144,14 +145,14 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
 }
 
 static irq_handler_t smp_ipi_action[] = {
-   [PPC_MSG_UNUSED] =  unused_action, /* Slot available for future use */
+   [PPC_MSG_TIMER] =  timer_action,
[PPC_MSG_RESCHEDULE] = reschedule_action,
[PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
 };
 
 const char *smp_ipi_name[] = {
-   [PPC_MSG_UNUSED] =  "ipi unused",
+   [PPC_MSG_TIMER] =  "ipi timer",
[PPC_MSG_RESCHEDULE] = "ipi reschedule",
[PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
[PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
@@ -221,6 +222,8 @@ irqreturn_t smp_ipi_demux(void)
all = xchg(&info->messages, 0);
 
 #ifdef __BIG_ENDIAN
+   if (all & (1 << (24 - 8 * PPC_MSG_TIMER)))
+   decrementer_timer_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
@@ -266,6 +269,14 @@ void arch_send_call_function_ipi_mask(const struct cpumask 
*mask)
do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
 }
 
+void arch_send_tick_broadcast(const struct cpumask *mask)
+{
+   unsigned int cpu;
+
+   for_each_cpu(cpu, mask)
+   do_message_pass(cpu, PPC_MSG_TIMER);
+}
+
 #if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
 void smp_send_debugger_break(void)
 {
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 65ab9e9..0dfa0c5 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -813,6 +813,10 @@ static void decrementer_set_mode(enum clock_event_mode 
mode,
decrementer_set_next_event

[PATCH V3 4/6] cpuidle/ppc: Add basic infrastructure to support the broadcast framework on ppc

2013-09-10 Thread Preeti U Murthy
The broadcast framework in the kernel expects an external clock device which 
will
continue functioning in deep idle states also. This ability is specified by
the "non-existence" of the feature C3STOP . This is the device that it relies
upon to wakup cpus in deep idle states whose local timers/clock devices get
switched off in deep idle states.

On ppc we do not have such an external device. Therefore we introduce a
pseudo clock device, which has the features of this external clock device
called the broadcast_clockevent. Having such a device qualifies the cpus to
enter and exit deep idle states from the point of view of the broadcast
framework, because there is an external device to wake them up.
Specifically the broadcast framework uses this device's event
handler and next_event members in its functioning. On ppc we use this
device as the gateway into the broadcast framework and *not* as a
timer. An explicit timer infrastructure will be developed in the following
patches to keep track of when to wake up cpus in deep idle.

Since this device is a pseudo device, it can be safely assumed to work for
all cpus. Therefore its cpumask is set to cpu_possible_mask. Also due to the
same reason, the set_next_event() routine associated with this device is a
nop.

The broadcast framework relies on a broadcast functionality being made
available in the .broadcast member of the local clock devices on all cpus.
This function is called upon by the broadcast framework on one of the nominated
cpus, to send ipis to all the cpus in deep idle at their expired timer events.
This patch also initializes the .broadcast member of the decrementer whose
job is to send the broadcast ipis.

When cpus inform the broadcast framework that they are entering deep idle,
their local timers are put in shutdown mode. On ppc, this means setting the
decrementer_next_tb and programming the decrementer to DECREMENTER_MAX.
On being woken up by the broadcast ipi, these cpus call __timer_interrupt(),
which runs the local timers only if decrementer_next_tb has expired.
  Therefore on being woken up from the broadcast ipi, set the 
decrementers_next_tb
to now before calling __timer_interrupt().

Signed-off-by: Preeti U Murthy 
---

 arch/powerpc/Kconfig|1 +
 arch/powerpc/include/asm/time.h |1 +
 arch/powerpc/kernel/time.c  |   69 ++-
 3 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index dbd9d3c..550fc04 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -130,6 +130,7 @@ config PPC
select GENERIC_CMOS_UPDATE
select GENERIC_TIME_VSYSCALL_OLD
select GENERIC_CLOCKEVENTS
+   select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select HAVE_MOD_ARCH_SPECIFIC
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 4e35282..264dc96 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -24,6 +24,7 @@ extern unsigned long tb_ticks_per_jiffy;
 extern unsigned long tb_ticks_per_usec;
 extern unsigned long tb_ticks_per_sec;
 extern struct clock_event_device decrementer_clockevent;
+extern struct clock_event_device broadcast_clockevent;
 
 struct rtc_time;
 extern void to_tm(int tim, struct rtc_time * tm);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index eb48291..bda78bb 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -97,8 +98,13 @@ static struct clocksource clocksource_timebase = {
 
 static int decrementer_set_next_event(unsigned long evt,
  struct clock_event_device *dev);
+static int broadcast_set_next_event(unsigned long evt,
+ struct clock_event_device *dev);
+static void broadcast_set_mode(enum clock_event_mode mode,
+struct clock_event_device *dev);
 static void decrementer_set_mode(enum clock_event_mode mode,
 struct clock_event_device *dev);
+static void decrementer_timer_broadcast(const struct cpumask *mask);
 
 struct clock_event_device decrementer_clockevent = {
.name   = "decrementer",
@@ -106,12 +112,24 @@ struct clock_event_device decrementer_clockevent = {
.irq= 0,
.set_next_event = decrementer_set_next_event,
.set_mode   = decrementer_set_mode,
-   .features   = CLOCK_EVT_FEAT_ONESHOT,
+   .broadcast  = decrementer_timer_broadcast,
+   .features   = CLOCK_EVT_FEAT_C3STOP | CLOCK_EVT_FEAT_ONESHOT,
 };
 EXPORT_SYMBOL(decrementer_clockevent);
 
+struct clock_event_device broadcast_clockevent = {
+   .name   = "broadcast",
+   .rating = 200,
+   .irq= 0,
+   .

[PATCH V3 6/6] cpuidle/ppc: Nominate new broadcast cpu on hotplug of the old

2013-09-10 Thread Preeti U Murthy
On hotplug of the broadcast cpu, cancel the hrtimer queued to do
broadcast and nominate a new broadcast cpu to be the first cpu in the
broadcast mask which includes all the cpus that have notified the broadcast
framework about entering deep idle state.

Since the new broadcast cpu is one of the cpus in deep idle, send an ipi to
wake it up to continue the duty of broadcast. The new broadcast cpu needs to
find out if it woke up to resume broadcast. If so it needs to restart the
broadcast hrtimer on itself.

Its possible that the old broadcast cpu was hotplugged out when the broadcast
hrtimer was about to fire on it. Therefore the newly nominated broadcast cpu
should set the broadcast hrtimer on itself to expire immediately so as to not
miss wakeups under such scenarios.

Signed-off-by: Preeti U Murthy 
---

 arch/powerpc/include/asm/time.h |1 +
 arch/powerpc/kernel/time.c  |1 +
 drivers/cpuidle/cpuidle-ibm-power.c |   22 ++
 3 files changed, 24 insertions(+)

diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 38341fa..3bc0205 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -31,6 +31,7 @@ struct rtc_time;
 extern void to_tm(int tim, struct rtc_time * tm);
 extern void GregorianDay(struct rtc_time *tm);
 extern void decrementer_timer_interrupt(void);
+extern void broadcast_irq_entry(void);
 
 extern void generic_calibrate_decr(void);
 
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 44a76de..0ac2e11 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -853,6 +853,7 @@ void decrementer_timer_interrupt(void)
 {
u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
 
+   broadcast_irq_entry();
*next_tb = get_tb_or_rtc();
__timer_interrupt();
 }
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c 
b/drivers/cpuidle/cpuidle-ibm-power.c
index ae47a0a..580ea04 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -282,6 +282,12 @@ static int longnap_loop(struct cpuidle_device *dev,
return index;
 }
 
+void broadcast_irq_entry(void)
+{
+   if (smp_processor_id() == bc_cpu)
+   hrtimer_start(bc_hrtimer, ns_to_ktime(0), 
HRTIMER_MODE_REL_PINNED);
+}
+
 /*
  * States for dedicated partition case.
  */
@@ -360,6 +366,7 @@ static int power_cpuidle_add_cpu_notifier(struct 
notifier_block *n,
unsigned long action, void *hcpu)
 {
int hotcpu = (unsigned long)hcpu;
+   unsigned long flags;
struct cpuidle_device *dev =
per_cpu(cpuidle_devices, hotcpu);
 
@@ -372,6 +379,21 @@ static int power_cpuidle_add_cpu_notifier(struct 
notifier_block *n,
cpuidle_resume_and_unlock();
break;
 
+   case CPU_DYING:
+   case CPU_DYING_FROZEN:
+   spin_lock_irqsave(&longnap_idle_lock, flags);
+   if (hotcpu == bc_cpu) {
+   bc_cpu = -1;
+   hrtimer_cancel(bc_hrtimer);
+   if 
(!cpumask_empty(tick_get_broadcast_oneshot_mask())) {
+   bc_cpu = cpumask_first(
+   
tick_get_broadcast_oneshot_mask());
+   
arch_send_tick_broadcast(cpumask_of(bc_cpu));
+   }
+   }
+   spin_unlock_irqrestore(&longnap_idle_lock, flags);
+   break;
+
case CPU_DEAD:
case CPU_DEAD_FROZEN:
cpuidle_pause_and_lock();

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V3 5/6] cpuidle/ppc: Introduce the deep idle state in which the local timers stop

2013-09-10 Thread Preeti U Murthy
Now that we have the basic infrastructure setup to make use of the broadcast
framework, introduce the deep idle state in which cpus need to avail the
functionality provided by this infrastructure to wake them up at their
expired timer events. On ppc this deep idle state is called sleep.
In this patch however, we introduce longnap, which emulates sleep
state, by disabling timer interrupts. This is until such time that sleep 
support is
made available in the kernel.

Since on ppc, we do not have an external device that can wakeup cpus in deep
idle, the local timer of one of the cpus need to be nominated to do this job.
This cpu is called the broadcast cpu/bc_cpu. Only if the bc_cpu is nominated
will the remaining cpus be allowed to enter deep idle state after notifying
the broadcast framework about their next timer event. The bc_cpu is not allowed
to enter deep idle state.

The first cpu that enters longnap is made the bc_cpu. It queues a hrtimer onto
itself which expires after a broadcast period. The job of this
hrtimer is to call into the broadcast framework[1] using the pseudo clock device
that we have initiliazed, in which, the cpus whose wakeup times
have expired are sent an ipi.
On each expiry of the hrtimer, it is programmed to the earlier of the
next pending timer event of the cpus in deep idle and the broadcast period, so
as to not miss any wakeups.

The broadcast period is nothing but the max duration until which the
bc_cpu need not concern itself with checking for expired timer events on cpus
in deep idle. The broadcast period is set to a jiffy in this patch for debug
purposes. Ideally it needn't be smaller than the target_residency of the deep
idle state.

But having a dedicated bc_cpu would mean overloading just one cpu with the
broadcast work which could hinder its performance apart from leading to thermal
imbalance on the chip. Therefore unassign the bc_cpu when there are no more cpus
in deep idle to be woken up. The bc_cpu is left unassigned until such a time 
that
a cpu enters longnap to be nominated as the bc_cpu and the above cycle repeats.

Protect the region of nomination,de-nomination and check for existence of 
broadcast
cpu with a lock to ensure synchronization between them.

[1] tick_handle_oneshot_broadcast() or tick_handle_periodic_broadcast().

Signed-off-by: Preeti U Murthy 
---

 arch/powerpc/include/asm/time.h |1 
 arch/powerpc/kernel/time.c  |2 
 drivers/cpuidle/cpuidle-ibm-power.c |  150 +++
 3 files changed, 152 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 264dc96..38341fa 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -25,6 +25,7 @@ extern unsigned long tb_ticks_per_usec;
 extern unsigned long tb_ticks_per_sec;
 extern struct clock_event_device decrementer_clockevent;
 extern struct clock_event_device broadcast_clockevent;
+extern struct clock_event_device bc_timer;
 
 struct rtc_time;
 extern void to_tm(int tim, struct rtc_time * tm);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index bda78bb..44a76de 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -129,7 +129,7 @@ EXPORT_SYMBOL(broadcast_clockevent);
 
 DEFINE_PER_CPU(u64, decrementers_next_tb);
 static DEFINE_PER_CPU(struct clock_event_device, decrementers);
-static struct clock_event_device bc_timer;
+struct clock_event_device bc_timer;
 
 #define XSEC_PER_SEC (1024*1024)
 
diff --git a/drivers/cpuidle/cpuidle-ibm-power.c 
b/drivers/cpuidle/cpuidle-ibm-power.c
index f8905c3..ae47a0a 100644
--- a/drivers/cpuidle/cpuidle-ibm-power.c
+++ b/drivers/cpuidle/cpuidle-ibm-power.c
@@ -12,12 +12,19 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct cpuidle_driver power_idle_driver = {
@@ -28,6 +35,26 @@ struct cpuidle_driver power_idle_driver = {
 static int max_idle_state;
 static struct cpuidle_state *cpuidle_state_table;
 
+static int bc_cpu = -1;
+static struct hrtimer *bc_hrtimer;
+static int bc_hrtimer_initialized = 0;
+
+/*
+ * Bits to indicate if a cpu can enter deep idle where local timer gets
+ * switched off.
+ * BROADCAST_CPU_PRESENT : Enter deep idle since bc_cpu is assigned
+ * BROADCAST_CPU_SELF   : Do not enter deep idle since you are bc_cpu
+ * BROADCAST_CPU_ABSENT : Do not enter deep idle since there is no 
bc_cpu,
+ *hence nominate yourself as bc_cpu
+ * BROADCAST_CPU_ERROR :  Do not enter deep idle since there is no bc_cpu
+ *and the broadcast hrtimer could not be initialized.
+ */
+enum broadcast_cpu_status {
+   BROADCAST_CPU_PRESENT,
+   BROADCAST_CPU_SELF,
+   BROADCAST_CPU_ERROR,
+};
+
 static inline void idle_loop_prolog(unsigned long *in_purr)
 {
*in_purr = mfspr(SPR

[git pull] Please pull powerpc.git merge branch

2013-09-10 Thread Benjamin Herrenschmidt
Hi Linus !

Here are a handful of small powerpc fixes. A couple of section mismatches
(always worth fixing), a missing export of a new symbol causing build
failures of modules, a page fault deadlock fix (interestingly that
bug has been around for a LONG time, though it seems to be more easily
triggered by KVM) and fixing pseries default idle loop in the absence of
the cpuidle drivers (such as during boot).

Cheers,
Ben.

The following changes since commit 8d7551eb1916832f2a5b27346edf24e7b2382f67:

  Merge tag 'cris-for-3.12' of git://jni.nu/cris (2013-09-10 14:55:16 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

for you to fetch changes up to 363edbe2614aa90df706c0f19ccfa2a6c06af0be:

  powerpc: Default arch idle could cede processor on pseries (2013-09-11 
11:41:54 +1000)


Aneesh Kumar K.V (1):
  powerpc: Fix possible deadlock on page fault

Guenter Roeck (1):
  powerpc: Export cpu_to_chip_id() to fix build error

Vaidyanathan Srinivasan (1):
  powerpc: Default arch idle could cede processor on pseries

Vladimir Murzin (2):
  powerpc: Fix section mismatch warning for prom_rtas_call
  fbdev/ps3fb: Fix section mismatch warning for ps3fb_probe

 arch/powerpc/kernel/prom_init.c|  3 ++-
 arch/powerpc/kernel/smp.c  |  1 +
 arch/powerpc/mm/fault.c| 13 ++---
 arch/powerpc/platforms/pseries/setup.c | 31 +--
 drivers/video/ps3fb.c  |  2 +-
 5 files changed, 35 insertions(+), 15 deletions(-)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [v3] powerpc/mpc85xx: Update the clock device tree nodes

2013-09-10 Thread Tang Yuantian-B29983
OK, will update per your suggestions.

Thanks,
Yuantian


> -Original Message-
> From: Wood Scott-B07421
> Sent: 2013年9月11日 星期三 5:47
> To: Tang Yuantian-B29983
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org;
> devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Mike Turquette
> Subject: Re: [v3] powerpc/mpc85xx: Update the clock device tree nodes
> 
> On Mon, 2013-08-26 at 21:49 -0500, Tang Yuantian-B29983 wrote:
> > > > > > +   };
> > > > > > +   pll1: pll1@820 {
> > > > > > +   #clock-cells = <1>;
> > > > > > +   reg = <0x820>;
> > > > > > +   compatible = "fsl,core-pll-clock";
> > > > > > +   clocks = <&clockgen>;
> > > > > > +   clock-output-names = "pll1", "pll1-div2", "pll1-
> > > div4";
> > > > > > +   };
> > > > >
> > > > > Please leave a blank line between properties and nodes, and
> > > > > between
> > > nodes.
> > > > >
> > > > OK, will add.
> > > >
> > > > > What does reg represent?  Where is the binding for this?
> > > > >
> > > > > The compatible is too vague.
> > > > Reg is register offset.
> > >
> > > With no size?
> >
> > No size is needed.
> 
> Yes, it is.  Register blocks have size -- even if it's just a single
> register.
> 
> > > > It is too later to change since the clock driver is merged for
> > > > months although I sent this patch first.
> > >
> > > It should not have gone in without an approved binding.  It seems it
> > > went in via Mike Turquette (why is a non-ARM-specific tree using
> > > linux-arm- kernel as its list, BTW?).  No ack from Ben, Kumar, or me
> > > is shown in the commit.
> > The Linux common clock framework is not ARM specific. Any other arch
> can use it.
> 
> Sure, it just seemed an odd choice of mailing list for something that
> isn't ARM-specific.
> 
> > > In any case, you can preserve compatibility with existing trees
> > > without using this compatible in new trees.  The driver can check
> > > for both compatibles, with a comment indicating that
> > > "fsl,core-mux-clock" is deprecated and for compatibility only.
> > It is sub-clock node, is it really necessary to think about
> compatibility?
> > I think that's the node clockgen's responsibility.
> 
> It describes registers, so yes, you need to consider compatibility.  A
> clock provider is not responsible for figuring out how to program devices
> that consume its clocks, nor should it make any assumptions about such
> devices.
> 
> > > > Besides, it is not too bad because other arch use the similar name.
> > >
> > > I don't follow.  This is a specific Freescale register interface,
> > > not a general concept.
> > >
> > > In any case, which "similar names" are you referring to?  A search
> > > in arch/arm/boot/dts for "mux" with "clk" or "clock" turns up
> > > "allwinner,sun4i-apb1-mux-clk" which is much more specific than
> > > "fsl,core-mux-clock".
> > Ok, I will change the compatible string.
> > Do you think "fsl,ppc-core-*" is ok?
> 
> No.  How about "fsl,qoriq-chassis1-*" (for e500mc/e5500) and fsl,qoriq-
> chassis2-*" (for e6500)?
> 
> -Scott
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree

2013-09-10 Thread Zhao Qiang
Since P1010RDB-PA and P1010RDB-PB boards use different external PHY
interrupt signals.
And actually the PHY interrupt is not used effectively with
corresponding interrupt handler.
So we can remove the interrupts node without side-effect to comply
with both P1010RDB-PA and P1010RDB-PB.

Signed-off-by: Shengzhou Liu 
Signed-off-by: Zhao Qiang 
---
 arch/powerpc/boot/dts/p1010rdb.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi 
b/arch/powerpc/boot/dts/p1010rdb.dtsi
index 7fc3402..2433ae4 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
@@ -199,17 +199,14 @@
 
mdio@24000 {
phy0: ethernet-phy@0 {
-   interrupts = <3 1 0 0>;
reg = <0x1>;
};
 
phy1: ethernet-phy@1 {
-   interrupts = <2 1 0 0>;
reg = <0x0>;
};
 
phy2: ethernet-phy@2 {
-   interrupts = <2 1 0 0>;
reg = <0x2>;
};
 
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly

2013-09-10 Thread Ananth N Mavinakayanahalli
On Mon, Sep 09, 2013 at 03:20:58PM -0500, Tom Musta wrote:
> > > Isn't that code occasionally used with uprobes too nowadays  ?
> >
> > Yes. I believe so.
> 
> I'm going to back-pedal a little.  I reread code and can connect
> single step code to kprobes but not necessarily to uprobes.  So
> I am not sure that this code is used with uprobes.

Yes, emulate_step() is used for uprobes too.

Ananth

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state

2013-09-10 Thread Dongsheng Wang
From: Wang Dongsheng 

Each core's AltiVec unit may be placed into a power savings mode
by turning off power to the unit. Core hardware will automatically
power down the AltiVec unit after no AltiVec instructions have
executed in N cycles. The AltiVec power-control is triggered by hardware.

Signed-off-by: Wang Dongsheng 
---
*v3:
Assembly code instead of C code.

*v2:
Remove:
delete setup_idle_hw_governor function.
delete "Fix erratum" for rev1.

Move:
move setup_* into __setup/restore_cpu_e6500.

 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index bfb18c7..3c03c109 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -53,11 +53,30 @@ _GLOBAL(__e500_dcache_setup)
isync
blr

+/*
+ * FIXME - We don't know the AltiVec application scenarios.
+ */
+#define AV_WAIT_IDLE_BIT   50 /* 1ms, TB frequency is 41.66MHZ */
+_GLOBAL(setup_altivec_idle)
+   mfspr   r3, SPRN_PWRMGTCR0
+
+   /* Enable Altivec Idle */
+   orisr3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h
+   li  r4, AV_WAIT_IDLE_BIT
+
+   /* Set Automatic AltiVec Idle Count */
+   rlwimi  r3, r4, PWRMGTCR0_AV_IDLE_CNT_SHIFT, PWRMGTCR0_AV_IDLE_CNT
+
+   mtspr   SPRN_PWRMGTCR0, r3
+
+   blr
+
 _GLOBAL(__setup_cpu_e6500)
mflrr6
 #ifdef CONFIG_PPC64
bl  .setup_altivec_ivors
 #endif
+   bl  .setup_altivec_idle
bl  __setup_cpu_e5500
mtlrr6
blr
@@ -119,6 +138,7 @@ _GLOBAL(__setup_cpu_e5500)
 _GLOBAL(__restore_cpu_e6500)
mflrr5
bl  .setup_altivec_ivors
+   bl  .setup_altivec_idle
bl  __restore_cpu_e5500
mtlrr5
blr
--
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v3 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define

2013-09-10 Thread Dongsheng Wang
From: Wang Dongsheng 

E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec
idle patches.

Signed-off-by: Wang Dongsheng 
---
*v3:
Add bit definitions for PWRMGTCR0.

 arch/powerpc/include/asm/reg.h   | 2 ++
 arch/powerpc/include/asm/reg_booke.h | 9 +
 2 files changed, 11 insertions(+)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 64264bf..d4160ca 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1053,6 +1053,8 @@
 #define PVR_8560   0x8020
 #define PVR_VER_E500V1 0x8020
 #define PVR_VER_E500V2 0x8021
+#define PVR_VER_E6500  0x8040
+
 /*
  * For the 8xx processors, all of them report the same PVR family for
  * the PowerPC core. The various versions of these processors must be
diff --git a/arch/powerpc/include/asm/reg_booke.h 
b/arch/powerpc/include/asm/reg_booke.h
index ed8f836..4a6457e 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -170,6 +170,7 @@
 #define SPRN_L2CSR10x3FA   /* L2 Data Cache Control and Status Register 1 
*/
 #define SPRN_DCCR  0x3FA   /* Data Cache Cacheability Register */
 #define SPRN_ICCR  0x3FB   /* Instruction Cache Cacheability Register */
+#define SPRN_PWRMGTCR0 0x3FB   /* Power management control register 0 */
 #define SPRN_SVR   0x3FF   /* System Version Register */

 /*
@@ -216,6 +217,14 @@
 #defineCCR1_DPC0x0100 /* Disable L1 I-Cache/D-Cache parity 
checking */
 #defineCCR1_TCS0x0080 /* Timer Clock Select */

+/* Bit definitions for PWRMGTCR0. */
+#define PWRMGTCR0_PW20_WAIT(1 << 14) /* PW20 state enable bit */
+#define PWRMGTCR0_PW20_ENT_SHIFT   8
+#define PWRMGTCR0_PW20_ENT 0x3F00
+#define PWRMGTCR0_AV_IDLE_PD_EN(1 << 22) /* Altivec idle 
enable */
+#define PWRMGTCR0_AV_IDLE_CNT_SHIFT16
+#define PWRMGTCR0_AV_IDLE_CNT  0x3F
+
 /* Bit definitions for the MCSR. */
 #define MCSR_MCS   0x8000 /* Machine Check Summary */
 #define MCSR_IB0x4000 /* Instruction PLB Error */
--
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

2013-09-10 Thread Dongsheng Wang
From: Wang Dongsheng 

Add a sys interface to enable/diable pw20 state or altivec idle, and
control the wait entry time.

Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle

Set wait entry bit interface:
bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
/sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
/sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit

Signed-off-by: Wang Dongsheng 
---
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 7389d49..7395d79 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -53,6 +53,21 @@ _GLOBAL(__e500_dcache_setup)
isync
blr

+_GLOBAL(has_pw20_altivec_idle)
+   /* 0 false, 1 true */
+   li  r3, 0
+
+   /* PW20 & AltiVec idle feature only exists for E6500 */
+   mfspr   r0, SPRN_PVR
+   rlwinm  r4, r0, 16, 16, 31
+   lis r12, 0
+   ori r12, r12, PVR_VER_E6500@l
+   cmpwr4, r12
+   bne 2f
+   li  r3, 1
+2:
+   blr
+
 /*
  * FIXME - We don't know, what time should we let the core into PW20 state.
  * because we don't know the current state of the cpu load. And threads are
diff --git a/arch/powerpc/platforms/85xx/common.c 
b/arch/powerpc/platforms/85xx/common.c
index d0861a0..fe4d3a7 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -5,12 +5,16 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+
+#include 
 #include 

 #include 

 #include "mpc85xx.h"

+#define MAX_BIT63
+
 static struct of_device_id __initdata mpc85xx_common_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
@@ -80,3 +84,234 @@ void __init mpc85xx_cpm2_pic_init(void)
irq_set_chained_handler(irq, cpm2_cascade);
 }
 #endif
+
+static void query_pwrmgtcr0(void *val)
+{
+   u32 *value = val;
+
+   *value = mfspr(SPRN_PWRMGTCR0);
+}
+
+static ssize_t show_pw20_state(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   u32 value;
+   unsigned int cpu = dev->id;
+
+   smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
+
+   value &= PWRMGTCR0_PW20_WAIT;
+
+   return sprintf(buf, "%u\n", value ? 1 : 0);
+}
+
+static void control_pw20_state(void *val)
+{
+   u32 *value = val;
+   u32 pw20_state;
+
+   pw20_state = mfspr(SPRN_PWRMGTCR0);
+
+   if (*value)
+   pw20_state |= PWRMGTCR0_PW20_WAIT;
+   else
+   pw20_state &= ~PWRMGTCR0_PW20_WAIT;
+
+   mtspr(SPRN_PWRMGTCR0, pw20_state);
+}
+
+static ssize_t store_pw20_state(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   u32 value;
+   unsigned int cpu = dev->id;
+
+   if (kstrtou32(buf, 0, &value))
+   return -EINVAL;
+
+   if (value > 1)
+   return -EINVAL;
+
+   smp_call_function_single(cpu, control_pw20_state, &value, 1);
+
+   return count;
+}
+
+static ssize_t show_pw20_wait_entry_bit(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   u32 value;
+   unsigned int cpu = dev->id;
+
+   smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
+
+   value = MAX_BIT - ((value & PWRMGTCR0_PW20_ENT) >>
+   PWRMGTCR0_PW20_ENT_SHIFT);
+
+   return sprintf(buf, "wait entry bit is %u\n", value);
+}
+
+static void set_pw20_wait_entry_bit(void *val)
+{
+   u32 *value = val;
+   u32 pw20_idle;
+
+   pw20_idle = mfspr(SPRN_PWRMGTCR0);
+
+   /* Set Automatic PW20 Core Idle Count */
+   /* clear count */
+   pw20_idle &= ~PWRMGTCR0_PW20_ENT;
+
+   /* set count */
+   pw20_idle |= ((MAX_BIT - *value) << PWRMGTCR0_PW20_ENT_SHIFT);
+
+   mtspr(SPRN_PWRMGTCR0, pw20_idle);
+}
+
+static ssize_t store_pw20_wait_entry_bit(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   u32 value;
+   unsigned int cpu = dev->id;
+
+   if (kstrtou32(buf, 0, &value))
+   return -EINVAL;
+
+   if (value > MAX_BIT)
+   return -EINVAL;
+
+   smp_call_function_single(cpu, set_pw20_wait_entry_bit,
+   &value, 1);
+
+   return count;
+}
+
+static ssize_t show_altivec_idle(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   u32 value;
+   unsigned int cpu = dev->id;
+
+   smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
+
+   value &= PWRMGTCR0_AV_IDLE_PD_EN;
+
+   return sprintf(buf, "%u\n", value ? 1 : 0);

[PATCH v3 3/4] powerpc/85xx: add hardware automatically enter pw20 state

2013-09-10 Thread Dongsheng Wang
From: Wang Dongsheng 

Using hardware features make core automatically enter PW20 state.
Set a TB count to hardware, the effective count begins when PW10
is entered. When the effective period has expired, the core will
proceed from PW10 to PW20 if no exit conditions have occurred during
the period.

Signed-off-by: Wang Dongsheng 
---
*v3:
Assembly code instead of C code.

*v2:
Remove:
delete setup_idle_hw_governor function.
delete "Fix erratum" for rev1.

Move:
move setup_* into __setup/restore_cpu_e6500.

 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 3c03c109..7389d49 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -54,6 +54,27 @@ _GLOBAL(__e500_dcache_setup)
blr

 /*
+ * FIXME - We don't know, what time should we let the core into PW20 state.
+ * because we don't know the current state of the cpu load. And threads are
+ * independent, so we can not know the state of different thread has been
+ * idle.
+ */
+#define PW20_WAIT_IDLE_BIT 50 /* 1ms, TB frequency is 41.66MHZ */
+_GLOBAL(setup_pw20_idle)
+   mfspr   r3, SPRN_PWRMGTCR0
+
+   /* Set PW20_WAIT bit, enable pw20 state*/
+   ori r3, r3, PWRMGTCR0_PW20_WAIT
+   li  r4, PW20_WAIT_IDLE_BIT
+
+   /* Set Automatic PW20 Core Idle Count */
+   rlwimi  r3, r4, PWRMGTCR0_PW20_ENT_SHIFT, PWRMGTCR0_PW20_ENT
+
+   mtspr   SPRN_PWRMGTCR0, r3
+
+   blr
+
+/*
  * FIXME - We don't know the AltiVec application scenarios.
  */
 #define AV_WAIT_IDLE_BIT   50 /* 1ms, TB frequency is 41.66MHZ */
@@ -76,6 +97,7 @@ _GLOBAL(__setup_cpu_e6500)
 #ifdef CONFIG_PPC64
bl  .setup_altivec_ivors
 #endif
+   bl  .setup_pw20_idle
bl  .setup_altivec_idle
bl  __setup_cpu_e5500
mtlrr6
@@ -138,6 +160,7 @@ _GLOBAL(__setup_cpu_e5500)
 _GLOBAL(__restore_cpu_e6500)
mflrr5
bl  .setup_altivec_ivors
+   bl  .setup_pw20_idle
bl  .setup_altivec_idle
bl  __restore_cpu_e5500
mtlrr5
--
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

2013-09-10 Thread Vasant Hegde

On 09/11/2013 04:20 AM, Guenter Roeck wrote:

On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:

On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:

On 09/08/2013 5:28 PM, Guenter Roeck wrote:

Hi all,



Guenter, Ben,

Sorry for the inconvenience. I never realized my patch could break somewhere :-(

Thanks you very much for identifying and fixing this issue. Other patch looks 
good to me.


-Vasant



powerpc allmodconfig build on the latest upstream kernel results in:

ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

This is due to commit 15863ff3b (powerpc: Make chip-id information
available to userspace).
Not surprising, as cpu_to_chip_id() is not exported.


Apart from the above error, I have a concern on the patch, purely based on the 
commit message.
(to be honest, I am not familiar with the ppc architecture)

Commit message of 15863ff3b has the following text.

**
So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id"
was always default (-1) on ppc64 architecture.

Now, some systems have an ibm,chip-id property in the cpu nodes in
the device tree. On these systems, we now use this information to
display physical_package_id
**

Shouldn't the new definition of "topology_physical_package_id" apply only to 
those systems supporting ibm,chip-id property?


There should be no negative side effect (appart from the missing
EXPORT_SYMBOL of course). If the property is not found in the
device-tree, the new function returns -1, so it should work fine on all
systems.


Good. I submitted a patch doing just that yesterday or so.
Hope you'll accept it ;).

Thanks,
Guenter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/3] powerpc: export cpu_to_chip_id

2013-09-10 Thread Vasant Hegde

On 09/10/2013 10:08 PM, Vladimir Murzin wrote:

While cross-building for PPC64 I've got


Vladimir,

Below commit ID fixes this issue.

commit 256588fda10f2a712631f8a4e72641a66adebdb8
Author: Guenter Roeck 
Date:   Mon Sep 9 18:37:56 2013 -0700

powerpc: Export cpu_to_chip_id() to fix build error

-Vasant


ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

mtip32xx refer to topology_physical_package_id, which stands for
cpu_to_chip-id.

Make cpu_to_chip-id (and topology_physical_package_id) available for
external users.

Signed-off-by: Vladimir Murzin 
---
  arch/powerpc/kernel/smp.c |1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 442d8e2..1d9c1c2 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu)
of_node_put(np);
return of_get_ibm_chip_id(np);
  }
+EXPORT_SYMBOL_GPL(cpu_to_chip_id);

  /* Helper routines for cpu to core mapping */
  int cpu_core_index_of_thread(int cpu)



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc/mpc85xx:Add initial device tree support of T104x

2013-09-10 Thread Prabhakar Kushwaha
The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
processor cores with high-performance data path acceleration architecture
and network peripheral interfaces required for networking & telecommunications.

T1042 personality is a reduced personality of T1040 without Integrated 8-port
Gigabit Ethernet switch.

The T1040/T1042 SoC includes the following function and features:

 - Four e5500 cores, each with a private 256 KB L2 cache
 - 256 KB shared L3 CoreNet platform cache (CPC)
 - Interconnect CoreNet platform
 - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
   support
 - Data Path Acceleration Architecture (DPAA) incorporating acceleration
 for the following functions:
-  Packet parsing, classification, and distribution
-  Queue management for scheduling, packet sequencing, and congestion
management
-  Cryptography Acceleration (SEC 5.0)
- RegEx Pattern Matching Acceleration (PME 2.2)
- IEEE Std 1588 support
- Hardware buffer management for buffer allocation and deallocation
 - Ethernet interfaces
- Integrated 8-port Gigabit Ethernet switch (T1040 only)
- Four 1 Gbps Ethernet controllers
 - Two RGMII interfaces or one RGMII and one MII interfaces
 - High speed peripheral interfaces
   - Four PCI Express 2.0 controllers running at up to 5 GHz
   - Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
   - Upto two QSGMII interface
   - Upto six SGMII interface supporting 1000 Mbps
   - One SGMII interface supporting upto 2500 Mbps
 - Additional peripheral interfaces
   - Two USB 2.0 controllers with integrated PHY
   - SD/eSDHC/eMMC
   -  eSPI controller
   - Four I2C controllers
   - Four UARTs
   - Four GPIO controllers
   - Integrated flash controller (IFC)
   - Change this to  LCD/ HDMI interface (DIU) with 12 bit dual data rate
   - TDM interface
 - Multicore programmable interrupt controller (PIC)
 - Two 8-channel DMA engines
 - Single source clocking implementation
 - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)

Signed-off-by: Poonam Aggrwal 
Signed-off-by: Priyanka Jain 
Signed-off-by: Varun Sethi 
Signed-off-by: Prabhakar Kushwaha 
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git

TODO: Add noded for ethernet

 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi |  116 
 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi |  430 +++
 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi  |  111 +++
 3 files changed, 657 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
new file mode 100644
index 000..6ef27fe
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -0,0 +1,116 @@
+/*
+ * T1040 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in the
+ *   documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *   names of its contributors may be used to endorse or promote products
+ *   derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "t1042si-post.dtsi"
+
+&pci0 {
+   compatible = "fsl,t1040-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
+};
+
+&pci1 {
+

[PATCH 1/2] powerpc/fsl-booke: Add initial T104x_QDS board support

2013-09-10 Thread Prabhakar Kushwaha
 Add support for T104x board in board file t104x_qds.c, It is common for
 both T1040 and T1042 as they share same QDS board.

 T1040QDS board Overview
 ---
 - SERDES Connections, 8 lanes supporting:
  — PCI Express: supporting Gen 1 and Gen 2;
  — SGMII
  — QSGMII
  — SATA 2.0
  — Aurora debug with dedicated connectors (T1040 only)
 - DDR Controller
 - Supports rates of up to 1600 MHz data-rate
 - Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank types.
 -IFC/Local Bus
 - NAND flash: 8-bit, async, up to 2GB.
 - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
 - GASIC: Simple (minimal) target within Qixis FPGA
 - PromJET rapid memory download support
 - Ethernet
 - Two on-board RGMII 10/100/1G ethernet ports.
 - PHY #0 remains powered up during deep-sleep (T1040 only)
 - QIXIS System Logic FPGA
 - Clocks
 - System and DDR clock (SYSCLK, “DDRCLK”)
 - SERDES clocks
 - Power Supplies
 - Video
 - DIU supports video at up to 1280x1024x32bpp
 - USB
 - Supports two USB 2.0 ports with integrated PHYs
 — Two type A ports with 5V@1.5A per port.
 — Second port can be converted to OTG mini-AB
 - SDHC
 - SDHC port connects directly to an adapter card slot, featuring:
 - Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC
 — Supporting eMMC memory devices
 - SPI
-  On-board support of 3 different devices and sizes
 - Other IO
- Two Serial ports
- ProfiBus port
- Four I2C ports

 Add T104xQDS support in Kconfig and Makefile. Also create device tree.

Signed-off-by: Priyanka Jain 
Signed-off-by: Poonam Aggrwal 
Signed-off-by: Prabhakar Kushwaha 
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git

TODO: Add noded for ethernet and board stuff

 arch/powerpc/boot/dts/t1040qds.dts  |  201 +++
 arch/powerpc/boot/dts/t1042qds.dts  |  201 +++
 arch/powerpc/platforms/85xx/Kconfig |   20 +++
 arch/powerpc/platforms/85xx/Makefile|1 +
 arch/powerpc/platforms/85xx/t104x_qds.c |  102 
 5 files changed, 525 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/t1040qds.dts
 create mode 100644 arch/powerpc/boot/dts/t1042qds.dts
 create mode 100644 arch/powerpc/platforms/85xx/t104x_qds.c

diff --git a/arch/powerpc/boot/dts/t1040qds.dts 
b/arch/powerpc/boot/dts/t1040qds.dts
new file mode 100644
index 000..cea5632
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1040qds.dts
@@ -0,0 +1,201 @@
+/*
+ * T1040QDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in the
+ *  documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ *  names of its contributors may be used to endorse or promote products
+ *  derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+
+/ {
+   model = "fsl,T1040QDS";
+   compatible = "fsl,T1040QDS";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+
+   aliases {
+/* TODO */
+   };
+
+   ifc: localbus@ffe124000 {
+   reg = <0xf 0xfe124000 0 0x2000>;
+   ranges = <0 0 0xf 0xe800 0x0800
+ 2 0 0xf 0xff80 0x0001
+ 3 0 0xf 0xffdf 0x8000>;
+
+   nor@0,0 {
+