* [v1 PATCH 0/3] Add CPC925 Memory Controller EDAC drivers
From: Harry Ciao @ 2009-04-03 5:59 UTC (permalink / raw)
To: norsk5, bluesmoke-devel, linuxppc-dev; +Cc: linux-kernel
Hi Doug and PPC developers,
This is v1 series of patches for CPC925 Memory Controller EDAC driver that works on PPC970FX. I have taken Arnd's suggestion to fold header/source/etc into one file and makes CONFIG_EDAC_CPC925 depend on CONFIG_PPC64.
Please take a look and give your comments, many thanks!
Best regards,
Harry
^ permalink raw reply
* Re: [v0 PATCH 5/5] EDAC: CPC925 MC platform device setup
From: Harry Ciao @ 2009-04-03 5:49 UTC (permalink / raw)
To: qingtao.cao
Cc: linuxppc-dev, norsk5, linux-kernel, Arnd Bergmann,
bluesmoke-devel
In-Reply-To: <49D57FBA.3090508@windriver.com>
Harry Ciao 写道:
> Arnd Bergmann 写道:
>> On Thursday 02 April 2009, Harry Ciao wrote:
>>
>>> +#ifdef CONFIG_EDAC
>>> +#define CPC925_MC_START 0xf8000000
>>> +#define CPC925_MC_END 0xf8ffffff /* sizeof 16MB */
>>> +/* Register a platform device for CPC925 memory controller */
>>> +static int __init maple_cpc925_edac_setup(void)
>>>
>>
>> It's not good to have these encoded as magic numbers.
>> Can't you find the addresses in the device tree? Maybe it's
>> even possible to make this an of_platform_driver if you
>> find a good node to bind to.
>>
>> Does the driver also work on a G5 Mac, or is it limited
>> to the maple platform?
>>
>> Arnd <><
>>
>>
Hi Arnd,
I forgot to mention that so far I have tested this CPC925 driver on the
Maple platform, I have no G5 Mac to test with.
CPC925 is specific to the PowerPC 970 family of processors, but I don't
think Maple is the only platform that ever use PowerPC 970
processors(that is why this driver should depend on PP64, rather than
PPC_MAPLE).
Thanks,
Harry
> Hi Arnd,
>
> I did try to get resource information from its DTB node first, the
> "hostbridge" node do can be found successfully, however,
> unfortunately, as I put in the notes in that function, the
> #address-cells and #size-cells specified by its parent node are both
> 2, but the cell number used in its "reg" property is actually 1, as
>
> reg = <0xf8000000 0x1000000>;
>
> which will make of_address_to_resource() failed with -EINVAL; that's
> why I have to set it up from scratch manually.
>
> Cheers,
>
> Harry
>
>
>
^ permalink raw reply
* Re: [PATCH] powerpc ptrace block-step
From: Roland McGrath @ 2009-04-03 1:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: utrace-devel, linuxppc-dev
In-Reply-To: <20090403011327.GA16881@zod.rchland.ibm.com>
> I don't think having it working for BookE is really a requirement before this
> gets in though. If we can get it working with minimal effort for ppc64, that
> would help get systemtap and related things functioning correctly there.
Sure, just conditionalize arch_has_block_step() however is correct for that
and put in what already works earlier rather than later, I'd say. Then
users of the excluded chips can come forward when they care, and you can
worry about it then if you don't happen to get to it first.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH] powerpc ptrace block-step
From: Benjamin Herrenschmidt @ 2009-04-03 1:43 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev, utrace-devel
In-Reply-To: <20090403004450.F2166FC3AB@magilla.sf.frob.com>
On Thu, 2009-04-02 at 17:44 -0700, Roland McGrath wrote:
> > The patch only implements it for "server/classic" processors, not BookE,
> > thus it should probably only advertise it for these :-)
> >
> > Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
> > (Branch Taken debug event) though it might need some careful fixups such
> > as the one we have for single step regarding hitting exception entry
> > code.
>
> In that case, this code seems fairly mysterious:
>
> > > +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> > > + task->thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
> > > + regs->msr |= MSR_DE;
>
> That doesn't already do whatever it is you described?
It should, I missed that bit. Except for the possible issue with
interrupts.
> Can we assume now that you or someone else who knows what all that means
> will take this up?
I can take this up after I'm back from vacation, which will be in about
4 weeks from now, but maybe Josh can give it a go in the meantime.
Basically, the "issue" with BookE is that the debug interrupts aren't
masked by the fact of taking an exception. So for example, if you have
single step enabled and take a TLB miss on a userland load, you'll take
a single step exception on the first (or rather the second but that's
a detail) instruction of the TLB miss exception vector.
The code for our BookE debug interrupts has a workaround that detects
that case and returns to the TLB miss vector with MSR:DE cleared, but
I think that code will not properly catch a similar things happening
due to block step. Though is should be easy to fix.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc ptrace block-step
From: Josh Boyer @ 2009-04-03 1:13 UTC (permalink / raw)
To: Roland McGrath; +Cc: utrace-devel, linuxppc-dev
In-Reply-To: <20090403004450.F2166FC3AB@magilla.sf.frob.com>
On Thu, Apr 02, 2009 at 05:44:50PM -0700, Roland McGrath wrote:
>> The patch only implements it for "server/classic" processors, not BookE,
>> thus it should probably only advertise it for these :-)
>>
>> Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
>> (Branch Taken debug event) though it might need some careful fixups such
>> as the one we have for single step regarding hitting exception entry
>> code.
>
>In that case, this code seems fairly mysterious:
>
>> > +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
>> > + task->thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
>> > + regs->msr |= MSR_DE;
>
>That doesn't already do whatever it is you described?
>
>Can we assume now that you or someone else who knows what all that means
>will take this up?
I will try and look at the patch a bit more tomorrow, yes.
I don't think having it working for BookE is really a requirement before this
gets in though. If we can get it working with minimal effort for ppc64, that
would help get systemtap and related things functioning correctly there.
While I would love to believe that systemtap should work everywhere, I can't
really see it running on an embedded board at this point.
josh
^ permalink raw reply
* Re: [PATCH] powerpc ptrace block-step
From: Roland McGrath @ 2009-04-03 0:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, utrace-devel
In-Reply-To: <1238650016.17330.193.camel@pasglop>
> The patch only implements it for "server/classic" processors, not BookE,
> thus it should probably only advertise it for these :-)
>
> Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
> (Branch Taken debug event) though it might need some careful fixups such
> as the one we have for single step regarding hitting exception entry
> code.
In that case, this code seems fairly mysterious:
> > +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> > + task->thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
> > + regs->msr |= MSR_DE;
That doesn't already do whatever it is you described?
Can we assume now that you or someone else who knows what all that means
will take this up?
Thanks,
Roland
^ permalink raw reply
* Please pull from 'next' branch (for 2.6.29)
From: Kumar Gala @ 2009-04-02 22:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Added a few minor commits..
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
arch/powerpc/Kconfig | 1 +
arch/powerpc/boot/dts/ksi8560.dts | 4 ++--
arch/powerpc/boot/dts/sbc8548.dts | 4 ++--
arch/powerpc/boot/dts/sbc8560.dts | 4 ++--
arch/powerpc/boot/dts/socrates.dts | 1 +
arch/powerpc/boot/dts/stx_gp3_8560.dts | 4 ++--
arch/powerpc/boot/dts/tqm8540.dts | 4 ++--
arch/powerpc/boot/dts/tqm8541.dts | 4 ++--
arch/powerpc/boot/dts/tqm8555.dts | 4 ++--
arch/powerpc/boot/dts/tqm8560.dts | 4 ++--
arch/powerpc/include/asm/reg.h | 30 ++++++++++++++++++++++++++++++
arch/powerpc/include/asm/reg_booke.h | 30 ------------------------------
arch/powerpc/include/asm/sfp-machine.h | 6 +++---
include/linux/fsl_devices.h | 22 ----------------------
14 files changed, 51 insertions(+), 71 deletions(-)
Grant Likely (1):
powerpc: Remove unused symbols from fsl_devices.h
Josh Boyer (1):
powerpc: Make LOWMEM_CAM_NUM depend on FSL_BOOKE
Kumar Gala (3):
powerpc/85xx: Use fsl,mpc85.. as prefix for memory ctrl & l2-cache nodes
powerpc: Move SPEFSCR defines to common header
powerpc/math-emu: Change types to work on ppc64
Wolfgang Grandegger (1):
powerpc/85xx: Re-add the device_type soc to socrates.dts
^ permalink raw reply
* Re: [RFC][PATCH] powerpc: Emulate enough of SPE instructions to make gcc happy
From: Kumar Gala @ 2009-04-02 22:13 UTC (permalink / raw)
To: Kyle McMartin; +Cc: linuxppc-dev
In-Reply-To: <20090402220947.GG14159@bombadil.infradead.org>
On Apr 2, 2009, at 5:09 PM, Kyle McMartin wrote:
> On Thu, Apr 02, 2009 at 05:04:47PM -0500, Kumar Gala wrote:
>> +config SPE_EMULATION
>> + bool "SPE Emulation Support"
>> + depends on (CLASSIC32 || POWER4) && !ALTIVEC && !SPE
>> + ---help---
>> + This option enables kernel support for the Altivec extensions
>> to the
>> +
>
> Looks like you kind of trailed off here... :)
Yeah, the patch is still a bit of a hack.. I'm just trying to gage
interest. If there is any than I'll spend some more effort to clean
it up.
:)
- k
^ permalink raw reply
* Re: [RFC][PATCH] powerpc: Emulate enough of SPE instructions to make gcc happy
From: Kyle McMartin @ 2009-04-02 22:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1238709887-26237-1-git-send-email-galak@kernel.crashing.org>
On Thu, Apr 02, 2009 at 05:04:47PM -0500, Kumar Gala wrote:
> +config SPE_EMULATION
> + bool "SPE Emulation Support"
> + depends on (CLASSIC32 || POWER4) && !ALTIVEC && !SPE
> + ---help---
> + This option enables kernel support for the Altivec extensions to the
> +
Looks like you kind of trailed off here... :)
cheers, Kyle
^ permalink raw reply
* [RFC][PATCH] powerpc: Emulate enough of SPE instructions to make gcc happy
From: Kumar Gala @ 2009-04-02 22:04 UTC (permalink / raw)
To: linuxppc-dev
Based on patch from Edmar Wienskoski
---
I posting this to see if anyone would possibly use this support if it was in
the stock kernel. It allows us to build and use e500/SPE toolchains on G5 HW.
- k
arch/powerpc/include/asm/processor.h | 6 +-
arch/powerpc/kernel/traps.c | 60 +++++++++-
arch/powerpc/math-emu/Makefile | 1 +
arch/powerpc/math-emu/math_efp.c | 219 +++++++++++++++++++++++++++++++-
arch/powerpc/platforms/Kconfig.cputype | 6 +
5 files changed, 286 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 9eed29e..331282c 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -191,12 +191,12 @@ struct thread_struct {
/* VSR status */
int used_vsr; /* set if process has used altivec */
#endif /* CONFIG_VSX */
-#ifdef CONFIG_SPE
+#if defined(CONFIG_SPE) || defined(CONFIG_SPE_EMULATION)
unsigned long evr[32]; /* upper 32-bits of SPE regs */
u64 acc; /* Accumulator */
unsigned long spefscr; /* SPE & eFP status */
int used_spe; /* set if process has used spe */
-#endif /* CONFIG_SPE */
+#endif /* CONFIG_SPE || CONFIG_SPE_EMULATION */
};
#define ARCH_MIN_TASKALIGN 16
@@ -205,7 +205,7 @@ struct thread_struct {
#define INIT_SP_LIMIT \
(_ALIGN_UP(sizeof(init_thread_info), 16) + (unsigned long) &init_stack)
-#ifdef CONFIG_SPE
+#if defined(CONFIG_SPE) || defined(CONFIG_SPE_EMULATION)
#define SPEFSCR_INIT .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE | SPEFSCR_FOVFE,
#else
#define SPEFSCR_INIT
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 678fbff..ebdd83a 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -798,6 +798,8 @@ int is_valid_bugaddr(unsigned long addr)
return is_kernel_addr(addr);
}
+int SPEFloatingPoint(struct pt_regs *);
+
void __kprobes program_check_exception(struct pt_regs *regs)
{
unsigned int reason = get_reason(regs);
@@ -830,6 +832,14 @@ void __kprobes program_check_exception(struct pt_regs *regs)
local_irq_enable();
+ switch (SPEFloatingPoint (regs)) {
+ case 0:
+ return;
+ case -ENOSYS:
+ _exception(SIGSEGV, regs, SEGV_MAPERR, regs->nip);
+ return;
+ }
+
#ifdef CONFIG_MATH_EMULATION
/* (reason & REASON_ILLEGAL) would be the obvious thing here,
* but there seems to be a hardware bug on the 405GP (RevD)
@@ -938,8 +948,10 @@ void altivec_unavailable_exception(struct pt_regs *regs)
if (user_mode(regs)) {
/* A user program has executed an altivec instruction,
but this kernel doesn't support altivec. */
- _exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
- return;
+ switch (SPEFloatingPoint (regs)) {
+ case 0:
+ return;
+ }
}
printk(KERN_EMERG "Unrecoverable VMX/Altivec Unavailable Exception "
@@ -1156,6 +1168,50 @@ void CacheLockingException(struct pt_regs *regs, unsigned long address,
}
#endif /* CONFIG_FSL_BOOKE */
+int SPEFloatingPoint(struct pt_regs *regs)
+{
+ extern int do_spe_mathemu(struct pt_regs *regs);
+ unsigned long spefscr;
+ int fpexc_mode;
+ int code = 0;
+ int err;
+
+ spefscr = current->thread.spefscr;
+ fpexc_mode = current->thread.fpexc_mode;
+
+ if ((spefscr & SPEFSCR_FOVF) && (fpexc_mode & PR_FP_EXC_OVF)) {
+ code = FPE_FLTOVF;
+ }
+ else if ((spefscr & SPEFSCR_FUNF) && (fpexc_mode & PR_FP_EXC_UND)) {
+ code = FPE_FLTUND;
+ }
+ else if ((spefscr & SPEFSCR_FDBZ) && (fpexc_mode & PR_FP_EXC_DIV))
+ code = FPE_FLTDIV;
+ else if ((spefscr & SPEFSCR_FINV) && (fpexc_mode & PR_FP_EXC_INV)) {
+ code = FPE_FLTINV;
+ }
+ else if ((spefscr & (SPEFSCR_FG | SPEFSCR_FX)) && (fpexc_mode & PR_FP_EXC_RES))
+ code = FPE_FLTRES;
+
+ err = do_spe_mathemu(regs);
+ if (err == 0) {
+ regs->nip += 4; /* skip emulated instruction */
+ emulate_single_step(regs);
+ return 0;
+ }
+
+ if (err == -EFAULT) {
+ /* got an error reading the instruction */
+ _exception(SIGSEGV, regs, SEGV_ACCERR, regs->nip);
+ } else if (err == -EINVAL || err == -ENOSYS) {
+ return 1;
+ } else {
+ _exception(SIGFPE, regs, code, regs->nip);
+ }
+
+ return 0;
+}
+
#ifdef CONFIG_SPE
void SPEFloatingPointException(struct pt_regs *regs)
{
diff --git a/arch/powerpc/math-emu/Makefile b/arch/powerpc/math-emu/Makefile
index 0c16ab9..f4eb888 100644
--- a/arch/powerpc/math-emu/Makefile
+++ b/arch/powerpc/math-emu/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MATH_EMULATION) += fabs.o fadd.o fadds.o fcmpo.o fcmpu.o \
math.o fmr.o lfd.o stfd.o
obj-$(CONFIG_SPE) += math_efp.o
+obj-$(CONFIG_SPE_EMULATION) += math_efp.o
CFLAGS_fabs.o = -fno-builtin-fabs
CFLAGS_math.o = -fno-builtin-fabs
diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c
index 41f4ef3..e9d9346 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -33,10 +33,26 @@
#define EFAPU 0x4
+#define VLD 0x0
+#define VST 0x1
#define VCT 0x4
#define SPFP 0x6
#define DPFP 0x7
+#define EVNEG 0x209
+#define EVAND 0x211
+#define EVANDC 0x212
+#define EVXOR 0x216
+#define EVOR 0x217
+#define EVNOR 0x218
+#define EVEQV 0x219
+#define EVORC 0x21b
+
+#define EVMERGEHI 0x22c
+#define EVMERGELO 0x22d
+#define EVMERGEHILO 0x22e
+#define EVMERGELOHI 0x22f
+
#define EFSADD 0x2c0
#define EFSSUB 0x2c1
#define EFSABS 0x2c4
@@ -48,6 +64,7 @@
#define EFSCMPLT 0x2cd
#define EFSCMPEQ 0x2ce
#define EFSCFD 0x2cf
+#define EFSCFUI 0x2d0
#define EFSCFSI 0x2d1
#define EFSCTUI 0x2d4
#define EFSCTSI 0x2d5
@@ -55,6 +72,9 @@
#define EFSCTSF 0x2d7
#define EFSCTUIZ 0x2d8
#define EFSCTSIZ 0x2da
+#define EFSTSTGT 0x2dc
+#define EFSTSTLT 0x2dd
+#define EFSTSTEQ 0x2de
#define EVFSADD 0x280
#define EVFSSUB 0x281
@@ -75,6 +95,8 @@
#define EFDADD 0x2e0
#define EFDSUB 0x2e1
+#define EFDCFUID 0x2e2
+#define EFDCFSID 0x2e3
#define EFDABS 0x2e4
#define EFDNABS 0x2e5
#define EFDNEG 0x2e6
@@ -86,12 +108,30 @@
#define EFDCMPLT 0x2ed
#define EFDCMPEQ 0x2ee
#define EFDCFS 0x2ef
+#define EFDCFUI 0x2f0
+#define EFDCFSI 0x2f1
#define EFDCTUI 0x2f4
#define EFDCTSI 0x2f5
#define EFDCTUF 0x2f6
#define EFDCTSF 0x2f7
#define EFDCTUIZ 0x2f8
#define EFDCTSIZ 0x2fa
+#define EFDTSTGT 0x2fc
+#define EFDTSTLT 0x2fd
+#define EFDTSTEQ 0x2fe
+
+#define EVLDDX 0x300
+#define EVLDD 0x301
+#define EVLDWX 0x302
+#define EVLDW 0x303
+#define EVLDHX 0x304
+#define EVLDH 0x305
+#define EVSTDDX 0x320
+#define EVSTDD 0x321
+#define EVSTDWX 0x322
+#define EVSTDW 0x323
+#define EVSTDHX 0x324
+#define EVSTDH 0x325
#define AB 2
#define XA 3
@@ -114,6 +154,20 @@ static unsigned long insn_type(unsigned long speinsn)
unsigned long ret = NOTYPE;
switch (speinsn & 0x7ff) {
+ case EVNEG: ret = XCR; break;
+ case EVAND: ret = XCR; break;
+ case EVANDC: ret = XCR; break;
+ case EVXOR: ret = XCR; break;
+ case EVOR: ret = XCR; break;
+ case EVNOR: ret = XCR; break;
+ case EVEQV: ret = XCR; break;
+ case EVORC: ret = XCR; break;
+
+ case EVMERGEHI: ret = XCR; break;
+ case EVMERGELO: ret = XCR; break;
+ case EVMERGEHILO: ret = XCR; break;
+ case EVMERGELOHI: ret = XCR; break;
+
case EFSABS: ret = XA; break;
case EFSADD: ret = AB; break;
case EFSCFD: ret = XB; break;
@@ -126,11 +180,15 @@ static unsigned long insn_type(unsigned long speinsn)
case EFSCTUF: ret = XB; break;
case EFSCTUI: ret = XB; break;
case EFSCTUIZ: ret = XB; break;
+ case EFSTSTGT: /* ret = XB;*/ break;
+ case EFSTSTLT: /* ret = XB;*/ break;
+ case EFSTSTEQ: /* ret = XB;*/ break;
case EFSDIV: ret = AB; break;
case EFSMUL: ret = AB; break;
case EFSNABS: ret = XA; break;
case EFSNEG: ret = XA; break;
case EFSSUB: ret = AB; break;
+ case EFSCFUI: ret = XB; break;
case EFSCFSI: ret = XB; break;
case EVFSABS: ret = XA; break;
@@ -149,7 +207,6 @@ static unsigned long insn_type(unsigned long speinsn)
case EVFSNABS: ret = XA; break;
case EVFSNEG: ret = XA; break;
case EVFSSUB: ret = AB; break;
-
case EFDABS: ret = XA; break;
case EFDADD: ret = AB; break;
case EFDCFS: ret = XB; break;
@@ -160,6 +217,11 @@ static unsigned long insn_type(unsigned long speinsn)
case EFDCTSI: ret = XB; break;
case EFDCTSIDZ: ret = XB; break;
case EFDCTSIZ: ret = XB; break;
+ case EFDTSTGT: /* ret = XB;*/ break;
+ case EFDTSTLT: /* ret = XB;*/ break;
+ case EFDTSTEQ: /* ret = XB;*/ break;
+ case EFDCFUI: ret = XB; break;
+ case EFDCFSI: ret = XB; break;
case EFDCTUF: ret = XB; break;
case EFDCTUI: ret = XB; break;
case EFDCTUIDZ: ret = XB; break;
@@ -169,6 +231,21 @@ static unsigned long insn_type(unsigned long speinsn)
case EFDNABS: ret = XA; break;
case EFDNEG: ret = XA; break;
case EFDSUB: ret = AB; break;
+ case EFDCFUID: ret = XB; break;
+ case EFDCFSID: ret = XB; break;
+
+ case EVLDDX: ret = XCR; break;
+ case EVLDD: ret = XCR; break;
+ case EVLDWX: ret = XCR; break;
+ case EVLDW: ret = XCR; break;
+ case EVLDHX: ret = XCR; break;
+ case EVLDH: ret = XCR; break;
+ case EVSTDDX: ret = XCR; break;
+ case EVSTDD: ret = XCR; break;
+ case EVSTDWX: ret = XCR; break;
+ case EVSTDW: ret = XCR; break;
+ case EVSTDHX: ret = XCR; break;
+ case EVSTDH: ret = XCR; break;
default:
printk(KERN_ERR "\nOoops! SPE instruction no type found.");
@@ -208,7 +285,11 @@ int do_spe_mathemu(struct pt_regs *regs)
vb.wp[0] = current->thread.evr[fb];
vb.wp[1] = regs->gpr[fb];
+#ifdef CONFIG_SPE_EMULATION
+ __FPU_FPSCR = current->thread.spefscr;
+#else
__FPU_FPSCR = mfspr(SPRN_SPEFSCR);
+#endif
#ifdef DEBUG
printk("speinsn:%08lx spefscr:%08lx\n", speinsn, __FPU_FPSCR);
@@ -218,6 +299,108 @@ int do_spe_mathemu(struct pt_regs *regs)
#endif
switch (src) {
+ case VLD:
+ switch (func) {
+ u32 *ea;
+
+ case EVNEG:
+ vc.wp[0] = ~va.wp[0] + 1;
+ vc.wp[1] = ~vb.wp[1] + 1;
+ goto write_dest_reg;
+
+ case EVAND:
+ vc.wp[0] = va.wp[0] & vb.wp[0];
+ vc.wp[1] = va.wp[1] & vb.wp[1];
+ goto write_dest_reg;
+
+ case EVANDC:
+ vc.wp[0] = va.wp[0] & ~vb.wp[0];
+ vc.wp[1] = va.wp[1] & ~vb.wp[1];
+ goto write_dest_reg;
+
+ case EVXOR:
+ vc.wp[0] = va.wp[0] ^ vb.wp[0];
+ vc.wp[1] = va.wp[1] ^ vb.wp[1];
+ goto write_dest_reg;
+
+ case EVOR:
+ vc.wp[0] = va.wp[0] | vb.wp[0];
+ vc.wp[1] = va.wp[1] | vb.wp[1];
+ goto write_dest_reg;
+
+ case EVNOR:
+ vc.wp[0] = ~ (va.wp[0] | vb.wp[0]);
+ vc.wp[1] = ~ (va.wp[1] | vb.wp[1]);
+ goto write_dest_reg;
+
+ case EVEQV:
+ vc.wp[0] = ~ (va.wp[0] ^ vb.wp[0]);
+ vc.wp[1] = ~ (va.wp[1] ^ vb.wp[1]);
+ goto write_dest_reg;
+
+ case EVORC:
+ vc.wp[0] = va.wp[0] | ~vb.wp[0];
+ vc.wp[1] = va.wp[1] | ~vb.wp[1];
+ goto write_dest_reg;
+
+ case EVLDDX:
+ case EVLDWX:
+ case EVLDHX:
+ ea = (void *)((fa ? va.wp[1] : 0) + vb.wp[1]);
+ if (copy_from_user(&vc.dp[0], ea, sizeof(u64)))
+ return -EFAULT;
+ goto write_dest_reg;
+ case EVLDD:
+ case EVLDW:
+ case EVLDH:
+ ea = (void *)((fa ? va.wp[1] : 0) + fb * 8);
+ if (copy_from_user(&vc.dp[0], ea, sizeof(u64)))
+ return -EFAULT;
+ goto write_dest_reg;
+ }
+ break;
+
+ case VST:
+ switch (func) {
+ u32 *ea;
+
+ case EVMERGEHI:
+ vc.wp[0] = va.wp[0];
+ vc.wp[1] = vb.wp[0];
+ goto write_dest_reg;
+
+ case EVMERGELO:
+ vc.wp[0] = va.wp[1];
+ vc.wp[1] = vb.wp[1];
+ goto write_dest_reg;
+
+ case EVMERGEHILO:
+ vc.wp[0] = va.wp[0];
+ vc.wp[1] = vb.wp[1];
+ goto write_dest_reg;
+
+ case EVMERGELOHI:
+ vc.wp[0] = va.wp[1];
+ vc.wp[1] = vb.wp[0];
+ goto write_dest_reg;
+
+ case EVSTDDX:
+ case EVSTDWX:
+ case EVSTDHX:
+ ea = (void *)((fa ? va.wp[1] : 0) + vb.wp[1]);
+ if (copy_to_user(ea, &vc.dp[0], sizeof(u64)))
+ return -EFAULT;
+ goto finish_insn;
+ case EVSTDD:
+ case EVSTDW:
+ case EVSTDH:
+ ea = (void *)((fa ? va.wp[1] : 0) + fb * 8);
+ if (copy_to_user(ea, &vc.dp[0], sizeof(u64)))
+ return -EFAULT;
+ goto finish_insn;
+ }
+ break;
+
case SPFP: {
FP_DECL_S(SA); FP_DECL_S(SB); FP_DECL_S(SR);
@@ -311,6 +494,14 @@ int do_spe_mathemu(struct pt_regs *regs)
goto pack_s;
}
+ case EFSCFUI:
+ FP_FROM_INT_S (SR, vb.wp[1], 32, int);
+ goto pack_s;
+
+ case EFSCFSI:
+ FP_FROM_INT_S (SR, (int) vb.wp[1], 32, int);
+ goto pack_s;
+
case EFSCTSI:
case EFSCTSIZ:
case EFSCTUI:
@@ -449,6 +640,22 @@ cmp_s:
FP_TO_INT_D(vc.dp[0], DB, 64, ((func & 0x1) == 0));
goto update_regs;
+ case EFDCFUI:
+ FP_FROM_INT_D(DR, vb.wp[1], 32, int);
+ goto pack_d;
+
+ case EFDCFSI:
+ FP_FROM_INT_D(DR, (int) vb.wp[1], 32, int);
+ goto pack_d;
+
+ case EFDCFUID:
+ FP_FROM_INT_D(DR, vb.dp[0], 64, long);
+ goto pack_d;
+
+ case EFDCFSID:
+ FP_FROM_INT_D(DR, (long)vb.dp[0], 64, long);
+ goto pack_d;
+
case EFDCTUI:
case EFDCTSI:
case EFDCTUIZ:
@@ -635,11 +842,17 @@ update_ccr:
update_regs:
__FPU_FPSCR &= ~FP_EX_MASK;
__FPU_FPSCR |= (FP_CUR_EXCEPTIONS & FP_EX_MASK);
+#ifdef CONFIG_SPE_EMULATION
+ current->thread.spefscr = __FPU_FPSCR;
+#else
mtspr(SPRN_SPEFSCR, __FPU_FPSCR);
+#endif
+write_dest_reg:
current->thread.evr[fc] = vc.wp[0];
regs->gpr[fc] = vc.wp[1];
+finish_insn:
#ifdef DEBUG
printk("ccr = %08lx\n", regs->ccr);
printk("cur exceptions = %08x spefscr = %08lx\n",
@@ -676,7 +889,11 @@ int speround_handler(struct pt_regs *regs)
fgpr.wp[0] = current->thread.evr[fc];
fgpr.wp[1] = regs->gpr[fc];
+#ifdef CONFIG_SPE_EMULATION
+ __FPU_FPSCR = current->thread.spefscr;
+#else
__FPU_FPSCR = mfspr(SPRN_SPEFSCR);
+#endif
switch ((speinsn >> 5) & 0x7) {
/* Since SPE instructions on E500 core can handle round to nearest
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 9da795e..1d5fd55 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -169,6 +169,12 @@ config ALTIVEC
If in doubt, say Y here.
+config SPE_EMULATION
+ bool "SPE Emulation Support"
+ depends on (CLASSIC32 || POWER4) && !ALTIVEC && !SPE
+ ---help---
+ This option enables kernel support for the Altivec extensions to the
+
config VSX
bool "VSX Support"
depends on POWER4 && ALTIVEC && PPC_FPU
--
1.5.6.6
^ permalink raw reply related
* Re: issue at the beginning of kernel booting
From: Benjamin Herrenschmidt @ 2009-04-02 21:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Sauce.Cheng
In-Reply-To: <20090402161209.GA19088@ld0162-tx32.am.freescale.net>
On Thu, 2009-04-02 at 11:12 -0500, Scott Wood wrote:
> On Wed, Apr 01, 2009 at 08:23:42PM -0700, Sauce.Cheng wrote:
> > > I don't see where you set up a BAT that covers 0xf0000000.
> >
> > if i have to set up a BAT that cover 0xF0000000. i had a debug with LEDs
> > like that in u-boot code. everything is //normal. 0xF00000000 is the value
> > of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address
> > and //base //address of all internal regishters, isnt? you mean that if i
> > set BATs, i should not get the phy address like in the //front ?
>
> I don't quite follow the above, but what I meant is that you need to
> put a mapping in place that covers your LED I/O once you have the MMU on.
>
> Any mappings that U-boot made will be gone at that point.
Also, f0000000 isn't a very good idea for a hard wired mapping, it will
overlap some kernel stuffs. You should dynamically allocate the virtual
address, or pick something above 0xfff00000 which should be unused iirc.
Ben.
^ permalink raw reply
* [PATCH] powerpc/math-emu: Change types to work on ppc64
From: Kumar Gala @ 2009-04-02 21:20 UTC (permalink / raw)
To: linuxppc-dev
While normally we don't use the math emulation code on ppc64 it can be
useful for doing things like emulating the embedded FP instructions.
Since performance isn't critical in this scenario its easier to keep
the sizes of the various math-emu the same as on ppc32.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/sfp-machine.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/sfp-machine.h b/arch/powerpc/include/asm/sfp-machine.h
index 3d9f831..3a7a67a 100644
--- a/arch/powerpc/include/asm/sfp-machine.h
+++ b/arch/powerpc/include/asm/sfp-machine.h
@@ -29,9 +29,9 @@
/* basic word size definitions */
#define _FP_W_TYPE_SIZE 32
-#define _FP_W_TYPE unsigned long
-#define _FP_WS_TYPE signed long
-#define _FP_I_TYPE long
+#define _FP_W_TYPE unsigned int
+#define _FP_WS_TYPE signed int
+#define _FP_I_TYPE int
#define __ll_B ((UWtype) 1 << (W_TYPE_SIZE / 2))
#define __ll_lowpart(t) ((UWtype) (t) & (__ll_B - 1))
--
1.5.6.6
^ permalink raw reply related
* Re: [PATCH] fsl_pq_mdio: Fix compile failure
From: David Miller @ 2009-04-02 20:57 UTC (permalink / raw)
To: galak; +Cc: netdev, linuxppc-dev
In-Reply-To: <1238679923-4370-1-git-send-email-galak@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Thu, 2 Apr 2009 08:45:23 -0500
> From: Segher Boessenkool <segher@kernel.crashing.org>
>
> Add EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name) for module builds
>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied, thanks.
^ permalink raw reply
* Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
From: Chris Friesen @ 2009-04-02 20:45 UTC (permalink / raw)
To: Hugh Dickins; +Cc: peterz, linux-kernel, linuxppc-dev, akpm, KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0904021938270.25731@blonde.anvils>
Hugh Dickins wrote:
> This is a cosmetic matter, not worth more than a couple of lines of
> code: I suggested masking off the high bits in the display, but when
> KAMEZAWA-san suggested just showing 0, it was hard to argue against
> his brutal simplicity.
<snip>
> Consider this change a fix: it used to show 00000000 before 2.6.7.
>
> See http://lkml.org/lkml/2009/1/13/331 for one of the threads
> on the subject - but you've not tempted me to reopen it!
Okay, fair enough. I'll change my code to deal with it. Thanks for the
explanation.
Chris
^ permalink raw reply
* early kernel debugging
From: Yigal Goldberger @ 2009-04-02 20:05 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board .
I see that after uncompressing the kernel it hangs.
I found a location (System.map) I think corresponds to the __log_buf (my SDRAM starts at physical address 0 (and u-boot performs -> Load Address: 00000000 Entry Point: 00000000) .
So I just removed the leading C0xxxxxx from the address leaving xxxxxx .
And that's where I looked .
I did see 2 error messages (though they were somewhat corrupt) the first designated a memory fault and the second a kernel oops at some address.
I looked this address up on System.map and it's somewhere inside prom.c
in of_scan_flat_dt( ) .
I have a few question at this point :
A)Am I looking at the right memory location for __log_buf ?
B)What is printed to the buffer (printk's of what verbose level ?)
C)In a previous kernel version 2.6.14 I don't remember explicitly using a flat device tree or pointing at such a tree through the bootm command) , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now .
I see a lot of stuff regarding the need to provide such a data structure upon booting via bootm .Do I need to explicitly prepare such a data structure and provide a pointer to it via bootm ?
Might this be the cause for this early hang ?
Best Regards,
Yigal Goldberger.
^ permalink raw reply
* [PATCH] net/gianfar: fix RMII mode detection
From: Matthew L. Creech @ 2009-04-02 20:02 UTC (permalink / raw)
To: linuxppc-dev
On MPC8313, the TSEC flags ECNTRL_REDUCED_MODE (for RGMII) and
ECNTRL_REDUCED_MII_MODE (for RMII) are mutually exclusive (15-32 of
the 8313 reference manual). The current gianfar driver only checks
for RMII when RGMII is enabled, so plain RMII is never detected. This
patch makes the flags independent.
Signed-off-by: Matthew Creech <mlcreech@gmail.com>
---
gianfar.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
diff -purN orig/drivers/net/gianfar.c linux-2.6.29/drivers/net/gianfar.c
--- orig/drivers/net/gianfar.c 2009-04-02 15:36:16.000000000 -0400
+++ linux-2.6.29/drivers/net/gianfar.c 2009-04-02 15:38:18.000000000 -0400
@@ -628,21 +628,20 @@ static phy_interface_t gfar_get_interfac
return PHY_INTERFACE_MODE_TBI;
}
+ if (ecntrl & ECNTRL_REDUCED_MII_MODE)
+ return PHY_INTERFACE_MODE_RMII;
+
if (ecntrl & ECNTRL_REDUCED_MODE) {
- if (ecntrl & ECNTRL_REDUCED_MII_MODE)
- return PHY_INTERFACE_MODE_RMII;
- else {
- phy_interface_t interface = priv->interface;
-
- /*
- * This isn't autodetected right now, so it must
- * be set by the device tree or platform code.
- */
- if (interface == PHY_INTERFACE_MODE_RGMII_ID)
- return PHY_INTERFACE_MODE_RGMII_ID;
+ phy_interface_t interface = priv->interface;
- return PHY_INTERFACE_MODE_RGMII;
- }
+ /*
+ * This isn't autodetected right now, so it must
+ * be set by the device tree or platform code.
+ */
+ if (interface == PHY_INTERFACE_MODE_RGMII_ID)
+ return PHY_INTERFACE_MODE_RGMII_ID;
+
+ return PHY_INTERFACE_MODE_RGMII;
}
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_GIGABIT)
--
Matthew L. Creech
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Kumar Gala @ 2009-04-02 19:52 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <49D50910.4020909@grandegger.com>
On Apr 2, 2009, at 1:50 PM, Wolfgang Grandegger wrote:
> [PATCH] powerpc/85xx: Re-add the device_type soc to socrates.dts
>
> The device_type "soc" is still required for MPC85xx boards.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
> arch/powerpc/boot/dts/socrates.dts | 1 +
> 1 file changed, 1 insertion(+)
applied
- k
^ permalink raw reply
* [PATCH] powerpc: Move SPEFSCR defines to common header
From: Kumar Gala @ 2009-04-02 19:51 UTC (permalink / raw)
To: linuxppc-dev
SPEFSCR is a user space register and doesn't conflict with anything.
Moving the defines of the various bit fields makes some emulation
code have fewer ifdefs
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/reg.h | 30 ++++++++++++++++++++++++++++++
arch/powerpc/include/asm/reg_booke.h | 30 ------------------------------
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index c9ff1ec..e8018d5 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -143,6 +143,36 @@
#define FPSCR_NI 0x00000004 /* FPU non IEEE-Mode */
#define FPSCR_RN 0x00000003 /* FPU rounding control */
+/* Bit definitions for SPEFSCR. */
+#define SPEFSCR_SOVH 0x80000000 /* Summary integer overflow high */
+#define SPEFSCR_OVH 0x40000000 /* Integer overflow high */
+#define SPEFSCR_FGH 0x20000000 /* Embedded FP guard bit high */
+#define SPEFSCR_FXH 0x10000000 /* Embedded FP sticky bit high */
+#define SPEFSCR_FINVH 0x08000000 /* Embedded FP invalid operation high */
+#define SPEFSCR_FDBZH 0x04000000 /* Embedded FP div by zero high */
+#define SPEFSCR_FUNFH 0x02000000 /* Embedded FP underflow high */
+#define SPEFSCR_FOVFH 0x01000000 /* Embedded FP overflow high */
+#define SPEFSCR_FINXS 0x00200000 /* Embedded FP inexact sticky */
+#define SPEFSCR_FINVS 0x00100000 /* Embedded FP invalid op. sticky */
+#define SPEFSCR_FDBZS 0x00080000 /* Embedded FP div by zero sticky */
+#define SPEFSCR_FUNFS 0x00040000 /* Embedded FP underflow sticky */
+#define SPEFSCR_FOVFS 0x00020000 /* Embedded FP overflow sticky */
+#define SPEFSCR_MODE 0x00010000 /* Embedded FP mode */
+#define SPEFSCR_SOV 0x00008000 /* Integer summary overflow */
+#define SPEFSCR_OV 0x00004000 /* Integer overflow */
+#define SPEFSCR_FG 0x00002000 /* Embedded FP guard bit */
+#define SPEFSCR_FX 0x00001000 /* Embedded FP sticky bit */
+#define SPEFSCR_FINV 0x00000800 /* Embedded FP invalid operation */
+#define SPEFSCR_FDBZ 0x00000400 /* Embedded FP div by zero */
+#define SPEFSCR_FUNF 0x00000200 /* Embedded FP underflow */
+#define SPEFSCR_FOVF 0x00000100 /* Embedded FP overflow */
+#define SPEFSCR_FINXE 0x00000040 /* Embedded FP inexact enable */
+#define SPEFSCR_FINVE 0x00000020 /* Embedded FP invalid op. enable */
+#define SPEFSCR_FDBZE 0x00000010 /* Embedded FP div by zero enable */
+#define SPEFSCR_FUNFE 0x00000008 /* Embedded FP underflow enable */
+#define SPEFSCR_FOVFE 0x00000004 /* Embedded FP overflow enable */
+#define SPEFSCR_FRMC 0x00000003 /* Embedded FP rounding mode control */
+
/* Special Purpose Registers (SPRNs)*/
#define SPRN_CTR 0x009 /* Count Register */
#define SPRN_DSCR 0x11
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index a56f4d6..601ddbc 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -423,36 +423,6 @@
#define SGR_NORMAL 0 /* Speculative fetching allowed. */
#define SGR_GUARDED 1 /* Speculative fetching disallowed. */
-/* Bit definitions for SPEFSCR. */
-#define SPEFSCR_SOVH 0x80000000 /* Summary integer overflow high */
-#define SPEFSCR_OVH 0x40000000 /* Integer overflow high */
-#define SPEFSCR_FGH 0x20000000 /* Embedded FP guard bit high */
-#define SPEFSCR_FXH 0x10000000 /* Embedded FP sticky bit high */
-#define SPEFSCR_FINVH 0x08000000 /* Embedded FP invalid operation high */
-#define SPEFSCR_FDBZH 0x04000000 /* Embedded FP div by zero high */
-#define SPEFSCR_FUNFH 0x02000000 /* Embedded FP underflow high */
-#define SPEFSCR_FOVFH 0x01000000 /* Embedded FP overflow high */
-#define SPEFSCR_FINXS 0x00200000 /* Embedded FP inexact sticky */
-#define SPEFSCR_FINVS 0x00100000 /* Embedded FP invalid op. sticky */
-#define SPEFSCR_FDBZS 0x00080000 /* Embedded FP div by zero sticky */
-#define SPEFSCR_FUNFS 0x00040000 /* Embedded FP underflow sticky */
-#define SPEFSCR_FOVFS 0x00020000 /* Embedded FP overflow sticky */
-#define SPEFSCR_MODE 0x00010000 /* Embedded FP mode */
-#define SPEFSCR_SOV 0x00008000 /* Integer summary overflow */
-#define SPEFSCR_OV 0x00004000 /* Integer overflow */
-#define SPEFSCR_FG 0x00002000 /* Embedded FP guard bit */
-#define SPEFSCR_FX 0x00001000 /* Embedded FP sticky bit */
-#define SPEFSCR_FINV 0x00000800 /* Embedded FP invalid operation */
-#define SPEFSCR_FDBZ 0x00000400 /* Embedded FP div by zero */
-#define SPEFSCR_FUNF 0x00000200 /* Embedded FP underflow */
-#define SPEFSCR_FOVF 0x00000100 /* Embedded FP overflow */
-#define SPEFSCR_FINXE 0x00000040 /* Embedded FP inexact enable */
-#define SPEFSCR_FINVE 0x00000020 /* Embedded FP invalid op. enable */
-#define SPEFSCR_FDBZE 0x00000010 /* Embedded FP div by zero enable */
-#define SPEFSCR_FUNFE 0x00000008 /* Embedded FP underflow enable */
-#define SPEFSCR_FOVFE 0x00000004 /* Embedded FP overflow enable */
-#define SPEFSCR_FRMC 0x00000003 /* Embedded FP rounding mode control */
-
/*
* The IBM-403 is an even more odd special case, as it is much
* older than the IBM-405 series. We put these down here incase someone
--
1.5.6.6
^ permalink raw reply related
* Re: [PATCH] linux-next remove wmb() from ide-dma-sff.c and scc_pata.c
From: Bartlomiej Zolnierkiewicz @ 2009-04-02 19:08 UTC (permalink / raw)
To: KOBAYASHI Yoshitake
Cc: Linux/MIPS Development, Linux/PPC Development, Atsushi Nemoto,
IDE/ATA Devel, Grant Grundler, Geert Uytterhoeven, LKML
In-Reply-To: <49D1E384.8080009@toshiba.co.jp>
On Tuesday 31 March 2009, KOBAYASHI Yoshitake wrote:
> 2009/03/31 16:51, Geert Uytterhoeven wrote:
> > On Mon, 30 Mar 2009, Grant Grundler wrote:
> >> Followup to "[PATCH 03/10] ide: destroy DMA mappings after ending DMA"
> >> email on March 14th:
> >> http://lkml.org/lkml/2009/3/14/17
> >>
> >> No maintainer is listed for "Toshiba CELL Reference Set IDE" (BLK_DEV_CELLEB)
> >> or tx4939ide.c in MAINTAINERS. I've CC'd "Ishizaki Kou" @Toshiba (Maintainer for
> >> "Spidernet Network Driver for CELL") and linuxppc-dev list in the hope
> >> someone else
> >> would know or would be able to ACK this patch.
> >
> > tx49xx is MIPS, for Nemoto-san.
>
> The patch looks good for Toshiba Cell Reference Set.
Great, I applied the patch.
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH] QE USB Host Integration for MPC832x
From: Scott Wood @ 2009-04-02 19:17 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Timur Tabi, linux-kernel, Marcel Ziswiler
In-Reply-To: <20090402191159.GA14626@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Thu, Apr 02, 2009 at 01:42:37PM -0500, Timur Tabi wrote:
>> Anton Vorontsov wrote:
>>
>>> Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
>>> matching, so you can't remove it. :-/
>> Ugh, that's a bug in the driver then.
>
> Yes, but that depends on what chip was the first one? MPC8323 or
> MPC8360?
Actually, it depends on which one we picked in the devtree binding
(assuming they're compatible both ways), which appears to be mpc8323.
-Scott
^ permalink raw reply
* Re: [PATCH] QE USB Host Integration for MPC832x
From: Anton Vorontsov @ 2009-04-02 19:11 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Marcel Ziswiler, linux-kernel
In-Reply-To: <49D5071D.50001@freescale.com>
On Thu, Apr 02, 2009 at 01:42:37PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> > Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
> > matching, so you can't remove it. :-/
>
> Ugh, that's a bug in the driver then.
Yes, but that depends on what chip was the first one? MPC8323 or
MPC8360?
> My understanding is that the only MPC8323 QE microcode update is the one
> for UART. If there are any updates to any other QE devices for standard
> functionality, I'm not aware of any.
I found them:
http://www.freescale.com/files/netcomm/software/app_software/microcode/QERAMPTCH.zip?fpsp=1
File is qe_usb3-8323_Rev11.c
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
From: Hugh Dickins @ 2009-04-02 19:10 UTC (permalink / raw)
To: Chris Friesen; +Cc: peterz, linux-kernel, linuxppc-dev, akpm, KAMEZAWA Hiroyuki
In-Reply-To: <49D4FB89.4070101@nortel.com>
On Thu, 2 Apr 2009, Chris Friesen wrote:
> Hugh Dickins wrote:
> > > > f7feb000-f7fec000 rw-p f7feb000 00:00 0
> > > > ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
>
> > Chris isn't the first to be concerned by that: there's a patch in
> > -mm which just shows 0 instead of anon vm_pgoff in /proc/<pid>/maps
> > output. That patch is on akpm's list for 2.6.30 merge, but I think
> > hasn't gone to Linus yet: expect it in a later batch.
>
> Alternately, what about just making the offset for the stack match the
> starting address of the VMA?
The rmap code for locating anonymous pages, even after the vma has
been moved meanwhile, depends on vma->vm_pgoff. There is no point
in making that more complicated for this.
For display purposes only? Well, yes, we could have done that,
but why bother? It wouldn't be adding any information, and
might raise a question of identifying "the" stack to do that to.
> That way it would look the same as other anonymous areas,
The stack will be looking the same as other anonymous areas:
they'll all be showing 00000000 there.
This is a cosmetic matter, not worth more than a couple of lines of
code: I suggested masking off the high bits in the display, but when
KAMEZAWA-san suggested just showing 0, it was hard to argue against
his brutal simplicity.
> and as a bonus would look the same as previous releases.
> Arguably, /proc/<pid>/maps should count as userspace-visible API.
Consider this change a fix: it used to show 00000000 before 2.6.7.
See http://lkml.org/lkml/2009/1/13/331 for one of the threads
on the subject - but you've not tempted me to reopen it!
Hugh
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-04-02 18:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <3247527D-1FD0-420F-99C6-9DADBB79B020@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 2, 2009, at 1:38 AM, Wolfgang Grandegger wrote:
>
>>
>> Socrates is a new board and it has no problem using an up-to-date
>> version of U-Boot. The socrates.dts file in your "next" tree already has
>> the "device_type = "soc" removed. We need to add "fsl,soc" to the
>> "compatible" property and update fsl_get_sys_freq(), etc. to search for
>> it as well. And U-Boot should use the same name to fixup the
>> frequencies. Are you already working on that issue? Should I provide
>> patches?
>>
>
> I'm not working on it at all. I'm also guessing at this point the
> Socrates support is in Linus tree :)
Yes, I know, but it does not work properly because the "device_type =
"soc" is missing :-(. I did not realize that immediately, sorry. Could
you please apply the fix below re-adding the 'device_type = "soc";' line
for the time being.
Thanks.
Wolfgang.
[PATCH] powerpc/85xx: Re-add the device_type soc to socrates.dts
The device_type "soc" is still required for MPC85xx boards.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/socrates.dts | 1 +
1 file changed, 1 insertion(+)
Index: powerpc/arch/powerpc/boot/dts/socrates.dts
===================================================================
--- powerpc.orig/arch/powerpc/boot/dts/socrates.dts 2009-04-01
15:26:09.000000000 +0200
+++ powerpc/arch/powerpc/boot/dts/socrates.dts 2009-04-02
16:37:09.838719521 +0200
@@ -52,6 +52,7 @@
soc8544@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
+ device_type = "soc";
ranges = <0x00000000 0xe0000000 0x00100000>;
reg = <0xe0000000 0x00001000>; // CCSRBAR 1M
^ permalink raw reply
* Re: [PATCH] QE USB Host Integration for MPC832x
From: Timur Tabi @ 2009-04-02 18:42 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Marcel Ziswiler, linux-kernel
In-Reply-To: <20090402183631.GA6699@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
> matching, so you can't remove it. :-/
Ugh, that's a bug in the driver then.
My understanding is that the only MPC8323 QE microcode update is the one
for UART. If there are any updates to any other QE devices for standard
functionality, I'm not aware of any.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] QE USB Host Integration for MPC832x
From: Anton Vorontsov @ 2009-04-02 18:36 UTC (permalink / raw)
To: Marcel Ziswiler; +Cc: linuxppc-dev, linux-kernel, Timur Tabi
In-Reply-To: <20090402183357.GA29050@oksana.dev.rtsoft.ru>
On Thu, Apr 02, 2009 at 10:33:57PM +0400, Anton Vorontsov wrote:
[...]
> > + compatible = "fsl,mpc8360-qe-usb",
>
> Ditto. No need for mpc8360 compatible.
Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
matching, so you can't remove it. :-/
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox