* [PATCH 04/13] powerpc/book3e: More doorbell cleanups. Sample the PIR register
From: Benjamin Herrenschmidt @ 2010-07-09 6:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1278656215-24705-3-git-send-email-benh@kernel.crashing.org>
The doorbells use the content of the PIR register to match messages
from other CPUs. This may or may not be the same as our linux CPU
number, so using that as the "target" is no right.
Instead, we sample the PIR register at boot on every processor
and use that value subsequently when sending IPIs.
We also use a per-cpu message mask rather than a global array which
should limit cache line contention.
Note: We could use the CPU number in the device-tree instead of
the PIR register, as they are supposed to be equivalent. This
might prove useful if doorbells are to be used to kick CPUs out
of FW at boot time, thus before we can sample the PIR. This is
however not the case now and using the PIR just works.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/dbell.h | 7 ++---
arch/powerpc/kernel/dbell.c | 47 ++++++++++++++++++++++++++----------
arch/powerpc/platforms/85xx/smp.c | 4 ++-
3 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/dbell.h b/arch/powerpc/include/asm/dbell.h
index 501189a..ced7e48 100644
--- a/arch/powerpc/include/asm/dbell.h
+++ b/arch/powerpc/include/asm/dbell.h
@@ -27,10 +27,9 @@ enum ppc_dbell {
PPC_G_DBELL_MC = 4, /* guest mcheck doorbell */
};
-#ifdef CONFIG_SMP
-extern unsigned long dbell_smp_message[NR_CPUS];
-extern void smp_dbell_message_pass(int target, int msg);
-#endif
+extern void doorbell_message_pass(int target, int msg);
+extern void doorbell_exception(struct pt_regs *regs);
+extern void doorbell_setup_this_cpu(void);
static inline void ppc_msgsnd(enum ppc_dbell type, u32 flags, u32 tag)
{
diff --git a/arch/powerpc/kernel/dbell.c b/arch/powerpc/kernel/dbell.c
index e3a7177..1c7a945 100644
--- a/arch/powerpc/kernel/dbell.c
+++ b/arch/powerpc/kernel/dbell.c
@@ -13,45 +13,66 @@
#include <linux/kernel.h>
#include <linux/smp.h>
#include <linux/threads.h>
+#include <linux/percpu.h>
#include <asm/dbell.h>
#ifdef CONFIG_SMP
-unsigned long dbell_smp_message[NR_CPUS];
+struct doorbell_cpu_info {
+ unsigned long messages; /* current messages bits */
+ unsigned int tag; /* tag value */
+};
-void smp_dbell_message_pass(int target, int msg)
+static DEFINE_PER_CPU(struct doorbell_cpu_info, doorbell_cpu_info);
+
+void doorbell_setup_this_cpu(void)
+{
+ struct doorbell_cpu_info *info = &__get_cpu_var(doorbell_cpu_info);
+
+ info->messages = 0;
+ info->tag = mfspr(SPRN_PIR) & 0x3fff;
+}
+
+void doorbell_message_pass(int target, int msg)
{
+ struct doorbell_cpu_info *info;
int i;
- if(target < NR_CPUS) {
- set_bit(msg, &dbell_smp_message[target]);
- ppc_msgsnd(PPC_DBELL, 0, target);
+ if (target < NR_CPUS) {
+ info = &per_cpu(doorbell_cpu_info, target);
+ set_bit(msg, &info->messages);
+ ppc_msgsnd(PPC_DBELL, 0, info->tag);
}
- else if(target == MSG_ALL_BUT_SELF) {
+ else if (target == MSG_ALL_BUT_SELF) {
for_each_online_cpu(i) {
if (i == smp_processor_id())
continue;
- set_bit(msg, &dbell_smp_message[i]);
- ppc_msgsnd(PPC_DBELL, 0, i);
+ info = &per_cpu(doorbell_cpu_info, i);
+ set_bit(msg, &info->messages);
+ ppc_msgsnd(PPC_DBELL, 0, info->tag);
}
}
else { /* target == MSG_ALL */
- for_each_online_cpu(i)
- set_bit(msg, &dbell_smp_message[i]);
+ for_each_online_cpu(i) {
+ info = &per_cpu(doorbell_cpu_info, i);
+ set_bit(msg, &info->messages);
+ }
ppc_msgsnd(PPC_DBELL, PPC_DBELL_MSG_BRDCAST, 0);
}
}
void doorbell_exception(struct pt_regs *regs)
{
- int cpu = smp_processor_id();
+ struct doorbell_cpu_info *info = &__get_cpu_var(doorbell_cpu_info);
int msg;
- if (num_online_cpus() < 2)
+ /* Warning: regs can be NULL when called from irq enable */
+
+ if (!info->messages || (num_online_cpus() < 2))
return;
for (msg = 0; msg < 4; msg++)
- if (test_and_clear_bit(msg, &dbell_smp_message[cpu]))
+ if (test_and_clear_bit(msg, &info->messages))
smp_message_recv(msg);
}
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index a15f582..4c3cde9 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -99,6 +99,8 @@ static void __init
smp_85xx_setup_cpu(int cpu_nr)
{
mpic_setup_this_cpu();
+ if (cpu_has_feature(CPU_FTR_DBELL))
+ doorbell_setup_this_cpu();
}
struct smp_ops_t smp_85xx_ops = {
@@ -117,7 +119,7 @@ void __init mpc85xx_smp_init(void)
}
if (cpu_has_feature(CPU_FTR_DBELL))
- smp_85xx_ops.message_pass = smp_dbell_message_pass;
+ smp_85xx_ops.message_pass = doorbell_message_pass;
BUG_ON(!smp_85xx_ops.message_pass);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 01/13] powerpc/book3e: mtmsr should not be mtmsrd on book3e 64-bit
From: Benjamin Herrenschmidt @ 2010-07-09 6:16 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/reg.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index d62fdf4..d8be016 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -890,7 +890,7 @@
#ifndef __ASSEMBLY__
#define mfmsr() ({unsigned long rval; \
asm volatile("mfmsr %0" : "=r" (rval)); rval;})
-#ifdef CONFIG_PPC64
+#ifdef CONFIG_PPC_BOOK3S_64
#define __mtmsrd(v, l) asm volatile("mtmsrd %0," __stringify(l) \
: : "r" (v) : "memory")
#define mtmsrd(v) __mtmsrd((v), 0)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 02/13] powerpc/book3e: Hack to get gdb moving along on Book3E 64-bit
From: Benjamin Herrenschmidt @ 2010-07-09 6:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1278656215-24705-1-git-send-email-benh@kernel.crashing.org>
Our handling of debug interrupts on Book3E 64-bit is not quite
the way it should be just yet. This is a workaround to let gdb
work at least for now. We ensure that when context switching,
we set the appropriate DBCR0 value for the new task. We also
make sure that we turn off MSR[DE] within the kernel, and set
it as part of the bits that get set when going back to userspace.
In the long run, we will probably set the userspace DBCR0 on the
exception exit code path and ensure we have some proper kernel
value to set on the way into the kernel, a bit like ppc32 does,
but that will take more work.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/reg_booke.h | 4 ++--
arch/powerpc/kernel/process.c | 22 ++++++++++++++++++++++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 2360317..66dc6f0 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -29,8 +29,8 @@
#if defined(CONFIG_PPC_BOOK3E_64)
#define MSR_ MSR_ME | MSR_CE
#define MSR_KERNEL MSR_ | MSR_CM
-#define MSR_USER32 MSR_ | MSR_PR | MSR_EE
-#define MSR_USER64 MSR_USER32 | MSR_CM
+#define MSR_USER32 MSR_ | MSR_PR | MSR_EE | MSR_DE
+#define MSR_USER64 MSR_USER32 | MSR_CM | MSR_DE
#elif defined (CONFIG_40x)
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE)
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 1e78453..551f671 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -477,6 +477,28 @@ struct task_struct *__switch_to(struct task_struct *prev,
new_thread = &new->thread;
old_thread = ¤t->thread;
+#if defined(CONFIG_PPC_BOOK3E_64)
+ /* XXX Current Book3E code doesn't deal with kernel side DBCR0,
+ * we always hold the user values, so we set it now.
+ *
+ * However, we ensure the kernel MSR:DE is appropriately cleared too
+ * to avoid spurrious single step exceptions in the kernel.
+ *
+ * This will have to change to merge with the ppc32 code at some point,
+ * but I don't like much what ppc32 is doing today so there's some
+ * thinking needed there
+ */
+ if ((new_thread->dbcr0 | old_thread->dbcr0) & DBCR0_IDM) {
+ u32 dbcr0;
+
+ mtmsr(mfmsr() & ~MSR_DE);
+ isync();
+ dbcr0 = mfspr(SPRN_DBCR0);
+ dbcr0 = (dbcr0 & DBCR0_EDM) | new_thread->dbcr0;
+ mtspr(SPRN_DBCR0, dbcr0);
+ }
+#endif /* CONFIG_PPC64_BOOK3E */
+
#ifdef CONFIG_PPC64
/*
* Collect processor utilization data per process
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Matthew McClintock @ 2010-07-09 5:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Kumar Gala, Milton Miller, Matthew McClintock
In-Reply-To: <20100708-mitltonm-msm-reply@mdm.bga.com>
Fix sizes of variables so correct values are exported via /proc.
Cast variable in comparison to avoid compiler error.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/crash_dump.c | 4 ++--
arch/powerpc/kernel/machine_kexec.c | 10 +++++-----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 5fb667a..d254132 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -128,9 +128,9 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
if (!csize)
return 0;
- csize = min(csize, PAGE_SIZE);
+ csize = min_t(size_t, csize, PAGE_SIZE);
- if (pfn < max_pfn) {
+ if ((min_low_pfn < pfn) && (pfn < max_pfn)) {
vaddr = __va(pfn << PAGE_SHIFT);
csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
} else {
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..6ff15f0 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -144,24 +144,24 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
}
/* Values we need to export to the second kernel via the device tree. */
-static unsigned long kernel_end;
-static unsigned long crashk_size;
+static phys_addr_t kernel_end;
+static phys_addr_t crashk_size;
static struct property kernel_end_prop = {
.name = "linux,kernel-end",
- .length = sizeof(unsigned long),
+ .length = sizeof(phys_addr_t),
.value = &kernel_end,
};
static struct property crashk_base_prop = {
.name = "linux,crashkernel-base",
- .length = sizeof(unsigned long),
+ .length = sizeof(phys_addr_t),
.value = &crashk_res.start,
};
static struct property crashk_size_prop = {
.name = "linux,crashkernel-size",
- .length = sizeof(unsigned long),
+ .length = sizeof(phys_addr_t),
.value = &crashk_size,
};
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 00/27] KVM PPC PV framework
From: MJ embd @ 2010-07-09 4:57 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1277980982-12433-1-git-send-email-agraf@suse.de>
On Thu, Jul 1, 2010 at 4:12 PM, Alexander Graf <agraf@suse.de> wrote:
> On PPC we run PR=3D0 (kernel mode) code in PR=3D1 (user mode) and don't u=
se the
> hypervisor extensions.
>
> While that is all great to show that virtualization is possible, there ar=
e
> quite some cases where the emulation overhead of privileged instructions =
is
> killing performance.
>
> This patchset tackles exactly that issue. It introduces a paravirtual fra=
mework
> using which KVM and Linux share a page to exchange register state with. T=
hat
KVM and Linux or KVM and GuestOS ?
> way we don't have to switch to the hypervisor just to change a value of a
> privileged register.
>
> To prove my point, I ran the same test I did for the MMU optimizations ag=
ainst
> the PV framework. Here are the results:
>
> [without]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null=
; done
>
> real =A0 =A00m14.659s
> user =A0 =A00m8.967s
> sys =A0 =A0 0m5.688s
>
> [with]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null=
; done
>
> real =A0 =A00m7.557s
> user =A0 =A00m4.121s
> sys =A0 =A0 0m3.426s
>
>
> So this is a significant performance improvement! I'm quite happy how fas=
t this
> whole thing becomes :)
>
> I tried to take all comments I've heard from people so far about such a P=
V
> framework into account. In case you told me something before that is a no=
-go
> and I still did it, please just tell me again.
>
> Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and s=
tart
> experiencing the power yourself. - heh
>
> v1 -> v2:
>
> =A0- change hypervisor calls to use r0 and r3
> =A0- make crit detection only trigger in supervisor mode
> =A0- RMO -> PAM
> =A0- introduce kvm_patch_ins
> =A0- only flush icache when patching
> =A0- introduce kvm_patch_ins_b
> =A0- update documentation
>
> Alexander Graf (27):
> =A0KVM: PPC: Introduce shared page
> =A0KVM: PPC: Convert MSR to shared page
> =A0KVM: PPC: Convert DSISR to shared page
> =A0KVM: PPC: Convert DAR to shared page.
> =A0KVM: PPC: Convert SRR0 and SRR1 to shared page
> =A0KVM: PPC: Convert SPRG[0-4] to shared page
> =A0KVM: PPC: Implement hypervisor interface
> =A0KVM: PPC: Add PV guest critical sections
> =A0KVM: PPC: Add PV guest scratch registers
> =A0KVM: PPC: Tell guest about pending interrupts
> =A0KVM: PPC: Make RMO a define
> =A0KVM: PPC: First magic page steps
> =A0KVM: PPC: Magic Page Book3s support
> =A0KVM: PPC: Magic Page BookE support
> =A0KVM: PPC: Expose magic page support to guest
> =A0KVM: Move kvm_guest_init out of generic code
> =A0KVM: PPC: Generic KVM PV guest support
> =A0KVM: PPC: KVM PV guest stubs
> =A0KVM: PPC: PV instructions to loads and stores
> =A0KVM: PPC: PV tlbsync to nop
> =A0KVM: PPC: Introduce kvm_tmp framework
> =A0KVM: PPC: Introduce branch patching helper
> =A0KVM: PPC: PV assembler helpers
> =A0KVM: PPC: PV mtmsrd L=3D1
> =A0KVM: PPC: PV mtmsrd L=3D0 and mtmsr
> =A0KVM: PPC: PV wrteei
> =A0KVM: PPC: Add Documentation about PV interface
>
> =A0Documentation/kvm/ppc-pv.txt =A0 =A0 =A0 =A0 =A0 =A0 | =A0185 ++++++++=
++++++
> =A0arch/powerpc/include/asm/kvm_book3s.h =A0 =A0| =A0 =A01 -
> =A0arch/powerpc/include/asm/kvm_host.h =A0 =A0 =A0| =A0 15 +-
> =A0arch/powerpc/include/asm/kvm_para.h =A0 =A0 =A0| =A0121 +++++++++-
> =A0arch/powerpc/include/asm/kvm_ppc.h =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/powerpc/kernel/Makefile =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A02 +
> =A0arch/powerpc/kernel/asm-offsets.c =A0 =A0 =A0 =A0| =A0 18 ++-
> =A0arch/powerpc/kernel/kvm.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0408 ++++=
++++++++++++++++++++++++++
> =A0arch/powerpc/kernel/kvm_emul.S =A0 =A0 =A0 =A0 =A0 | =A0237 ++++++++++=
+++++++
> =A0arch/powerpc/kvm/44x.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A07 =
+
> =A0arch/powerpc/kvm/44x_tlb.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A08 +-
> =A0arch/powerpc/kvm/book3s.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0165 ++++=
++++-----
> =A0arch/powerpc/kvm/book3s_32_mmu.c =A0 =A0 =A0 =A0 | =A0 28 ++-
> =A0arch/powerpc/kvm/book3s_32_mmu_host.c =A0 =A0| =A0 16 +-
> =A0arch/powerpc/kvm/book3s_64_mmu.c =A0 =A0 =A0 =A0 | =A0 42 +++-
> =A0arch/powerpc/kvm/book3s_64_mmu_host.c =A0 =A0| =A0 16 +-
> =A0arch/powerpc/kvm/book3s_emulate.c =A0 =A0 =A0 =A0| =A0 25 +-
> =A0arch/powerpc/kvm/book3s_paired_singles.c | =A0 11 +-
> =A0arch/powerpc/kvm/booke.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0113 ++++=
+++--
> =A0arch/powerpc/kvm/booke.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A06 +-
> =A0arch/powerpc/kvm/booke_emulate.c =A0 =A0 =A0 =A0 | =A0 14 +-
> =A0arch/powerpc/kvm/booke_interrupts.S =A0 =A0 =A0| =A0 =A03 +-
> =A0arch/powerpc/kvm/e500.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A07 =
+
> =A0arch/powerpc/kvm/e500_tlb.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 31 ++-
> =A0arch/powerpc/kvm/e500_tlb.h =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A02 +-
> =A0arch/powerpc/kvm/emulate.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 47 +++-
> =A0arch/powerpc/kvm/powerpc.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 42 +++-
> =A0arch/powerpc/platforms/Kconfig =A0 =A0 =A0 =A0 =A0 | =A0 10 +
> =A0arch/x86/include/asm/kvm_para.h =A0 =A0 =A0 =A0 =A0| =A0 =A06 +
> =A0include/linux/kvm_para.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A07 +-
> =A030 files changed, 1420 insertions(+), 174 deletions(-)
> =A0create mode 100644 Documentation/kvm/ppc-pv.txt
> =A0create mode 100644 arch/powerpc/kernel/kvm.c
> =A0create mode 100644 arch/powerpc/kernel/kvm_emul.S
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Benjamin Herrenschmidt @ 2010-07-09 1:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Matthew McClintock, linuxppc-dev, Milton Miller
In-Reply-To: <F4BDFB0D-51C0-49C1-918F-FAC0DD565E63@freescale.com>
On Thu, 2010-07-08 at 07:40 -0500, Kumar Gala wrote:
> On Jul 8, 2010, at 5:49 AM, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
> >> On Wed, 07 Jul 2010 around 10:51:20 -0000 Matthew McClintock wrote:
> >>>
> >>> Fix sizes of variables so correct values are exported via /proc.
> >>> Cast variable in comparison to avoid compiler error.
> >>>
> >
> > I'm afraid I already pulled that in. Please send a fixup patch.
> >
> pulled into which tree?
My confusion. It was in my to-be-posted -next but I hadn't actually
uploaded it yet so I've dropped the patch for now. Matthew, don't send
an incremental fixup, a whole new patch will do. I've also dropped the
second patch that enables building of crash dump kernels for now.
I've left the MPIC CPU reset one though.
Cheers,
Ben.
^ permalink raw reply
* Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Matthew McClintock @ 2010-07-08 22:17 UTC (permalink / raw)
To: Milton Miller; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <11278706694663348731.1957747793.miltonm@bga.com>
On Fri, 2010-07-09 at 15:18 -0500, Milton Miller wrote:
> > I don't disagree but this can break kexec if phys_addr_t != unsigned
> > long. Also, doesn't the crash kernel have to live below 2GB so
> unsigned
> > long is always fine?
>
>
> Its could only break kexec for the case of phys_addr_t != unsigned
> long
> which you are fixing, and its the right way to fix it. There is
> nothing
> inherent in linux requiring the crash kernel to be below 2G, although
> there may be limitations of the current kernel that require such a
> limit.
Fair enough. This will be updated in the next patch.
>
> >
> > Will still change unless I hear otherwise.
> >
>
>
> > >
> > > By the way, why does 32 bit care about the running kernel's size?
> aka
> > > linux,kernel-end? 64 bit book 3S needs it because we use mmu
> hooks
> > > to copy the pages to their destination, but I thought ppc32 was
> using
> > > a relocatable copy routine. Are we missing the code to create
> > > temp ref tlbs on the fly for book 3E?
> >
> > This is not really in this patch or did I miss something? Kexec uses
> > kernel-end just to add as a invalid region. Not crucial though for
> 32
> > bit.
>
> No its not in this patch, hence "By the way". I figured you might
> have
> some knowledge as you were working in this area. If there is no
> reason
> to have the kernel region blocked for 32 bit, then it should be
> removed.
> Obviously from kexec-tools first, and then after some time we could
> move
> its export to be only for 64-bit (or only 64 bit book-3S?)
>
As far as I can tell it's just used as an exclusion range. It's only
applicable for a crash kernel to make sure your crashkernel=XXM@XXM does
not overlap with the current kernel. Seems like it might not be needed.
> It only causes additional time for traditional, and memory
> fragmentation
> for book 3E, if you disallow memory below the current kernel end.
> For
> that matter, on 3E, does this limit creep as you repeatedly reboot?
>
For a crash kernel it does not matter as you stick with the reserved
region. For kexec proper the current kexec HEAD disallows loading from
0x0-kernelend but I think that is wrong and needs to be modified for at
least some platforms. So, basically you can't load too the currently
running kernel address, and you can't even restart but I have not tried
a different address.
I submitted a patch a while back to change that behavior for
kexec-uImage targets and have more working coming soon which will need
to be reviewed as well for kexec-elf targets.
-Matthew
^ permalink raw reply
* [PATCH 1/2] fsl_pci: add quirk for mpc8308 pcie bridge
From: Ilya Yanok @ 2010-07-08 20:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ilya Yanok, wd, dzu
In-Reply-To: <1278619839-23998-1-git-send-email-yanok@emcraft.com>
This patch adds the quirk for PCIE controller found on Freescale MPC8308.
The quirk is the same as for other MPC83xx processors.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/powerpc/sysdev/fsl_pci.c | 1 +
include/linux/pci_ids.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index a14760f..7e900ec 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -412,6 +412,7 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P4080, quirk_fsl_pcie_header);
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8308, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8314E, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8314, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8315E, quirk_fsl_pcie_header);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 3bedcc1..79bb11f 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2264,6 +2264,7 @@
#define PCI_DEVICE_ID_TDI_EHCI 0x0101
#define PCI_VENDOR_ID_FREESCALE 0x1957
+#define PCI_DEVICE_ID_MPC8308 0xc006
#define PCI_DEVICE_ID_MPC8315E 0x00b4
#define PCI_DEVICE_ID_MPC8315 0x00b5
#define PCI_DEVICE_ID_MPC8314E 0x00b6
--
1.6.2.5
^ permalink raw reply related
* [PATCH 0/2] Support for MPC8308RDB development board
From: Ilya Yanok @ 2010-07-08 20:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ilya Yanok, wd, dzu
These two patches add support for MPC8308RDB development board from Freescale.
Supported hardware:
DUART
Dual Ethernet
NOR and NAND flashes
I2C
USB device
PCIE (MSI support is broken by commit 3da34aa)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
^ permalink raw reply
* Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Milton Miller @ 2010-07-09 20:18 UTC (permalink / raw)
To: msm; +Cc: kumar.gala, linuxppc-dev
On Thu, 08 Jul 2010 around 09:27:15 -0500 Matthew McClintock wrote:
> On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
> > On Wed, 07 Jul 2010 around 10:51:20 -0000 Matthew McClintock wrote:
...
> > > Fix sizes of variables so correct values are exported via /proc.
> > > Cast variable in comparison to avoid compiler error.
> > >
> > > diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> > > index bb3d893..ec7f054 100644
> > > --- a/arch/powerpc/kernel/machine_kexec.c
> > > +++ b/arch/powerpc/kernel/machine_kexec.c
> > > @@ -145,6 +145,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
> > >
> > > /* Values we need to export to the second kernel via the device tree. */
> > > static unsigned long kernel_end;
> > > +static unsigned long crashk_start;
> > > static unsigned long crashk_size;
> > >
> > > static struct property kernel_end_prop = {
> > > @@ -156,7 +157,7 @@ static struct property kernel_end_prop = {
> > > static struct property crashk_base_prop = {
> > > .name = "linux,crashkernel-base",
> > > .length = sizeof(unsigned long),
> > > - .value = &crashk_res.start,
> > > + .value = &crashk_start,
> > > };
> > >
> >
> > This is wrong, its truncating the start and size.
> >
> > Change the variables to be physaddr_t and the length to be sizeof(physaddr_t).
> >
> > Since these properites only contain one variable, the number of cells
> > can be inferred from the property size like we do for reading the initrd-size.
> >
> > Technically they should be an array of be32 but we can make that a comment.
>
> I don't disagree but this can break kexec if phys_addr_t != unsigned
> long. Also, doesn't the crash kernel have to live below 2GB so unsigned
> long is always fine?
Its could only break kexec for the case of phys_addr_t != unsigned long
which you are fixing, and its the right way to fix it. There is nothing
inherent in linux requiring the crash kernel to be below 2G, although
there may be limitations of the current kernel that require such a limit.
>
> Will still change unless I hear otherwise.
>
> >
> > By the way, why does 32 bit care about the running kernel's size? aka
> > linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks
> > to copy the pages to their destination, but I thought ppc32 was using
> > a relocatable copy routine. Are we missing the code to create
> > temp ref tlbs on the fly for book 3E?
>
> This is not really in this patch or did I miss something? Kexec uses
> kernel-end just to add as a invalid region. Not crucial though for 32
> bit.
No its not in this patch, hence "By the way". I figured you might have
some knowledge as you were working in this area. If there is no reason
to have the kernel region blocked for 32 bit, then it should be removed.
Obviously from kexec-tools first, and then after some time we could move
its export to be only for 64-bit (or only 64 bit book-3S?)
It only causes additional time for traditional, and memory fragmentation
for book 3E, if you disallow memory below the current kernel end. For
that matter, on 3E, does this limit creep as you repeatedly reboot?
milton
^ permalink raw reply
* Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx)
From: Ilya Yanok @ 2010-07-08 20:36 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
Hi Kumar, All,
I've found that MSI work correctly with older kernels on my MPC8308RDB
board and don't work with newer ones. After bisecting I've found that
the source of the problem is commit 3da34aa:
commit 3da34aae03d498ee62f75aa7467de93cce3030fd
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue May 12 15:51:56 2009 -0500
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
Its feasible based on how the PCI address map is setup that the region
of PCI address space used for MSIs differs for each PHB on the same
SoC.
Instead of assuming that the address mappes to CCSRBAR 1:1 we read
PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
I can see BAR0 initialization for 85xx/86xx hardware but not for 83xx
neigher in the kernel nor in U-Boot (that makes me think that all 83xx
can be affected).
I'm not actually an PCI expert so I've just tried to write IMMR base
address to the BAR0 register from the U-Boot to get the correct address
but this doesn't help.
Please direct me how to init 83xx PCIE controller to make it compatible
with this patch.
Thanks in advance.
Regards, Ilya.
^ permalink raw reply
* [PATCH 2/2] mpc8308rdb: support for MPC8308RDB board from Freescale
From: Ilya Yanok @ 2010-07-08 20:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ilya Yanok, wd, dzu
In-Reply-To: <1278619839-23998-1-git-send-email-yanok@emcraft.com>
This patch adds support for MPC8308RDB development board from
Freescale.
Supported devices:
DUART
Dual Ethernet
NOR and NAND flashes
I2C
USB in peripheral mode
PCIE support is broken by the commit 3da34aa ("powerpc/fsl: Support
unique MSI addresses per PCIe Root Complex"). Works after revert.
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/powerpc/boot/dts/mpc8308rdb.dts | 303 +++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/Kconfig | 8 +
arch/powerpc/platforms/83xx/Makefile | 1 +
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 94 +++++++++
4 files changed, 406 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8308rdb.dts
create mode 100644 arch/powerpc/platforms/83xx/mpc830x_rdb.c
diff --git a/arch/powerpc/boot/dts/mpc8308rdb.dts b/arch/powerpc/boot/dts/mpc8308rdb.dts
new file mode 100644
index 0000000..a97eb2d
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8308rdb.dts
@@ -0,0 +1,303 @@
+/*
+ * MPC8308RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ * Copyright 2010 Ilya Yanok, Emcraft Systems, yanok@emcraft.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "fsl,mpc8308rdb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8308@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <16384>;
+ i-cache-size = <16384>;
+ timebase-frequency = <0>; // from bootloader
+ bus-frequency = <0>; // from bootloader
+ clock-frequency = <0>; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x08000000>; // 128MB at 0
+ };
+
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8315-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+
+ // CS0 and CS1 are swapped when
+ // booting from nand, but the
+ // addresses are the same.
+ ranges = <0x0 0x0 0xfe000000 0x00800000
+ 0x1 0x0 0xe0600000 0x00002000
+ 0x2 0x0 0xf0000000 0x00020000
+ 0x3 0x0 0xfa000000 0x00008000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x800000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ u-boot@0 {
+ reg = <0x0 0x60000>;
+ read-only;
+ };
+ env@60000 {
+ reg = <0x60000 0x10000>;
+ };
+ env1@70000 {
+ reg = <0x70000 0x10000>;
+ };
+ kernel@80000 {
+ reg = <0x80000 0x200000>;
+ };
+ dtb@280000 {
+ reg = <0x280000 0x10000>;
+ };
+ ramdisk@290000 {
+ reg = <0x290000 0x570000>;
+ };
+ };
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8315-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <0x1 0x0 0x2000>;
+
+ jffs2@0 {
+ reg = <0x0 0x2000000>;
+ };
+ };
+ };
+
+ immr@e0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,mpc8315-immr", "simple-bus";
+ ranges = <0 0xe0000000 0x00100000>;
+ reg = <0xe0000000 0x00000200>;
+ bus-frequency = <0>;
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <14 0x8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ rtc@68 {
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ };
+ };
+
+ usb@23000 {
+ compatible = "fsl-usb2-dr";
+ reg = <0x23000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&ipic>;
+ interrupts = <38 0x8>;
+ dr_mode = "peripheral";
+ phy_type = "ulpi";
+ };
+
+ enet0: ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x24000 0x1000>;
+
+ cell-index = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x24000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <32 0x8 33 0x8 34 0x8>;
+ interrupt-parent = <&ipic>;
+ tbi-handle = < &tbi0 >;
+ phy-handle = < &phy2 >;
+ fsl,magic-packet;
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x520 0x20>;
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&ipic>;
+ interrupts = <17 0x8>;
+ reg = <0x2>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ enet1: ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <1>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x25000 0x1000>;
+ ranges = <0x0 0x25000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <35 0x8 36 0x8 37 0x8>;
+ interrupt-parent = <&ipic>;
+ tbi-handle = < &tbi1 >;
+ /* Vitesse 7385 isn't on the MDIO bus */
+ fixed-link = <1 1 1000 0 0>;
+ fsl,magic-packet;
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <133333333>;
+ interrupts = <9 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <133333333>;
+ interrupts = <10 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ gpio@c00 {
+ #gpio-cells = <2>;
+ device_type = "gpio";
+ compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
+ reg = <0xc00 0x18>;
+ interrupts = <74 0x8>;
+ interrupt-parent = <&ipic>;
+ gpio-controller;
+ };
+
+ /* IPIC
+ * interrupts cell = <intr #, sense>
+ * sense values match linux IORESOURCE_IRQ_* defines:
+ * sense == 8: Level, low assertion
+ * sense == 2: Edge, high-to-low change
+ */
+ ipic: interrupt-controller@700 {
+ compatible = "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x700 0x100>;
+ device_type = "ipic";
+ };
+
+ ipic-msi@7c0 {
+ compatible = "fsl,ipic-msi";
+ reg = <0x7c0 0x40>;
+ msi-available-ranges = <0x0 0x100>;
+ interrupts = < 0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8 >;
+ interrupt-parent = < &ipic >;
+ };
+
+ };
+
+ pci0: pcie@e0009000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "fsl,mpc8308-pcie", "fsl,mpc8314-pcie";
+ reg = <0xe0009000 0x00001000
+ 0xb0000000 0x01000000>;
+ ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xb1000000 0 0x00800000>;
+ bus-range = <0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0 0 0 1 &ipic 1 8
+ 0 0 0 2 &ipic 1 8
+ 0 0 0 3 &ipic 1 8
+ 0 0 0 4 &ipic 1 8>;
+ interrupts = <0x1 0x8>;
+ interrupt-parent = <&ipic>;
+ clock-frequency = <0>;
+
+ pcie@0 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ reg = <0 0 0 0 0>;
+ ranges = <0x02000000 0 0xa0000000
+ 0x02000000 0 0xa0000000
+ 0 0x10000000
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00800000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index f49a254..021763a 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -9,6 +9,14 @@ menuconfig PPC_83xx
if PPC_83xx
+config MPC830x_RDB
+ bool "Freescale MPC830x RDB"
+ select DEFAULT_UIMAGE
+ select PPC_MPC831x
+ select FSL_GTM
+ help
+ This option enables support for the MPC8308 RDB board.
+
config MPC831x_RDB
bool "Freescale MPC831x RDB"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index e139c36..6e8bbbb 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -4,6 +4,7 @@
obj-y := misc.o usb.o
obj-$(CONFIG_SUSPEND) += suspend.o suspend-asm.o
obj-$(CONFIG_MCU_MPC8349EMITX) += mcu_mpc8349emitx.o
+obj-$(CONFIG_MPC830x_RDB) += mpc830x_rdb.o
obj-$(CONFIG_MPC831x_RDB) += mpc831x_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o
diff --git a/arch/powerpc/platforms/83xx/mpc830x_rdb.c b/arch/powerpc/platforms/83xx/mpc830x_rdb.c
new file mode 100644
index 0000000..ac102ee
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mpc830x_rdb.c
@@ -0,0 +1,94 @@
+/*
+ * arch/powerpc/platforms/83xx/mpc830x_rdb.c
+ *
+ * Description: MPC830x RDB board specific routines.
+ * This file is based on mpc831x_rdb.c
+ *
+ * Copyright (C) Freescale Semiconductor, Inc. 2009. All rights reserved.
+ * Copyright (C) 2010. Ilya Yanok, Emcraft Systems, yanok@emcraft.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+#include <asm/time.h>
+#include <asm/ipic.h>
+#include <asm/udbg.h>
+#include <sysdev/fsl_pci.h>
+#include <sysdev/fsl_soc.h>
+#include "mpc83xx.h"
+
+/*
+ * Setup the architecture
+ */
+static void __init mpc830x_rdb_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
+
+ if (ppc_md.progress)
+ ppc_md.progress("mpc830x_rdb_setup_arch()", 0);
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,mpc8308-pcie")
+ mpc83xx_add_bridge(np);
+#endif
+ mpc831x_usb_cfg();
+}
+
+static void __init mpc830x_rdb_init_IRQ(void)
+{
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, "ipic");
+ if (!np)
+ return;
+
+ ipic_init(np, 0);
+
+ /* Initialize the default interrupt mapping priorities,
+ * in case the boot rom changed something on us.
+ */
+ ipic_set_default_priority();
+}
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc830x_rdb_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "MPC8308RDB") ||
+ of_flat_dt_is_compatible(root, "fsl,mpc8308rdb");
+}
+
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .compatible = "simple-bus" },
+ { .compatible = "gianfar" },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ return 0;
+}
+machine_device_initcall(mpc830x_rdb, declare_of_platform_devices);
+
+define_machine(mpc830x_rdb) {
+ .name = "MPC830x RDB",
+ .probe = mpc830x_rdb_probe,
+ .setup_arch = mpc830x_rdb_setup_arch,
+ .init_IRQ = mpc830x_rdb_init_IRQ,
+ .get_irq = ipic_get_irq,
+ .restart = mpc83xx_restart,
+ .time_init = mpc83xx_time_init,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Albrecht Dreß @ 2010-07-08 20:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: David Woodhouse, Steve Deiters, linuxppc-dev
In-Reply-To: <DC489835-1F97-49DA-A00C-7D73D0EC0900@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
Am 08.07.10 21:30 schrieb(en) Segher Boessenkool:
>> Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept?
>
> There already is "device-width"; the drivers never should use any other access width unless they *know* that will work.
Hmm, unfortunately, it's usage is not clearly documented in mtd-physmap.txt, so I never thought of this parameter. And IMHO the problem goes further - basically *any* chip which is attached to the LPB can be affected by this problem, so it might be better to have a more general approach like a "chip select property".
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Scott Wood @ 2010-07-08 20:09 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Albrecht Dreß, Steve Deiters, linuxppc-dev, David Woodhouse
In-Reply-To: <DC489835-1F97-49DA-A00C-7D73D0EC0900@kernel.crashing.org>
On Thu, 8 Jul 2010 21:30:33 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > Actually, this is something which might need closer attention -
> > and maybe some support in the device tree indicating which read or
> > write width a device can accept?
>
> There already is "device-width"; the drivers never should use any
> other access width unless they *know* that will work.
Wouldn't you want to use "bank-width" instead? "device-width" might
not even work if, say, you've got two 8-bit chips interleaved, feeding
into a bus controller in 16-bit mode that only accepts 16-bit accesses.
It would be nice to have a device tree property that can specify that
all access widths supported by the CPU will work, though.
-Scott
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Marc Chidester @ 2010-07-08 19:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Lee Nipper
In-Reply-To: <20100708182455.GC28969@zod.rchland.ibm.com>
On Thu, Jul 8, 2010 at 2:24 PM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wro=
te:
> On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>> It looks like the Rev D version of the 405EX chip without security
>>> will be identified as a 405EXr, based on the values in the cpu_specs
>>> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
>>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>>> Rev D PVR value for the 405EX without security is 0x12911473, which
>>> would mask out to the EXr value.
>>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>With 405EX Rev D, we have noticed that we must reset our board
>>one time after the initial powerup to make the PVR read correctly.
>>
>>See this post:
>>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
>
> That is very very weird. =A0Have you seen that behavior on multiple Rev D=
CPUs
> or just one board or?
>
> The PVR value should never change, so if you have odd behavior I wonder i=
f the
> are silicon bugs in that revision. =A0Did you happen to ask AMCC about it=
?
>
> josh
>
Check the recent Errata for the chip on this issue.
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Segher Boessenkool @ 2010-07-08 19:30 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev, Steve Deiters, David Woodhouse
In-Reply-To: <1278614421.1801.0@antares>
> Actually, this is something which might need closer attention - and
> maybe some support in the device tree indicating which read or
> write width a device can accept?
There already is "device-width"; the drivers never should use any other
access width unless they *know* that will work.
Segher
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Lee Nipper @ 2010-07-08 19:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20100708182210.GB28969@zod.rchland.ibm.com>
On Thu, Jul 8, 2010 at 13:22, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote=
:
> On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
>>pvr_mask =3D 0xffff000f =A0?
>
> Have you tried that in a locally modified kernel? =A0If so, did it work? =
=A0If so,
> care to submit a patch? :)
>
I have not yet. I will prepare a patch.
Lee
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Lee Nipper @ 2010-07-08 18:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20100708182455.GC28969@zod.rchland.ibm.com>
On Thu, Jul 8, 2010 at 13:24, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote=
:
> On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>> It looks like the Rev D version of the 405EX chip without security
>>> will be identified as a 405EXr, based on the values in the cpu_specs
>>> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
>>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>>> Rev D PVR value for the 405EX without security is 0x12911473, which
>>> would mask out to the EXr value.
>>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>With 405EX Rev D, we have noticed that we must reset our board
>>one time after the initial powerup to make the PVR read correctly.
>>
>>See this post:
>>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
>
> That is very very weird. =A0Have you seen that behavior on multiple Rev D=
CPUs
> or just one board or?
>
Multiple Rev D CPUs. In fact, ALL of the samples we obtained behave this w=
ay.
> The PVR value should never change, so if you have odd behavior I wonder i=
f the
> are silicon bugs in that revision. =A0Did you happen to ask AMCC about it=
?
>
Yes, I did.
AMCC suggested doing an early one-time s/w reset to make the PVR read
"correctly" afterwards.
Since we only support one specific 405EX variety, we could do that.
However, on a generic u-boot, there is no way to know if a "correct"
PVR is read,
so that approach is not a solution.
I'm wondering if our power on reset circuitry is not entirely correct,
and it showed up with the Rev D part. I received no comments on my
original post
from other users of the 405EX, so I'm thinking it is a possible explanation=
.
Does anyone have a board with a 405EX Rev D ?
If so, does the PVR value match your processor chip after power up ?
Lee
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Albrecht Dreß @ 2010-07-08 18:40 UTC (permalink / raw)
To: Grant Likely; +Cc: David Woodhouse, Steve Deiters, linuxppc-dev
In-Reply-To: <AANLkTikP_ZrWddakihhslDHphEaDsW-IQY4C-lDoXEgm@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]
Am 08.07.10 17:22 schrieb(en) Grant Likely:
>> Just out of curiousity, what configuration might cause a byte-wise alignment not to work?
>
> Can't remember the register configuration, but I worked on one project where this was the case. In hindsight, it was probably a mis-configuration of the localbus CS for the particular device.
Not sure if you're thinking of this configuration, but if you attach a device in 16-bit mode (i.e. 16 data lines) to the LPB, byte writes simply don't work. I ran into that problem as I have a nvram attached this way to a 5200b. Using the device as mtd-ram with a jffs2 file system on it I also sometimes saw corruption after a write.
I had a patch for that last year, but it was actually badly crafted (see <http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072903.html>). I still use the mpc52xx_memcpy2lpb16() function somewhere in my current code which is actually an ugly hack (but it works...).
Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept?
Best, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Josh Boyer @ 2010-07-08 18:24 UTC (permalink / raw)
To: Lee Nipper; +Cc: linuxppc-dev
In-Reply-To: <AANLkTim8xuZSaDHyxRVqk63PTT66rrR8hUhEDeNzfmKD@mail.gmail.com>
On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
>> It looks like the Rev D version of the 405EX chip without security
>> will be identified as a 405EXr, based on the values in the cpu_specs
>> table. For 405EX/405EXr the pvr_mask is 0xffff0004 with the
>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>> Rev D PVR value for the 405EX without security is 0x12911473, which
>> would mask out to the EXr value.
>>
>> Is there an algorithm update needed or am I missing something?
>
>With 405EX Rev D, we have noticed that we must reset our board
>one time after the initial powerup to make the PVR read correctly.
>
>See this post:
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
That is very very weird. Have you seen that behavior on multiple Rev D CPUs
or just one board or?
The PVR value should never change, so if you have odd behavior I wonder if the
are silicon bugs in that revision. Did you happen to ask AMCC about it?
josh
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Josh Boyer @ 2010-07-08 18:22 UTC (permalink / raw)
To: Lee Nipper; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikCFgFZsAl0QLkZbI1Jbrh8v0d7gK9EVtqCe1QU@mail.gmail.com>
On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote:
>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
>> It looks like the Rev D version of the 405EX chip without security
>> will be identified as a 405EXr, based on the values in the cpu_specs
>> table.
>
>Yes, that is the case.
>The 405EX Rev D without security PVR matches an old 405EXr A/B with security,
>and hence the cpu_spec entries' pvr_mask values are no longer correct.
>
>> Is there an algorithm update needed or am I missing something?
>
>Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
>pvr_mask = 0xffff000f ?
Have you tried that in a locally modified kernel? If so, did it work? If so,
care to submit a patch? :)
josh
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Lee Nipper @ 2010-07-08 17:59 UTC (permalink / raw)
To: Marc Chidester; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikrUvEicL1DaeLz9Vr-lE_hkKZqJi_7qzERZMu8@mail.gmail.com>
On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
> It looks like the Rev D version of the 405EX chip without security
> will be identified as a 405EXr, based on the values in the cpu_specs
> table.
Yes, that is the case.
The 405EX Rev D without security PVR matches an old 405EXr A/B with security,
and hence the cpu_spec entries' pvr_mask values are no longer correct.
> Is there an algorithm update needed or am I missing something?
Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
pvr_mask = 0xffff000f ?
^ permalink raw reply
* [PATCH 3/3] powerpc/cpm1: Mark micropatch code/data static and __init
From: Anton Vorontsov @ 2010-07-08 17:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: LEROY Christophe, linuxppc-dev, Scott Wood
This saves runtime memory and fixes lots of sparse warnings like this:
CHECK arch/powerpc/sysdev/micropatch.c
arch/powerpc/sysdev/micropatch.c:27:6: warning: symbol 'patch_2000'
was not declared. Should it be static?
arch/powerpc/sysdev/micropatch.c:146:6: warning: symbol 'patch_2f00'
was not declared. Should it be static?
...
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/powerpc/include/asm/cpm1.h | 3 ++-
arch/powerpc/sysdev/micropatch.c | 18 +++++++++---------
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm1.h b/arch/powerpc/include/asm/cpm1.h
index 81b0119..bd07650 100644
--- a/arch/powerpc/include/asm/cpm1.h
+++ b/arch/powerpc/include/asm/cpm1.h
@@ -17,6 +17,7 @@
#ifndef __CPM1__
#define __CPM1__
+#include <linux/init.h>
#include <asm/8xx_immap.h>
#include <asm/ptrace.h>
#include <asm/cpm.h>
@@ -54,7 +55,7 @@ extern cpm8xx_t __iomem *cpmp; /* Pointer to comm processor */
extern void cpm_setbrg(uint brg, uint rate);
-extern void cpm_load_patch(cpm8xx_t *cp);
+extern void __init cpm_load_patch(cpm8xx_t *cp);
extern void cpm_reset(void);
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index 6c56ae9..c0bb76e 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -4,6 +4,7 @@
* also relocates SMC2, but this would require additional changes
* to uart.c, so I am holding off on that for a moment.
*/
+#include <linux/init.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/kernel.h>
@@ -25,7 +26,7 @@
#ifdef CONFIG_I2C_SPI_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x7FFFEFD9,
0x3FFD0000,
0x7FFB49F7,
@@ -144,7 +145,7 @@ uint patch_2000[] = {
0x5F8247F8
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x3E303430,
0x34343737,
0xABF7BF9B,
@@ -183,7 +184,7 @@ uint patch_2f00[] = {
#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x3fff0000,
0x3ffd0000,
0x3ffb0000,
@@ -506,7 +507,7 @@ uint patch_2000[] = {
0x6079e2bb
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x30303030,
0x3e3e3434,
0xabbf9b99,
@@ -573,7 +574,7 @@ uint patch_2f00[] = {
0xf22f3f23
};
-uint patch_2e00[] = {
+static uint patch_2e00[] __initdata = {
0x27eeeeee,
0xeeeeeeee,
0xeeeeeeee,
@@ -599,7 +600,7 @@ uint patch_2e00[] = {
#ifdef CONFIG_USB_SOF_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x7fff0000,
0x7ffd0000,
0x7ffb0000,
@@ -614,15 +615,14 @@ uint patch_2000[] = {
0x60750000
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x3030304c,
0xcab9e441,
0xa1aaf220
};
#endif
-void
-cpm_load_patch(cpm8xx_t *cp)
+void __init cpm_load_patch(cpm8xx_t *cp)
{
volatile uint *dp; /* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
--
1.7.0.5
^ permalink raw reply related
* [PATCH 2/3] powerpc/cpm1: Fix build with various CONFIG_*_UCODE_PATCH combinations
From: Anton Vorontsov @ 2010-07-08 17:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: LEROY Christophe, linuxppc-dev, Scott Wood
Warnings are treated as errors for arch/powerpc code, so build fails
with CONFIG_I2C_SPI_UCODE_PATCH=y:
CC arch/powerpc/sysdev/micropatch.o
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
And with CONFIG_USB_SOF_UCODE_PATCH=y:
CC arch/powerpc/sysdev/micropatch.o
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:629: warning: unused variable 'spp'
arch/powerpc/sysdev/micropatch.c:628: warning: unused variable 'iip'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
This patch fixes these issues by introducing proper #ifdefs.
Cc: <stable@kernel.org> [ .33, .34 ]
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/powerpc/sysdev/micropatch.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index 18080f3..6c56ae9 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -626,9 +626,14 @@ cpm_load_patch(cpm8xx_t *cp)
{
volatile uint *dp; /* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
+#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
+ defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
volatile iic_t *iip;
volatile struct spi_pram *spp;
+#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
volatile smc_uart_t *smp;
+#endif
+#endif
int i;
commproc = cp;
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/3] powerpc/cpm: Reintroduce global spi_pram struct (fixes build issue)
From: Anton Vorontsov @ 2010-07-08 17:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: LEROY Christophe, linuxppc-dev, Scott Wood
spi_t was removed in commit 644b2a680ccc51a9ec4d6beb12e9d47d2dee98e2
("powerpc/cpm: Remove SPI defines and spi structs"), the commit assumed
that spi_t isn't used anywhere outside of the spi_mpc8xxx driver. But
it appears that the struct is needed for micropatch code. So, let's
reintroduce the struct.
Fixes the following build issue:
CC arch/powerpc/sysdev/micropatch.o
micropatch.c: In function 'cpm_load_patch':
micropatch.c:629: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
micropatch.c:629: error: 'spp' undeclared (first use in this function)
micropatch.c:629: error: (Each undeclared identifier is reported only once
micropatch.c:629: error: for each function it appears in.)
Reported-by: LEROY Christophe <christophe.leroy@c-s.fr>
Reported-by: Tony Breeds <tony@bakeyournoodle.com>
Cc: <stable@kernel.org> [ .33, .34 ]
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/powerpc/include/asm/cpm.h | 24 ++++++++++++++++++++++++
arch/powerpc/sysdev/micropatch.c | 7 ++++---
drivers/spi/spi_mpc8xxx.c | 22 ----------------------
3 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
index 0835eb9..e50323f 100644
--- a/arch/powerpc/include/asm/cpm.h
+++ b/arch/powerpc/include/asm/cpm.h
@@ -7,6 +7,30 @@
#include <linux/of.h>
/*
+ * SPI Parameter RAM common to QE and CPM.
+ */
+struct spi_pram {
+ __be16 rbase; /* Rx Buffer descriptor base address */
+ __be16 tbase; /* Tx Buffer descriptor base address */
+ u8 rfcr; /* Rx function code */
+ u8 tfcr; /* Tx function code */
+ __be16 mrblr; /* Max receive buffer length */
+ __be32 rstate; /* Internal */
+ __be32 rdp; /* Internal */
+ __be16 rbptr; /* Internal */
+ __be16 rbc; /* Internal */
+ __be32 rxtmp; /* Internal */
+ __be32 tstate; /* Internal */
+ __be32 tdp; /* Internal */
+ __be16 tbptr; /* Internal */
+ __be16 tbc; /* Internal */
+ __be32 txtmp; /* Internal */
+ __be32 res; /* Tx temp. */
+ __be16 rpbase; /* Relocation pointer (CPM1 only) */
+ __be16 res1; /* Reserved */
+};
+
+/*
* USB Controller pram common to QE and CPM.
*/
struct usb_ctlr {
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index d8d6028..18080f3 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -16,6 +16,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/8xx_immap.h>
+#include <asm/cpm.h>
#include <asm/cpm1.h>
/*
@@ -626,7 +627,7 @@ cpm_load_patch(cpm8xx_t *cp)
volatile uint *dp; /* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
volatile iic_t *iip;
- volatile spi_t *spp;
+ volatile struct spi_pram *spp;
volatile smc_uart_t *smp;
int i;
@@ -668,8 +669,8 @@ cpm_load_patch(cpm8xx_t *cp)
/* Put SPI above the IIC, also 32-byte aligned.
*/
i = (RPBASE + sizeof(iic_t) + 31) & ~31;
- spp = (spi_t *)&commproc->cp_dparam[PROFF_SPI];
- spp->spi_rpbase = i;
+ spp = (struct spi_pram *)&commproc->cp_dparam[PROFF_SPI];
+ spp->rpbase = i;
# if defined(CONFIG_I2C_SPI_UCODE_PATCH)
commproc->cp_cpmcr1 = 0x802a;
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index ffa111a..97ab0a8 100644
--- a/drivers/spi/spi_mpc8xxx.c
+++ b/drivers/spi/spi_mpc8xxx.c
@@ -66,28 +66,6 @@ struct mpc8xxx_spi_reg {
__be32 receive;
};
-/* SPI Parameter RAM */
-struct spi_pram {
- __be16 rbase; /* Rx Buffer descriptor base address */
- __be16 tbase; /* Tx Buffer descriptor base address */
- u8 rfcr; /* Rx function code */
- u8 tfcr; /* Tx function code */
- __be16 mrblr; /* Max receive buffer length */
- __be32 rstate; /* Internal */
- __be32 rdp; /* Internal */
- __be16 rbptr; /* Internal */
- __be16 rbc; /* Internal */
- __be32 rxtmp; /* Internal */
- __be32 tstate; /* Internal */
- __be32 tdp; /* Internal */
- __be16 tbptr; /* Internal */
- __be16 tbc; /* Internal */
- __be32 txtmp; /* Internal */
- __be32 res; /* Tx temp. */
- __be16 rpbase; /* Relocation pointer (CPM1 only) */
- __be16 res1; /* Reserved */
-};
-
/* SPI Controller mode register definitions */
#define SPMODE_LOOP (1 << 30)
#define SPMODE_CI_INACTIVEHIGH (1 << 29)
--
1.7.0.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox