Please pull my perf.git tree support
Ben, When you set up your next branch for commits to go in 2.6.36-rc1, please do a pull from: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git master to get a series of commits that add support for hw_breakpoint events on 64-bit POWER server processors in the perf_event subsystem. This consists of a commit from me that adds support for most integer instructions to the emulate_step() function, a series from K. Prasad that add the ppc64-specific hw_breakpoint code, and some small commits from me that fix a few bugs that I found in testing. There is one commit in there from K. Prasad that modifies the generic hw_breakpoint code to add the ability to have an arch-specific unregister hook for hw_breakpoints. It has been acked by Frederic Weisbecker. Thanks, Paul. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git master K.Prasad (5): hw_breakpoints: Allow arch-specific cleanup before breakpoint unregistration powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server processors powerpc, hw_breakpoint: Handle concurrent alignment interrupts powerpc, hw_breakpoint: Enable hw-breakpoints while handling intervening signals powerpc, hw_breakpoint: Discard extraneous interrupt due to accesses outside symbol length Paul Mackerras (4): powerpc: Emulate most Book I instructions in emulate_step() powerpc, hw_breakpoint: Fix off-by-one in checking access address powerpc, hw_breakpoint: Cooperate better with other single-steppers powerpc, hw_breakpoint: Tell generic code we have no instruction breakpoints arch/powerpc/Kconfig |1 + arch/powerpc/include/asm/asm-compat.h|2 + arch/powerpc/include/asm/cputable.h |4 + arch/powerpc/include/asm/hw_breakpoint.h | 74 ++ arch/powerpc/include/asm/ppc-opcode.h|7 + arch/powerpc/include/asm/processor.h |8 + arch/powerpc/kernel/Makefile |1 + arch/powerpc/kernel/exceptions-64s.S |1 + arch/powerpc/kernel/hw_breakpoint.c | 364 +++ arch/powerpc/kernel/machine_kexec_64.c |3 + arch/powerpc/kernel/process.c| 14 + arch/powerpc/kernel/ptrace.c | 64 ++ arch/powerpc/kernel/signal.c |3 + arch/powerpc/kernel/traps.c |8 +- arch/powerpc/lib/Makefile|5 +- arch/powerpc/lib/ldstfp.S| 375 arch/powerpc/lib/sstep.c | 1514 +- kernel/hw_breakpoint.c | 12 + 18 files changed, 2408 insertions(+), 52 deletions(-) create mode 100644 arch/powerpc/include/asm/hw_breakpoint.h create mode 100644 arch/powerpc/kernel/hw_breakpoint.c create mode 100644 arch/powerpc/lib/ldstfp.S ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
Hi Scott, >> Bus Fault @ 0x00404c40, fixup 0x >> Machine check in kernel mode. >> Caused by (from msr): regs 07d1cb80 Unknown values in msr >> NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: >> 0001 >> MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 > > Can you look up the source line/instruction corresponding to 0x404c40, in > the wrapper ELF file? I'm not sure how to look up it. But I used the BDI to dump the instructions in which you may find some clue? These should be kernel code, right? Maybe the gdb can help to de-assemble them? BDI>md 0x404c00 0x20 00404c00 : 0x4800317d 1207972221 H.1} 00404c04 : 0x80010014 -2147418092 00404c08 : 0xbbc10008 -1144979448 00404c0c : 0x7c0803a6 208096 |... 00404c10 : 0x38210010941686800 8!.. 00404c14 : 0x4e800020 1317011488 N.. 00404c18 : 0x9421fff0 -1809711120 .!.. 00404c1c : 0x7c0802a6 2080899750 |... 00404c20 : 0x429f0005 1117716485 B... 00404c24 : 0xbfc10008 -1077870584 00404c28 : 0x7fc802a6 2143814310 00404c2c : 0x90010014 -1878982636 00404c30 : 0x3fde0001 1071513601 ?... 00404c34 : 0x3bdedd98 1004461464 ;... 00404c38 : 0x813e8000 -2126610432 .>.. 00404c3c : 0x8149 -2125922304 .I.. 00404c40 : 0xa00a -1609957376 00404c44 : 0x0c00201326592 00404c48 : 0x4c00012c 1275068716 L.., 00404c4c : 0x70090001 1879638017 p... 00404c50 : 0x4082fff0 1082327024 @... 00404c54 : 0x817e8000 -2122416128 .~.. 00404c58 : 0x5469402e 1416183854 t...@. Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix module building for gcc 4.5 and 64 bit
Gcc 4.5 is now generating out of line register save and restore in the function prefix and postfix when we use -Os. Signed-off-by: Stephen Rothwell --- arch/powerpc/Makefile|4 +- arch/powerpc/lib/Makefile|4 +- arch/powerpc/lib/crtsavres.S | 129 ++ scripts/mod/modpost.c|5 ++ 4 files changed, 138 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 42dcd3f..77cfe7a 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -92,10 +92,10 @@ endif else KBUILD_CFLAGS += $(call cc-option,-mtune=power4) endif -else -LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o endif +LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o + ifeq ($(CONFIG_TUNE_CELL),y) KBUILD_CFLAGS += $(call cc-option,-mtune=cell) endif diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 3040dac..111da1c 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -12,8 +12,8 @@ CFLAGS_REMOVE_code-patching.o = -pg CFLAGS_REMOVE_feature-fixups.o = -pg obj-y := string.o alloc.o \ - checksum_$(CONFIG_WORD_SIZE).o -obj-$(CONFIG_PPC32)+= div64.o copy_32.o crtsavres.o + checksum_$(CONFIG_WORD_SIZE).o crtsavres.o +obj-$(CONFIG_PPC32)+= div64.o copy_32.o obj-$(CONFIG_HAS_IOMEM)+= devres.o obj-$(CONFIG_PPC64)+= copypage_64.o copyuser_64.o \ diff --git a/arch/powerpc/lib/crtsavres.S b/arch/powerpc/lib/crtsavres.S index 70a9cd8..1c893f0 100644 --- a/arch/powerpc/lib/crtsavres.S +++ b/arch/powerpc/lib/crtsavres.S @@ -6,6 +6,7 @@ * Written By Michael Meissner * * Based on gcc/config/rs6000/crtsavres.asm from gcc + * 64 bit additions from reading the PPC elf64abi document. * * This file is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -44,6 +45,8 @@ #ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE +#ifndef CONFIG_PPC64 + /* Routines for saving integer registers, called by the compiler. */ /* Called with r11 pointing to the stack header word of the caller of the */ /* function, just beyond the end of the integer save area. */ @@ -226,4 +229,130 @@ _GLOBAL(_rest32gpr_31_x) mtlr0 mr 1,11 blr + +#else /* CONFIG_PPC64 */ + +.globl _savegpr0_14 +_savegpr0_14: + std r14,-144(r1) +.globl _savegpr0_15 +_savegpr0_15: + std r15,-136(r1) +.globl _savegpr0_16 +_savegpr0_16: + std r16,-128(r1) +.globl _savegpr0_17 +_savegpr0_17: + std r17,-120(r1) +.globl _savegpr0_18 +_savegpr0_18: + std r18,-112(r1) +.globl _savegpr0_19 +_savegpr0_19: + std r19,-104(r1) +.globl _savegpr0_20 +_savegpr0_20: + std r20,-96(r1) +.globl _savegpr0_21 +_savegpr0_21: + std r21,-88(r1) +.globl _savegpr0_22 +_savegpr0_22: + std r22,-80(r1) +.globl _savegpr0_23 +_savegpr0_23: + std r23,-72(r1) +.globl _savegpr0_24 +_savegpr0_24: + std r24,-64(r1) +.globl _savegpr0_25 +_savegpr0_25: + std r25,-56(r1) +.globl _savegpr0_26 +_savegpr0_26: + std r26,-48(r1) +.globl _savegpr0_27 +_savegpr0_27: + std r27,-40(r1) +.globl _savegpr0_28 +_savegpr0_28: + std r28,-32(r1) +.globl _savegpr0_29 +_savegpr0_29: + std r29,-24(r1) +.globl _savegpr0_30 +_savegpr0_30: + std r30,-16(r1) +.globl _savegpr0_31 +_savegpr0_31: + std r31,-8(r1) + std r0,16(r1) + blr + +.globl _restgpr0_14 +_restgpr0_14: + ld r14,-144(r1) +.globl _restgpr0_15 +_restgpr0_15: + ld r15,-136(r1) +.globl _restgpr0_16 +_restgpr0_16: + ld r16,-128(r1) +.globl _restgpr0_17 +_restgpr0_17: + ld r17,-120(r1) +.globl _restgpr0_18 +_restgpr0_18: + ld r18,-112(r1) +.globl _restgpr0_19 +_restgpr0_19: + ld r19,-104(r1) +.globl _restgpr0_20 +_restgpr0_20: + ld r20,-96(r1) +.globl _restgpr0_21 +_restgpr0_21: + ld r21,-88(r1) +.globl _restgpr0_22 +_restgpr0_22: + ld r22,-80(r1) +.globl _restgpr0_23 +_restgpr0_23: + ld r23,-72(r1) +.globl _restgpr0_24 +_restgpr0_24: + ld r24,-64(r1) +.globl _restgpr0_25 +_restgpr0_25: + ld r25,-56(r1) +.globl _restgpr0_26 +_restgpr0_26: + ld r26,-48(r1) +.globl _restgpr0_27 +_restgpr0_27: + ld r27,-40(r1) +.globl _restgpr0_28 +_restgpr0_28: + ld r28,-32(r1) +.globl _restgpr0_29 +_restgpr0_29: + ld r0,16(r1) + ld r29,-24(r1) + mtlrr0 + ld r30,-16(r1) + ld r31,-8(r1) + blr + +.globl _restgpr0_30 +_restgpr0_30: + ld r30,-16(r1) +.globl _restgpr0_31 +_restgpr0_31: + ld r0,16(r1) + ld r31,-8(r1) + mtlrr0 + blr + +#endif /* CONFIG_PPC64 */ + #endif diff --git a/scripts/mod/modpost
[PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
Just whitelist these extra compiler generated symbols.
Fixes these errors:
Error: External symbol '_restgpr0_14' referenced from prom_init.c
Error: External symbol '_restgpr0_20' referenced from prom_init.c
Error: External symbol '_restgpr0_22' referenced from prom_init.c
Error: External symbol '_restgpr0_24' referenced from prom_init.c
Error: External symbol '_restgpr0_25' referenced from prom_init.c
Error: External symbol '_restgpr0_26' referenced from prom_init.c
Error: External symbol '_restgpr0_27' referenced from prom_init.c
Error: External symbol '_restgpr0_28' referenced from prom_init.c
Error: External symbol '_restgpr0_29' referenced from prom_init.c
Error: External symbol '_restgpr0_31' referenced from prom_init.c
Error: External symbol '_savegpr0_14' referenced from prom_init.c
Error: External symbol '_savegpr0_20' referenced from prom_init.c
Error: External symbol '_savegpr0_22' referenced from prom_init.c
Error: External symbol '_savegpr0_24' referenced from prom_init.c
Error: External symbol '_savegpr0_25' referenced from prom_init.c
Error: External symbol '_savegpr0_26' referenced from prom_init.c
Error: External symbol '_savegpr0_27' referenced from prom_init.c
Error: External symbol '_savegpr0_28' referenced from prom_init.c
Error: External symbol '_savegpr0_29' referenced from prom_init.c
Error: External symbol '_savegpr0_31' referenced from prom_init.c
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/prom_init_check.sh |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init_check.sh
b/arch/powerpc/kernel/prom_init_check.sh
index 1ac136b..9f82f49 100644
--- a/arch/powerpc/kernel/prom_init_check.sh
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -52,12 +52,18 @@ do
if [ "${UNDEF:0:9}" = "_restgpr_" ]; then
OK=1
fi
+ if [ "${UNDEF:0:10}" = "_restgpr0_" ]; then
+ OK=1
+ fi
if [ "${UNDEF:0:11}" = "_rest32gpr_" ]; then
OK=1
fi
if [ "${UNDEF:0:9}" = "_savegpr_" ]; then
OK=1
fi
+ if [ "${UNDEF:0:10}" = "_savegpr0_" ]; then
+ OK=1
+ fi
if [ "${UNDEF:0:11}" = "_save32gpr_" ]; then
OK=1
fi
--
1.7.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_NO_HZ causing poor console responsiveness
On Tue, Jun 29, 2010 at 02:54:17PM -0500, Timur Tabi wrote: > I'm adding support for a new e500-based board (the P1022DS), and in > the process I've discovered that enabling CONFIG_NO_HZ (Tickless > System / Dynamic Ticks) causes significant responsiveness problems on > the serial console. When I type on the console, I see delays of up to > a half-second for almost every character. It acts as if there's a > background process eating all the CPU. > > I don't have time to debug this thoroughly at the moment. The problem > occurs in the latest kernel, but it appears not to occur in 2.6.32. > > Has anyone else seen anything like this? Yes, with a P2020RDB and kernel 2.6.35-rc1. Serial console is really slow on an otherwise idle machine. I assumed it was a hardware problem. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Dear David Daney, In message <4c2a8038.50...@caviumnetworks.com> you wrote: > > > Why are you posting this old driver version without trying to sync > > against our tree which includes a number of fixes - you should know > > about these. > > > > This could be a question with an obvious answer, but which tree are you > referring to when you say 'our tree'? git://git.denx.de/linux-2.6-denx.git Fushen Chen should know this, as the fixes I've mentioned were part of contract/support work for Applied Micro. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The Wright Bothers weren't the first to fly. They were just the first not to crash. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
Olof Johansson wrote: > Sure, the family-defconfigs are supposed to be supersets that can boot > everywhere. If you're concerned about static kernel size you can always > enable it as modules instead. It just seems wrong to add full support for audio and video in the kernel, when it can be used only on one, relatively obscure chip. Video support would need to be in-kernel only in order to get the console working, and I suspect that core ALSA support would need to be in-kernel as well. -- Timur Tabi Linux kernel developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
On Tue, Jun 29, 2010 at 06:16:08PM -0700, Tabi Timur-B04825 wrote: > Olof Johansson wrote: > > Sure, the family-defconfigs are supposed to be supersets that can boot > > everywhere. If you're concerned about static kernel size you can always > > enable it as modules instead. > > It just seems wrong to add full support for audio and video in the kernel, > when it can be used only on one, relatively obscure chip. Video support > would need to be in-kernel only in order to get the console working, and I > suspect that core ALSA support would need to be in-kernel as well. See the text you quoted from me above, it applies at a reply to this as well. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
On Tue, Jun 29, 2010 at 04:37:59PM -0700, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>
> > Drop the defconfig and update mpc85xx_{smp_}defconfig to build p1022.
>
> What about video and audio support? I'm going to add that later? We don't
> want to compile the DIU and SSI drivers on all 85xx systems, do we?
Sure, the family-defconfigs are supposed to be supersets that can boot
everywhere. If you're concerned about static kernel size you can always
enable it as modules instead.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel init exception
On Tue, Jun 29, 2010 at 06:51:16PM +0200, Segher Boessenkool wrote: > >why there generated a signal 4 in init process? > > That's SIGILL; sounds like you compiled init with the wrong (sub-)arch > or cpu flags. Or it's been corrupted during load. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
Kim Phillips wrote:
> On Tue, 29 Jun 2010 16:34:34 -0500
> Timur Tabi wrote:
>
>> Introduce basic support for the Freescale P1022DS reference board, based on
>> the
>> Freescale BSP for this board.
>>
>> Details: No DIU video or SSI audio support, no MMC/SD card support, 36-bit
>> and
>> SWIOTLB support enabled, 36-bit DTS only, and CONFIG_NO_HZ disabled because
>> it
>> causes performance problems on this kernel.
>
> what kind of performance problems?
See my post on linuxppc-dev about CONFIG_NO_HZ.
>> +queue-gr...@0{
>> +#address-cells =<1>;
>> +#size-cells =<1>;
>> +reg =<0xB1000 0x1000>;
>> +fsl,rx-err-int-map =<0xAA>;
>> +fsl,tx-int-map =<0xAA>;
>> +interrupts =<35 2 36 2 40 2>;
>> +};
>> +queue-gr...@1{
>> +#address-cells =<1>;
>> +#size-cells =<1>;
>> +reg =<0xB5000 0x1000>;
>> +fsl,rx-err-int-map =<0x55>;
>> +fsl,tx-int-map =<0x55>;
>> +interrupts =<51 2 52 2 67 2>;
>> +};
>
> these queue-group nodes, fsl,{r,t}x-* properties...
I just copied this tree from the BSP. I have no idea what they should ok
like. Can you be more specific?
>> +cry...@3 {
>
>> +fsl,multi-host-mode = "dual";
>> +fsl,channel-remap =<0x3>;
>
> and the above two properties aren't supported by their respective
> drivers, nor are they listed in the dts bindings documentation.
Then please tell me what these nodes should look like.
--
Timur Tabi
Linux kernel developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
Kumar Gala wrote:
> Drop the defconfig and update mpc85xx_{smp_}defconfig to build p1022.
What about video and audio support? I'm going to add that later? We don't
want to compile the DIU and SSI drivers on all 85xx systems, do we?
--
Timur Tabi
Linux kernel developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
On Tue, 29 Jun 2010 17:39:17 -0600
"Tabi Timur-B04825" wrote:
> Kim Phillips wrote:
> > On Tue, 29 Jun 2010 16:34:34 -0500
> > Timur Tabi wrote:
> >
> >> Introduce basic support for the Freescale P1022DS reference board, based
> >> on the
> >> Freescale BSP for this board.
> >>
> >> Details: No DIU video or SSI audio support, no MMC/SD card support, 36-bit
> >> and
> >> SWIOTLB support enabled, 36-bit DTS only, and CONFIG_NO_HZ disabled
> >> because it
> >> causes performance problems on this kernel.
> >
> > what kind of performance problems?
>
> See my post on linuxppc-dev about CONFIG_NO_HZ.
looks like it should be easily bisected, esp. since
mpc85xx_smp_defconfig has NO_HZ=y.
> >> + queue-gr...@0{
> >> + #address-cells =<1>;
> >> + #size-cells =<1>;
> >> + reg =<0xB1000 0x1000>;
> >> + fsl,rx-err-int-map =<0xAA>;
> >> + fsl,tx-int-map =<0xAA>;
> >> + interrupts =<35 2 36 2 40 2>;
> >> + };
> >> + queue-gr...@1{
> >> + #address-cells =<1>;
> >> + #size-cells =<1>;
> >> + reg =<0xB5000 0x1000>;
> >> + fsl,rx-err-int-map =<0x55>;
> >> + fsl,tx-int-map =<0x55>;
> >> + interrupts =<51 2 52 2 67 2>;
> >> + };
> >
> > these queue-group nodes, fsl,{r,t}x-* properties...
>
> I just copied this tree from the BSP. I have no idea what they should ok
> like. Can you be more specific?
eh? you submitted the patch; I'm just calling out the
foreign/undocumented matter in it.
> >> + cry...@3 {
> >
> >> + fsl,multi-host-mode = "dual";
> >> + fsl,channel-remap =<0x3>;
> >
> > and the above two properties aren't supported by their respective
> > drivers, nor are they listed in the dts bindings documentation.
>
> Then please tell me what these nodes should look like.
delete them?
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
On 06/29/2010 03:41 PM, David Brownell wrote: Good -- MUSB won't be the only one. ;) Could you mention a few Linux-enabled chips which include this controller? I can. Some members of the Octeon family: arch/mips/cavium-octeon Although there would probably be some SOC specific glue needed for chips not targeted by the initial patch set. David Daney arch/powerpc/boot/dts/kilauea.dts | 15 + Also, please provide a clean patch that only includes the driver, and split PPC hooks into a separate patch. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/9] Add Synopsys DesignWare HS USB OTG Controller driver.
On 06/29/2010 04:13 PM, Wolfgang Denk wrote: Dear Fushen Chen, In message<1277846824673-git-send-email-fc...@apm.com> you wrote: Implements DWC OTG USB Host Controller Driver (HCD) and interface to USB Host controller Driver framework. Signed-off-by: Fushen Chen Signed-off-by: Mark Miesfeld --- drivers/usb/otg/dwc_otg_hcd.c | 2397 + drivers/usb/otg/dwc_otg_hcd.h | 421 2 files changed, 2818 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/otg/dwc_otg_hcd.c create mode 100644 drivers/usb/otg/dwc_otg_hcd.h Why are you posting this old driver version without trying to sync against our tree which includes a number of fixes - you should know about these. This could be a question with an obvious answer, but which tree are you referring to when you say 'our tree'? David Daney ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Dear Fushen Chen,
In message <1277846824673-git-send-email-fc...@apm.com> you wrote:
> Implements DWC OTG USB Host Controller Driver (HCD) and interface to
> USB Host controller Driver framework.
>
> Signed-off-by: Fushen Chen
> Signed-off-by: Mark Miesfeld
> ---
> drivers/usb/otg/dwc_otg_hcd.c | 2397
> +
> drivers/usb/otg/dwc_otg_hcd.h | 421
> 2 files changed, 2818 insertions(+), 0 deletions(-)
> create mode 100644 drivers/usb/otg/dwc_otg_hcd.c
> create mode 100644 drivers/usb/otg/dwc_otg_hcd.h
Why are you posting this old driver version without trying to sync
against our tree which includes a number of fixes - you should know
about these.
...
> + do {
> + hcchar.d32 = dwc_read_reg32(&hc_regs->hcchar);
> + if (++count > 1) {
> + printk(KERN_ERR "%s: Unable to clear halt on "
> + "channel %d\n", __func__, i);
> + break;
> + }
> + } while (hcchar.b.chen);
> + }
For example, here you are missing
commit 018b43db153da063182c87be2eaad037cba2d879
Author: Stefan Roese
Date: Thu Sep 24 17:15:06 2009 +0200
USB: Fix timeout problem with polling loops in DWC USB-OTG driver
In [PATCH 6/9] Add Synopsys DesignWare HS USB OTG Controller driver
you are missing
commit 538fe70d696bc5e694ab08e9627a99a0b11358ec
Author: Stefan Roese
Date: Wed Sep 23 08:50:29 2009 +0200
USB: Fix problem with reconnection in DWC USB-OTG driver
etc.
Please update your code and resubmit.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The biggest difference between time and space is that you can't reuse
time. - Merrick Furst
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Good -- MUSB won't be the only one. ;) Could you mention a few Linux-enabled chips which include this controller? > arch/powerpc/boot/dts/kilauea.dts | 15 + Also, please provide a clean patch that only includes the driver, and split PPC hooks into a separate patch. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/9] Add Synopsys DesignWare HS USB OTG Controller driver.
The Peripheral Controller Driver (PCD) is responsible for translating
requests from the Function Driver into the appropriate actions on the
DWC OTG controller.
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
---
drivers/usb/otg/dwc_otg_pcd.c | 1749 +
drivers/usb/otg/dwc_otg_pcd.h | 159
2 files changed, 1908 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/dwc_otg_pcd.c
create mode 100644 drivers/usb/otg/dwc_otg_pcd.h
diff --git a/drivers/usb/otg/dwc_otg_pcd.c b/drivers/usb/otg/dwc_otg_pcd.c
new file mode 100644
index 000..152c0a6
--- /dev/null
+++ b/drivers/usb/otg/dwc_otg_pcd.c
@@ -0,0 +1,1749 @@
+/*
+ * DesignWare HS OTG controller driver
+ *
+ * Author: Mark Miesfeld
+ *
+ * Based on versions provided by AMCC and Synopsis which are:
+ * Copyright (C) 2009-2010 AppliedMicro(www.apm.com)
+ *
+ * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
+ * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
+ * otherwise expressly agreed to in writing between Synopsys and you.
+ *
+ * The Software IS NOT an item of Licensed Software or Licensed Product under
+ * any End User Software License Agreement or Agreement for Licensed Product
+ * with Synopsys or any supplement thereto. You are permitted to use and
+ * redistribute this Software in source and binary forms, with or without
+ * modification, provided that redistributions of source code must retain this
+ * notice. You may not view, use, disclose, copy or distribute this file or
+ * any information contained herein except pursuant to this license grant from
+ * Synopsys. If you do not agree with this notice, including the disclaimer
+ * below, then you are not authorized to use the Software.
+ *
+ * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/*
+ * This file implements the Peripheral Controller Driver.
+ *
+ * The Peripheral Controller Driver (PCD) is responsible for
+ * translating requests from the Function Driver into the appropriate
+ * actions on the DWC_otg controller. It isolates the Function Driver
+ * from the specifics of the controller by providing an API to the
+ * Function Driver.
+ *
+ * The Peripheral Controller Driver for Linux will implement the
+ * Gadget API, so that the existing Gadget drivers can be used.
+ * (Gadget Driver is the Linux terminology for a Function Driver.)
+ *
+ * The Linux Gadget API is defined in the header file linux/usb/gadget.h. The
+ * USB EP operations API is defined in the structure usb_ep_ops and the USB
+ * Controller API is defined in the structure usb_gadget_ops
+ *
+ * An important function of the PCD is managing interrupts generated
+ * by the DWC_otg controller. The implementation of the DWC_otg device
+ * mode interrupt service routines is in dwc_otg_pcd_intr.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dwc_otg_driver.h"
+#include "dwc_otg_pcd.h"
+
+/*
+ * Static PCD pointer for use in usb_gadget_register_driver and
+ * usb_gadget_unregister_driver. Initialized in dwc_otg_pcd_init.
+ */
+static struct dwc_pcd *s_pcd;
+
+static inline int need_stop_srp_timer(struct core_if *core_if)
+{
+ if (core_if->core_params->phy_type != DWC_PHY_TYPE_PARAM_FS ||
+ !core_if->core_params->i2c_enable)
+ return core_if->srp_timer_started ? 1 : 0;
+ return 0;
+}
+
+/**
+ * Tests if the module is set to FS or if the PHY_TYPE is FS. If so, then the
+ * gadget should not repo
[PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
The DWC OTG driver module provides the initialization and cleanup
entry points for the DWC OTG USB driver.
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
---
arch/powerpc/boot/dts/kilauea.dts | 15 +
drivers/usb/gadget/Kconfig|8 +-
drivers/usb/gadget/gadget_chips.h |7 +
drivers/usb/otg/Kconfig | 87 +++
drivers/usb/otg/Makefile | 10 +
drivers/usb/otg/dwc_otg_driver.c | 1236 +
drivers/usb/otg/dwc_otg_driver.h | 97 +++
7 files changed, 1457 insertions(+), 3 deletions(-)
create mode 100644 drivers/usb/otg/dwc_otg_driver.c
create mode 100644 drivers/usb/otg/dwc_otg_driver.h
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index 083e68e..1a141b8 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -394,5 +394,20 @@
0x0 0x0 0x0 0x3 &UIC2 0xd 0x4 /* swizzled int C
*/
0x0 0x0 0x0 0x4 &UIC2 0xe 0x4 /* swizzled int D
*/>;
};
+
+ USBOTG0: usb...@ef6c {
+ compatible = "amcc,dwc-otg";
+ reg = <0xef6c 0x1>;
+ interrupt-parent = <&USBOTG0>;
+ interrupts = <0x0 0x1 0x2>;
+ #interrupt-cells = <0x1>;
+ #address-cells = <0x0>;
+ #size-cells = <0x0>;
+ interrupt-map = <
+ 0x0 &UIC2 0x1e 0x4 /* USB-OTG */
+ 0x1 &UIC1 0x1a 0x8 /* HIGH-POWER */
+ 0x2 &UIC0 0xc 0x4 /* DMA */ >;
+ interrupt-map-mask = <0x>;
+ };
};
};
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 591ae9f..130626a 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -109,8 +109,8 @@ config USB_GADGET_SELECTED
# - discrete ones (including all PCI-only controllers)
# - debug/dummy gadget+hcd is last.
#
-choice
- prompt "USB Peripheral Controller"
+menuconfig USB_PERIPHERAL_CONTROLLER
+ bool "USB Peripheral Controller"
depends on USB_GADGET
help
A USB device uses a controller to talk to its host.
@@ -122,6 +122,8 @@ choice
# Integrated controllers
#
+if USB_PERIPHERAL_CONTROLLER
+
config USB_GADGET_AT91
boolean "Atmel AT91 USB Device Port"
depends on ARCH_AT91 && !ARCH_AT91SAM9RL && !ARCH_AT91CAP9 &&
!ARCH_AT91SAM9G45
@@ -542,7 +544,7 @@ config USB_DUMMY_HCD
# NOTE: Please keep dummy_hcd LAST so that "real hardware" appears
# first and will be selected by default.
-endchoice
+endif # USB_PERIPHERAL_CONTROLLER
config USB_GADGET_DUALSPEED
bool
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index e511fec..3d5c136 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -142,6 +142,11 @@
#define gadget_is_s3c_hsotg(g)0
#endif
+#if defined(CONFIG_USB_DWC_OTG) || defined(CONFIG_DWC_DEVICE_ONLY)
+#definegadget_is_dwc_otg_pcd(g)(!strcmp("dwc_otg_pcd",
(g)->name))
+#else
+#definegadget_is_dwc_otg_pcd(g)0
+#endif
/**
* usb_gadget_controller_number - support bcdDevice id convention
@@ -200,6 +205,8 @@ static inline int usb_gadget_controller_number(struct
usb_gadget *gadget)
return 0x25;
else if (gadget_is_s3c_hsotg(gadget))
return 0x26;
+ else if (gadget_is_dwc_otg_pcd(gadget))
+ return 0x27;
return -ENOENT;
}
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 3d2d3e5..745bac2 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -69,4 +69,91 @@ config NOP_USB_XCEIV
built-in with usb ip or which are autonomous and doesn't require any
phy programming such as ISP1x04 etc.
+config USB_DWC_OTG
+ depends on (USB || USB_GADGET)
+ depends on 405EZ || 405EX || 460EX
+ select USB_OTG_UTILS
+ tristate "Synopsys DWC OTG Controller"
+ default USB_GADGET
+ help
+ This driver provides USB Device Controller support for the
+ Synopsys DesignWare USB OTG Core used on the AMCC 405EZ/405EX/
+ 460EX.
+
+ Note that on the 405EZ, this Core provides USB Device Controller
+ function only. It does not act as a true OTG device, and the
+ 'OTG' is slightly misleading.
+
+config DWC_LEGACY_405EX
+ bool "Enable 405EX Legacy Support (lower performance)"
+ default n
+ depends on USB_DWC_OTG && 405EX
+ select DWC_SLAVE
+ help
+ Enable Legacy 405EX Chip support (Rev 1.0) where DWC DMA is broken
+ Selecting this option will cause lower performance
+ Don't select this unless you want to support Rev 1.0 405EX ch
[PATCH 5/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Implements DWC OTG USB Host Controller Driver (HCD) interrupt
service routine.
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
---
drivers/usb/otg/dwc_otg_hcd_intr.c | 1446
1 files changed, 1446 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/dwc_otg_hcd_intr.c
diff --git a/drivers/usb/otg/dwc_otg_hcd_intr.c
b/drivers/usb/otg/dwc_otg_hcd_intr.c
new file mode 100644
index 000..dc00184
--- /dev/null
+++ b/drivers/usb/otg/dwc_otg_hcd_intr.c
@@ -0,0 +1,1446 @@
+/*
+ * DesignWare HS OTG controller driver
+ *
+ * Author: Mark Miesfeld
+ *
+ * Based on versions provided by AMCC and Synopsis which are:
+ * Copyright (C) 2009-2010 AppliedMicro(www.apm.com)
+ *
+ * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
+ * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
+ * otherwise expressly agreed to in writing between Synopsys and you.
+ *
+ * The Software IS NOT an item of Licensed Software or Licensed Product under
+ * any End User Software License Agreement or Agreement for Licensed Product
+ * with Synopsys or any supplement thereto. You are permitted to use and
+ * redistribute this Software in source and binary forms, with or without
+ * modification, provided that redistributions of source code must retain this
+ * notice. You may not view, use, disclose, copy or distribute this file or
+ * any information contained herein except pursuant to this license grant from
+ * Synopsys. If you do not agree with this notice, including the disclaimer
+ * below, then you are not authorized to use the Software.
+ *
+ * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include "dwc_otg_driver.h"
+#include "dwc_otg_hcd.h"
+#include "dwc_otg_regs.h"
+
+/* This file contains the implementation of the HCD Interrupt handlers.
*/
+
+
+
+/**
+ * Handles the start-of-frame interrupt in host mode. Non-periodic
+ * transactions may be queued to the DWC_otg controller for the current
+ * (micro)frame. Periodic transactions may be queued to the controller for the
+ * next (micro)frame.
+ */
+static int dwc_otg_hcd_handle_sof_intr(struct dwc_hcd *hcd)
+{
+ union hfnum_data hfnum;
+ struct list_head *qh_entry;
+ struct dwc_qh *qh;
+ enum dwc_transaction_type tr_type;
+ union gintsts_data gintsts = {.d32 = 0};
+
+ hfnum.d32 =
+ dwc_read_reg32(&hcd->core_if->host_if->host_global_regs->hfnum);
+
+ hcd->frame_number = hfnum.b.frnum;
+
+ /* Determine whether any periodic QHs should be executed. */
+ qh_entry = hcd->periodic_sched_inactive.next;
+ while (qh_entry != &hcd->periodic_sched_inactive) {
+ qh = list_entry(qh_entry, struct dwc_qh, qh_list_entry);
+ qh_entry = qh_entry->next;
+
+ /*
+* If needed, move QH to the ready list to be executed next
+* (micro)frame.
+*/
+ if (dwc_frame_num_le(qh->sched_frame, hcd->frame_number))
+ list_move(&qh->qh_list_entry,
+ &hcd->periodic_sched_ready);
+ }
+
+ tr_type = dwc_otg_hcd_select_transactions(hcd);
+ if (tr_type != DWC_OTG_TRANSACTION_NONE)
+ dwc_otg_hcd_queue_transactions(hcd, tr_type);
+
+ /* Clear interrupt */
+ gintsts.b.sofintr = 1;
+ dwc_write_reg32(gintsts_reg(hcd), gintsts.d32);
+ return 1;
+}
+
+/**
+ * Handles the Rx Status Queue Level Interrupt, which indicates that there is
at
+ * least one packet in the Rx FIFO. The p
[PATCH 3/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Core Interface Layer Common Interrupt handlers provides common interrupt
handler for both host controller and peripheral controller.
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
---
drivers/usb/otg/dwc_otg_cil_intr.c | 625
1 files changed, 625 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/dwc_otg_cil_intr.c
diff --git a/drivers/usb/otg/dwc_otg_cil_intr.c
b/drivers/usb/otg/dwc_otg_cil_intr.c
new file mode 100644
index 000..2e5be88
--- /dev/null
+++ b/drivers/usb/otg/dwc_otg_cil_intr.c
@@ -0,0 +1,625 @@
+/*
+ * DesignWare HS OTG controller driver
+ *
+ * Author: Mark Miesfeld
+ *
+ * Based on versions provided by AMCC and Synopsis which are:
+ * Copyright (C) 2009-2010 AppliedMicro(www.apm.com)
+ *
+ * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
+ * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
+ * otherwise expressly agreed to in writing between Synopsys and you.
+ *
+ * The Software IS NOT an item of Licensed Software or Licensed Product under
+ * any End User Software License Agreement or Agreement for Licensed Product
+ * with Synopsys or any supplement thereto. You are permitted to use and
+ * redistribute this Software in source and binary forms, with or without
+ * modification, provided that redistributions of source code must retain this
+ * notice. You may not view, use, disclose, copy or distribute this file or
+ * any information contained herein except pursuant to this license grant from
+ * Synopsys. If you do not agree with this notice, including the disclaimer
+ * below, then you are not authorized to use the Software.
+ *
+ * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/*
+ * The Core Interface Layer provides basic services for accessing and
+ * managing the DWC_otg hardware. These services are used by both the
+ * Host Controller Driver and the Peripheral Controller Driver.
+ *
+ * This file contains the Common Interrupt handlers.
+ */
+
+#include "dwc_otg_regs.h"
+#include "dwc_otg_cil.h"
+
+#include
+#include
+
+inline const char *op_state_str(struct core_if *core_if)
+{
+ return (core_if->op_state == A_HOST ? "a_host" :
+ (core_if->op_state == A_SUSPEND ? "a_suspend" :
+ (core_if->op_state == A_PERIPHERAL ? "a_peripheral" :
+ (core_if->op_state == B_PERIPHERAL ? "b_peripheral" :
+ (core_if->op_state == B_HOST ? "b_host" : "unknown");
+}
+
+/**
+ * This function will log a debug message
+ */
+static int dwc_otg_handle_mode_mismatch_intr(struct core_if *core_if)
+{
+ union gintsts_data gintsts;
+
+ printk(KERN_WARNING "Mode Mismatch Interrupt: currently in %s mode\n",
+ dwc_otg_mode(core_if) ? "Host" : "Device");
+
+ /* Clear interrupt */
+ gintsts.d32 = 0;
+ gintsts.b.modemismatch = 1;
+ dwc_write_reg32(&core_if->core_global_regs->gintsts, gintsts.d32);
+
+ return 1;
+}
+
+/**
+ * Start the HCD. Helper function for using the HCD callbacks.
+ */
+static inline void hcd_start(struct core_if *core_if)
+{
+ if (core_if->hcd_cb && core_if->hcd_cb->start)
+ core_if->hcd_cb->start(core_if->hcd_cb->p);
+}
+
+/**
+ * Stop the HCD. Helper function for using the HCD callbacks.
+ */
+static inline void hcd_stop(struct core_if *core_if)
+{
+ if (core_if->hcd_cb && core_if->hcd_cb->stop)
+ core_if->hcd_cb->stop(core_if->hcd_cb->p);
+}
+
+/**
+ * Disconnect the HCD. Helper function for using the HCD callbacks.
+ */
+static inline void hcd_disc
[PATCH 6/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Implements functions to manage Queue Heads and Queue
Transfer Descriptors of DWC USB OTG Controller.
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
---
drivers/usb/otg/dwc_otg_hcd_queue.c | 584 +++
1 files changed, 584 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/dwc_otg_hcd_queue.c
diff --git a/drivers/usb/otg/dwc_otg_hcd_queue.c
b/drivers/usb/otg/dwc_otg_hcd_queue.c
new file mode 100644
index 000..a33c0da
--- /dev/null
+++ b/drivers/usb/otg/dwc_otg_hcd_queue.c
@@ -0,0 +1,584 @@
+/*
+ * DesignWare HS OTG controller driver
+ *
+ * Author: Mark Miesfeld
+ *
+ * Based on versions provided by AMCC and Synopsis which are:
+ * Copyright (C) 2009-2010 AppliedMicro(www.apm.com)
+ *
+ * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
+ * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
+ * otherwise expressly agreed to in writing between Synopsys and you.
+ *
+ * The Software IS NOT an item of Licensed Software or Licensed Product under
+ * any End User Software License Agreement or Agreement for Licensed Product
+ * with Synopsys or any supplement thereto. You are permitted to use and
+ * redistribute this Software in source and binary forms, with or without
+ * modification, provided that redistributions of source code must retain this
+ * notice. You may not view, use, disclose, copy or distribute this file or
+ * any information contained herein except pursuant to this license grant from
+ * Synopsys. If you do not agree with this notice, including the disclaimer
+ * below, then you are not authorized to use the Software.
+ *
+ * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/*
+ * This file contains the functions to manage Queue Heads and Queue
+ * Transfer Descriptors.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dwc_otg_driver.h"
+#include "dwc_otg_hcd.h"
+#include "dwc_otg_regs.h"
+
+static inline int is_fs_ls(enum usb_device_speed speed)
+{
+ return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+/* Allocates memory for a QH structure. */
+static inline struct dwc_qh *dwc_otg_hcd_qh_alloc(void)
+{
+ return kmalloc(sizeof(struct dwc_qh), GFP_ATOMIC);
+}
+
+/**
+ * Initializes a QH structure to initialize the QH.
+ */
+#define SCHEDULE_SLOP 10
+static void dwc_otg_hcd_qh_init(struct dwc_hcd *hcd, struct dwc_qh *qh,
+ struct urb *urb)
+{
+ memset(qh, 0, sizeof(struct dwc_qh));
+
+ /* Initialize QH */
+ switch (usb_pipetype(urb->pipe)) {
+ case PIPE_CONTROL:
+ qh->ep_type = USB_ENDPOINT_XFER_CONTROL;
+ break;
+ case PIPE_BULK:
+ qh->ep_type = USB_ENDPOINT_XFER_BULK;
+ break;
+ case PIPE_ISOCHRONOUS:
+ qh->ep_type = USB_ENDPOINT_XFER_ISOC;
+ break;
+ case PIPE_INTERRUPT:
+ qh->ep_type = USB_ENDPOINT_XFER_INT;
+ break;
+ }
+
+ qh->ep_is_in = usb_pipein(urb->pipe) ? 1 : 0;
+ qh->data_toggle = DWC_OTG_HC_PID_DATA0;
+ qh->maxp = usb_maxpacket(urb->dev, urb->pipe, !(usb_pipein(urb->pipe)));
+
+ INIT_LIST_HEAD(&qh->qtd_list);
+ INIT_LIST_HEAD(&qh->qh_list_entry);
+
+ qh->channel = NULL;
+
+ /*
+* FS/LS Enpoint on HS Hub NOT virtual root hub
+*/
+ qh->do_split = 0;
+ if (is_fs_ls(urb->dev->speed) && urb->dev->tt && urb->dev->tt->hub &&
+ urb->dev->tt->hub->devnum != 1)
+ qh->do_split = 1;
+
+
Re: [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
On Tue, 29 Jun 2010 16:34:34 -0500
Timur Tabi wrote:
> Introduce basic support for the Freescale P1022DS reference board, based on
> the
> Freescale BSP for this board.
>
> Details: No DIU video or SSI audio support, no MMC/SD card support, 36-bit and
> SWIOTLB support enabled, 36-bit DTS only, and CONFIG_NO_HZ disabled because it
> causes performance problems on this kernel.
what kind of performance problems?
> + enet0: ether...@b {
> + queue-gr...@0{
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xB 0x1000>;
> + fsl,rx-err-int-map = <0xAA>;
> + fsl,tx-int-map = <0xAA>;
> + interrupts = <29 2 30 2 34 2>;
> + };
> + queue-gr...@1{
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xB4000 0x1000>;
> + fsl,rx-err-int-map = <0x55>;
> + fsl,tx-int-map = <0x55>;
> + interrupts = <17 2 18 2 24 2>;
> + };
> + };
> +
> + enet1: ether...@b1000 {
> + queue-gr...@0{
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xB1000 0x1000>;
> + fsl,rx-err-int-map = <0xAA>;
> + fsl,tx-int-map = <0xAA>;
> + interrupts = <35 2 36 2 40 2>;
> + };
> + queue-gr...@1{
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xB5000 0x1000>;
> + fsl,rx-err-int-map = <0x55>;
> + fsl,tx-int-map = <0x55>;
> + interrupts = <51 2 52 2 67 2>;
> + };
these queue-group nodes, fsl,{r,t}x-* properties...
> + cry...@3 {
> + fsl,multi-host-mode = "dual";
> + fsl,channel-remap = <0x3>;
and the above two properties aren't supported by their respective
drivers, nor are they listed in the dts bindings documentation.
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
I really don't see any value at all to this config option, the errata fixup code should be there all the time. It really does no harm to be there in the cases where it isn't used, and forcing users to turn this on is just another obscure way to end up with an incorrect configuration. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ftp login problem using wu-ftpd
Dear Stevan Ignjatovic, In message <1277820991.4257.18.ca...@stevan> you wrote: > > I ported Linux-2.6.30-rc8 on my custom mpc885 board. The filesystem I am > using is jffs2 which I created from > eldk-4.2/ppc_8xx/images/ramdisk_image.gz. Linux boots fine and I can > telnet to the board but I cannot ftp: ... > Here ftp connection hangs. Do I have to create another user (beside > root) in order to make ftp connection? Earlier, when I was using 2.4 > linux I didn't have problems with ftp connection as root. check your kernel configuration. You might be missing options like CONFIG_UNIX98_PTYS or CONFIG_LEGACY_PTYS or similar. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Every program has at least one bug and can be shortened by at least one instruction - from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH] powerpc: introduce basic support for the Freescale P1022DS reference board
On Jun 29, 2010, at 4:34 PM, Timur Tabi wrote:
> Introduce basic support for the Freescale P1022DS reference board, based on
> the
> Freescale BSP for this board.
>
> Details: No DIU video or SSI audio support, no MMC/SD card support, 36-bit and
> SWIOTLB support enabled, 36-bit DTS only, and CONFIG_NO_HZ disabled because it
> causes performance problems on this kernel.
>
> Signed-off-by: Timur Tabi
> ---
>
> This patch is for 2.6.36.
>
> arch/powerpc/boot/dts/p1022ds.dts| 676 +++
> arch/powerpc/configs/85xx/p1022_ds_defconfig | 1620 ++
> arch/powerpc/platforms/85xx/Kconfig |9 +
> arch/powerpc/platforms/85xx/Makefile |1 +
> arch/powerpc/platforms/85xx/p1022_ds.c | 148 +++
> 5 files changed, 2454 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1022ds.dts
> create mode 100644 arch/powerpc/configs/85xx/p1022_ds_defconfig
> create mode 100644 arch/powerpc/platforms/85xx/p1022_ds.c
Drop the defconfig and update mpc85xx_{smp_}defconfig to build p1022.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_ISA_DMA_API without CONFIG_GENERIC_ISA_DMA
On Thu, Feb 25, 2010 at 3:40 PM, Scott Wood wrote: > Commit fb4f0e8832e0075849b41b65f6bb9fdfa7593b99 (Enable GENERIC_ISA_DMA if > FSL_ULI1575 to fix compile issue) tries to deal with this, but it ties it to > CONFIG_FSL_ULI1575, which is not selected in a p4080ds-only config. > > It seems that ULI isn't really relevant to the actual problem, which is that > we enable ISA DMA API support without selecting an implementation. Whether > a certain chip is on the board that has an actual ISA interface is > irrelevant to the build breakage. > > Where did the dependency list for GENERIC_ISA_DMA come from? Are there any > legitimate cases on powerpc where we want to select ISA_DMA_API but not > GENERIC_ISA_DMA (i.e. we have an alternate implementation)? I've been bitten by this issue as well on the P1022DS. If I enable ALSA, then some ISA support also gets compile (by itself, that's probably a bug), and that code calls claim_dma_lock(). This problem's been around for a long time. I would have encountered it on the MPC8610 HPCD, but that board has an ULI 1575. The P1022Ds doesn't. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
MPC8313ECE says:
"If the controller receives a 1- or 2-byte frame (such as an illegal
runt packet or a packet with RX_ER asserted) before GRS is asserted
and does not receive any other frames, the controller may fail to set
GRSC even when the receive logic is completely idle. Any subsequent
receive frame that is larger than two bytes will reset the state so
the graceful stop can complete. A MAC receiver (Rx) reset will also
reset the state."
This patch implements the proposed workaround:
"If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
If the register fields are not equal, wait for another timeout
period and check again."
Signed-off-by: Anton Vorontsov
---
drivers/net/gianfar.c | 40 +---
drivers/net/gianfar.h |1 +
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f8b9693..f3da17a 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -947,6 +947,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 && mod == 0x80b0) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_A002;
+
if (priv->errata) {
#ifdef CONFIG_GIANFAR_ERRATA
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
@@ -1577,6 +1582,29 @@ static void init_registers(struct net_device *dev)
gfar_write(®s->minflr, MINFLR_INIT_SETTINGS);
}
+static int __gfar_is_rx_idle(struct gfar_private *priv)
+{
+ u32 res;
+
+ /*
+* Normaly TSEC should not hang on GRS commands, so we should
+* actually wait for IEVENT_GRSC flag.
+*/
+ if (likely(!gfar_has_errata(priv, A002)))
+ return 0;
+
+ /*
+* Read the eTSEC register at offset 0xD1C. If bits 7-14 are
+* the same as bits 23-30, the eTSEC Rx is assumed to be idle
+* and the Rx can be safely reset.
+*/
+ res = gfar_read((void __iomem *)priv->gfargrp[0].regs + 0xd1c);
+ res &= 0x7f807f80;
+ if ((res & 0x) == (res >> 16))
+ return 1;
+
+ return 0;
+}
/* Halt the receive and transmit queues */
static void gfar_halt_nodisable(struct net_device *dev)
@@ -1600,12 +1628,18 @@ static void gfar_halt_nodisable(struct net_device *dev)
tempval = gfar_read(®s->dmactrl);
if ((tempval & (DMACTRL_GRS | DMACTRL_GTS))
!= (DMACTRL_GRS | DMACTRL_GTS)) {
+ int ret;
+
tempval |= (DMACTRL_GRS | DMACTRL_GTS);
gfar_write(®s->dmactrl, tempval);
- spin_event_timeout(((gfar_read(®s->ievent) &
-(IEVENT_GRSC | IEVENT_GTSC)) ==
-(IEVENT_GRSC | IEVENT_GTSC)), -1, 0);
+ do {
+ ret = spin_event_timeout(((gfar_read(®s->ievent) &
+(IEVENT_GRSC | IEVENT_GTSC)) ==
+(IEVENT_GRSC | IEVENT_GTSC)), 100, 0);
+ if (!(gfar_read(®s->ievent) & IEVENT_GRSC))
+ ret = __gfar_is_rx_idle(priv);
+ } while (!ret);
}
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index fb308c8..e0907eb 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1028,6 +1028,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
+ GFAR_ERRATA_A002= 0x04,
};
#ifdef CONFIG_GIANFAR_ERRATA
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] gianfar: Implement workaround for eTSEC76 erratum
MPC8313ECE says:
"For TOE=1 huge or jumbo frames, the data required to generate the
checksum may exceed the 2500-byte threshold beyond which the controller
constrains itself to one memory fetch every 256 eTSEC system clocks.
This throttling threshold is supposed to trigger only when the
controller has sufficient data to keep transmit active for the duration
of the memory fetches. The state machine handling this threshold,
however, fails to take large TOE frames into account. As a result,
TOE=1 frames larger than 2500 bytes often see excess delays before start
of transmission."
This patch implements the workaround as suggested by the errata
document, i.e.:
"Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
memory throttling.
When using packets larger than 2700 bytes, it is recommended to turn TOE
off."
To be sure, we limit the TOE frames to 2500 bytes, and do software
checksumming instead.
Signed-off-by: Anton Vorontsov
---
drivers/net/gianfar.c | 19 +++
drivers/net/gianfar.h |1 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 9c85d05..f8b9693 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -942,6 +942,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_74;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 && mod == 0x80b0) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_76;
+
if (priv->errata) {
#ifdef CONFIG_GIANFAR_ERRATA
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
@@ -2018,6 +2023,20 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
unsigned int nr_frags, nr_txbds, length;
union skb_shared_tx *shtx;
+ /*
+* TOE=1 frames larger than 2500 bytes may see excess delays
+* before start of transmission.
+*/
+ if (unlikely(gfar_has_errata(priv, 76) &&
+ skb->ip_summed == CHECKSUM_PARTIAL &&
+ skb->len > 2500)) {
+ int ret;
+
+ ret = skb_checksum_help(skb);
+ if (ret)
+ return ret;
+ }
+
rq = skb->queue_mapping;
tx_queue = priv->tx_queue[rq];
txq = netdev_get_tx_queue(dev, rq);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d1e2986..fb308c8 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1027,6 +1027,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
+ GFAR_ERRATA_76 = 0x02,
};
#ifdef CONFIG_GIANFAR_ERRATA
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
MPC8313ECE says:
"If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
which are larger than MAXFRM, the controller truncates the frames to
length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
or MAXFRM-1, even though those frames are not truncated.
No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
There are two options to workaround the issue:
"1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
frames. Software can determine if a frame is larger than MAXFRM by
reading RxBD[LG] or RxBD[Data Length].
2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
normal-length frames are not marked as truncated. Software can examine
RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
This patch implements the first workaround option by setting HUGEFRAME
bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
Signed-off-by: Anton Vorontsov
---
drivers/net/Kconfig | 10 ++
drivers/net/gianfar.c | 36 ++--
drivers/net/gianfar.h | 11 +++
3 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ce2fcdd..d3fcaba 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2400,6 +2400,16 @@ config GIANFAR
This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
and MPC86xx family of chips, and the FEC on the 8540.
+config GIANFAR_ERRATA
+ bool "Gianfar Ethernet errata handling"
+ depends on GIANFAR && (PPC_MPC837x || PPC_MPC831x)
+ default y
+ help
+ With this option enabled, gianfar driver will able to cope with
+ some TSEC errata.
+
+ If unsure, say Y.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 28b53d1..9c85d05 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -85,6 +85,7 @@
#include
#include
+#include
#include
#include
#include
@@ -928,6 +929,31 @@ static void gfar_init_filer_table(struct gfar_private
*priv)
}
}
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = &priv->ofdev->dev;
+ unsigned int pvr = mfspr(SPRN_PVR);
+ unsigned int svr = mfspr(SPRN_SVR);
+ unsigned int mod = (svr >> 16) & 0xfff6; /* w/o E suffix */
+ unsigned int rev = svr & 0x;
+
+ /* MPC8313 Rev 2.0 and higher; All MPC837x */
+ if ((pvr == 0x80850010 && mod == 0x80b0 && rev >= 0x0020) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_74;
+
+ if (priv->errata) {
+#ifdef CONFIG_GIANFAR_ERRATA
+ dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
+ priv->errata);
+#else
+ dev_warn(dev, "consider enabling CONFIG_GIANFAR_ERRATA, "
+"flags: 0x%x\n", priv->errata);
+ WARN_ON(1);
+#endif /* CONFIG_GIANFAR_ERRATA */
+ }
+}
+
/* Set up the ethernet device structure, private data,
* and anything else we need before we start */
static int gfar_probe(struct of_device *ofdev,
@@ -960,6 +986,8 @@ static int gfar_probe(struct of_device *ofdev,
dev_set_drvdata(&ofdev->dev, priv);
regs = priv->gfargrp[0].regs;
+ gfar_detect_errata(priv);
+
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
gfar_halt(dev);
@@ -974,7 +1002,10 @@ static int gfar_probe(struct of_device *ofdev,
gfar_write(®s->maccfg1, tempval);
/* Initialize MACCFG2. */
- gfar_write(®s->maccfg2, MACCFG2_INIT_SETTINGS);
+ tempval = MACCFG2_INIT_SETTINGS;
+ if (gfar_has_errata(priv, 74))
+ tempval |= MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK;
+ gfar_write(®s->maccfg2, tempval);
/* Initialize ECNTRL */
gfar_write(®s->ecntrl, ECNTRL_INIT_SETTINGS);
@@ -2300,7 +2331,8 @@ static int gfar_change_mtu(struct net_device *dev, int
new_mtu)
* to allow huge frames, and to check the length */
tempval = gfar_read(®s->maccfg2);
- if (priv->rx_buffer_size > DEFAULT_RX_BUFFER_SIZE)
+ if (priv->rx_buffer_size > DEFAULT_RX_BUFFER_SIZE ||
+ gfar_has_errata(priv, 74))
tempval |= (MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
else
tempval &= ~(MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index ac4a92e..d1e2986 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1025,6 +1025,16 @@ struct gfar_priv_grp {
char int_name_er[GFAR_INT_NAME_MAX];
};
+enum gfar_errata {
CONFIG_NO_HZ causing poor console responsiveness
I'm adding support for a new e500-based board (the P1022DS), and in the process I've discovered that enabling CONFIG_NO_HZ (Tickless System / Dynamic Ticks) causes significant responsiveness problems on the serial console. When I type on the console, I see delays of up to a half-second for almost every character. It acts as if there's a background process eating all the CPU. I don't have time to debug this thoroughly at the moment. The problem occurs in the latest kernel, but it appears not to occur in 2.6.32. Has anyone else seen anything like this? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/85xx platorms: kexec for SMP 85xx BookE systems
Adds support for kexec on 85xx machines for the BookE platform.
Including support for SMP machines
Based off work from Maxim Uvarov
Signed-off-by: Matthew McClintock
---
To test/use you will need to fetch kexec from GIT and apply the following
patch for kexec to work properply with uImages
http://lists.infradead.org/pipermail/kexec/2010-June/004163.html
arch/powerpc/Kconfig |2 +-
arch/powerpc/platforms/85xx/smp.c | 57 +
2 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..042f2f0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -351,7 +351,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool "kexec system call (EXPERIMENTAL)"
- depends on (PPC_BOOK3S || (FSL_BOOKE && !SMP)) && EXPERIMENTAL
+ depends on (PPC_BOOK3S || FSL_BOOKE) && EXPERIMENTAL
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index a15f582..35c3d95 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -24,6 +25,7 @@
#include
#include
+#include
extern void __early_start(void);
@@ -103,8 +105,58 @@ smp_85xx_setup_cpu(int cpu_nr)
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+#ifdef CONFIG_KEXEC
+ .give_timebase = smp_generic_give_timebase,
+ .take_timebase = smp_generic_take_timebase,
+#endif
};
+#ifdef CONFIG_KEXEC
+void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
+{
+ mpic_teardown_this_cpu(1);
+}
+
+static int kexec_down_cpus = 0;
+
+static void mpc85xx_smp_kexec_down(void *arg)
+{
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(0,1);
+
+ local_irq_disable();
+ kexec_down_cpus++;
+ while (1) ;
+}
+
+static void mpc85xx_smp_machine_kexec(struct kimage *image)
+{
+ int timeout = 1000;
+ int i;
+
+ set_cpus_allowed(current, cpumask_of_cpu(boot_cpuid));
+
+ smp_call_function(mpc85xx_smp_kexec_down, NULL, 0);
+
+ while ( (kexec_down_cpus != (num_present_cpus() - 1)) &&
+ ( timeout-- > 0 ) )
+ {
+ timeout--;
+ }
+
+ if ( !timeout )
+ printk(KERN_ERR "Unable to bring down secondary cpu(s)");
+
+ for (i = 0; i < num_present_cpus(); i++)
+ {
+ if ( i == smp_processor_id() ) continue;
+ mpic_reset_core(i);
+ }
+
+ default_machine_kexec(image);
+}
+#endif /* CONFIG_KEXEC */
+
void __init mpc85xx_smp_init(void)
{
struct device_node *np;
@@ -122,4 +174,9 @@ void __init mpc85xx_smp_init(void)
BUG_ON(!smp_85xx_ops.message_pass);
smp_ops = &smp_85xx_ops;
+
+#ifdef CONFIG_KEXEC
+ ppc_md.kexec_cpu_down = mpc85xx_smp_kexec_cpu_down;
+ ppc_md.machine_kexec = mpc85xx_smp_machine_kexec;
+#endif
}
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/mpic: Add ability to reset a core via MPIC
We need the ability to reset cores for use with kexec/kdump for
SMP systems. Calling this function with the specific core you want
to reset will cause the CPU to spin in reset.
Signed-off-by: Matthew McClintock
---
arch/powerpc/sysdev/mpic.c | 18 ++
arch/powerpc/sysdev/mpic.h |1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 20b73c0..7c13426 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1636,6 +1636,24 @@ void __devinit smp_mpic_setup_cpu(int cpu)
{
mpic_setup_this_cpu();
}
+
+void mpic_reset_core(int cpu)
+{
+ struct mpic *mpic = mpic_primary;
+ u32 pir;
+ int cpuid = get_hard_smp_processor_id(cpu);
+
+ /* Set target bit for core reset */
+ pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+ pir |= (1 << cpuid);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Restore target bit after reset complete */
+ pir &= ~(1 << cpuid);
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+}
#endif /* CONFIG_SMP */
#ifdef CONFIG_PM
diff --git a/arch/powerpc/sysdev/mpic.h b/arch/powerpc/sysdev/mpic.h
index eff433c..e4a6df7 100644
--- a/arch/powerpc/sysdev/mpic.h
+++ b/arch/powerpc/sysdev/mpic.h
@@ -37,5 +37,6 @@ static inline int mpic_pasemi_msi_init(struct mpic *mpic)
extern int mpic_set_irq_type(unsigned int virq, unsigned int flow_type);
extern void mpic_set_vector(unsigned int virq, unsigned int vector);
extern int mpic_set_affinity(unsigned int irq, const struct cpumask *cpumask);
+extern void mpic_reset_core(int cpu);
#endif /* _POWERPC_SYSDEV_MPIC_H */
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-booke: Fix address issue when using relocatable kernels
When booting a relocatable kernel it needs to jump to the correct start address, which for BookE parts is usually unchanged regardless of the physical memory offset. Recent changes cause problems with how we calculate the start address, it was always adding the RMO into the start address which is incorrect. This patch only adds in the RMO offset if we are in the kexec code path, as it needs the RMO to work correctly. Instead of adding the RMO offset in in the common code path, we can just set r6 to the RMO offset in the kexec code path instead of to zero, and finally perform the masking in the common code path Signed-off-by: Matthew McClintock --- arch/powerpc/kernel/fsl_booke_entry_mapping.S |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/fsl_booke_entry_mapping.S b/arch/powerpc/kernel/fsl_booke_entry_mapping.S index beb4d78..a92c79b 100644 --- a/arch/powerpc/kernel/fsl_booke_entry_mapping.S +++ b/arch/powerpc/kernel/fsl_booke_entry_mapping.S @@ -205,8 +205,7 @@ next_tlb_setup: bdnz+ next_tlb_setup /* 7. Jump to our 1:1 mapping */ - li r6, 0 - + mr r6, r25 #else #error You need to specify the mapping or not use this at all. #endif @@ -217,7 +216,6 @@ next_tlb_setup: 1: mflrr9 rlwimi r6,r9,0,20,31 addir6,r6,(2f - 1b) - add r6, r6, r25 mtspr SPRN_SRR0,r6 mtspr SPRN_SRR1,r7 rfi /* start execution out of TLB1[0] entry */ -- 1.6.6.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
On Tue, Jun 29, 2010 at 12:59:56AM -0700, Shawn Jin wrote: > I'm porting a mpc870 board to the powerpc arch. The base is the > adder-875 board. My first try to boot the cuImage.my870 is > experiencing a machine check. And I have no clue where to look. Any > help? > > => bootm 100 > ## Booting image at 0100 ... >Image Name: Linux-2.6.33.5 >Image Type: PowerPC Linux Kernel Image (gzip compressed) >Data Size:747319 Bytes = 729.8 kB >Load Address: 0040 >Entry Point: 004004d4 >Verifying Checksum ... OK >Uncompressing Kernel Image ... OK > Bus Fault @ 0x00404c40, fixup 0x > Machine check in kernel mode. > Caused by (from msr): regs 07d1cb80 Unknown values in msr > NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: > 0001 > MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 Can you look up the source line/instruction corresponding to 0x404c40, in the wrapper ELF file? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
These processors will corrupt data if accessing the local bus with unaligned addresses. This version fixes the typical case of copying from Flash on the local bus by keeping the source address always aligned. On many platforms accessing ROM as RAM simply doesn't work(*). You shouldn't map ROM as if it is RAM, and shouldn't use the same access functions on it. Segher (*) Example: any existing 970 system will checkstop as soon as you try to do any cacheable access to some ROM. Another example of course is unaligned accesses on pretty much any system, no matter whether it's called a bug or a feature on that system :-P ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC Patch 1/1] Implement hardware breakpoint interfaces for PowerPC BookE processors
Introduce support for generic hw-breakpoint interfaces for PowerPC
BookIII E processors.
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig |2
arch/powerpc/include/asm/cputable.h|4
arch/powerpc/include/asm/hw_breakpoint_booke.h | 46 ++
arch/powerpc/kernel/Makefile |4
arch/powerpc/kernel/hw_breakpoint_booke.c | 429 +
arch/powerpc/kernel/process.c |3
arch/powerpc/kernel/ptrace.c | 51 ++
arch/powerpc/kernel/traps.c|9
include/linux/perf_event.h |4
kernel/trace/trace_ksym.c |4
10 files changed, 554 insertions(+), 2 deletions(-)
Index: linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
===
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
@@ -0,0 +1,46 @@
+#ifndef_I386_HW_BREAKPOINT_H
+#define_I386_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+
+struct arch_hw_breakpoint {
+ unsigned intlen;
+ unsigned long address;
+ unsigned long type;
+};
+
+#include
+#include
+#include
+
+/* Breakpoint length beyond which we should use 'range' breakpoints */
+#define DAC_LEN 8
+#define HW_BREAKPOINT_ALIGN 0x3
+
+static inline int hw_breakpoint_slots(int type)
+{
+ return HBP_NUM;
+}
+
+struct perf_event;
+struct perf_sample_data;
+struct pmu;
+
+extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+extern void hw_breakpoint_handler(struct pt_regs *regs,
+ unsigned long debug_status);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+
+extern struct pmu perf_ops_bp;
+
+#endif /* __KERNEL__ */
+#endif /* _I386_HW_BREAKPOINT_H */
+
Index: linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
===
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
@@ -0,0 +1,429 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers for PowerPC BookIII E. Derived from
+ * "arch/powerpc/kernel/hw_breakpoint.c"
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2010 IBM Corporation
+ * Author: K.Prasad
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Stores the breakpoints currently in use on each debug register for each CPU
+ * register for each cpus
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg[HBP_NUM]);
+
+int hw_breakpoint_weight(struct perf_event *bp)
+{
+ return (bp->attr.bp_len > DAC_LEN) ? 2 : 1;
+}
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint. Eventually we enable it in the debug control register.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ int i;
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+
+ for (i = 0; i < HBP_NUM; i++) {
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg[i]);
+
+ if (*slot)
+ continue;
+ *slot = bp;
+ mtspr(SPRN_DAC1, info->address);
+ /* Clean the 'type' fields from DBCR0 to erase old values */
+ dbcr0 &= ~(DBCR0_DAC1W | DBCR0_DAC1R | DBCR0_DAC2W |
DBCR0_DAC2R);
+
+ mtspr(SPRN_DBCR0,
Re: kernel init exception
why there generated a signal 4 in init process? That's SIGILL; sounds like you compiled init with the wrong (sub-)arch or cpu flags. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC Patch 0/1] hw-breakpoint interfaces for BookE - ver II
Hi All, Please find a new version of the patch that implements generic hw-breakpoint interfaces for PowerPC BookIII E. While there are several improvements over the previous version in terms of code placement, support for ptrace and fixes for incorrect issues, the patch remains compile-tested (only)(against 44x/iss476-smp_defconfig config) and is yet to be tested on hardware (for functionality). Changelog Version II (Version I:linuxppc-dev message-id: 20100427164029.ga8...@in.ibm.com) - - ptrace requests (through PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG) are now supported. - Changes in original arch/powerpc/kernel/hw_breakpoint.c have been percolated down to hw_breakpoint_booke.c (such as introduction of thread_change_pc(), arch_unregister_hw_breakpoint() and changes to hw_breakpoint_handler()) along with some code re-arrangement (for brevity/clarity). The usage of CONFIG (in this patch) option doesn't largely represent a form that it would turn into after enabling the use of DVCs, DACs by non-ptrace breakpoint requests. They should turn correct as versions of this patch progress. Kindly let me know your comments. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
These processors will corrupt data if accessing the local bus with unaligned addresses. This version fixes the typical case of copying from Flash on the local bus by keeping the source address always aligned. Signed-off-by: Steve Deiters --- arch/powerpc/lib/copy_32.S | 56 1 files changed, 56 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S index 74a7f41..42e7df5 100644 --- a/arch/powerpc/lib/copy_32.S +++ b/arch/powerpc/lib/copy_32.S @@ -226,6 +226,60 @@ _GLOBAL(memmove) bgt backwards_memcpy /* fall through */ +#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx) + +/* + * Alternate memcpy for MPC512x and MPC52xx to guarantee source + * address is always aligned to prevent corruption issues when + * copying unaligned from the local bus. This only fixes the usage + * when copying from the local bus (e.g. Flash) and will not fix + * issues copying to the local bus + */ +_GLOBAL(memcpy) + srwi. r7,r5,3 + addir6,r3,-4 + addir4,r4,-4 + beq 2f /* if less than 8 bytes to do */ + andi. r0,r4,3 /* get src word aligned */ + mtctr r7 + bne 5f +1: lwz r7,4(r4) + lwzur8,8(r4) + stw r7,4(r6) + stwur8,8(r6) + bdnz1b + andi. r5,r5,7 +2: cmplwi 0,r5,4 + blt 3f + andi. r0,r4,3 + bne 3f + lwzur0,4(r4) + addir5,r5,-4 + stwur0,4(r6) +3: cmpwi 0,r5,0 + beqlr + mtctr r5 + addir4,r4,3 + addir6,r6,3 +4: lbzur0,1(r4) + stbur0,1(r6) + bdnz4b + blr +5: subfic r0,r0,4 + mtctr r0 +6: lbz r7,4(r4) + addir4,r4,1 + stb r7,4(r6) + addir6,r6,1 + bdnz6b + subfr5,r0,r5 + rlwinm. r7,r5,32-3,3,31 + beq 2b + mtctr r7 + b 1b + +#else + _GLOBAL(memcpy) srwi. r7,r5,3 addir6,r3,-4 @@ -267,6 +321,8 @@ _GLOBAL(memcpy) mtctr r7 b 1b +#endif + _GLOBAL(backwards_memcpy) rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */ add r6,r3,r5 -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Using devices trees on X86
> -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Monday, June 28, 2010 7:39 PM > To: Stephen Neuendorffer > Cc: grant.lik...@secretlab.ca; devicetree-disc...@lists.ozlabs.org; David Miller; > sparcli...@vger.kernel.org; Michal Simek; microblaze-ucli...@itee.uq.edu.au; Benjamin Herrenschmidt; > Paul Mackerras; linuxppc-dev@lists.ozlabs.org > Subject: Re: Using devices trees on X86 > > Hi Stephen, > > On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer wrote: > > > > 2) config OF is currently implemented in the architecture code. This > > should be non-architecture dependent and selected by the arches that > > need it. > > > > Comments greatly appreciated, in particular if you have > > likely-to-be-easy-to-get-accepted suggestions for 3), or feel like > > carefully solving 2) in > > a way which doesn't bork the existing of-based arches. > > See the following patch set. Parts 1, 2 and 3 could be applied to the > respective architecture trees as well as Grant's tree to aleviate some > conflict problems. Part 5 could wait until a later time if necessary. > However, this is relatively trivial, so we could just collect ACKs and > put it all in Grant's tree and live with any minor pain. > > Having OF in more than one Kconfig file should not cause any problems as > long as they are all the same. Ah, well, that simplifies things.. :) Thanks! Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
kernel init exception
We are porting linux 2.6.21.7 to a powerpc e500mc board , p4080.
But something is wrong when loading init file:
log:
free init memory...
init has generated signal 4 but has no handler for it
I found it print in _exception --->
if (is_init(current)) {
if (handler == SIG_DFL) {
printk(KERN_CRIT "init has generated signal %d "
"but has no handler for it\n", signr);
do_exit(signr);
}
}
why there generated a signal 4 in init process?
Thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ftp login problem using wu-ftpd
Hi all,
I ported Linux-2.6.30-rc8 on my custom mpc885 board. The filesystem I am
using is jffs2 which I created from
eldk-4.2/ppc_8xx/images/ramdisk_image.gz. Linux boots fine and I can
telnet to the board but I cannot ftp:
# ftp 10.8.1.5
Connected to 10.8.1.5.
220 10.8.1.5 FTP server (Version wu-2.6.2(1) Wed Apr 2 09:10:49 MEST
2008) ready.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (10.8.1.5:root): root
Here ftp connection hangs. Do I have to create another user (beside
root) in order to make ftp connection? Earlier, when I was using 2.4
linux I didn't have problems with ftp connection as root.
/etc/ftpaccess:
class all real,guest,anonymous *
email r...@localhost
loginfails 5
readme README*login
readme README*cwd=*
message /welcome.msglogin
message .messagecwd=*
compressyes all
tar yes all
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
log transfers anonymous,real inbound,outbound
shutdown /etc/shutmsg
passwd-check rfc822 warn
/etc/xinetd.d/wu-ftpd:
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
socket_type = stream
wait= no
user= root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice= 10
disable = no
}
/etc/pam.d/ftp:
#%PAM-1.0
authinclude system-auth
auth required /lib/security/pam_listfile.so item=user sense=deny
file=/etc/ftpusers onerr=succeed
auth required /lib/security/pam_shells.so
account include system-auth
session include system-auth
Thanks in advance.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sched: fix spelling of sibling
Michael Neuling wrote: > No logic changes, only spelling. > > Signed-off-by: Michael Neuling Acked-by: David Howells ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Add generic hpte management functions
On 06/29/2010 04:06 PM, Alexander Graf wrote:
Are we looking at the same link? Looks good to me there.
We're probably looking at the same link but looking at different
things. I'm whining about
static u64 f() {
...
}
as opposed to the more sober
static u64 f()
{
...
}
for f in [kvmppc_mmu_hash_pte, kvmppc_mmu_hash_vpte,
kvmppc_mmu_hash_vpte_long].
--
error compiling committee.c: too many arguments to function
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Add generic hpte management functions
Avi Kivity wrote:
> On 06/29/2010 03:56 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>>
>> +
>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>> +return hash_64(eaddr>>PTE_SIZE, HPTEG_HASH_BITS_PTE);
>> +}
>> +
>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>> +return hash_64(vpage&0xfULL, HPTEG_HASH_BITS_VPTE);
>> +}
>> +
>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>> +return hash_64((vpage&0xff000ULL)>>12,
>> + HPTEG_HASH_BITS_VPTE_LONG);
>> +}
>>
>>
>>
> Still with the wierd coding style?
>
>
Not sure what's going on there. My editor displays it normally. Weird.
>>> Try hitting 'save'.
>>>
>> hexdump -C on the respective section in the exact patch file I submitted
>> above shows:
>>
>> 0a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
>> hash_64(eadd|
>> 0a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
>> PTE_SIZE, H|
>>
>>
>> Maybe your mail client breaks it?
>>
>
> The list archives too:
>
> http://www.mail-archive.com/k...@vger.kernel.org/msg37093.html
>
> Looks like a cache coherency bug. What processor are you using?
Are we looking at the same link? Looks good to me there.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Add generic hpte management functions
On 06/29/2010 03:56 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 06/28/2010 11:55 AM, Alexander Graf wrote:
+
+static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
+return hash_64(eaddr>>PTE_SIZE, HPTEG_HASH_BITS_PTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
+return hash_64(vpage&0xfULL, HPTEG_HASH_BITS_VPTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
+return hash_64((vpage&0xff000ULL)>>12,
+ HPTEG_HASH_BITS_VPTE_LONG);
+}
Still with the wierd coding style?
Not sure what's going on there. My editor displays it normally. Weird.
Try hitting 'save'.
hexdump -C on the respective section in the exact patch file I submitted
above shows:
0a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
hash_64(eadd|
0a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
PTE_SIZE, H|
Maybe your mail client breaks it?
The list archives too:
http://www.mail-archive.com/k...@vger.kernel.org/msg37093.html
Looks like a cache coherency bug. What processor are you using?
--
error compiling committee.c: too many arguments to function
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: PPC: Add generic hpte management functions
Avi Kivity wrote:
> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
+
+static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
+return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
+return hash_64(vpage& 0xfULL, HPTEG_HASH_BITS_VPTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
+return hash_64((vpage& 0xff000ULL)>> 12,
+ HPTEG_HASH_BITS_VPTE_LONG);
+}
>>> Still with the wierd coding style?
>>>
>> Not sure what's going on there. My editor displays it normally. Weird.
>>
>
> Try hitting 'save'.
hexdump -C on the respective section in the exact patch file I submitted
above shows:
0a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
hash_64(eadd|
0a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r >>
PTE_SIZE, H|
Maybe your mail client breaks it?
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driver
On Tue, Jun 29, 2010 at 03:33:50AM +0200, Marek Vasut wrote: > Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a): > > This patch enables the on-chip DWC SATA controller of the AppliedMicro > > processor 460EX. > > > > Signed-off-by: Rupjyoti Sarmah > > Signed-off-by: Mark Miesfeld > > Signed-off-by: Prodyut Hazarika > > > > --SNIP-- > > > + dev_err(ap->dev, "%s: Command not pending cmd_issued=%d " > > + "(tag=%d) DMA NOT started\n", __func__, > > + hsdevp->cmd_issued[tag], tag); > > Just a nitpick, but don't break strings if possible. Note that in this particular case breaking strings was OK, and was actually done in a clever manner. That is, I doubt that anyone grep for error messages with regexps, so grep "Command not pending" or grep "DMA NOT started" would work. This makes the code more readable (literally, because you don't have to scroll to see dev_err's arguments) without sacrificing grep'ability. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH]460EX on-chip SATA driver
Hi, Thanks for your feedback. I submitted an updated version of this patch later. I tried to limit the lines within 80 characters. Regards, Rup -Original Message- From: Marek Vasut [mailto:marek.va...@gmail.com] Sent: Tuesday, June 29, 2010 7:04 AM To: Rupjyoti Sarmah Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; jgar...@pobox.com; s...@denx.de; linuxppc-...@ozlabs.org Subject: Re: [PATCH]460EX on-chip SATA driver Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a): > This patch enables the on-chip DWC SATA controller of the AppliedMicro > processor 460EX. > > Signed-off-by: Rupjyoti Sarmah > Signed-off-by: Mark Miesfeld > Signed-off-by: Prodyut Hazarika > --SNIP-- > + dev_err(ap->dev, "%s: Command not pending cmd_issued=%d " > + "(tag=%d) DMA NOT started\n", __func__, > + hsdevp->cmd_issued[tag], tag); Just a nitpick, but don't break strings if possible. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/26] KVM: PPC: Introduce shared page
On 06/29/2010 12:54 PM, Alexander Graf wrote: Code repeats 3x. Share please. Looking at this again, I could combine the 3 lines of init code into 3 lines of code that do a generic function call and then error checking. And I could convert the one free_page line with one function call that would free the page. Is there a real gain behind this? Looks marginal, yes. It will help if initialization is expanded later, but currently it doesn't help much. -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] of: remove architecture CONFIG_OF definitions
Stephen Rothwell wrote: now that CONFIG_OF is defined globally Signed-off-by: Stephen Rothwell Acked-by: Michal Simek --- arch/microblaze/Kconfig |3 --- arch/powerpc/Kconfig|3 --- arch/sparc/Kconfig |3 --- 3 files changed, 0 insertions(+), 9 deletions(-) diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index 2b37820..1a8f682 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -126,9 +126,6 @@ config CMDLINE_FORCE Set this to have arguments from the default kernel command string override those passed by the boot loader. -config OF - bool - config PROC_DEVICETREE bool "Support for device tree in /proc" depends on PROC_FS diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 3697231..402f4c0 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -174,9 +174,6 @@ config ARCH_MAY_HAVE_PC_FDC config PPC_OF def_bool y -config OF - bool - config PPC_UDBG_16550 bool default n diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index d02e8ac..13a9f2f 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -149,9 +149,6 @@ config GENERIC_GPIO config ARCH_NO_VIRT_TO_BUS def_bool y -config OF - bool - config ARCH_SUPPORTS_DEBUG_PAGEALLOC def_bool y if SPARC64 -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] microblaze: turn CONFIG_OF into a select
Stephen Rothwell wrote: so that we can make CONFIG_OF global and remove it from the architecture Kconfig files later. Signed-off-by: Stephen Rothwell Acked-by: Michal Simek --- arch/microblaze/Kconfig |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index 76818f9..2b37820 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -17,6 +17,8 @@ config MICROBLAZE select HAVE_DMA_ATTRS select HAVE_DMA_API_DEBUG select TRACING_SUPPORT + select OF + select OF_FLATTREE config SWAP def_bool n @@ -125,8 +127,7 @@ config CMDLINE_FORCE override those passed by the boot loader. config OF - def_bool y - select OF_FLATTREE + bool config PROC_DEVICETREE bool "Support for device tree in /proc" -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/26] KVM: PPC: Introduce shared page
Avi Kivity wrote:
> On 06/26/2010 02:24 AM, Alexander Graf wrote:
>> For transparent variable sharing between the hypervisor and guest, I
>> introduce
>> a shared page. This shared page will contain all the registers the
>> guest can
>> read and write safely without exiting guest context.
>>
>> This patch only implements the stubs required for the basic structure
>> of the
>> shared page. The actual register moving follows.
>>
>>
>> @@ -123,8 +123,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto free_vcpu;
>>
>> +vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> +if (!vcpu->arch.shared)
>> +goto uninit_vcpu;
>> +
>> return vcpu;
>>
>> +uninit_vcpu:
>> +kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> out:
>> @@ -135,6 +141,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
>>
>> +free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> }
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index 884d4a5..ba79b35 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -1247,6 +1247,10 @@ struct kvm_vcpu
>> *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
>> if (err)
>> goto free_shadow_vcpu;
>>
>> +vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> +if (!vcpu->arch.shared)
>> +goto uninit_vcpu;
>> +
>> vcpu->arch.host_retip = kvm_return_point;
>> vcpu->arch.host_msr = mfmsr();
>> #ifdef CONFIG_PPC_BOOK3S_64
>> @@ -1277,6 +1281,8 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>>
>> return vcpu;
>>
>> +uninit_vcpu:
>> +kvm_vcpu_uninit(vcpu);
>> free_shadow_vcpu:
>> kfree(vcpu_book3s->shadow_vcpu);
>> free_vcpu:
>> @@ -1289,6 +1295,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
>>
>> +free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kfree(vcpu_book3s->shadow_vcpu);
>> vfree(vcpu_book3s);
>> diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
>> index e8a00b0..71750f2 100644
>> --- a/arch/powerpc/kvm/e500.c
>> +++ b/arch/powerpc/kvm/e500.c
>> @@ -117,8 +117,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto uninit_vcpu;
>>
>> +vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> +if (!vcpu->arch.shared)
>> +goto uninit_tlb;
>> +
>> return vcpu;
>>
>> +uninit_tlb:
>> +kvmppc_e500_tlb_uninit(vcpu_e500);
>> uninit_vcpu:
>> kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> @@ -131,6 +137,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>>
>> +free_page((unsigned long)vcpu->arch.shared);
>> kvmppc_e500_tlb_uninit(vcpu_e500);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
>>
>
> Code repeats 3x. Share please.
Looking at this again, I could combine the 3 lines of init code into 3
lines of code that do a generic function call and then error checking.
And I could convert the one free_page line with one function call that
would free the page. Is there a real gain behind this?
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: disable SPARSE_IRQ by default
The SPARSE_IRQ considerably adds overhead to critical path of IRQ handling. However it doesn't benefit much in space for most systems with limited IRQ_NR. Should be disabled unless really necessary. Signed-off-by: Li Yang --- arch/powerpc/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 328774b..6506bf4 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -400,7 +400,7 @@ config IRQ_ALL_CPUS config SPARSE_IRQ bool "Support sparse irq numbering" - default y + default n help This enables support for sparse irqs. This is useful for distro kernels that want to define a high CONFIG_NR_CPUS value but still @@ -409,7 +409,7 @@ config SPARSE_IRQ ( Sparse IRQs can also be beneficial on NUMA boxes, as they spread out the irq_desc[] array in a more NUMA-friendly way. ) - If you don't know what to do here, say Y. + If you don't know what to do here, say N. config NUMA bool "NUMA support" -- 1.6.6-rc1.GIT ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
>> => bootm 100 >> ## Booting image at 0100 ... >> Image Name: Linux-2.6.33.5 >> Image Type: PowerPC Linux Kernel Image (gzip compressed) >> Data Size: 747319 Bytes = 729.8 kB >> Load Address: 0040 >> Entry Point: 004004d4 > > Load and Entry Point should probably be 0 But the cuImage.adder875-uboot image also has the same load address as mine and the entry point is 0x4004d8. Also cuImage.mpc885ads has the same load address and entry point as cuImage.adder875-uboot. So I don't suspect them. All right. I built a uImage for mpc885ads and the uImage's load address and entry point are both 0. So this is because I'm using cuImage instead of uImage. Thanks Joake, anyway. -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
> From: Shawn Jin > > I'm porting a mpc870 board to the powerpc arch. The base is the > adder-875 board. My first try to boot the cuImage.my870 is > experiencing a machine check. And I have no clue where to look. Any > help? > > => bootm 100 > ## Booting image at 0100 ... >Image Name: Linux-2.6.33.5 >Image Type: PowerPC Linux Kernel Image (gzip compressed) >Data Size:747319 Bytes = 729.8 kB >Load Address: 0040 >Entry Point: 004004d4 Load and Entry Point should probably be 0 Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/26] KVM: PPC: Make RMO a define
On 29.06.2010, at 09:52, Segher Boessenkool wrote: > Also, it seems you construct the physical address by masking out bits from > the effective address. Most implementations will trap or machine check if > you address outside of physical address space, instead. Well the only case where I remember to have hit a real RMO case is on the PS3 - that issues a data/instruction storage interrupt when accessing anything > 8MB in real mode. So I'd argue this is heavily implementation specific. >>> >>> It is. So what is the behaviour you want to implement? >> >> The one below. > > I'm sorry, I lost it. "Below"? Well, the ones a few lines below :). > Apart from that what I'm trying to cover is that on ppc64 accessing 0xc0 in real mode gets you 0x0. Is there a better name for this? >>> >>> (You missed two zeroes). >>> In hypervisor real mode, the top few bits are magic. They are used for e.g. >>> enabling hypervisor offset real mode. >>> In supervisor real mode, those bits are ignored (and all other bits that do >>> not correspond to physical address lines may also be ignored). >> >> So which bits exactly are reserved? I couldn't find a reference to that part. > > If by "reserved" you mean "cannot be used for addressing", it's the top four > bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 document. > Implementations are allowed to ignore more bits than that. > > I believe in earlier versions of the architecture it was the top two bits, > not four, but maybe I misremember. Ah, nice. So that part is implementation specific too. Awesome ;). > >>> Maybe you want to call it physical_address_mask or similar? >> >> PAM - doesn't sound bad :). > > And miraculously nothing in the Power arch uses that acronym yet! But I > would spell it out if I were you, acronyms are confusing. Well, the bad thing about not using acronyms here is that I'll run out of the 80 character limit pretty soon. And that means line wraps and more confusingness when reading the code. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
machine check in kernel for a mpc870 board
I'm porting a mpc870 board to the powerpc arch. The base is the adder-875 board. My first try to boot the cuImage.my870 is experiencing a machine check. And I have no clue where to look. Any help? => bootm 100 ## Booting image at 0100 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:747319 Bytes = 729.8 kB Load Address: 0040 Entry Point: 004004d4 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Bus Fault @ 0x00404c40, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 07d1cb80 Unknown values in msr NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 0001 MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 00404D50 07D1CC70 0004 007FFF0C 0001 0040AAB8 726F6F74 GPR08: 3D2F6465 0059D958 FF0009C0 0059DDDC FF003C00 1014BAC4 07FFF000 0001 GPR16: 007FFF0D 004004D4 0001 007FFF00 07FF9D78 07D5D2A0 GPR24: 007FFEC0 0080 0059D958 004129BC Call backtrace: machine check Thanks alot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/26] KVM: PPC: Make RMO a define
Also, it seems you construct the physical address by masking out bits from the effective address. Most implementations will trap or machine check if you address outside of physical address space, instead. Well the only case where I remember to have hit a real RMO case is on the PS3 - that issues a data/instruction storage interrupt when accessing anything > 8MB in real mode. So I'd argue this is heavily implementation specific. It is. So what is the behaviour you want to implement? The one below. I'm sorry, I lost it. "Below"? Apart from that what I'm trying to cover is that on ppc64 accessing 0xc0 in real mode gets you 0x0. Is there a better name for this? (You missed two zeroes). In hypervisor real mode, the top few bits are magic. They are used for e.g. enabling hypervisor offset real mode. In supervisor real mode, those bits are ignored (and all other bits that do not correspond to physical address lines may also be ignored). So which bits exactly are reserved? I couldn't find a reference to that part. If by "reserved" you mean "cannot be used for addressing", it's the top four bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 document. Implementations are allowed to ignore more bits than that. I believe in earlier versions of the architecture it was the top two bits, not four, but maybe I misremember. Maybe you want to call it physical_address_mask or similar? PAM - doesn't sound bad :). And miraculously nothing in the Power arch uses that acronym yet! But I would spell it out if I were you, acronyms are confusing. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/26] KVM: PPC: Make RMO a define
On 29.06.2010, at 09:32, Segher Boessenkool wrote:
On PowerPC it's very normal to not support all of the physical RAM in real
mode.
>>>
>>> Oh? Are you referring to "real mode limit", or 32-bit implementations with
>>> more than 32 address lines, or something else?
>>
>> The former.
>
> Okay. In that case, the hypervisor can usually access all of physical
> ram directly, unless it limits itself; and a supervisor gets either
> no real mode access, or all ram, or some part -- whatever the hypervisor
> likes.
>
> If you access outside of ram, you will most likely get a machine check.
> Depends on the implementation (like most things here).
>
>>> Either way, RMO is a really bad name for this, since that name is already
>>> used for a similar but different concept.
>>
>> It's the same concept, no? Not all physical memory is accessible from real
>> mode.
>
> I think you're looking for "real mode limit":
>
> The concept is called "offset real mode".
>
> RMO ("real mode offset") is the value that is ORed to an effective address
> to make the physical address (not added, "offset" is a pretty bad name).
> RML ("real mode limit") is the value that has to be bigger than the effective
> address or you will get an exception.
> RMA ("real mode area") is the name for the range of addresses usable in offset
> real mode.
>
>>> Also, it seems you construct the physical address by masking out bits from
>>> the effective address. Most implementations will trap or machine check if
>>> you address outside of physical address space, instead.
>>
>> Well the only case where I remember to have hit a real RMO case is on the
>> PS3 - that issues a data/instruction storage interrupt when accessing
>> anything > 8MB in real mode.
>>
>> So I'd argue this is heavily implementation specific.
>
> It is. So what is the behaviour you want to implement?
The one below.
>
>> Apart from that what I'm trying to cover is that on ppc64 accessing
>> 0xc0 in real mode gets you 0x0. Is there a better name for this?
>
> (You missed two zeroes).
> In hypervisor real mode, the top few bits are magic. They are used for e.g.
> enabling hypervisor offset real mode.
> In supervisor real mode, those bits are ignored (and all other bits that do
> not correspond to physical address lines may also be ignored).
So which bits exactly are reserved? I couldn't find a reference to that part.
> Maybe you want to call it physical_address_mask or similar?
PAM - doesn't sound bad :).
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 24/26] KVM: PPC: PV mtmsrd L=0 and mtmsr
There is also a form of mtmsr where all bits need to be addressed. While the PPC64 Linux kernel behaves resonably well here, the PPC32 one never uses the L=1 form but does mtmsr even for simple things like only changing EE. You make it sound like the 32-bit kernel does something stupid, while there is no other choice. The "L=1" thing only exists for 64-bit. Oh, so that's why :). That doesn't really change the fact that it's very hard to distinguish between a mtmsr that only changes MSR_EE vs one that changes MSR_IR for example :). Hard to predict for the CPU as well, guess why there is a separate instruction now :-P By the way, L=1 _does_ exist for mtmsr; it's just that no 32-bit "classic" implementations support it. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/26] KVM: PPC: Make RMO a define
On PowerPC it's very normal to not support all of the physical
RAM in real mode.
Oh? Are you referring to "real mode limit", or 32-bit
implementations with
more than 32 address lines, or something else?
The former.
Okay. In that case, the hypervisor can usually access all of physical
ram directly, unless it limits itself; and a supervisor gets either
no real mode access, or all ram, or some part -- whatever the hypervisor
likes.
If you access outside of ram, you will most likely get a machine check.
Depends on the implementation (like most things here).
Either way, RMO is a really bad name for this, since that name is
already
used for a similar but different concept.
It's the same concept, no? Not all physical memory is accessible
from real mode.
I think you're looking for "real mode limit":
The concept is called "offset real mode".
RMO ("real mode offset") is the value that is ORed to an effective
address
to make the physical address (not added, "offset" is a pretty bad name).
RML ("real mode limit") is the value that has to be bigger than the
effective
address or you will get an exception.
RMA ("real mode area") is the name for the range of addresses usable
in offset
real mode.
Also, it seems you construct the physical address by masking out
bits from
the effective address. Most implementations will trap or machine
check if
you address outside of physical address space, instead.
Well the only case where I remember to have hit a real RMO case is
on the PS3 - that issues a data/instruction storage interrupt when
accessing anything > 8MB in real mode.
So I'd argue this is heavily implementation specific.
It is. So what is the behaviour you want to implement?
Apart from that what I'm trying to cover is that on ppc64 accessing
0xc0 in real mode gets you 0x0. Is there a better name
for this?
(You missed two zeroes).
In hypervisor real mode, the top few bits are magic. They are used
for e.g.
enabling hypervisor offset real mode.
In supervisor real mode, those bits are ignored (and all other bits
that do
not correspond to physical address lines may also be ignored).
Maybe you want to call it physical_address_mask or similar?
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix feature-fixup tests for gcc 4.5
The feature-fixup test declare some extern void variables and then take
their addresses. Fix this by declaring them as extern u8 instead.
Fixes these warnings (treated as errors):
CC arch/powerpc/lib/feature-fixups.o
cc1: warnings being treated as errors
arch/powerpc/lib/feature-fixups.c: In function 'test_cpu_macros':
arch/powerpc/lib/feature-fixups.c:293:23: error: taking address of expression
of type 'void'
arch/powerpc/lib/feature-fixups.c:294:9: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:297:2: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:297:2: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c: In function 'test_fw_macros':
arch/powerpc/lib/feature-fixups.c:306:23: error: taking address of expression
of type 'void'
arch/powerpc/lib/feature-fixups.c:307:9: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:310:2: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:310:2: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c: In function 'test_lwsync_macros':
arch/powerpc/lib/feature-fixups.c:321:23: error: taking address of expression
of type 'void'
arch/powerpc/lib/feature-fixups.c:322:9: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:326:3: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:326:3: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:329:3: error: taking address of expression of
type 'void'
arch/powerpc/lib/feature-fixups.c:329:3: error: taking address of expression of
type 'void'
Signed-off-by: Stephen Rothwell
---
arch/powerpc/lib/feature-fixups.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
I haven't actually booted this, just built it.
diff --git a/arch/powerpc/lib/feature-fixups.c
b/arch/powerpc/lib/feature-fixups.c
index e640175..0d08d01 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -12,6 +12,7 @@
* 2 of the License, or (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -288,8 +289,8 @@ static void test_alternative_case_with_external_branch(void)
static void test_cpu_macros(void)
{
- extern void ftr_fixup_test_FTR_macros;
- extern void ftr_fixup_test_FTR_macros_expected;
+ extern u8 ftr_fixup_test_FTR_macros;
+ extern u8 ftr_fixup_test_FTR_macros_expected;
unsigned long size = &ftr_fixup_test_FTR_macros_expected -
&ftr_fixup_test_FTR_macros;
@@ -301,8 +302,8 @@ static void test_cpu_macros(void)
static void test_fw_macros(void)
{
#ifdef CONFIG_PPC64
- extern void ftr_fixup_test_FW_FTR_macros;
- extern void ftr_fixup_test_FW_FTR_macros_expected;
+ extern u8 ftr_fixup_test_FW_FTR_macros;
+ extern u8 ftr_fixup_test_FW_FTR_macros_expected;
unsigned long size = &ftr_fixup_test_FW_FTR_macros_expected -
&ftr_fixup_test_FW_FTR_macros;
@@ -314,10 +315,10 @@ static void test_fw_macros(void)
static void test_lwsync_macros(void)
{
- extern void lwsync_fixup_test;
- extern void end_lwsync_fixup_test;
- extern void lwsync_fixup_test_expected_LWSYNC;
- extern void lwsync_fixup_test_expected_SYNC;
+ extern u8 lwsync_fixup_test;
+ extern u8 end_lwsync_fixup_test;
+ extern u8 lwsync_fixup_test_expected_LWSYNC;
+ extern u8 lwsync_fixup_test_expected_SYNC;
unsigned long size = &end_lwsync_fixup_test -
&lwsync_fixup_test;
--
1.7.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
