* Re: [git pull] Please pull powerpc.git master branch
From: Kumar Gala @ 2008-05-02 6:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <18458.44292.817770.800636@cargo.ozlabs.ibm.com>
Paul,
Any plans to start applying some patches to powerpc-next (for .27)?
For example, your NAP patch? the devres_ioremap_prot patch.
- k
^ permalink raw reply
* [PATCH] powerpc ptrace block-step
From: Roland McGrath @ 2008-05-02 6:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
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 <roland@redhat.com>
---
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 */
^ permalink raw reply related
* [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala @ 2008-05-02 8:11 UTC (permalink / raw)
To: linuxppc-dev
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 <galak@kernel.crashing.org>
---
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 0000000..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 header word of the caller of the */
+/* function, just beyond the end of the integer restore area. */
+
+FUNC_START(_restgpr_14) lwz 14,-72(11) /* restore gp registers */
+FUNC_START(_restgpr_15) lwz 15,-68(11)
+FUNC_START(_restgpr_16) lwz 16,-64(11)
+FUNC_START(_restgpr_17) lwz 17,-60(11)
+FUNC_START(_restgpr_18) lwz 18,-56(11)
+FUNC_START(_restgpr_19) lwz 19,-52(11)
+FUNC_START(_restgpr_20) lwz 20,-48(11)
+FUNC_START(_restgpr_21) lwz 21,-44(11)
+FUNC_START(_restgpr_22) lwz 22,-40(11)
+FUNC_START(_restgpr_23) lwz 23,-36(11)
+FUNC_START(_restgpr_24) lwz 24,-32(11)
+FUNC_START(_restgpr_25) lwz 25,-28(11)
+FUNC_START(_restgpr_26) lwz 26,-24(11)
+FUNC_START(_restgpr_27) lwz 27,-20(11)
+FUNC_START(_restgpr_28) lwz 28,-16(11)
+FUNC_START(_restgpr_29) lwz 29,-12(11)
+FUNC_START(_restgpr_30) lwz 30,-8(11)
+FUNC_START(_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. */
+
+FUNC_START(_restgpr_14_x) lwz 14,-72(11) /* restore gp registers */
+FUNC_START(_restgpr_15_x) lwz 15,-68(11)
+FUNC_START(_restgpr_16_x) lwz 16,-64(11)
+FUNC_START(_restgpr_17_x) lwz 17,-60(11)
+FUNC_START(_restgpr_18_x) lwz 18,-56(11)
+FUNC_START(_restgpr_19_x) lwz 19,-52(11)
+FUNC_START(_restgpr_20_x) lwz 20,-48(11)
+FUNC_START(_restgpr_21_x) lwz 21,-44(11)
+FUNC_START(_restgpr_22_x) lwz 22,-40(11)
+FUNC_START(_restgpr_23_x) lwz 23,-36(11)
+FUNC_START(_restgpr_24_x) lwz 24,-32(11)
+FUNC_START(_restgpr_25_x) lwz 25,-28(11)
+FUNC_START(_restgpr_26_x) lwz 26,-24(11)
+FUNC_START(_restgpr_27_x) lwz 27,-20(11)
+FUNC_START(_restgpr_28_x) lwz 28,-16(11)
+FUNC_START(_restgpr_29_x) lwz 29,-12(11)
+FUNC_START(_restgpr_30_x) lwz 30,-8(11)
+FUNC_START(_restgpr_31_x) lwz 0,4(11)
+ lwz 31,-4(11)
+ mtlr 0
+ mr 1,11
+ blr
+#endif
--
1.5.4.1
^ permalink raw reply related
* Re: [POWERPC][v2] Bolt in SLB entry for kernel stack on secondary cpus
From: Paul Mackerras @ 2008-05-02 9:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080502055648.GA28378@yookeroo.seuss>
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.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Segher Boessenkool @ 2008-05-02 11:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0805020311310.28690@blarg.am.freescale.net>
> 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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Josh Boyer @ 2008-05-02 12:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0805020311310.28690@blarg.am.freescale.net>
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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala @ 2008-05-02 13:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <bfc75e2dc32ba86b93751cb21df97e56@kernel.crashing.org>
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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala @ 2008-05-02 13:32 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev
In-Reply-To: <1209730435.2946.160.camel@vader.jdub.homelinux.org>
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
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git master branch
From: Grant Likely @ 2008-05-02 13:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <18458.44292.817770.800636@cargo.ozlabs.ibm.com>
On Thu, May 1, 2008 at 11:56 PM, Paul Mackerras <paulus@samba.org> 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.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Segher Boessenkool @ 2008-05-02 13:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <BC3385F6-8403-446C-BC04-4DA811CFE96A@kernel.crashing.org>
>> 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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala @ 2008-05-02 13:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20862df61b024849f55dbd54de7cfb8f@kernel.crashing.org>
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
^ permalink raw reply
* Re: [patch 5/5] PS3: Update ps3_defconfig
From: Marvin @ 2008-05-02 13:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <4818F1E0.4010609@am.sony.com>
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 <geoffrey.levand@am.sony.com>
> ---
> 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
> [...]
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Josh Boyer @ 2008-05-02 13:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E55D097A-13D0-45BF-9AE8-E9741A0A869D@kernel.crashing.org>
On Fri, 2 May 2008 08:32:12 -0500
Kumar Gala <galak@kernel.crashing.org> 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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala @ 2008-05-02 13:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080502085304.1c58d995@zod.rchland.ibm.com>
On May 2, 2008, at 8:53 AM, Josh Boyer wrote:
> On Fri, 2 May 2008 08:32:12 -0500
> Kumar Gala <galak@kernel.crashing.org> 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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Kumar Gala @ 2008-05-02 14:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <bfc75e2dc32ba86b93751cb21df97e56@kernel.crashing.org>
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
^ permalink raw reply
* treeImage vs cuImage
From: Darcy Watkins @ 2008-05-02 14:14 UTC (permalink / raw)
To: LinuxPPC-Embedded
Hello,
I am upgrading my BSP to 2.6.25 and notice cuImage and treeImage. The
source files both say Old U-Boot compatibility.
Someone please educate me (or point me to a good URL that explains) as
to what the difference is.
I want to be able to load the kernel image using an older U-Boot and
currently use cuImage for 2.6.23 arch/powerpc (and plain uImage for
older kernels under arch/ppc).
Eventually, I want to generate both an old U-Boot compatible image and a
new U-boot compatible image.
I notice that some boards, the boot support is all in one file, in
others, it is split between cuboot-<board>.c and <board>.c. In the case
of ebony board, I see support for both cuImage and treeImage. Is the
strcuture into multiple files to ensure that ebony supports both of
these and new U-boot support as well?
I would like to make my BSP modules lean and clean enough to eventually
send back upstream to kernel.org.
Also, if there are common snags / pitfalls I need to watch out for
switching my BSP and DTS from 2.6.23 to 2.6.25, please warn me.
I am using AMCC PPC405EP processor.
Thanks in advance.
Regards,
Darcy
^ permalink raw reply
* Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jon Smirl @ 2008-05-02 14:23 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080219174221.5b18cba8@hyperion.delvare>
On 2/19/08, Jean Delvare <khali@linux-fr.org> 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
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Kumar Gala @ 2008-05-02 14:21 UTC (permalink / raw)
To: linuxppc-dev
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 <galak@kernel.crashing.org>
---
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 89aaaa6..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)
+ mtlr 0
+ 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);
+void _savegpr_15(void);
+void _savegpr_16(void);
+void _savegpr_17(void);
+void _savegpr_18(void);
+void _savegpr_19(void);
+void _savegpr_20(void);
+void _savegpr_21(void);
+void _savegpr_22(void);
+void _savegpr_23(void);
+void _savegpr_24(void);
+void _savegpr_25(void);
+void _savegpr_26(void);
+void _savegpr_27(void);
+void _savegpr_28(void);
+void _savegpr_29(void);
+void _savegpr_30(void);
+void _savegpr_31(void);
+void _restgpr_14(void);
+void _restgpr_15(void);
+void _restgpr_16(void);
+void _restgpr_17(void);
+void _restgpr_18(void);
+void _restgpr_19(void);
+void _restgpr_20(void);
+void _restgpr_21(void);
+void _restgpr_22(void);
+void _restgpr_23(void);
+void _restgpr_24(void);
+void _restgpr_25(void);
+void _restgpr_26(void);
+void _restgpr_27(void);
+void _restgpr_28(void);
+void _restgpr_29(void);
+void _restgpr_30(void);
+void _restgpr_31(void);
+void _restgpr_14_x(void);
+void _restgpr_15_x(void);
+void _restgpr_16_x(void);
+void _restgpr_17_x(void);
+void _restgpr_18_x(void);
+void _restgpr_19_x(void);
+void _restgpr_20_x(void);
+void _restgpr_21_x(void);
+void _restgpr_22_x(void);
+void _restgpr_23_x(void);
+void _restgpr_24_x(void);
+void _restgpr_25_x(void);
+void _restgpr_26_x(void);
+void _restgpr_27_x(void);
+void _restgpr_28_x(void);
+void _restgpr_29_x(void);
+void _restgpr_30_x(void);
+void _restgpr_31_x(void);
+EXPORT_SYMBOL(_savegpr_14);
+EXPORT_SYMBOL(_savegpr_15);
+EXPORT_SYMBOL(_savegpr_16);
+EXPORT_SYMBOL(_savegpr_17);
+EXPORT_SYMBOL(_savegpr_18);
+EXPORT_SYMBOL(_savegpr_19);
+EXPORT_SYMBOL(_savegpr_20);
+EXPORT_SYMBOL(_savegpr_21);
+EXPORT_SYMBOL(_savegpr_22);
+EXPORT_SYMBOL(_savegpr_23);
+EXPORT_SYMBOL(_savegpr_24);
+EXPORT_SYMBOL(_savegpr_25);
+EXPORT_SYMBOL(_savegpr_26);
+EXPORT_SYMBOL(_savegpr_27);
+EXPORT_SYMBOL(_savegpr_28);
+EXPORT_SYMBOL(_savegpr_29);
+EXPORT_SYMBOL(_savegpr_30);
+EXPORT_SYMBOL(_savegpr_31);
+EXPORT_SYMBOL(_restgpr_14);
+EXPORT_SYMBOL(_restgpr_15);
+EXPORT_SYMBOL(_restgpr_16);
+EXPORT_SYMBOL(_restgpr_17);
+EXPORT_SYMBOL(_restgpr_18);
+EXPORT_SYMBOL(_restgpr_19);
+EXPORT_SYMBOL(_restgpr_20);
+EXPORT_SYMBOL(_restgpr_21);
+EXPORT_SYMBOL(_restgpr_22);
+EXPORT_SYMBOL(_restgpr_23);
+EXPORT_SYMBOL(_restgpr_24);
+EXPORT_SYMBOL(_restgpr_25);
+EXPORT_SYMBOL(_restgpr_26);
+EXPORT_SYMBOL(_restgpr_27);
+EXPORT_SYMBOL(_restgpr_28);
+EXPORT_SYMBOL(_restgpr_29);
+EXPORT_SYMBOL(_restgpr_30);
+EXPORT_SYMBOL(_restgpr_31);
+EXPORT_SYMBOL(_restgpr_14_x);
+EXPORT_SYMBOL(_restgpr_15_x);
+EXPORT_SYMBOL(_restgpr_16_x);
+EXPORT_SYMBOL(_restgpr_17_x);
+EXPORT_SYMBOL(_restgpr_18_x);
+EXPORT_SYMBOL(_restgpr_19_x);
+EXPORT_SYMBOL(_restgpr_20_x);
+EXPORT_SYMBOL(_restgpr_21_x);
+EXPORT_SYMBOL(_restgpr_22_x);
+EXPORT_SYMBOL(_restgpr_23_x);
+EXPORT_SYMBOL(_restgpr_24_x);
+EXPORT_SYMBOL(_restgpr_25_x);
+EXPORT_SYMBOL(_restgpr_26_x);
+EXPORT_SYMBOL(_restgpr_27_x);
+EXPORT_SYMBOL(_restgpr_28_x);
+EXPORT_SYMBOL(_restgpr_29_x);
+EXPORT_SYMBOL(_restgpr_30_x);
+EXPORT_SYMBOL(_restgpr_31_x);
+#endif /* CONFIG_PPC32 && CONFIG_CC_OPTIMIZE_FOR_SIZE */
--
1.5.4.1
^ permalink raw reply related
* Re: treeImage vs cuImage
From: Josh Boyer @ 2008-05-02 14:29 UTC (permalink / raw)
To: Darcy Watkins; +Cc: LinuxPPC-Embedded
In-Reply-To: <D61182AC8012EA4EBC531B3AF23BE109583679@tranzeo-mail2.12stewart.tranzeo.com>
On Fri, 2008-05-02 at 07:14 -0700, Darcy Watkins wrote:
> Hello,
>
> I am upgrading my BSP to 2.6.25 and notice cuImage and treeImage. The
> source files both say Old U-Boot compatibility.
That's wrong. treeImage isn't for U-Boot. I should correct that
comment.
> Someone please educate me (or point me to a good URL that explains) as
> to what the difference is.
treeImage is for the older IBM 4xx eval boards that use the simple
OpenBIOS ROM monitor. Ebony, Walnut, etc typically came with this
firmware. cuImage is for boards using older U-Boot.
> I want to be able to load the kernel image using an older U-Boot and
> currently use cuImage for 2.6.23 arch/powerpc (and plain uImage for
> older kernels under arch/ppc).
You want cuImage then.
> Eventually, I want to generate both an old U-Boot compatible image and a
> new U-boot compatible image.
You'll get this by default when you build for cuImage. The cuImage will
contain the vmlinux and the dtb wrapped into a single file for use with
older U-Boots. You can just use the vmlinux itself and provide the dtb
separately for newer. (I think.)
> I notice that some boards, the boot support is all in one file, in
> others, it is split between cuboot-<board>.c and <board>.c. In the case
> of ebony board, I see support for both cuImage and treeImage. Is the
> strcuture into multiple files to ensure that ebony supports both of
> these and new U-boot support as well?
The boards that are split are for support with multiple different
firmwares, or because pieces of those can be shared with different
boards.
> I would like to make my BSP modules lean and clean enough to eventually
> send back upstream to kernel.org.
Great!
>
> Also, if there are common snags / pitfalls I need to watch out for
> switching my BSP and DTS from 2.6.23 to 2.6.25, please warn me.
>
> I am using AMCC PPC405EP processor.
405EP should be supported soon. I have a Taihu board, I just need to
port it. After that, you should be able to either reuse or mostly copy
it. But if you beat me to it, I won't complain at all :)
josh
^ permalink raw reply
* Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jean Delvare @ 2008-05-02 14:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <9e4733910805020723p7900c132j872893113f9d739e@mail.gmail.com>
Hi Jon,
On Fri, 2 May 2008 10:23:01 -0400, Jon Smirl wrote:
> On 2/19/08, Jean Delvare <khali@linux-fr.org> 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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Scott Wood @ 2008-05-02 15:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0805020920120.1141@blarg.am.freescale.net>
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
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git master branch
From: Linus Torvalds @ 2008-05-02 15:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <18458.44292.817770.800636@cargo.ozlabs.ibm.com>
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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Scott Wood @ 2008-05-02 15:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <68FE3962-84B3-4A5A-A64A-3FD1B7F6B4E3@kernel.crashing.org>
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
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Kumar Gala @ 2008-05-02 15:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080502150753.GA7753@ld0162-tx32.am.freescale.net>
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
^ permalink raw reply
* Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jon Smirl @ 2008-05-02 16:02 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080502164610.277ec04b@hyperion.delvare>
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
jonsmirl@gmail.com
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox