Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus
On Fri, May 02, 2008 at 02:29:12PM +1000, Paul Mackerras wrote: This fixes a regression reported by Kamalesh Bulabel where a POWER4 machine would crash because of an SLB miss at a point where the SLB miss exception was unrecoverable. This regression is tracked at: http://bugzilla.kernel.org/show_bug.cgi?id=10082 SLB misses at such points shouldn't happen because the kernel stack is the only memory accessed other than things in the first segment of the linear mapping (which is mapped at all times by entry 0 of the SLB). The context switch code ensures that SLB entry 2 covers the kernel stack, if it is not already covered by entry 0. None of entries 0 to 2 are ever replaced by the SLB miss handler. Where this went wrong is that the context switch code assumes it doesn't have to write to SLB entry 2 if the new kernel stack is in the same segment as the old kernel stack, since entry 2 should already be correct. However, when we start up a secondary cpu, it calls slb_initialize, which doesn't set up entry 2. This is correct for the boot cpu, where we will be using a stack in the kernel BSS at this point (i.e. init_thread_union), but not necessarily for secondary cpus, whose initial stack can be allocated anywhere. This doesn't cause any immediate problem since the SLB miss handler will just create an SLB entry somewhere else to cover the initial stack. In fact it's possible for the cpu to go quite a long time without SLB entry 2 being valid. Eventually, though, the entry created by the SLB miss handler will get overwritten by some other entry, and if the next access to the stack is at an unrecoverable point, we get the crash. This fixes the problem by making slb_initialize create a suitable entry for the kernel stack, if we are on a secondary cpu and the stack isn't covered by SLB entry 0. This requires initializing the get_paca()-kstack field earlier, so I do that in smp_create_idle where the current field is initialized. This also abstracts a bit of the computation that mk_esid_data in slb.c does so that it can be used in slb_initialize. Signed-off-by: Paul Mackerras [EMAIL PROTECTED] --- Michael Ellerman pointed out that I should be comparing raw_smp_processor_id() with boot_cpuid rather than with 0. Do you even need the processor ID test at all? The boot processor should always have its stack covered by SLB entry 0 when we come through here, shouldn't it? -- 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@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git master branch
Paul, Any plans to start applying some patches to powerpc-next (for .27)? For example, your NAP patch? the devres_ioremap_prot patch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc ptrace block-step
I didn't test the booke variant of this (I don't have that hardware).
I only tested it on a Mac G5 (ppc64, 970FX).
There is a test program at:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/block-step.c?cvsroot=systemtap
To build that program for powerpc, remove the 0 from this line:
# elif defined __powerpc__ 0/* XXX not upstream yet */
and compile with -D_GNU_SOURCE.
Thanks,
Roland
---
[PATCH] powerpc ptrace block-step
This adds block-step support on powerpc,
including a PTRACE_SINGLEBLOCK request for ptrace.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/ptrace.c | 19 ++-
include/asm-powerpc/ptrace.h |4
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 2a9fe97..91ee077 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -619,12 +619,29 @@ void user_enable_single_step(struct task_struct *task)
task-thread.dbcr0 = DBCR0_IDM | DBCR0_IC;
regs-msr |= MSR_DE;
#else
+ regs-msr = ~MSR_BE;
regs-msr |= MSR_SE;
#endif
}
set_tsk_thread_flag(task, TIF_SINGLESTEP);
}
+void user_enable_block_step(struct task_struct *task)
+{
+ struct pt_regs *regs = task-thread.regs;
+
+ if (regs != NULL) {
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ task-thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
+ regs-msr |= MSR_DE;
+#else
+ regs-msr = ~MSR_SE;
+ regs-msr |= MSR_BE;
+#endif
+ }
+ set_tsk_thread_flag(task, TIF_SINGLESTEP);
+}
+
void user_disable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task-thread.regs;
@@ -634,7 +651,7 @@ void user_disable_single_step(struct task_struct *task)
task-thread.dbcr0 = 0;
regs-msr = ~MSR_DE;
#else
- regs-msr = ~MSR_SE;
+ regs-msr = ~(MSR_SE | MSR_BE);
#endif
}
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
diff --git a/include/asm-powerpc/ptrace.h b/include/asm-powerpc/ptrace.h
index 39023dd..6a3892d 100644
--- a/include/asm-powerpc/ptrace.h
+++ b/include/asm-powerpc/ptrace.h
@@ -135,7 +135,9 @@ do {
\
* These are defined as per linux/ptrace.h, which see.
*/
#define arch_has_single_step() (1)
+#define arch_has_block_step() (1)
extern void user_enable_single_step(struct task_struct *);
+extern void user_enable_block_step(struct task_struct *);
extern void user_disable_single_step(struct task_struct *);
#endif /* __ASSEMBLY__ */
@@ -276,4 +278,6 @@ extern void user_disable_single_step(struct task_struct *);
#define PPC_PTRACE_PEEKUSR_3264 0x91
#define PPC_PTRACE_POKEUSR_3264 0x90
+#define PTRACE_SINGLEBLOCK 0x100 /* resume execution until next branch */
+
#endif /* _ASM_POWERPC_PTRACE_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. To workaround this issue, we just stole the save/restore code from gcc and simplified it down for our needs (integer only). Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/boot/Makefile|2 +- arch/powerpc/boot/crtsavres.S | 125 + 2 files changed, 126 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/boot/crtsavres.S diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 7822d25..77645a3 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -51,7 +51,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.o main.o): \ $(addprefix $(obj)/,$(zliblinuxheader)) $(addprefix $(obj)/,$(zlibheader)) src-libfdt := fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c -src-wlib := string.S crt0.S stdio.c main.c \ +src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \ $(addprefix libfdt/,$(src-libfdt)) libfdt-wrapper.c \ ns16550.c serial.c simple_alloc.c div64.S util.S \ gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \ diff --git a/arch/powerpc/boot/crtsavres.S b/arch/powerpc/boot/crtsavres.S new file mode 100644 index 000..614f3c4 --- /dev/null +++ b/arch/powerpc/boot/crtsavres.S @@ -0,0 +1,125 @@ +/* + * Special support for eabi and SVR4 + * + * Copyright (C) 1995, 1996, 1998, 2000, 2001 Free Software Foundation, Inc. + * Written By Michael Meissner + * 64-bit support written by David Edelsohn + * + * 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 + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * In addition to the permissions in the GNU General Public License, the + * Free Software Foundation gives you unlimited permission to link the + * compiled version of this file with other programs, and to distribute + * those programs without any restriction coming from the use of this + * file. (The General Public License restrictions do apply in other + * respects; for example, they cover modification of the file, and + * distribution when not linked into another program.) + * + * This file 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; see the file COPYING. If not, write to + * the Free Software Foundation, 51 Franklin Street, Fifth Floor, + * Boston, MA 02110-1301, USA. + * + *As a special exception, if you link this library with files + *compiled with GCC to produce an executable, this does not cause + *the resulting executable to be covered by the GNU General Public License. + *This exception does not however invalidate any other reasons why + *the executable file might be covered by the GNU General Public License. + */ + +/* Do any initializations needed for the eabi environment */ + + .file crtsavres.S + .section .text + +/* On PowerPC64 Linux, these functions are provided by the linker. */ +#ifndef __powerpc64__ + +#define FUNC_START(name) \ + .type name,@function; \ + .globl name; \ +name: + +/* 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. */ + +FUNC_START(_savegpr_14)stw 14,-72(11) /* save gp registers */ +FUNC_START(_savegpr_15)stw 15,-68(11) +FUNC_START(_savegpr_16)stw 16,-64(11) +FUNC_START(_savegpr_17)stw 17,-60(11) +FUNC_START(_savegpr_18)stw 18,-56(11) +FUNC_START(_savegpr_19)stw 19,-52(11) +FUNC_START(_savegpr_20)stw 20,-48(11) +FUNC_START(_savegpr_21)stw 21,-44(11) +FUNC_START(_savegpr_22)stw 22,-40(11) +FUNC_START(_savegpr_23)stw 23,-36(11) +FUNC_START(_savegpr_24)stw 24,-32(11) +FUNC_START(_savegpr_25)stw 25,-28(11) +FUNC_START(_savegpr_26)stw 26,-24(11) +FUNC_START(_savegpr_27)stw 27,-20(11) +FUNC_START(_savegpr_28)stw 28,-16(11) +FUNC_START(_savegpr_29)stw 29,-12(11) +FUNC_START(_savegpr_30)stw 30,-8(11) +FUNC_START(_savegpr_31)stw 31,-4(11) + blr + +/* Routines for restoring integer registers, called by the compiler. */ +/* Called with r11 pointing to the stack
Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus
David Gibson writes: Do you even need the processor ID test at all? The boot processor should always have its stack covered by SLB entry 0 when we come through here, shouldn't it? I was concerned that get_paca()-kstack wouldn't have been initialized by the time the boot cpu calls slb_initialize(). If that fear is unfounded then the check could go. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. To workaround this issue, we just stole the save/restore code from gcc and simplified it down for our needs (integer only). Why can't we link with libgcc, instead? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. We don't link with libgcc anywhere in the kernel. Is this going to have similar impacts for building the vmlinux itself? What are they actually error messages you see with that version of GCC, out of curiosity? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On May 2, 2008, at 6:54 AM, Segher Boessenkool wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. To workaround this issue, we just stole the save/restore code from gcc and simplified it down for our needs (integer only). Why can't we link with libgcc, instead? we possibly could, the problem is knowing the path of libgcc to link with. This seemed easier to me than the makefile headaches to ensure that we get that right. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On May 2, 2008, at 7:13 AM, Josh Boyer wrote: On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. We don't link with libgcc anywhere in the kernel. Is this going to have similar impacts for building the vmlinux itself? Not by default. The issue only shows up with -Os. Not sure if we can build the kernel that way. What are they actually error messages you see with that version of GCC, out of curiosity? CC fs/qnx4/qnx4.mod.o arch/powerpc/boot/cuboot-85xx.o: In function `setprop': /home/galak/git/linux-2.6/arch/powerpc/boot/ops.h:114: undefined reference to `_restgpr_30_x' arch/powerpc/boot/cuboot-85xx.o: In function `platform_init': /home/galak/git/linux-2.6/arch/powerpc/boot/cuboot-85xx.c:60: undefined reference to `_restgpr_25_x' arch/powerpc/boot/cuboot-85xx.o: In function `find_node_by_devtype': /home/galak/git/linux-2.6/arch/powerpc/boot/ops.h:163: undefined reference to `_restgpr_29_x' arch/powerpc/boot/cuboot-85xx.o: In function `platform_fixups': /home/galak/git/linux-2.6/arch/powerpc/boot/cuboot-85xx.c:51: undefined reference to `_restgpr_25_x' CC fs/sysv/sysv.mod.o arch/powerpc/boot/wrapper.a(main.o): In function `setprop': /home/galak/git/linux-2.6/arch/powerpc/boot/ops.h:114: undefined reference to `_restgpr_30_x' arch/powerpc/boot/wrapper.a(main.o): In function `start': /home/galak/git/linux-2.6/arch/powerpc/boot/main.c:207: undefined reference to `_restgpr_24_x' arch/powerpc/boot/wrapper.a(libfdt-wrapper.o): In function `fdt_init': /home/galak/git/linux-2.6/arch/powerpc/boot/libfdt-wrapper.c:193: undefined reference to `_restgpr_30_x' ... /home/galak/git/linux-2.6/arch/powerpc/boot/libfdt/fdt_wip.c:132: undefined reference to `_restgpr_26_x' arch/powerpc/boot/wrapper.a(fdt_wip.o): In function `fdt_nop_node': /home/galak/git/linux-2.6/arch/powerpc/boot/libfdt/fdt_wip.c:144: undefined reference to `_restgpr_28_x' arch/powerpc/boot/wrapper.a(fdt_wip.o): In function `fdt_setprop_inplace': /home/galak/git/linux-2.6/arch/powerpc/boot/libfdt/fdt_wip.c:73: undefined reference to `_restgpr_29_x' make[1]: *** [arch/powerpc/boot/cuImage.mpc8560ads] Error 1 CC lib/libcrc32c.mod.o CC net/key/af_key.mod.o - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git master branch
On Thu, May 1, 2008 at 11:56 PM, Paul Mackerras [EMAIL PROTECTED] wrote: Linus, Please do: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master Hmmm; none of these commits appear in your public git server ATM. Top of tree is still [POWERPC] Fix crashkernel= handling when no crashkernel from 2 days ago. http://git.kernel.org/?p=linux/kernel/git/paulus/powerpc.git;a=summary Cheers, g. With the exception of one commit from Grant Likely, these are all fixes for various bugs and compile problems, or documentation updates. The one from Grant is something that has been around for a month or so and only affects MPC5200-based embedded platforms. Thanks, Paul. .../powerpc/mpc52xx-device-tree-bindings.txt | 11 ++ arch/powerpc/boot/dts/mpc8610_hpcd.dts | 23 +++ arch/powerpc/configs/ps3_defconfig | 132 +--- arch/powerpc/kernel/smp.c |2 arch/powerpc/mm/slb.c | 27 ++-- arch/powerpc/platforms/ps3/interrupt.c |6 - arch/powerpc/sysdev/fsl_rio.c |9 + arch/powerpc/sysdev/fsl_soc.c |4 - arch/powerpc/sysdev/xilinx_intc.c |2 drivers/char/xilinx_hwicap/xilinx_hwicap.c |6 - drivers/net/fec_mpc52xx.c | 97 +++ drivers/net/fec_mpc52xx.h | 19 --- drivers/ps3/ps3-lpm.c |1 drivers/ps3/ps3-sys-manager.c |7 - drivers/serial/mpc52xx_uart.c |2 include/asm-powerpc/ps3.h |3 include/linux/rio.h|2 17 files changed, 231 insertions(+), 122 deletions(-) Andrew Liu (1): Fix a potential issue in mpc52xx uart driver Anton Vorontsov (1): [POWERPC] 86xx: mpc8610_hpcd: add support for PCI Express x8 slot Becky Bruce (1): [POWERPC] Squash build warning for print of resource_size_t in fsl_soc.c FUJITA Tomonori (1): [POWERPC] PS3: Add time include to lpm Geert Uytterhoeven (1): [POWERPC] PS3: Make ps3_virq_setup and ps3_virq_destroy static Geoff Levand (3): [POWERPC] Fix slb.c compile warnings [POWERPC] PS3: Remove unsupported wakeup sources [POWERPC] PS3: Update ps3_defconfig Grant Likely (1): [POWERPC] mpc5200: Allow for fixed speed MII configurations Jason Jin (1): [POWERPC] 86xx: Fix the wrong serial1 interrupt for 8610 board Kumar Gala (1): [POWERPC] Xilinx: Fix compile warnings Paul Mackerras (1): [POWERPC] Bolt in SLB entry for kernel stack on secondary cpus Randy Dunlap (1): [RAPIDIO] fix current kernel-doc notation ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
Why can't we link with libgcc, instead? we possibly could, the problem is knowing the path of libgcc to link with. gcc -print-libgcc-file-name This seemed easier to me than the makefile headaches to ensure that we get that right. Ah come on, make syntax is fun! Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On May 2, 2008, at 8:37 AM, Segher Boessenkool wrote: Why can't we link with libgcc, instead? we possibly could, the problem is knowing the path of libgcc to link with. gcc -print-libgcc-file-name It wasn't clear if we used a multilib toolchain if we always get the proper libgcc since we are building bootwrappers for all kinda of variants. (e500, 40x, 6xx, etc.). My patch seemed the least painful solution to me. I assume there is a reason we don't link libgcc w/the kernel. This seemed easier to me than the makefile headaches to ensure that we get that right. Ah come on, make syntax is fun! Yes, yes it is ;) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/5] PS3: Update ps3_defconfig
Hi Geoff, what about adding these defaults: - CONFIG_SCHED_SMT - CONFIG_HUGETLBFS (needed by ibm cell sdk) not sure about: - CONFIG_SPU_FS_64K_LS Greetings Marvin On Thursday 01 May 2008 00:25:36 Geoff Levand wrote: Update ps3_defconfig. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- arch/powerpc/configs/ps3_defconfig | 132 +++-- 1 file changed, 84 insertions(+), 48 deletions(-) --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.25-rc6 -# Thu Mar 20 11:07:04 2008 +# Linux kernel version: 2.6.25 +# Mon Apr 28 12:39:10 2008 # CONFIG_PPC64=y [...] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On Fri, 2 May 2008 08:32:12 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On May 2, 2008, at 7:13 AM, Josh Boyer wrote: On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. We don't link with libgcc anywhere in the kernel. Is this going to have similar impacts for building the vmlinux itself? Not by default. The issue only shows up with -Os. Not sure if we can build the kernel that way. We can. See CONFIG_CC_OPTIMIZE_FOR_SIZE. That's set in at least pseries_defconfig and ps3_defconfig. It's also something I've been thinking about trying with 4xx. Seems we need a bit more than just the bootwrapper. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On May 2, 2008, at 8:53 AM, Josh Boyer wrote: On Fri, 2 May 2008 08:32:12 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On May 2, 2008, at 7:13 AM, Josh Boyer wrote: On Fri, 2008-05-02 at 03:11 -0500, Kumar Gala wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. We don't link with libgcc anywhere in the kernel. Is this going to have similar impacts for building the vmlinux itself? Not by default. The issue only shows up with -Os. Not sure if we can build the kernel that way. We can. See CONFIG_CC_OPTIMIZE_FOR_SIZE. That's set in at least pseries_defconfig and ps3_defconfig. It's also something I've been thinking about trying with 4xx. Seems we need a bit more than just the bootwrapper. building w/this enabled and will produce a patch for the kernel if needed. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
On 2/19/08, Jean Delvare [EMAIL PROTECTED] wrote:
i2c-irq = platform_get_irq(pdev, 0);
- if (i2c-irq 0) {
+ if (i2c-irq NO_IRQ) {
I am skeptical about this one. Can platform_get_irq() really return
NO_IRQ? I thought that the IRQ resource would be plain missing if the
device has no IRQ, so I would expect:
i2c-irq = platform_get_irq(pdev, 0);
if (i2c-irq 0)
i2c-irq = NO_IRQ; /* Use polling */
Testing against NO_IRQ suggests that devices with no IRQ would still
have an IRQ resource defined and explicitly set to NO_IRQ. Sounds weird
to me. Can you please clarify this point?
Your fix is correct. I'm not sure polling worked in the original driver.
For what it's worth, no other kernel driver checks for irq NO_IRQ.
They all check for irq 0 after calling platform_get_irq().
result = -ENXIO;
goto fail_get_irq;
}
@@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
goto fail_map;
}
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
if ((result = request_irq(i2c-irq, mpc_i2c_isr,
IRQF_SHARED, i2c-mpc, i2c)) 0)
{
printk(KERN_ERR
@@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return result;
fail_add:
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
fail_irq:
iounmap(i2c-base);
@@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(i2c-adap);
platform_set_drvdata(pdev, NULL);
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
iounmap(i2c-base);
The rest looks good.
--
Jean Delvare
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the kernel build as we'd have to link with libgcc to get the implementation of the register save/restores. To workaround this issue, we just stole the save/restore code from gcc and simplified it down for our needs (integer only). We only do this if PPC32 as gcc makes believe the linker on ppc64 will deal with this and only if CONFIG_CC_OPTIMIZE_FOR_SIZE is set (thus -Os). Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- If someone using cutting edge toolchains for ppc64 could test and make sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that would be nice. - k arch/powerpc/kernel/misc_32.S | 77 +++ arch/powerpc/kernel/ppc_ksyms.c | 111 +++ 2 files changed, 188 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index 896..651eac0 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -974,3 +974,80 @@ relocate_new_kernel_end: relocate_new_kernel_size: .long relocate_new_kernel_end - relocate_new_kernel #endif + +#if defined(CONFIG_PPC32) defined(CONFIG_CC_OPTIMIZE_FOR_SIZE) +/* 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. */ + +_GLOBAL(_savegpr_14) stw 14,-72(11) /* save gp registers */ +_GLOBAL(_savegpr_15) stw 15,-68(11) +_GLOBAL(_savegpr_16) stw 16,-64(11) +_GLOBAL(_savegpr_17) stw 17,-60(11) +_GLOBAL(_savegpr_18) stw 18,-56(11) +_GLOBAL(_savegpr_19) stw 19,-52(11) +_GLOBAL(_savegpr_20) stw 20,-48(11) +_GLOBAL(_savegpr_21) stw 21,-44(11) +_GLOBAL(_savegpr_22) stw 22,-40(11) +_GLOBAL(_savegpr_23) stw 23,-36(11) +_GLOBAL(_savegpr_24) stw 24,-32(11) +_GLOBAL(_savegpr_25) stw 25,-28(11) +_GLOBAL(_savegpr_26) stw 26,-24(11) +_GLOBAL(_savegpr_27) stw 27,-20(11) +_GLOBAL(_savegpr_28) stw 28,-16(11) +_GLOBAL(_savegpr_29) stw 29,-12(11) +_GLOBAL(_savegpr_30) stw 30,-8(11) +_GLOBAL(_savegpr_31) stw 31,-4(11) + blr + +/* Routines for restoring 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 restore area. */ + +_GLOBAL(_restgpr_14) lwz 14,-72(11) /* restore gp registers */ +_GLOBAL(_restgpr_15) lwz 15,-68(11) +_GLOBAL(_restgpr_16) lwz 16,-64(11) +_GLOBAL(_restgpr_17) lwz 17,-60(11) +_GLOBAL(_restgpr_18) lwz 18,-56(11) +_GLOBAL(_restgpr_19) lwz 19,-52(11) +_GLOBAL(_restgpr_20) lwz 20,-48(11) +_GLOBAL(_restgpr_21) lwz 21,-44(11) +_GLOBAL(_restgpr_22) lwz 22,-40(11) +_GLOBAL(_restgpr_23) lwz 23,-36(11) +_GLOBAL(_restgpr_24) lwz 24,-32(11) +_GLOBAL(_restgpr_25) lwz 25,-28(11) +_GLOBAL(_restgpr_26) lwz 26,-24(11) +_GLOBAL(_restgpr_27) lwz 27,-20(11) +_GLOBAL(_restgpr_28) lwz 28,-16(11) +_GLOBAL(_restgpr_29) lwz 29,-12(11) +_GLOBAL(_restgpr_30) lwz 30,-8(11) +_GLOBAL(_restgpr_31) lwz 31,-4(11) + blr + +/* Routines for restoring 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 restore area. */ + +_GLOBAL(_restgpr_14_x) lwz 14,-72(11) /* restore gp registers */ +_GLOBAL(_restgpr_15_x) lwz 15,-68(11) +_GLOBAL(_restgpr_16_x) lwz 16,-64(11) +_GLOBAL(_restgpr_17_x) lwz 17,-60(11) +_GLOBAL(_restgpr_18_x) lwz 18,-56(11) +_GLOBAL(_restgpr_19_x) lwz 19,-52(11) +_GLOBAL(_restgpr_20_x) lwz 20,-48(11) +_GLOBAL(_restgpr_21_x) lwz 21,-44(11) +_GLOBAL(_restgpr_22_x) lwz 22,-40(11) +_GLOBAL(_restgpr_23_x) lwz 23,-36(11) +_GLOBAL(_restgpr_24_x) lwz 24,-32(11) +_GLOBAL(_restgpr_25_x) lwz 25,-28(11) +_GLOBAL(_restgpr_26_x) lwz 26,-24(11) +_GLOBAL(_restgpr_27_x) lwz 27,-20(11) +_GLOBAL(_restgpr_28_x) lwz 28,-16(11) +_GLOBAL(_restgpr_29_x) lwz 29,-12(11) +_GLOBAL(_restgpr_30_x) lwz 30,-8(11) +_GLOBAL(_restgpr_31_x) lwz 0,4(11) + lwz 31,-4(11) + mtlr0 + mr 1,11 + blr +#endif diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c index cf6b5a7..a165ef0 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -185,3 +185,114 @@ EXPORT_SYMBOL(__mtdcr); EXPORT_SYMBOL(__mfdcr); #endif EXPORT_SYMBOL(empty_zero_page); + +#if defined(CONFIG_PPC32) defined(CONFIG_CC_OPTIMIZE_FOR_SIZE) +void _savegpr_14(void);
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On May 2, 2008, at 6:54 AM, Segher Boessenkool wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the bootwrapper as we'd need to link with libgcc to get the implementation of the register save/restores. To workaround this issue, we just stole the save/restore code from gcc and simplified it down for our needs (integer only). Why can't we link with libgcc, instead? Do you have or can you generate a ppc64 toolchain with this patch in it? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
Hi Jon,
On Fri, 2 May 2008 10:23:01 -0400, Jon Smirl wrote:
On 2/19/08, Jean Delvare [EMAIL PROTECTED] wrote:
i2c-irq = platform_get_irq(pdev, 0);
- if (i2c-irq 0) {
+ if (i2c-irq NO_IRQ) {
I am skeptical about this one. Can platform_get_irq() really return
NO_IRQ? I thought that the IRQ resource would be plain missing if the
device has no IRQ, so I would expect:
i2c-irq = platform_get_irq(pdev, 0);
if (i2c-irq 0)
i2c-irq = NO_IRQ; /* Use polling */
Testing against NO_IRQ suggests that devices with no IRQ would still
have an IRQ resource defined and explicitly set to NO_IRQ. Sounds weird
to me. Can you please clarify this point?
Your fix is correct. I'm not sure polling worked in the original driver.
OK, can you send an updated patch then?
Thanks.
For what it's worth, no other kernel driver checks for irq NO_IRQ.
They all check for irq 0 after calling platform_get_irq().
result = -ENXIO;
goto fail_get_irq;
}
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
On Fri, May 02, 2008 at 09:21:08AM -0500, Kumar Gala wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the kernel build as we'd have to link with libgcc to get the implementation of the register save/restores. brokenrecord Why don't we just link with libgcc? /brokenrecord -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git master branch
On Fri, 2 May 2008, Paul Mackerras wrote: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master Already up-to-date. Forgot to push? Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On Fri, May 02, 2008 at 08:41:27AM -0500, Kumar Gala wrote: I assume there is a reason we don't link libgcc w/the kernel. Inertia? BTW, it looks like ARM, SuperH, PA-Risc, and a few others do link in libgcc. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
On May 2, 2008, at 10:07 AM, Scott Wood wrote: On Fri, May 02, 2008 at 09:21:08AM -0500, Kumar Gala wrote: GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the kernel build as we'd have to link with libgcc to get the implementation of the register save/restores. brokenrecord Why don't we just link with libgcc? /brokenrecord Its something of a PITA to do that in the kernel at this point since we've duplicated libgcc functionality in it. I'm sure there are some historical reasons this wasn't done to start with. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
New version with your fix.
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index bbe787b..b141057 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned
timeout, int writing)
u32 x;
int result = 0;
- if (i2c-irq == 0)
+ if (i2c-irq == NO_IRQ)
{
while (!(readb(i2c-base + MPC_I2C_SR) CSR_MIF)) {
schedule();
@@ -329,10 +329,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return -ENOMEM;
i2c-irq = platform_get_irq(pdev, 0);
- if (i2c-irq 0) {
- result = -ENXIO;
- goto fail_get_irq;
- }
+ if (i2c-irq 0)
+ i2c-irq = NO_IRQ; /* Use polling */
+
i2c-flags = pdata-device_flags;
init_waitqueue_head(i2c-queue);
@@ -344,7 +343,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
goto fail_map;
}
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
if ((result = request_irq(i2c-irq, mpc_i2c_isr,
IRQF_SHARED, i2c-mpc, i2c)) 0) {
printk(KERN_ERR
@@ -367,7 +366,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return result;
fail_add:
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
fail_irq:
iounmap(i2c-base);
@@ -384,7 +383,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(i2c-adap);
platform_set_drvdata(pdev, NULL);
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
iounmap(i2c-base);
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
Hi Jon,
On Fri, 2 May 2008 12:02:27 -0400, Jon Smirl wrote:
New version with your fix.
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index bbe787b..b141057 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned
timeout, int writing)
Long lines folded, patch doesn't apply...
u32 x;
int result = 0;
- if (i2c-irq == 0)
+ if (i2c-irq == NO_IRQ)
{
while (!(readb(i2c-base + MPC_I2C_SR) CSR_MIF)) {
schedule();
@@ -329,10 +329,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return -ENOMEM;
i2c-irq = platform_get_irq(pdev, 0);
- if (i2c-irq 0) {
- result = -ENXIO;
- goto fail_get_irq;
- }
+ if (i2c-irq 0)
+ i2c-irq = NO_IRQ; /* Use polling */
+
After this change, label fail_get_irq is unused so you should remove
it. gcc should have told you, didn't it?
i2c-flags = pdata-device_flags;
init_waitqueue_head(i2c-queue);
@@ -344,7 +343,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
goto fail_map;
}
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
if ((result = request_irq(i2c-irq, mpc_i2c_isr,
IRQF_SHARED, i2c-mpc, i2c)) 0) {
printk(KERN_ERR
@@ -367,7 +366,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return result;
fail_add:
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
fail_irq:
iounmap(i2c-base);
@@ -384,7 +383,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(i2c-adap);
platform_set_drvdata(pdev, NULL);
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
iounmap(i2c-base);
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
Why can't we link with libgcc, instead? Do you have or can you generate a ppc64 toolchain with this patch in it? I'm not sure what you mean. I build GCC TOT toolchains sort-of daily, and build the kernel with it (all architectures). I don't build any 4xx config though, maybe I should. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [2.6 patch] char/xilinx_hwicap/ section fix
Acked-by: Stephen Neuendorffer [EMAIL PROTECTED]
Grant, please pick this up.
Steve
-Original Message-
From: Adrian Bunk [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 2:52 AM
To: Stephen Neuendorffer; Grant Likely; [EMAIL PROTECTED]
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: [2.6 patch] char/xilinx_hwicap/ section fix
This patch fixes the following build error:
-- snip --
...
CC [M] drivers/char/xilinx_hwicap/xilinx_hwicap.o
...
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/xilinx_hwicap/xil
inx_hwicap.c:806: error:
hwicap_of_match causes a section type conflict
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/xilinx_hwicap/xil
inx_hwicap.c:806: error:
hwicap_of_match causes a section type conflict
make[4]: *** [drivers/char/xilinx_hwicap/xilinx_hwicap.o] Error 1
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
2f0f31d8aa696ca6cc45ab865ec8c68b90cd0e46 diff --git
a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 016f905..dfe6907 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -803,7 +803,7 @@ static int __devexit hwicap_of_remove(struct
of_device *op)
}
/* Match table for of_platform binding */
-static const struct of_device_id __devinit hwicap_of_match[] = {
+static const struct of_device_id __devinitconst hwicap_of_match[] = {
{ .compatible = xlnx,opb-hwicap-1.00.b, .data =
buffer_icap_config},
{ .compatible = xlnx,xps-hwicap-1.00.a, .data =
fifo_icap_config},
{},
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
gcc -print-libgcc-file-name It wasn't clear if we used a multilib toolchain if we always get the proper libgcc since we are building bootwrappers for all kinda of variants. (e500, 40x, 6xx, etc.). gcc -mthe-options-to-select-some-target -print-libgcc-file-name My patch seemed the least painful solution to me. In the short term, perhaps ;-) I assume there is a reason we don't link libgcc w/the kernel. It's historical, even _if_ there was a valid reason once (and I'm not so sure about that), who knows if there still is. Besides, this is not the kernel, this is the bootwrapper, I strongly doubt libgcc would cause any conflicts here. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
I attached the diff file. I had forgot that I renamed the file so it
wasn't getting compiled. I compiled it this time. I've made too many
other changes to it to test this version on my current hardware.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index bbe787b..d73edef 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
u32 x;
int result = 0;
- if (i2c-irq == 0)
+ if (i2c-irq == NO_IRQ)
{
while (!(readb(i2c-base + MPC_I2C_SR) CSR_MIF)) {
schedule();
@@ -329,10 +329,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return -ENOMEM;
i2c-irq = platform_get_irq(pdev, 0);
- if (i2c-irq 0) {
- result = -ENXIO;
- goto fail_get_irq;
- }
+ if (i2c-irq 0)
+ i2c-irq = NO_IRQ; /* Use polling */
+
i2c-flags = pdata-device_flags;
init_waitqueue_head(i2c-queue);
@@ -344,7 +343,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
goto fail_map;
}
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
if ((result = request_irq(i2c-irq, mpc_i2c_isr,
IRQF_SHARED, i2c-mpc, i2c)) 0) {
printk(KERN_ERR
@@ -367,12 +366,11 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return result;
fail_add:
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
fail_irq:
iounmap(i2c-base);
fail_map:
- fail_get_irq:
kfree(i2c);
return result;
};
@@ -384,7 +382,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(i2c-adap);
platform_set_drvdata(pdev, NULL);
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
iounmap(i2c-base);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
If someone using cutting edge toolchains for ppc64 could test and make sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that would be nice. Current linus tree + some more stuff + this patch, ppc64_defconfig, powerpc64-linux-gcc (GCC) 4.4.0 20080429 (experimental), builds just fine. CONFIG_CC_OPTIMIZE_FOR_SIZE=y. Need any more test / more info? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
brokenrecord Why don't we just link with libgcc? /brokenrecord Its something of a PITA to do that in the kernel at this point since we've duplicated libgcc functionality in it. I'm sure there are some historical reasons this wasn't done to start with. That's the same as saying that it would be a nice cleanup to remove all that duplicated code now... Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2.6.26] 85xx: Fix some sparse warnings for 85xx MDS
Signed-off-by: Andy Fleming [EMAIL PROTECTED]
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 25f8bc7..12f68ab 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -64,7 +64,7 @@
static void __init mpc85xx_mds_setup_arch(void)
{
struct device_node *np;
- static u8 *bcsr_regs = NULL;
+ static u8 __iomem *bcsr_regs = NULL;
if (ppc_md.progress)
ppc_md.progress(mpc85xx_mds_setup_arch(), 0);
--
1.5.4.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2.6.26] powerpc: Fix a bunch of sparse warnings in the qe_lib
Mostly having to do with not marking things __iomem. And some failure
to use appropriate accessors to read MMIO regs.
Signed-off-by: Andy Fleming [EMAIL PROTECTED]
---
arch/powerpc/sysdev/qe_lib/qe.c |6 ++--
arch/powerpc/sysdev/qe_lib/ucc.c |6 ++--
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 16
include/asm-powerpc/immap_qe.h| 58
include/asm-powerpc/ucc_fast.h|8 ++--
5 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index cff550e..07260a6 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -65,7 +65,7 @@ static phys_addr_t qebase = -1;
phys_addr_t get_qe_base(void)
{
struct device_node *qe;
- unsigned int size;
+ int size;
const u32 *prop;
if (qebase != -1)
@@ -159,7 +159,7 @@ static unsigned int brg_clk = 0;
unsigned int qe_get_brg_clk(void)
{
struct device_node *qe;
- unsigned int size;
+ int size;
const u32 *prop;
if (brg_clk)
@@ -306,7 +306,7 @@ EXPORT_SYMBOL(qe_put_snum);
static int qe_sdma_init(void)
{
- struct sdma *sdma = qe_immr-sdma;
+ struct sdma __iomem *sdma = qe_immr-sdma;
unsigned long sdma_buf_offset;
if (!sdma)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index 0e348d9..4103dc1 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -87,7 +87,7 @@ int ucc_set_type(unsigned int ucc_num, enum ucc_speed_type
speed)
return 0;
}
-static void get_cmxucr_reg(unsigned int ucc_num, __be32 **cmxucr,
+static void get_cmxucr_reg(unsigned int ucc_num, __be32 __iomem **cmxucr,
unsigned int *reg_num, unsigned int *shift)
{
unsigned int cmx = ((ucc_num 1) 1) + (ucc_num 3);
@@ -99,7 +99,7 @@ static void get_cmxucr_reg(unsigned int ucc_num, __be32
**cmxucr,
int ucc_mux_set_grant_tsa_bkpt(unsigned int ucc_num, int set, u32 mask)
{
- __be32 *cmxucr;
+ __be32 __iomem *cmxucr;
unsigned int reg_num;
unsigned int shift;
@@ -120,7 +120,7 @@ int ucc_mux_set_grant_tsa_bkpt(unsigned int ucc_num, int
set, u32 mask)
int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum qe_clock clock,
enum comm_dir mode)
{
- __be32 *cmxucr;
+ __be32 __iomem *cmxucr;
unsigned int reg_num;
unsigned int shift;
u32 clock_bits = 0;
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index bcf88e6..fcbec85 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -46,7 +46,7 @@ void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
printk(KERN_INFO uccm : addr=0x%p, val=0x%08x\n,
uccf-uf_regs-uccm, in_be32(uccf-uf_regs-uccm));
printk(KERN_INFO uccs : addr=0x%p, val=0x%02x\n,
- uccf-uf_regs-uccs, uccf-uf_regs-uccs);
+ uccf-uf_regs-uccs, in_8(uccf-uf_regs-uccs));
printk(KERN_INFO urfb : addr=0x%p, val=0x%08x\n,
uccf-uf_regs-urfb, in_be32(uccf-uf_regs-urfb));
printk(KERN_INFO urfs : addr=0x%p, val=0x%04x\n,
@@ -68,7 +68,7 @@ void ucc_fast_dump_regs(struct ucc_fast_private * uccf)
printk(KERN_INFO urtry : addr=0x%p, val=0x%08x\n,
uccf-uf_regs-urtry, in_be32(uccf-uf_regs-urtry));
printk(KERN_INFO guemr : addr=0x%p, val=0x%02x\n,
- uccf-uf_regs-guemr, uccf-uf_regs-guemr);
+ uccf-uf_regs-guemr, in_8(uccf-uf_regs-guemr));
}
EXPORT_SYMBOL(ucc_fast_dump_regs);
@@ -96,7 +96,7 @@ EXPORT_SYMBOL(ucc_fast_transmit_on_demand);
void ucc_fast_enable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
uf_regs = uccf-uf_regs;
@@ -117,7 +117,7 @@ EXPORT_SYMBOL(ucc_fast_enable);
void ucc_fast_disable(struct ucc_fast_private * uccf, enum comm_dir mode)
{
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
uf_regs = uccf-uf_regs;
@@ -139,7 +139,7 @@ EXPORT_SYMBOL(ucc_fast_disable);
int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private **
uccf_ret)
{
struct ucc_fast_private *uccf;
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
@@ -216,10 +216,10 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct
ucc_fast_private ** ucc
uccf-stopped_tx = 0;
uccf-stopped_rx = 0;
uf_regs = uccf-uf_regs;
- uccf-p_ucce = (u32 *) (uf_regs-ucce);
- uccf-p_uccm = (u32 *) (uf_regs-uccm);
+ uccf-p_ucce = (u32 __iomem *) (uf_regs-ucce);
+ uccf-p_uccm = (u32 __iomem *) (uf_regs-uccm);
#ifdef CONFIG_UGETH_TX_ON_DEMAND
- uccf-p_utodr
[PATCH v2.6.26] powerpc: Add 8568 PHY workarounds to board code
The 8568 MDS needs some configuration changes to the PHY in order to work
properly. These are done in the firmware, normally, but Linux shouldn't
need to rely on the firmware running such things (someone could disable
the PHY support in the firmware to save space, for instance).
Signed-off-by: Andy Fleming [EMAIL PROTECTED]
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 119 +
1 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 12f68ab..9ae29c5 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -32,6 +32,7 @@
#include linux/fsl_devices.h
#include linux/of_platform.h
#include linux/of_device.h
+#include linux/phy.h
#include asm/system.h
#include asm/atomic.h
@@ -56,6 +57,95 @@
#define DBG(fmt...)
#endif
+#define MV88E_SCR 0x10
+#define MV88E_SCR_125CLK 0x0010
+static int mpc8568_fixup_125_clock(struct phy_device *phydev)
+{
+ int scr;
+ int err;
+
+ /* Workaround for the 125 CLK Toggle */
+ scr = phy_read(phydev, MV88E_SCR);
+
+ if (scr 0)
+ return scr;
+
+ err = phy_write(phydev, MV88E_SCR, scr ~(MV88E_SCR_125CLK));
+
+ if (err)
+ return err;
+
+ err = phy_write(phydev, MII_BMCR, BMCR_RESET);
+
+ if (err)
+ return err;
+
+ scr = phy_read(phydev, MV88E_SCR);
+
+ if (scr 0)
+ return err;
+
+ err = phy_write(phydev, MV88E_SCR, scr | 0x0008);
+
+ return err;
+}
+
+static int mpc8568_mds_phy_fixups(struct phy_device *phydev)
+{
+ int temp;
+ int err;
+
+ /* Errata */
+ err = phy_write(phydev,29, 0x0006);
+
+ if (err)
+ return err;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp 0)
+ return temp;
+
+ temp = (temp (~0x8000)) | 0x4000;
+ err = phy_write(phydev,30, temp);
+
+ if (err)
+ return err;
+
+ err = phy_write(phydev,29, 0x000a);
+
+ if (err)
+ return err;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp 0)
+ return temp;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp 0)
+ return temp;
+
+ temp = ~0x0020;
+
+ err = phy_write(phydev,30,temp);
+
+ if (err)
+ return err;
+
+ /* Disable automatic MDI/MDIX selection */
+ temp = phy_read(phydev, 16);
+
+ if (temp 0)
+ return temp;
+
+ temp = ~0x0060;
+ err = phy_write(phydev,16,temp);
+
+ return err;
+}
+
/*
*
* Setup the architecture
@@ -138,6 +228,35 @@ static void __init mpc85xx_mds_setup_arch(void)
#endif /* CONFIG_QUICC_ENGINE */
}
+
+static int __init board_fixups(void)
+{
+ char phy_id[BUS_ID_SIZE];
+ char *compstrs[2] = {fsl,gianfar-mdio, fsl,ucc-mdio};
+ struct device_node *mdio;
+ struct resource res;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(compstrs); i++) {
+ mdio = of_find_compatible_node(NULL, NULL, compstrs[i]);
+
+ of_address_to_resource(mdio, 0, res);
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 1);
+
+ phy_register_fixup_for_id(phy_id, mpc8568_fixup_125_clock);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ /* Register a workaround for errata */
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 7);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ of_node_put(mdio);
+ }
+
+ return 0;
+}
+arch_initcall(board_fixups);
+
static struct of_device_id mpc85xx_ids[] = {
{ .type = soc, },
{ .compatible = soc, },
--
1.5.4.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2.6.26] powerpc: Add support for multiple gfar mdio interfaces
The old code assumed there was only one, but the 8572 actually has 3.
Also, our usual id, 0xe0024520, gets resolved to -1 somewhere, and this was
preventing the multiple buses from having different ids. So we only keep
the low 20 bits, which have the interesting info, anyway.
Signed-off-by: Andy Fleming [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 84 ++--
1 files changed, 38 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3a7054e..52f52b2 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -207,66 +207,58 @@ static int __init of_add_fixed_phys(void)
arch_initcall(of_add_fixed_phys);
#endif /* CONFIG_FIXED_PHY */
-static int __init gfar_mdio_of_init(void)
+static int gfar_mdio_of_init_one(struct device_node *np)
{
- struct device_node *np = NULL;
+ int k;
+ struct device_node *child = NULL;
+ struct gianfar_mdio_data mdio_data;
struct platform_device *mdio_dev;
struct resource res;
int ret;
- np = of_find_compatible_node(np, NULL, fsl,gianfar-mdio);
-
- /* try the deprecated version */
- if (!np)
- np = of_find_compatible_node(np, mdio, gianfar);
+ memset(res, 0, sizeof(res));
+ memset(mdio_data, 0, sizeof(mdio_data));
- if (np) {
- int k;
- struct device_node *child = NULL;
- struct gianfar_mdio_data mdio_data;
+ ret = of_address_to_resource(np, 0, res);
+ if (ret)
+ return ret;
- memset(res, 0, sizeof(res));
- memset(mdio_data, 0, sizeof(mdio_data));
+ mdio_dev = platform_device_register_simple(fsl-gianfar_mdio,
+ res.start0xf, res, 1);
+ if (IS_ERR(mdio_dev))
+ return PTR_ERR(mdio_dev);
- ret = of_address_to_resource(np, 0, res);
- if (ret)
- goto err;
+ for (k = 0; k 32; k++)
+ mdio_data.irq[k] = PHY_POLL;
- mdio_dev =
- platform_device_register_simple(fsl-gianfar_mdio,
- res.start, res, 1);
- if (IS_ERR(mdio_dev)) {
- ret = PTR_ERR(mdio_dev);
- goto err;
+ while ((child = of_get_next_child(np, child)) != NULL) {
+ int irq = irq_of_parse_and_map(child, 0);
+ if (irq != NO_IRQ) {
+ const u32 *id = of_get_property(child, reg, NULL);
+ mdio_data.irq[*id] = irq;
}
+ }
- for (k = 0; k 32; k++)
- mdio_data.irq[k] = PHY_POLL;
+ ret = platform_device_add_data(mdio_dev, mdio_data,
+ sizeof(struct gianfar_mdio_data));
+ if (ret)
+ platform_device_unregister(mdio_dev);
- while ((child = of_get_next_child(np, child)) != NULL) {
- int irq = irq_of_parse_and_map(child, 0);
- if (irq != NO_IRQ) {
- const u32 *id = of_get_property(child,
- reg, NULL);
- mdio_data.irq[*id] = irq;
- }
- }
+ return ret;
+}
- ret =
- platform_device_add_data(mdio_dev, mdio_data,
-sizeof(struct gianfar_mdio_data));
- if (ret)
- goto unreg;
- }
+static int __init gfar_mdio_of_init(void)
+{
+ struct device_node *np = NULL;
- of_node_put(np);
- return 0;
+ for_each_compatible_node(np, NULL, fsl,gianfar-mdio)
+ gfar_mdio_of_init_one(np);
-unreg:
- platform_device_unregister(mdio_dev);
-err:
- of_node_put(np);
- return ret;
+ /* try the deprecated version */
+ for_each_compatible_node(np, mdio, gianfar);
+ gfar_mdio_of_init_one(np);
+
+ return 0;
}
arch_initcall(gfar_mdio_of_init);
@@ -390,7 +382,7 @@ static int __init gfar_of_init(void)
gfar_data.phy_id = *id;
snprintf(gfar_data.bus_id, MII_BUS_ID_SIZE, %llx,
-(unsigned long long)res.start);
+(unsigned long long)res.start0xf);
of_node_put(phy);
of_node_put(mdio);
--
1.5.4.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26] powerpc: Fix a bunch of sparse warnings in the qe_lib
Andy Fleming wrote: + struct qe_iram __iomem iram; /* I-RAM */ + struct qe_ic_regs __iomem ic; /* Interrupt Controller */ + struct cp_qe __iomemcp; /* Communications Processor */ + struct qe_mux __iomem qmx;/* QE Multiplexer */ + struct qe_timers __iomem qet; /* QE Timers */ + struct spi __iomem spi[0x2]; /* spi */ + struct mcc __iomem mcc;/* mcc */ + struct qe_brg __iomem brg;/* brg */ + struct usb_ctlr __iomem usb;/* USB */ + struct si1 __iomem si1;/* SI */ Why not just set __iomem on qe_immap references? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26] powerpc: Fix a bunch of sparse warnings in the qe_lib
Andy Fleming wrote:
int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private **
uccf_ret)
{
struct ucc_fast_private *uccf;
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
@@ -216,10 +216,10 @@ int ucc_fast_init(struct ucc_fast_info * uf_info,
struct ucc_fast_private ** ucc
uccf-stopped_tx = 0;
uccf-stopped_rx = 0;
uf_regs = uccf-uf_regs;
- uccf-p_ucce = (u32 *) (uf_regs-ucce);
- uccf-p_uccm = (u32 *) (uf_regs-uccm);
+ uccf-p_ucce = (u32 __iomem *) (uf_regs-ucce);
+ uccf-p_uccm = (u32 __iomem *) (uf_regs-uccm);
Since you've already made uf_regs into an __iomem pointer, do you really need to
cast it?
And please remember to CC: me on any QE library patches.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Delete unused fec_8xx net driver
This driver has been superseded by fs_enet and is no longer in use.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
drivers/net/Kconfig |1 -
drivers/net/Makefile|1 -
drivers/net/fec_8xx/Kconfig | 20 -
drivers/net/fec_8xx/Makefile| 12 -
drivers/net/fec_8xx/fec_8xx-netta.c | 151 -
drivers/net/fec_8xx/fec_8xx.h | 220 --
drivers/net/fec_8xx/fec_main.c | 1264 ---
drivers/net/fec_8xx/fec_mii.c | 418
8 files changed, 0 insertions(+), 2087 deletions(-)
delete mode 100644 drivers/net/fec_8xx/Kconfig
delete mode 100644 drivers/net/fec_8xx/Makefile
delete mode 100644 drivers/net/fec_8xx/fec_8xx-netta.c
delete mode 100644 drivers/net/fec_8xx/fec_8xx.h
delete mode 100644 drivers/net/fec_8xx/fec_main.c
delete mode 100644 drivers/net/fec_8xx/fec_mii.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f90a86b..388ba79 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1898,7 +1898,6 @@ config NE_H8300
Say Y here if you want to use the NE2000 compatible
controller on the Renesas H8/300 processor.
-source drivers/net/fec_8xx/Kconfig
source drivers/net/fs_enet/Kconfig
endif # NET_ETHERNET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 2f1f3f2..b58bd60 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -217,7 +217,6 @@ obj-$(CONFIG_SMC91X) += smc91x.o
obj-$(CONFIG_SMC911X) += smc911x.o
obj-$(CONFIG_BFIN_MAC) += bfin_mac.o
obj-$(CONFIG_DM9000) += dm9000.o
-obj-$(CONFIG_FEC_8XX) += fec_8xx/
obj-$(CONFIG_PASEMI_MAC) += pasemi_mac_driver.o
pasemi_mac_driver-objs := pasemi_mac.o pasemi_mac_ethtool.o
obj-$(CONFIG_MLX4_CORE) += mlx4/
diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
deleted file mode 100644
index afb34de..000
--- a/drivers/net/fec_8xx/Kconfig
+++ /dev/null
@@ -1,20 +0,0 @@
-config FEC_8XX
- tristate Motorola 8xx FEC driver
- depends on 8XX
- select MII
-
-config FEC_8XX_GENERIC_PHY
- bool Support any generic PHY
- depends on FEC_8XX
- default y
-
-config FEC_8XX_DM9161_PHY
- bool Support DM9161 PHY
- depends on FEC_8XX
- default n
-
-config FEC_8XX_LXT971_PHY
- bool Support LXT971/LXT972 PHY
- depends on FEC_8XX
- default n
-
diff --git a/drivers/net/fec_8xx/Makefile b/drivers/net/fec_8xx/Makefile
deleted file mode 100644
index 70c54f8..000
--- a/drivers/net/fec_8xx/Makefile
+++ /dev/null
@@ -1,12 +0,0 @@
-#
-# Makefile for the Motorola 8xx FEC ethernet controller
-#
-
-obj-$(CONFIG_FEC_8XX) += fec_8xx.o
-
-fec_8xx-objs := fec_main.o fec_mii.o
-
-# the platform instantatiation objects
-ifeq ($(CONFIG_NETTA),y)
-fec_8xx-objs += fec_8xx-netta.o
-endif
diff --git a/drivers/net/fec_8xx/fec_8xx-netta.c
b/drivers/net/fec_8xx/fec_8xx-netta.c
deleted file mode 100644
index 79deee2..000
--- a/drivers/net/fec_8xx/fec_8xx-netta.c
+++ /dev/null
@@ -1,151 +0,0 @@
-/*
- * FEC instantatiation file for NETTA
- */
-
-#include linux/kernel.h
-#include linux/types.h
-#include linux/string.h
-#include linux/ptrace.h
-#include linux/errno.h
-#include linux/ioport.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include linux/pci.h
-#include linux/init.h
-#include linux/delay.h
-#include linux/netdevice.h
-#include linux/etherdevice.h
-#include linux/skbuff.h
-#include linux/spinlock.h
-#include linux/mii.h
-#include linux/ethtool.h
-#include linux/bitops.h
-
-#include asm/8xx_immap.h
-#include asm/pgtable.h
-#include asm/mpc8xx.h
-#include asm/irq.h
-#include asm/uaccess.h
-#include asm/cpm1.h
-
-#include fec_8xx.h
-
-/*/
-
-static struct fec_platform_info fec1_info = {
- .fec_no = 0,
- .use_mdio = 1,
- .phy_addr = 8,
- .fec_irq = SIU_LEVEL1,
- .phy_irq = CPM_IRQ_OFFSET + CPMVEC_PIO_PC6,
- .rx_ring = 128,
- .tx_ring = 16,
- .rx_copybreak = 240,
- .use_napi = 1,
- .napi_weight = 17,
-};
-
-static struct fec_platform_info fec2_info = {
- .fec_no = 1,
- .use_mdio = 1,
- .phy_addr = 2,
- .fec_irq = SIU_LEVEL3,
- .phy_irq = CPM_IRQ_OFFSET + CPMVEC_PIO_PC7,
- .rx_ring = 128,
- .tx_ring = 16,
- .rx_copybreak = 240,
- .use_napi = 1,
- .napi_weight = 17,
-};
-
-static struct net_device *fec1_dev;
-static struct net_device *fec2_dev;
-
-/* XXX custom u-boot Linux startup needed */
-extern const char *__fw_getenv(const char *var);
-
-/* access ports */
-#define setbits32(_addr, _v) __fec_out32((_addr), __fec_in32((_addr)) |
(_v))
-#define clrbits32(_addr, _v) __fec_out32((_addr), __fec_in32((_addr))
~(_v))
-
-#define setbits16(_addr, _v) __fec_out16((_addr), __fec_in16((_addr)) |
(_v))
-#define clrbits16(_addr, _v) __fec_out16((_addr), __fec_in16((_addr))
~(_v))
-
-int fec_8xx_platform_init(void)
-{
- immap_t *immap =
Re: [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
Phil,
When you have a chance, could you please take a look at the
arch-independent pieces of the OProfile kernel driver that this patch
touches? In short, this patch fixes a bug that I was responsible for in
my original OProfile-Cell SPE port (argh! :-[ ) where I was
improperly adding events to the main event buffer without first getting
the buffer_mutex. Under certain timing conditions, this caused some
synchronicity problems between the daemon and the driver, resulting in a
very confused daemon (only when running on Cell, by the way). So part
of the patch backs out some of the changes I had originally made (like
adding add_event_entry to include/linux/oprofile.h), and the rest of the
patch reworks the Cell code to use a new interface Carl added to oprofile.h.
Let me know if you have any questions about the patch as I worked pretty
closely with Carl while he was developing it.
P.S. I'm cc'ing Robert since he expressed an interest in reviewing
kernel driver patches.
Thanks.
Regards,
-Maynard
Carl Love wrote:
Sorry, looks like my mailer mangled the file.
This is a reworked patch to fix the SPU data storage. Currently, the
SPU escape sequences and program counter data is being added directly
into the kernel buffer without holding the buffer_mutex lock. This
patch changes how the data is stored. A new function,
oprofile_add_value, is added into the oprofile driver to allow adding
generic data to the per cpu buffers. This enables a series of calls
to the oprofile_add_value to enter the needed SPU escape sequences
and SPU program data into the kernel buffer via the per cpu buffers
without any additional processing. The oprofile_add_value function is
generic so it could be used by other architecures as well provided
the needed postprocessing was added to opreport.
Finally, this patch backs out the changes previously added to the
oprofile generic code for handling the architecture specific
ops.sync_start and ops.sync_stop that allowed the architecture
to skip the per CPU buffer creation.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h
===
--- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/pr_util.h
+++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h
@@ -20,11 +20,6 @@
#include asm/cell-regs.h
#include asm/spu.h
-/* Defines used for sync_start */
-#define SKIP_GENERIC_SYNC 0
-#define SYNC_START_ERROR -1
-#define DO_GENERIC_SYNC 1
-
struct spu_overlay_info {/* map of sections within an SPU overlay */
unsigned int vma; /* SPU virtual memory address from elf */
unsigned int size; /* size of section from elf */
@@ -85,7 +80,7 @@ void stop_spu_profiling(void);
int spu_sync_start(void);
/* remove the hooks */
-int spu_sync_stop(void);
+void spu_sync_stop(void);
/* Record SPU program counter samples to the oprofile event buffer. */
void spu_sync_buffer(int spu_num, unsigned int *samples,
Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
===
--- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/spu_task_sync.c
+++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
@@ -31,11 +31,12 @@
#define RELEASE_ALL
-static DEFINE_SPINLOCK(buffer_lock);
+static DEFINE_SPINLOCK(add_value_lock);
static DEFINE_SPINLOCK(cache_lock);
static int num_spu_nodes;
int spu_prof_num_nodes;
int last_guard_val[MAX_NUMNODES * 8];
+static int spu_ctx_sw_seen[MAX_NUMNODES * 8];
/* Container for caching information about an active SPU task. */
struct cached_info {
@@ -289,6 +290,7 @@ static int process_context_switch(struct
int retval;
unsigned int offset = 0;
unsigned long spu_cookie = 0, app_dcookie;
+ int cpu_buf;
retval = prepare_cached_spu_info(spu, objectId);
if (retval)
@@ -303,17 +305,28 @@ static int process_context_switch(struct
goto out;
}
- /* Record context info in event buffer */
- spin_lock_irqsave(buffer_lock, flags);
- add_event_entry(ESCAPE_CODE);
- add_event_entry(SPU_CTX_SWITCH_CODE);
- add_event_entry(spu-number);
- add_event_entry(spu-pid);
- add_event_entry(spu-tgid);
- add_event_entry(app_dcookie);
- add_event_entry(spu_cookie);
- add_event_entry(offset);
- spin_unlock_irqrestore(buffer_lock, flags);
+ /* Record context info in event buffer. Note, there are 4x more
+ * SPUs then CPUs. Map the SPU events/data for a given SPU to
+ * the same CPU buffer. Need to ensure the cntxt switch data and
+ * samples stay in order.
+ */
+ cpu_buf = spu-number 2;
+ spin_lock_irqsave(add_value_lock, flags);
+ oprofile_add_value(ESCAPE_CODE, cpu_buf);
+ oprofile_add_value(SPU_CTX_SWITCH_CODE,
function calls from identify_cpu()
I added:
int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
{
return s-t;
}
right before the definition of identify_cpu() in cputable.c and:
// (void) (*PTRRELOC(iDoNothingUseful))(s,t);
(void) iDoNothingUseful(s,t);
right before the return s; in the match block and it will not boot? Can
someone please explain what might be going on?
Thanks!
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
On Fri, 2 May 2008 13:19:44 -0400, Jon Smirl wrote: I attached the diff file. I had forgot that I renamed the file so it wasn't getting compiled. I compiled it this time. I've made too many other changes to it to test this version on my current hardware. Applied, thanks. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/5] macintosh: therm_pm72: driver_lock semaphore to mutex
From: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/macintosh/therm_pm72.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff -puN
drivers/macintosh/therm_pm72.c~macintosh-therm_pm72-driver_lock-semaphore-to-mutex
drivers/macintosh/therm_pm72.c
---
a/drivers/macintosh/therm_pm72.c~macintosh-therm_pm72-driver_lock-semaphore-to-mutex
+++ a/drivers/macintosh/therm_pm72.c
@@ -122,6 +122,7 @@
#include linux/kmod.h
#include linux/i2c.h
#include linux/kthread.h
+#include linux/mutex.h
#include asm/prom.h
#include asm/machdep.h
#include asm/io.h
@@ -169,7 +170,7 @@ static int rackmac;
static s32 dimm_output_clamp;
static int fcu_rpm_shift;
static int fcu_tickle_ticks;
-static DECLARE_MUTEX(driver_lock);
+static DEFINE_MUTEX(driver_lock);
/*
* We have 3 types of CPU PID control. One is split old style control
@@ -729,9 +730,9 @@ static void fetch_cpu_pumps_minmax(void)
static ssize_t show_##name(struct device *dev, struct device_attribute *attr,
char *buf) \
{ \
ssize_t r; \
- down(driver_lock); \
+ mutex_lock(driver_lock); \
r = sprintf(buf, %d.%03d, FIX32TOPRINT(data));\
- up(driver_lock); \
+ mutex_unlock(driver_lock); \
return r; \
}
#define BUILD_SHOW_FUNC_INT(name, data)\
@@ -1803,11 +1804,11 @@ static int main_control_loop(void *x)
{
DBG(main_control_loop started\n);
- down(driver_lock);
+ mutex_lock(driver_lock);
if (start_fcu() 0) {
printk(KERN_ERR kfand: failed to start FCU\n);
- up(driver_lock);
+ mutex_unlock(driver_lock);
goto out;
}
@@ -1822,14 +1823,14 @@ static int main_control_loop(void *x)
fcu_tickle_ticks = FCU_TICKLE_TICKS;
- up(driver_lock);
+ mutex_unlock(driver_lock);
while (state == state_attached) {
unsigned long elapsed, start;
start = jiffies;
- down(driver_lock);
+ mutex_lock(driver_lock);
/* Tickle the FCU just in case */
if (--fcu_tickle_ticks 0) {
@@ -1861,7 +1862,7 @@ static int main_control_loop(void *x)
do_monitor_slots(slots_state);
else
do_monitor_drives(drives_state);
- up(driver_lock);
+ mutex_unlock(driver_lock);
if (critical_state == 1) {
printk(KERN_WARNING Temperature control detected a
critical condition\n);
@@ -2019,13 +2020,13 @@ static void detach_fcu(void)
*/
static int therm_pm72_attach(struct i2c_adapter *adapter)
{
- down(driver_lock);
+ mutex_lock(driver_lock);
/* Check state */
if (state == state_detached)
state = state_attaching;
if (state != state_attaching) {
- up(driver_lock);
+ mutex_unlock(driver_lock);
return 0;
}
@@ -2054,7 +2055,7 @@ static int therm_pm72_attach(struct i2c_
state = state_attached;
start_control_loops();
}
- up(driver_lock);
+ mutex_unlock(driver_lock);
return 0;
}
@@ -2065,16 +2066,16 @@ static int therm_pm72_attach(struct i2c_
*/
static int therm_pm72_detach(struct i2c_adapter *adapter)
{
- down(driver_lock);
+ mutex_lock(driver_lock);
if (state != state_detached)
state = state_detaching;
/* Stop control loops if any */
DBG(stopping control loops\n);
- up(driver_lock);
+ mutex_unlock(driver_lock);
stop_control_loops();
- down(driver_lock);
+ mutex_lock(driver_lock);
if (u3_0 != NULL !strcmp(adapter-name, u3 0)) {
DBG(lost U3-0, disposing control loops\n);
@@ -2090,7 +2091,7 @@ static int therm_pm72_detach(struct i2c_
if (u3_0 == NULL u3_1 == NULL)
state = state_detached;
- up(driver_lock);
+ mutex_unlock(driver_lock);
return 0;
}
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/5] macintosh: qindfarm_smu_sat: semaphore to mutex
From: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/macintosh/windfarm_smu_sat.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff -puN
drivers/macintosh/windfarm_smu_sat.c~macintosh-qindfarm_smu_sat-semaphore-to-mutex
drivers/macintosh/windfarm_smu_sat.c
---
a/drivers/macintosh/windfarm_smu_sat.c~macintosh-qindfarm_smu_sat-semaphore-to-mutex
+++ a/drivers/macintosh/windfarm_smu_sat.c
@@ -13,7 +13,7 @@
#include linux/init.h
#include linux/wait.h
#include linux/i2c.h
-#include linux/semaphore.h
+#include linux/mutex.h
#include asm/prom.h
#include asm/smu.h
#include asm/pmac_low_i2c.h
@@ -36,7 +36,7 @@
struct wf_sat {
int nr;
atomic_trefcnt;
- struct semaphoremutex;
+ struct mutexmutex;
unsigned long last_read; /* jiffies when cache last updated */
u8 cache[16];
struct i2c_client i2c;
@@ -163,7 +163,7 @@ static int wf_sat_get(struct wf_sensor *
if (sat-i2c.adapter == NULL)
return -ENODEV;
- down(sat-mutex);
+ mutex_lock(sat-mutex);
if (time_after(jiffies, (sat-last_read + MAX_AGE))) {
err = wf_sat_read_cache(sat);
if (err)
@@ -182,7 +182,7 @@ static int wf_sat_get(struct wf_sensor *
err = 0;
fail:
- up(sat-mutex);
+ mutex_unlock(sat-mutex);
return err;
}
@@ -233,7 +233,7 @@ static void wf_sat_create(struct i2c_ada
sat-nr = -1;
sat-node = of_node_get(dev);
atomic_set(sat-refcnt, 0);
- init_MUTEX(sat-mutex);
+ mutex_init(sat-mutex);
sat-i2c.addr = (addr 1) 0x7f;
sat-i2c.adapter = adapter;
sat-i2c.driver = wf_sat_driver;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/5] powerpc: devres: Add devm_ioremap_prot()
From: Emil Medve [EMAIL PROTECTED]
We provide an ioremap_flags so provide a corresponding devm_ioremap_prot. The
slight name difference is at Ben Herrenschmidt request as he plans on changing
ioremap_flags to ioremap_prot in the future.
Signed-off-by: Emil Medve [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Acked-by: Tejun Heo [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/lib/Makefile |1
arch/powerpc/lib/devres.c | 42
include/asm-powerpc/io.h |8 ++
include/linux/io.h|1
lib/devres.c |2 -
5 files changed, 52 insertions(+), 2 deletions(-)
diff -puN arch/powerpc/lib/Makefile~devres-add-devm_ioremap_prot
arch/powerpc/lib/Makefile
--- a/arch/powerpc/lib/Makefile~devres-add-devm_ioremap_prot
+++ a/arch/powerpc/lib/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o
endif
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
+obj-$(CONFIG_HAS_IOMEM)+= devres.o
diff -puN /dev/null arch/powerpc/lib/devres.c
--- /dev/null
+++ a/arch/powerpc/lib/devres.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2008 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/device.h /* devres_*(), devm_ioremap_release() */
+#include linux/io.h /* ioremap_flags() */
+#include linux/module.h /* EXPORT_SYMBOL() */
+
+/**
+ * devm_ioremap_prot - Managed ioremap_flags()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ * @flags: Page flags
+ *
+ * Managed ioremap_prot(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+size_t size, unsigned long flags)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_flags(offset, size, flags);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_prot);
diff -puN include/asm-powerpc/io.h~devres-add-devm_ioremap_prot
include/asm-powerpc/io.h
--- a/include/asm-powerpc/io.h~devres-add-devm_ioremap_prot
+++ a/include/asm-powerpc/io.h
@@ -2,7 +2,7 @@
#define _ASM_POWERPC_IO_H
#ifdef __KERNEL__
-/*
+/*
* 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
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned
#define _PNPWRP0xa79
#define PNPBIOS_BASE 0xf000
+#include linux/device.h
+#include linux/io.h
+
#include linux/compiler.h
#include asm/page.h
#include asm/byteorder.h
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigne
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
diff -puN include/linux/io.h~devres-add-devm_ioremap_prot include/linux/io.h
--- a/include/linux/io.h~devres-add-devm_ioremap_prot
+++ a/include/linux/io.h
@@ -65,5 +65,6 @@ void __iomem *devm_ioremap_nocache(struc
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
+void devm_ioremap_release(struct device *dev, void *res);
#endif /* _LINUX_IO_H */
diff -puN lib/devres.c~devres-add-devm_ioremap_prot lib/devres.c
--- a/lib/devres.c~devres-add-devm_ioremap_prot
+++ a/lib/devres.c
@@ -2,7 +2,7 @@
#include linux/io.h
#include linux/module.h
-static void devm_ioremap_release(struct device *dev, void *res)
+void devm_ioremap_release(struct device *dev, void *res)
{
iounmap(*(void __iomem **)res);
}
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 5/5] powerpc: assign PDE-data before gluing PDE into /proc tree
From: Denis V. Lunev [EMAIL PROTECTED]
Simply replace proc_create and further data assigned with proc_create_data.
No need to check for data!=NULL after that.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
Cc: Alexey Dobriyan [EMAIL PROTECTED]
Cc: Eric W. Biederman [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/scanlog.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff -puN
arch/powerpc/platforms/pseries/scanlog.c~powerpc-assign-pde-data-before-gluing-pde-into-proc-tree
arch/powerpc/platforms/pseries/scanlog.c
---
a/arch/powerpc/platforms/pseries/scanlog.c~powerpc-assign-pde-data-before-gluing-pde-into-proc-tree
+++ a/arch/powerpc/platforms/pseries/scanlog.c
@@ -55,11 +55,6 @@ static ssize_t scanlog_read(struct file
dp = PDE(inode);
data = (unsigned int *)dp-data;
- if (!data) {
- printk(KERN_ERR scanlog: read failed no data\n);
- return -EIO;
- }
-
if (count RTAS_DATA_BUF_SIZE)
count = RTAS_DATA_BUF_SIZE;
@@ -146,11 +141,6 @@ static int scanlog_open(struct inode * i
struct proc_dir_entry *dp = PDE(inode);
unsigned int *data = (unsigned int *)dp-data;
- if (!data) {
- printk(KERN_ERR scanlog: open failed no data\n);
- return -EIO;
- }
-
if (data[0] != 0) {
/* This imperfect test stops a second copy of the
* data (or a reset while data is being copied)
@@ -168,10 +158,6 @@ static int scanlog_release(struct inode
struct proc_dir_entry *dp = PDE(inode);
unsigned int *data = (unsigned int *)dp-data;
- if (!data) {
- printk(KERN_ERR scanlog: release failed no data\n);
- return -EIO;
- }
data[0] = 0;
return 0;
@@ -200,12 +186,11 @@ static int __init scanlog_init(void)
if (!data)
goto err;
- ent = proc_create(ppc64/rtas/scan-log-dump, S_IRUSR, NULL,
- scanlog_fops);
+ ent = proc_create_data(ppc64/rtas/scan-log-dump, S_IRUSR, NULL,
+ scanlog_fops, data);
if (!ent)
goto err;
- ent-data = data;
proc_ppc64_scan_log_dump = ent;
return 0;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 3/5] machintosh: ADB driver: adb_handler_sem semaphore to mutex
From: Daniel Walker [EMAIL PROTECTED]
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/macintosh/adb.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff -puN
drivers/macintosh/adb.c~machintosh-adb-driver-adb_handler_sem-semaphore-to-mutex
drivers/macintosh/adb.c
---
a/drivers/macintosh/adb.c~machintosh-adb-driver-adb_handler_sem-semaphore-to-mutex
+++ a/drivers/macintosh/adb.c
@@ -37,7 +37,7 @@
#include linux/device.h
#include linux/kthread.h
#include linux/platform_device.h
-#include linux/semaphore.h
+#include linux/mutex.h
#include asm/uaccess.h
#ifdef CONFIG_PPC
@@ -102,7 +102,7 @@ static struct adb_handler {
} adb_handler[16];
/*
- * The adb_handler_sem mutex protects all accesses to the original_address
+ * The adb_handler_mutex mutex protects all accesses to the original_address
* and handler_id fields of adb_handler[i] for all i, and changes to the
* handler field.
* Accesses to the handler field are protected by the adb_handler_lock
@@ -110,7 +110,7 @@ static struct adb_handler {
* time adb_unregister returns, we know that the old handler isn't being
* called.
*/
-static DECLARE_MUTEX(adb_handler_sem);
+static DEFINE_MUTEX(adb_handler_mutex);
static DEFINE_RWLOCK(adb_handler_lock);
#if 0
@@ -355,7 +355,7 @@ do_adb_reset_bus(void)
msleep(500);
}
- down(adb_handler_sem);
+ mutex_lock(adb_handler_mutex);
write_lock_irq(adb_handler_lock);
memset(adb_handler, 0, sizeof(adb_handler));
write_unlock_irq(adb_handler_lock);
@@ -376,7 +376,7 @@ do_adb_reset_bus(void)
if (adb_controller-autopoll)
adb_controller-autopoll(autopoll_devs);
}
- up(adb_handler_sem);
+ mutex_unlock(adb_handler_mutex);
blocking_notifier_call_chain(adb_client_list,
ADB_MSG_POST_RESET, NULL);
@@ -454,7 +454,7 @@ adb_register(int default_id, int handler
{
int i;
- down(adb_handler_sem);
+ mutex_lock(adb_handler_mutex);
ids-nids = 0;
for (i = 1; i 16; i++) {
if ((adb_handler[i].original_address == default_id)
@@ -472,7 +472,7 @@ adb_register(int default_id, int handler
ids-id[ids-nids++] = i;
}
}
- up(adb_handler_sem);
+ mutex_unlock(adb_handler_mutex);
return ids-nids;
}
@@ -481,7 +481,7 @@ adb_unregister(int index)
{
int ret = -ENODEV;
- down(adb_handler_sem);
+ mutex_lock(adb_handler_mutex);
write_lock_irq(adb_handler_lock);
if (adb_handler[index].handler) {
while(adb_handler[index].busy) {
@@ -493,7 +493,7 @@ adb_unregister(int index)
adb_handler[index].handler = NULL;
}
write_unlock_irq(adb_handler_lock);
- up(adb_handler_sem);
+ mutex_unlock(adb_handler_mutex);
return ret;
}
@@ -557,19 +557,19 @@ adb_try_handler_change(int address, int
{
int ret;
- down(adb_handler_sem);
+ mutex_lock(adb_handler_mutex);
ret = try_handler_change(address, new_id);
- up(adb_handler_sem);
+ mutex_unlock(adb_handler_mutex);
return ret;
}
int
adb_get_infos(int address, int *original_address, int *handler_id)
{
- down(adb_handler_sem);
+ mutex_lock(adb_handler_mutex);
*original_address = adb_handler[address].original_address;
*handler_id = adb_handler[address].handler_id;
- up(adb_handler_sem);
+ mutex_unlock(adb_handler_mutex);
return (*original_address != 0);
}
@@ -628,10 +628,10 @@ do_adb_query(struct adb_request *req)
case ADB_QUERY_GETDEVINFO:
if (req-nbytes 3)
break;
- down(adb_handler_sem);
+ mutex_lock(adb_handler_mutex);
req-reply[0] = adb_handler[req-data[2]].original_address;
req-reply[1] = adb_handler[req-data[2]].handler_id;
- up(adb_handler_sem);
+ mutex_unlock(adb_handler_mutex);
req-complete = 1;
req-reply_len = 2;
adb_write_done(req);
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On May 2, 2008, at 12:11 PM, Segher Boessenkool wrote: Why can't we link with libgcc, instead? Do you have or can you generate a ppc64 toolchain with this patch in it? I'm not sure what you mean. Sorry, I meant the gcc patch. I'm not sure if this has been committed to FSF head or not. I build GCC TOT toolchains sort-of daily, and build the kernel with it (all architectures). I don't build any 4xx config though, maybe I should. I'm guessing you haven't seen this issue yet. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
On May 2, 2008, at 12:33 PM, Segher Boessenkool wrote: If someone using cutting edge toolchains for ppc64 could test and make sure if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE things work that would be nice. Current linus tree + some more stuff + this patch, ppc64_defconfig, powerpc64-linux-gcc (GCC) 4.4.0 20080429 (experimental), builds just fine. CONFIG_CC_OPTIMIZE_FOR_SIZE=y. Need any more test / more info? I don't think the gcc guys have accepted (or committed) the patch I was referencing. Once it has been we should retest and see what happens. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote: brokenrecord Why don't we just link with libgcc? /brokenrecord Its something of a PITA to do that in the kernel at this point since we've duplicated libgcc functionality in it. I'm sure there are some historical reasons this wasn't done to start with. That's the same as saying that it would be a nice cleanup to remove all that duplicated code now... We'll hopefully this thread might spark either an explanation for why we aren't just linking libgcc in a statement that says we should and we can remove the code that implements libgcc functionality. How would libgcc linking intermix with modules? Would we have to EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing that's varies w/different gcc versions. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
Kumar Gala wrote: On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote: brokenrecord Why don't we just link with libgcc? /brokenrecord Its something of a PITA to do that in the kernel at this point since we've duplicated libgcc functionality in it. I'm sure there are some historical reasons this wasn't done to start with. That's the same as saying that it would be a nice cleanup to remove all that duplicated code now... We'll hopefully this thread might spark either an explanation for why we aren't just linking libgcc in a statement that says we should and we can remove the code that implements libgcc functionality. How would libgcc linking intermix with modules? Would we have to EXPORT_SYMBOL() all functions that libgcc implements? Yes, unfortunately. A quick way to generate such a list would be to build a non-modular kernel and leave out the libgcc link (after removing the reimplemented functions), and see what linker errors you get. I'm guessing that's varies w/different gcc versions. Yeah, but so does the set of functions that Linux needs to reimplement. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala [EMAIL PROTECTED] Date: Fri, 2 May 2008 16:28:36 -0500 Sorry, I meant the gcc patch. I'm not sure if this has been committed to FSF head or not. If that's the case it would be a good idea to suggest a command line option to disable the new out-of-line code generation feature of that patch. But if the stubs it calls are really simple, you can just add implementations under arch/powerpc/lib/, and therefore it's not such a big deal. This is what we've traditionally done with libcalls generated by gcc for runtime support. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Kumar Gala [EMAIL PROTECTED] Date: Fri, 2 May 2008 16:34:13 -0500 We'll hopefully this thread might spark either an explanation for why we aren't just linking libgcc in a statement that says we should and we can remove the code that implements libgcc functionality. How would libgcc linking intermix with modules? Would we have to EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing that's varies w/different gcc versions. If you link in libgcc, all of a sudden you have a whole new class of potential problems, don't do it. All it takes is one of these libgcc libcalls the kernel actually references, needing something else in libc, to make this exercise futile. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
David Miller wrote: If you link in libgcc, all of a sudden you have a whole new class of potential problems, don't do it. All it takes is one of these libgcc libcalls the kernel actually references, needing something else in libc, to make this exercise futile. What in libgcc references libc, and why isn't this a problem for Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs that use libgcc? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On May 2, 2008, at 4:40 PM, David Miller wrote: From: Kumar Gala [EMAIL PROTECTED] Date: Fri, 2 May 2008 16:28:36 -0500 Sorry, I meant the gcc patch. I'm not sure if this has been committed to FSF head or not. If that's the case it would be a good idea to suggest a command line option to disable the new out-of-line code generation feature of that patch. But if the stubs it calls are really simple, you can just add implementations under arch/powerpc/lib/, and therefore it's not such a big deal. This is what we've traditionally done with libcalls generated by gcc for runtime support. They are pretty simple. http://patchwork.ozlabs.org/linuxppc/patch?id=18292 http://patchwork.ozlabs.org/linuxppc/patch?id=18290 I've got a toolchain from CodeSourcery that has the GCC change in it and was posting this as preemptive for the point in time when FSF GCC has it. At which point the whole discussion about why don't we just link libgcc started up :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood [EMAIL PROTECTED] Date: Fri, 02 May 2008 16:45:45 -0500 David Miller wrote: If you link in libgcc, all of a sudden you have a whole new class of potential problems, don't do it. All it takes is one of these libgcc libcalls the kernel actually references, needing something else in libc, to make this exercise futile. What in libgcc references libc, and why isn't this a problem for Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs that use libgcc? The problem only occurs once you reference a function that references libc stuff, and those guys are just lucky so far. It's also one less variable to debug if you put the implementation in the kernel, or do you like debugging compiler induced problems? I don't :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
David Miller wrote: The problem only occurs once you reference a function that references libc stuff, and those guys are just lucky so far. Yeah, lucky they don't need to reinvent the wheel every time the GCC/libgcc interface changes. :-) If GCC generates a call to a libgcc function that calls a libc function, I'd consider that a pretty serious bug, given that said libc function is likely to consist of GCC-generated code, which could call the same libgcc function, which calls the libc function, etc. It's also one less variable to debug if you put the implementation in the kernel, or do you like debugging compiler induced problems? I don't :-) I'd say problems are more likely if you use nonstandard implementations of GCC internals... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
Benjamin Herrenschmidt wrote: On Thu, 2008-05-01 at 14:46 -0700, Geoff Levand wrote: It doesn't seem to cause problems on PS3, and I added it into ps3-linux.git as other/powerpc-vmemmap-variable-page-size.diff, but I couldn't get it to fail without the patch... Could you send me your kernel .config? ps3_defconfig with added vmmemap (which is disabled by default). Well, it seems that it wasn't that I couldn't get it to fail, but that it always fails. add_memory() doesn't work anymore, with or without vmmemap. I'll look at it more next week. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood [EMAIL PROTECTED] Date: Fri, 02 May 2008 17:16:07 -0500 If GCC generates a call to a libgcc function that calls a libc function, I'd consider that a pretty serious bug, given that said libc function is likely to consist of GCC-generated code, which could call the same libgcc function, which calls the libc function, etc. Not really, there are several interfaces in libgcc that need some runtime help from the C library or the dynamic linker. For example, EH frame support. You really don't know what you're talking about. I'd say problems are more likely if you use nonstandard implementations of GCC internals... The kernel is a special environment. Therefore even if you start linking with libgcc, it is inevitable that you will need some changed local version for some of those routines in the kernel. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
David Miller wrote: From: Scott Wood [EMAIL PROTECTED] Date: Fri, 02 May 2008 17:16:07 -0500 If GCC generates a call to a libgcc function that calls a libc function, I'd consider that a pretty serious bug, given that said libc function is likely to consist of GCC-generated code, which could call the same libgcc function, which calls the libc function, etc. Not really, there are several interfaces in libgcc that need some runtime help from the C library or the dynamic linker. For example, EH frame support. ...which is in libgcc_eh, not libgcc, and is in support of features not found in the language that libc is implemented in, avoiding any possibility of a cyclic dependency. And the sort of libc functions it uses are basic, standard things like memcpy and malloc. Much easier and more stable to implement than the internal libgcc interface. You really don't know what you're talking about. Yawn. I'd say problems are more likely if you use nonstandard implementations of GCC internals... The kernel is a special environment. Therefore even if you start linking with libgcc, it is inevitable that you will need some changed local version for some of those routines in the kernel. Such as? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood [EMAIL PROTECTED] Date: Fri, 02 May 2008 17:38:21 -0500 David Miller wrote: The kernel is a special environment. Therefore even if you start linking with libgcc, it is inevitable that you will need some changed local version for some of those routines in the kernel. Such as? When I added the software multiply and divide implemenations to the 32-bit sparc port, I ended up using a different software trap for signalling divide by zero in the handler so that it was easier to detect the from kernel kernel case. We're not talking about big complicated routines, we're talking about quite simple stubs whose interfaces really are not going to change. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus
On Fri, 2008-05-02 at 19:03 +1000, Paul Mackerras wrote: David Gibson writes: Do you even need the processor ID test at all? The boot processor should always have its stack covered by SLB entry 0 when we come through here, shouldn't it? I was concerned that get_paca()-kstack wouldn't have been initialized by the time the boot cpu calls slb_initialize(). If that fear is unfounded then the check could go. No, you are correct, it's not initialized. However, I find that a bit weird, as we shouldn't have a problem initializing it in start_here_multiplatform rather than start_here_common. The whole stack setup part of these here seems like a dup to me. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
On Fri, 2008-05-02 at 16:34 -0500, Kumar Gala wrote: On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote: brokenrecord Why don't we just link with libgcc? /brokenrecord Its something of a PITA to do that in the kernel at this point since we've duplicated libgcc functionality in it. I'm sure there are some historical reasons this wasn't done to start with. That's the same as saying that it would be a nice cleanup to remove all that duplicated code now... We'll hopefully this thread might spark either an explanation for why we aren't just linking libgcc in a statement that says we should and we can remove the code that implements libgcc functionality. How would libgcc linking intermix with modules? Would we have to EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing that's varies w/different gcc versions. The historical reason for not linking with libgcc was around the lines of we want to catch when people do stupid things like 64 bits divides in the kernel. Nowadays, this is mostly moot and it's accepted that things might want to do such operations here or there. I personally don't see any problem with a patch that would make us link with libgcc and get rid of the hacks. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
On Fri, 2008-05-02 at 14:42 -0700, David Miller wrote: From: Kumar Gala [EMAIL PROTECTED] Date: Fri, 2 May 2008 16:34:13 -0500 We'll hopefully this thread might spark either an explanation for why we aren't just linking libgcc in a statement that says we should and we can remove the code that implements libgcc functionality. How would libgcc linking intermix with modules? Would we have to EXPORT_SYMBOL() all functions that libgcc implements? I'm guessing that's varies w/different gcc versions. If you link in libgcc, all of a sudden you have a whole new class of potential problems, don't do it. All it takes is one of these libgcc libcalls the kernel actually references, needing something else in libc, to make this exercise futile. Hrm... I though you linked it in, I must be confusing with another arch :-) Oh well, if we fail with something pulling bits off libc etc... we'll see quickly who is the culprit no ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
On Fri, 2008-05-02 at 14:40 -0700, David Miller wrote: From: Kumar Gala [EMAIL PROTECTED] Date: Fri, 2 May 2008 16:28:36 -0500 Sorry, I meant the gcc patch. I'm not sure if this has been committed to FSF head or not. If that's the case it would be a good idea to suggest a command line option to disable the new out-of-line code generation feature of that patch. But if the stubs it calls are really simple, you can just add implementations under arch/powerpc/lib/, and therefore it's not such a big deal. This is what we've traditionally done with libcalls generated by gcc for runtime support. My only worry with this is modules. That is, it would be fairly non-sensical for module code to go through the trampoline to call those stubs in the kernel (and having to EXPORT_SYMBOL them). In the case of those register save stubs, I believe they should really be linked with the modules. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: function calls from identify_cpu()
On Fri, 2008-05-02 at 13:42 -0700, Kevin Diggs wrote:
I added:
int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
{
return s-t;
}
right before the definition of identify_cpu() in cputable.c and:
// (void) (*PTRRELOC(iDoNothingUseful))(s,t);
(void) iDoNothingUseful(s,t);
right before the return s; in the match block and it will not boot? Can
someone please explain what might be going on?
Why are you trying to muck around with that code in the first
place ? :-)
What are you trying to achieve ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git master branch
Linus Torvalds writes: On Fri, 2 May 2008, Paul Mackerras wrote: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master Already up-to-date. Forgot to push? Yep. :( Try again now. Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26] powerpc: Add 8568 PHY workarounds to board code
Hi,
On Fri, May 02, 2008 at 01:03:42PM -0500, Andy Fleming wrote:
+static int __init board_fixups(void)
+{
+ char phy_id[BUS_ID_SIZE];
+ char *compstrs[2] = {fsl,gianfar-mdio, fsl,ucc-mdio};
+ struct device_node *mdio;
+ struct resource res;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(compstrs); i++) {
+ mdio = of_find_compatible_node(NULL, NULL, compstrs[i]);
+
+ of_address_to_resource(mdio, 0, res);
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 1);
+
+ phy_register_fixup_for_id(phy_id, mpc8568_fixup_125_clock);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ /* Register a workaround for errata */
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 7);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ of_node_put(mdio);
+ }
+
+ return 0;
+}
+arch_initcall(board_fixups);
Are you sure you want to run this workaround on all boards that happen
to be built-in? I.e. shouldn't you be checked for what board you are
running on, since the compatible strings you match on seem generic?
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Sat, 03 May 2008 09:27:55 +1000 That is, it would be fairly non-sensical for module code to go through the trampoline to call those stubs in the kernel (and having to EXPORT_SYMBOL them). Oh, I forgot about how far function calls are done on powerpc. Yes, that will suck. Is there some way to map all of the modules in the low 32-bits and thus aovid the trampolines? The powerpc call instruction can cover 4GB like on sparc right? Actually, I remember there is some linkage register that has to be setup on powerpc with the code model you guys use, is that the problem? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26] powerpc: Add 8568 PHY workarounds to board code
On May 2, 2008, at 18:49, Olof Johansson wrote:
Hi,
On Fri, May 02, 2008 at 01:03:42PM -0500, Andy Fleming wrote:
+static int __init board_fixups(void)
+{
+ char phy_id[BUS_ID_SIZE];
+ char *compstrs[2] = {fsl,gianfar-mdio, fsl,ucc-mdio};
+ struct device_node *mdio;
+ struct resource res;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(compstrs); i++) {
+ mdio = of_find_compatible_node(NULL, NULL, compstrs[i]);
+
+ of_address_to_resource(mdio, 0, res);
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 1);
+
+ phy_register_fixup_for_id(phy_id, mpc8568_fixup_125_clock);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ /* Register a workaround for errata */
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 7);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ of_node_put(mdio);
+ }
+
+ return 0;
+}
+arch_initcall(board_fixups);
Are you sure you want to run this workaround on all boards that happen
to be built-in? I.e. shouldn't you be checked for what board you are
running on, since the compatible strings you match on seem generic?
Shoot. That's a good point. I keep forgetting that just because it's
in mpc85xx_mds.c, doesn't mean it's only being run on that platform.
Alright, I'll resubmit.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Add 8568 PHY workarounds to board code
The 8568 MDS needs some configuration changes to the PHY in order to
work properly. These are done in the firmware, normally, but Linux
shouldn't need to rely on the firmware running such things (someone
could disable the PHY support in the firmware to save space, for instance).
Signed-off-by: Andy Fleming [EMAIL PROTECTED]
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 119 +
1 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 12f68ab..43a459f 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -32,6 +32,7 @@
#include linux/fsl_devices.h
#include linux/of_platform.h
#include linux/of_device.h
+#include linux/phy.h
#include asm/system.h
#include asm/atomic.h
@@ -56,6 +57,95 @@
#define DBG(fmt...)
#endif
+#define MV88E_SCR 0x10
+#define MV88E_SCR_125CLK 0x0010
+static int mpc8568_fixup_125_clock(struct phy_device *phydev)
+{
+ int scr;
+ int err;
+
+ /* Workaround for the 125 CLK Toggle */
+ scr = phy_read(phydev, MV88E_SCR);
+
+ if (scr 0)
+ return scr;
+
+ err = phy_write(phydev, MV88E_SCR, scr ~(MV88E_SCR_125CLK));
+
+ if (err)
+ return err;
+
+ err = phy_write(phydev, MII_BMCR, BMCR_RESET);
+
+ if (err)
+ return err;
+
+ scr = phy_read(phydev, MV88E_SCR);
+
+ if (scr 0)
+ return err;
+
+ err = phy_write(phydev, MV88E_SCR, scr | 0x0008);
+
+ return err;
+}
+
+static int mpc8568_mds_phy_fixups(struct phy_device *phydev)
+{
+ int temp;
+ int err;
+
+ /* Errata */
+ err = phy_write(phydev,29, 0x0006);
+
+ if (err)
+ return err;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp 0)
+ return temp;
+
+ temp = (temp (~0x8000)) | 0x4000;
+ err = phy_write(phydev,30, temp);
+
+ if (err)
+ return err;
+
+ err = phy_write(phydev,29, 0x000a);
+
+ if (err)
+ return err;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp 0)
+ return temp;
+
+ temp = phy_read(phydev, 30);
+
+ if (temp 0)
+ return temp;
+
+ temp = ~0x0020;
+
+ err = phy_write(phydev,30,temp);
+
+ if (err)
+ return err;
+
+ /* Disable automatic MDI/MDIX selection */
+ temp = phy_read(phydev, 16);
+
+ if (temp 0)
+ return temp;
+
+ temp = ~0x0060;
+ err = phy_write(phydev,16,temp);
+
+ return err;
+}
+
/*
*
* Setup the architecture
@@ -138,6 +228,35 @@ static void __init mpc85xx_mds_setup_arch(void)
#endif /* CONFIG_QUICC_ENGINE */
}
+
+static int __init board_fixups(void)
+{
+ char phy_id[BUS_ID_SIZE];
+ char *compstrs[2] = {fsl,gianfar-mdio, fsl,ucc-mdio};
+ struct device_node *mdio;
+ struct resource res;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(compstrs); i++) {
+ mdio = of_find_compatible_node(NULL, NULL, compstrs[i]);
+
+ of_address_to_resource(mdio, 0, res);
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 1);
+
+ phy_register_fixup_for_id(phy_id, mpc8568_fixup_125_clock);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ /* Register a workaround for errata */
+ snprintf(phy_id, BUS_ID_SIZE, %x:%02x, res.start, 7);
+ phy_register_fixup_for_id(phy_id, mpc8568_mds_phy_fixups);
+
+ of_node_put(mdio);
+ }
+
+ return 0;
+}
+machine_arch_initcall(mpc85xx_mds, board_fixups);
+
static struct of_device_id mpc85xx_ids[] = {
{ .type = soc, },
{ .compatible = soc, },
--
1.5.4.GIT
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26] powerpc: Fix a bunch of sparse warnings in the qe_lib
On May 2, 2008, at 13:37, Timur Tabi wrote:
Andy Fleming wrote:
int ucc_fast_init(struct ucc_fast_info * uf_info, struct
ucc_fast_private ** uccf_ret)
{
struct ucc_fast_private *uccf;
- struct ucc_fast *uf_regs;
+ struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
@@ -216,10 +216,10 @@ int ucc_fast_init(struct ucc_fast_info *
uf_info, struct ucc_fast_private ** ucc
uccf-stopped_tx = 0;
uccf-stopped_rx = 0;
uf_regs = uccf-uf_regs;
- uccf-p_ucce = (u32 *) (uf_regs-ucce);
- uccf-p_uccm = (u32 *) (uf_regs-uccm);
+ uccf-p_ucce = (u32 __iomem *) (uf_regs-ucce);
+ uccf-p_uccm = (u32 __iomem *) (uf_regs-uccm);
Since you've already made uf_regs into an __iomem pointer, do you
really need to
cast it?
Ah, yes. That's probably leftover from when uf_regs wasn't __iomem.
And please remember to CC: me on any QE library patches.
Can do.
Andy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
That is, it would be fairly non-sensical for module code to go through the trampoline to call those stubs in the kernel (and having to EXPORT_SYMBOL them). You can link every module to libgcc separately. Probably it can also be set up so that some libgcc routines get linked into the kernel, and exported, and the rest is linked into every module that wants them. We can also blacklist some symbols altogether (__udivdi3...) Oh, I forgot about how far function calls are done on powerpc. Yes, that will suck. Is there some way to map all of the modules in the low 32-bits and thus aovid the trampolines? The powerpc call instruction can cover 4GB like on sparc right? A direct call reaches +-32MB, either relative or absolute; an indirect call can go anywhere. Actually, I remember there is some linkage register that has to be setup on powerpc with the code model you guys use, is that the problem? I think the problem is just that the compiler generates near calls (the 32MB thing) because of the code model used, but things don't necessarily end up this close by at run time. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] SBC8548: Add flash support and HW Rev reporting
The following adds local bus, flash and MTD partition nodes for
sbc8548. As well, a compatible field for the soc node, so that
of_platform_bus_probe() will pick it up.
Something that is provided through this newly added epld node
is the Hardware Revision is now being reported at bootup.
Signed-off-by: Jeremy McNicoll [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/sbc8548.dts | 94 +
arch/powerpc/platforms/85xx/sbc8548.c | 25 +
2 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8548.dts
b/arch/powerpc/boot/dts/sbc8548.dts
index b86e65d..dd9a061 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -52,6 +52,99 @@
reg = 0x 0x1000;
};
+ [EMAIL PROTECTED] {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = simple-bus;
+ reg = 0xe000 0x5000;
+ interrupt-parent = mpic;
+
+ ranges = 0x0 0x0 0xff80 0x0080 /*8MB Flash*/
+ 0x3 0x0 0xf000 0x0400 /*64MB SDRAM*/
+ 0x4 0x0 0xf400 0x0400 /*64MB SDRAM*/
+ 0x5 0x0 0xf800 0x00b1 /* EPLD */
+ 0x6 0x0 0xfb80 0x0400; /*64MB Flash*/
+
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x80;
+ bank-width = 1;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = space;
+ reg = 0x 0x0010;
+ };
+ [EMAIL PROTECTED] {
+ label = bootloader;
+ reg = 0x0010 0x0070;
+ read-only;
+ };
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = wrs,epld-localbus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0x5 0x0 0x00b1;
+ ranges =
+ 0x0 0x0 0x5 0x00 0x1fff /* LED */
+ 0x1 0x0 0x5 0x10 0x1fff /* Switches */
+ 0x3 0x0 0x5 0x30 0x1fff /* HW Rev. */
+ 0xb 0x0 0x5 0xb0 0x1fff /* EEPROM */
+ ;
+
+ [EMAIL PROTECTED],0 {
+ compatible = led;
+ reg = 0x0 0x0 0x1fff;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = switches;
+ reg = 0x1 0x0 0x1fff;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = hw-rev;
+ reg = 0x3 0x0 0x1fff;
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = eeprom;
+ reg = 0xb 0 0x1fff;
+ };
+
+ };
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x6 0x0 0x0400;
+ compatible = cfi-flash;
+ bank-width = 4;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = bootloader;
+ reg = 0x 0x0010;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = file-system;
+ reg = 0x0010 0x01f0;
+ };
+ [EMAIL PROTECTED] {
+ label = boot-config;
+ reg = 0x0200 0x0010;
+ };
+ [EMAIL PROTECTED] {
+ label = space;
+ reg = 0x0210 0x01f0;
+ };
+};
+};
+
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
@@ -59,6 +152,7 @@
ranges = 0x 0xe000 0x0010;
reg = 0xe000 0x1000; // CCSRBAR
bus-frequency = 0;
+ compatible = simple-bus;
[EMAIL PROTECTED] {
Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
What in libgcc references libc, and why isn't this a problem for Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs that use libgcc? The problem only occurs once you reference a function that references libc stuff, and those guys are just lucky so far. The only calls to the C library that GCC ever generates by itself (for freestanding mode, at least) are calls to memcmp, memcpy, memmove, memset (and abort, in some circumstances). This is true whether or not you link to libgcc. It's also one less variable to debug if you put the implementation in the kernel, or do you like debugging compiler induced problems? I don't :-) On the other hand, if we opt to re-implement, we have to make sure the in-kernel version of the GCC support routines is correct. We have to trust the compiler everywhere else already, why not here as well? Segher p.s. I just finished some testing linking a powerpc kernel with libgcc. All went fine, as expected. I also did a stupid test that actually needed a libgcc routine (__udivdi3); that went fine as well. And yeah, I know about the modules issue, but that isn't really very different from the analogue issue with in-kernel library routines. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: function calls from identify_cpu()
Benjamin Herrenschmidt wrote:
On Fri, 2008-05-02 at 13:42 -0700, Kevin Diggs wrote:
I added:
int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
{
return s-t;
}
right before the definition of identify_cpu() in cputable.c and:
// (void) (*PTRRELOC(iDoNothingUseful))(s,t);
(void) iDoNothingUseful(s,t);
right before the return s; in the match block and it will not boot? Can
someone please explain what might be going on?
Why are you trying to muck around with that code in the first
place ? :-)
What are you trying to achieve ?
Cheers,
Ben.
The original intent was to find a way to add some of the PLL parameters
(min and max core frequencies, min and max bus ratios - FX 400 - 800, 2
- 20; GX 500 - 1000, 2 - 20). Initially it seemed like the place to put
them. To avoid kernel bloat I think I'll just put them in the init
routine of the driver. I'll have to redo the cpu detection (FX vs GX);
but I guess that is not that big of a deal.
But now it is about retaining what is left of my sanity. I took the
above code and added it to a GigE running the same installation (the
8600 installation was created by installing its disk in the GigE) and it
ran fine!?! ANY suggestions would be greatly appreciated. Something to
do with BootX? BootX is to old (1.2.4)? System needs an exorcism? I
screwed up something in the 750GX cpu_spec entry?
Both are running 2.6.24.
kevin
P.S.: I would still appreciate it if someone could explain why this line:
*PTRRELOC(cur_cpu_spec) = the_cpu_spec;
isn't:
*PTRRELOC((cur_cpu_spec) = PTRRELOC(the_cpu_spec);
Is the address the_cpu_spec valid later in the kernel initialization?
Is it ... valid now?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
