Re: [PATCH] [POWERPC] Fix a mm compile error
On Apr 2, 2008, at 6:05 PM, Emil Medve wrote: arch/powerpc/mm/init_32.c:102: error: conflicting types for '__initial_memory_limit_addr' arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of '__initial_memory_limit_addr' was here Signed-off-by: Emil Medve [EMAIL PROTECTED] --- arch/powerpc/mm/init_32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index 555bb7e..63c5e3d 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -99,7 +99,7 @@ unsigned long __max_low_memory = MAX_LOW_MEM; * address of the limit of what is accessible with initial MMU setup - * 256MB usually, but only 16MB on 601. */ -unsigned long __initial_memory_limit_addr = 0x1000; +phys_addr_t __initial_memory_limit_addr = 0x1000; I should have fixed this in my tree, if there are still issues let me know. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Update linker script to properly set physical addresses
We can set LOAD_OFFSET and use the AT attribute on sections and the
linker will properly set the physical address of the LOAD program
header for us.
This allows us to know how the PHYSICAL_START the user configured a
kernel with by just looking at the resulting vmlinux ELF.
This is pretty much stolen from how x86 does things in their linker
scripts.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Paul,
This patch is top of my existing series of mm init cleanup/rework.
- k
arch/powerpc/kernel/vmlinux.lds.S | 47 ++---
include/asm-powerpc/page.h|1 +
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index b5a76bc..0c3000b 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -31,7 +31,7 @@ SECTIONS
*/
/* Text and gots */
- .text : {
+ .text : AT(ADDR(.text) - LOAD_OFFSET) {
ALIGN_FUNCTION();
*(.text.head)
_text = .;
@@ -56,7 +56,7 @@ SECTIONS
RODATA
/* Exception bug tables */
- __ex_table : {
+ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
__start___ex_table = .;
*(__ex_table)
__stop___ex_table = .;
@@ -72,7 +72,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__init_begin = .;
- .init.text : {
+ .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
INIT_TEXT
_einittext = .;
@@ -81,11 +81,11 @@ SECTIONS
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
*/
- .exit.text : {
+ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
EXIT_TEXT
}
- .init.data : {
+ .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
INIT_DATA
__vtop_table_begin = .;
*(.vtop_fixup);
@@ -101,19 +101,19 @@ SECTIONS
}
. = ALIGN(16);
- .init.setup : {
+ .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
__setup_start = .;
*(.init.setup)
__setup_end = .;
}
- .initcall.init : {
+ .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
__initcall_start = .;
INITCALLS
__initcall_end = .;
}
- .con_initcall.init : {
+ .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
@@ -122,14 +122,14 @@ SECTIONS
SECURITY_INIT
. = ALIGN(8);
- __ftr_fixup : {
+ __ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
__start___ftr_fixup = .;
*(__ftr_fixup)
__stop___ftr_fixup = .;
}
#ifdef CONFIG_PPC64
. = ALIGN(8);
- __fw_ftr_fixup : {
+ __fw_ftr_fixup : AT(ADDR(__fw_ftr_fixup) - LOAD_OFFSET) {
__start___fw_ftr_fixup = .;
*(__fw_ftr_fixup)
__stop___fw_ftr_fixup = .;
@@ -137,14 +137,14 @@ SECTIONS
#endif
#ifdef CONFIG_BLK_DEV_INITRD
. = ALIGN(PAGE_SIZE);
- .init.ramfs : {
+ .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
}
#endif
. = ALIGN(PAGE_SIZE);
- .data.percpu : {
+ .data.percpu : AT(ADDR(.data.percpu) - LOAD_OFFSET) {
__per_cpu_start = .;
*(.data.percpu)
*(.data.percpu.shared_aligned)
@@ -152,7 +152,7 @@ SECTIONS
}
. = ALIGN(8);
- .machine.desc : {
+ .machine.desc : AT(ADDR(.machine.desc) - LOAD_OFFSET) {
__machine_desc_start = . ;
*(.machine.desc)
__machine_desc_end = . ;
@@ -170,25 +170,24 @@ SECTIONS
_sdata = .;
#ifdef CONFIG_PPC32
- .data:
- {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.sdata)
*(.got.plt) *(.got)
}
#else
- .data : {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.data.rel*)
*(.toc1)
*(.branch_lt)
}
- .opd : {
+ .opd : AT(ADDR(.opd) - LOAD_OFFSET) {
*(.opd)
}
- .got : {
+ .got : AT(ADDR(.got) - LOAD_OFFSET) {
__toc_start = .;
*(.got)
*(.toc)
@@ -205,26 +204,26 @@ SECTIONS
#else
. = ALIGN(16384);
#endif
- .data.init_task : {
+ .data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
*(.data.init_task)
}
Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
Kumar Gala writes: For a kdump kernel, at least for 64-bit, the physical address has to be 32MB. There is no other choice, so there is no possibility of confusion. But how do you know a vmlinux image is for kdump or not? By looking at the ELF headers -- either the first PT_LOAD segment or the .text section -- and seeing whether the start address is 0xc200 or not. For 85xx, would it be possible to have the kernel figure out what physical address it has been loaded at, and use that as the base address, rather than having the base address set at compile time? Yes, that is what CONFIG_RELOCATABLE is all about. Is there any reason to have that as an option, rather than just always doing that? That would solve my objection since it would mean that there would no longer be two things that had to be kept in sync. You could pass any value to wrapper/mkimage (subject to constraints such as it has to be a multiple of 256M) and it would work. That value could even come from a config option in the case where wrapper is invoked as part of the kernel build, but that config option shouldn't affect anything at all in the vmlinux. Ok, but I still think the issues exists when we config PHYSICAL_START to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys address the PHDR, but I'm not sure how to get the linker to do that. If we can do that then the wrapper script can dig it out and pass it to mkimage, which would solve the problem. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix CPM2 SCC1 clock initialization.
On Apr 2, 2008, at 9:46 AM, Laurent Pinchart wrote: A missing break statement in a switch caused cpm2_clk_setup() to initialize SCC2 instead of SCC1. This patch fixes the bug. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm2.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied. However your email is malformatted. Since it was a trivial patch I fixed it up by hand. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.25' branch [UPDATED]
Please pull from 'for-2.6.25' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25 to receive the following updates: (Added trivial cpm2 fix from Laurent) - k arch/powerpc/boot/dts/mpc8377_mds.dts |4 ++-- arch/powerpc/boot/dts/mpc8377_rdb.dts |3 +-- arch/powerpc/boot/dts/mpc8378_rdb.dts |3 +-- arch/powerpc/boot/dts/mpc8379_mds.dts |8 arch/powerpc/boot/dts/mpc8379_rdb.dts |3 +-- arch/powerpc/configs/mpc832x_mds_defconfig | 11 +++ arch/powerpc/configs/mpc834x_mds_defconfig | 11 +++ arch/powerpc/configs/mpc836x_mds_defconfig | 11 +++ arch/powerpc/configs/mpc837x_rdb_defconfig | 24 +++- arch/powerpc/configs/mpc83xx_defconfig | 24 +++- arch/powerpc/configs/mpc8544_ds_defconfig | 11 +++ arch/powerpc/configs/mpc8568mds_defconfig | 11 +++ arch/powerpc/configs/mpc8572_ds_defconfig | 11 +++ arch/powerpc/configs/mpc85xx_defconfig | 11 +++ arch/powerpc/configs/mpc8641_hpcn_defconfig | 11 +++ arch/powerpc/configs/prpmc2800_defconfig| 11 +++ arch/powerpc/configs/storcenter_defconfig | 11 +++ arch/powerpc/sysdev/cpm2.c |1 + drivers/ata/sata_fsl.c |5 + drivers/dma/fsldma.c|8 20 files changed, 91 insertions(+), 102 deletions(-) Anton Vorontsov (1): [POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts Kim Phillips (2): [POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs [POWERPC] sata_fsl: reduce compatibility to fsl,pq-sata Kumar Gala (2): [POWERPC] fsldma: Use compatiable binding as spec [POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB Laurent Pinchart (1): [POWERPC] Fix CPM2 SCC1 clock initialization. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
On Apr 3, 2008, at 1:34 AM, Paul Mackerras wrote: Kumar Gala writes: For a kdump kernel, at least for 64-bit, the physical address has to be 32MB. There is no other choice, so there is no possibility of confusion. But how do you know a vmlinux image is for kdump or not? By looking at the ELF headers -- either the first PT_LOAD segment or the .text section -- and seeing whether the start address is 0xc200 or not. fair point. For 85xx, would it be possible to have the kernel figure out what physical address it has been loaded at, and use that as the base address, rather than having the base address set at compile time? Yes, that is what CONFIG_RELOCATABLE is all about. Is there any reason to have that as an option, rather than just always doing that? Concerned about runtime performance of __va() and __pa(). That would solve my objection since it would mean that there would no longer be two things that had to be kept in sync. You could pass any value to wrapper/mkimage (subject to constraints such as it has to be a multiple of 256M) and it would work. That value could even come from a config option in the case where wrapper is invoked as part of the kernel build, but that config option shouldn't affect anything at all in the vmlinux. Ok, but I still think the issues exists when we config PHYSICAL_START to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys address the PHDR, but I'm not sure how to get the linker to do that. If we can do that then the wrapper script can dig it out and pass it to mkimage, which would solve the problem. Ok, so on Segher's recommendation I looked at 'AT' and posted a patch that uses that so now regardless of the kernel the PT_LOAD PHDR will have the physical address set properly. So now we can look at the vmlinux and determine the physical offset. The question is how best to do that. Here are the options I see: * readelf, grep and parse output * objdump grep and parse output * simple C program that read's the elf and reports back [looking for suggestion on what direction you want to take] The other questions is if we'd ever have a vmlinux with more than one PT_LOAD PHDR. If so which one do we use (the one with the lowest physical address)? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][PATCH] initial port of fixmap over from x86 for ppc32
Wanted to get any feedback on this initial port of the fixmap support over
from x86. There are a few TODOs:
* change HIGHMEM support to use fixmap
* fixup up VMALLOC config to respect fixmap
(after initial powerpc patch is in tree/accepted):
* rework a few bits of fixmap.h into an asm-generic/fixmap.h
The reason for introducing fixmap into ppc32 is it provides us with a
clean way of getting fixed compile time virtual addresses for things.
Beyond the HIGHMEM usage. Ben and I have discussed cleaning up the PCIe
44x config code (and 83xx PCIe cfg) to use it. Also, Dale's kexec/kdump
support on ppc32 can take advantage of it. I'm also told this is useful
for hypervisor interactions.
One question for the guys looking at hypervisor. The x86 code also has a
function called reserve_top_address (see arch/x86/mm/pgtable_32.c). Is
this functionality something useful on ppc? If so for what?
- k
---
arch/powerpc/mm/pgtable_32.c | 18 ++
include/asm-powerpc/fixmap.h | 123 ++
2 files changed, 141 insertions(+), 0 deletions(-)
create mode 100644 include/asm-powerpc/fixmap.h
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 64c44bc..fa0e48e 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -29,6 +29,7 @@
#include asm/pgtable.h
#include asm/pgalloc.h
+#include asm/fixmap.h
#include asm/io.h
#include mmu_decl.h
@@ -387,3 +388,20 @@ void kernel_map_pages(struct page *page, int numpages, int
enable)
change_page_attr(page, numpages, enable ? PAGE_KERNEL : __pgprot(0));
}
#endif /* CONFIG_DEBUG_PAGEALLOC */
+
+static int fixmaps;
+unsigned long __FIXADDR_TOP = 0xf000;
+EXPORT_SYMBOL(__FIXADDR_TOP);
+
+void __set_fixmap (enum fixed_addresses idx, phys_addr_t phys, pgprot_t flags)
+{
+ unsigned long address = __fix_to_virt(idx);
+
+ if (idx = __end_of_fixed_addresses) {
+ BUG();
+ return;
+ }
+
+ map_page(address, phys, flags);
+ fixmaps++;
+}
diff --git a/include/asm-powerpc/fixmap.h b/include/asm-powerpc/fixmap.h
new file mode 100644
index 000..7b570e5
--- /dev/null
+++ b/include/asm-powerpc/fixmap.h
@@ -0,0 +1,123 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ *
+ * Copyright 2008 Freescale Semiconductor Inc.
+ * Port to powerpc added by Kumar Gala
+ */
+
+#ifndef _ASM_FIXMAP_H
+#define _ASM_FIXMAP_H
+
+
+/* used by vmalloc.c, vsyscall.lds.S.
+ *
+ * Leave one empty page between vmalloc'ed areas and
+ * the start of the fixmap.
+ */
+extern unsigned long __FIXADDR_TOP;
+#define FIXADDR_USER_START __fix_to_virt(FIX_VDSO)
+#define FIXADDR_USER_END __fix_to_virt(FIX_VDSO - 1)
+
+#ifndef __ASSEMBLY__
+#include linux/kernel.h
+#include asm/page.h
+#ifdef CONFIG_HIGHMEM
+#include linux/threads.h
+#include asm/kmap_types.h
+#endif
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process. We allocate these special addresses
+ * from the end of virtual memory (0xf000) backwards.
+ * Also this lets us do fail-safe vmalloc(), we
+ * can guarantee that these special addresses and
+ * vmalloc()-ed addresses never overlap.
+ *
+ * these 'compile-time allocated' memory buffers are
+ * fixed-size 4k pages. (or larger if used with an increment
+ * highger than 1) use fixmap_set(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ * TLB entries of such buffers will not be flushed across
+ * task switches.
+ */
+enum fixed_addresses {
+ FIX_HOLE,
+ FIX_VDSO,
+#ifdef CONFIG_HIGHMEM
+ FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
+ FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
+#endif
+#ifdef CONFIG_PCI_MMCONFIG
+ FIX_PCIE_MCFG,
+#endif
+ __end_of_fixed_addresses
+};
+
+extern void __set_fixmap (enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL)
+/*
+ * Some hardware wants to get fixmapped without caching.
+ */
+#define set_fixmap_nocache(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
+
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, __pgprot(0))
+
+#define FIXADDR_TOP((unsigned long)__FIXADDR_TOP)
+
+#define __FIXADDR_SIZE (__end_of_fixed_addresses PAGE_SHIFT)
+#define __FIXADDR_BOOT_SIZE(__end_of_fixed_addresses PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
+#define FIXADDR_BOOT_START
Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc
On Fri, 2008-02-01 at 12:50 -0700, Dale Farnsworth wrote: This adds the low level irq tracing hooks for 32-bit powerpc. This patch applies on top of Benjamin Herrenschmidt's patch that provides similar support for 64-bit powerpc. See http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044361.html It seems to work on my prpmc2800 board with a ppc7447. At first it appears to work on my powerbook (with Ben's latest version of the 64-bit patch), but then it seems to cause random corruption, I've had a crash in the ext3 code and one in console_callback(), both of which I cannot otherwise explain. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk time confusion?
On Wed, 2008-04-02 at 16:23 +0200, Johannes Berg wrote:
Hi,
Not sure whether the lockdep patches or something else is causing this
as I haven't checked w/o the patches yet, but I seem to be having some
confusion of printk timestamps:
Tried reverting the patches ?
[...]
[ 176.440255] iwl4965: No space for Tx
[...]
[ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/2
[...]
[ 173.589209] BUG kmalloc-2048: Poison overwritten
[...]
[ 208.385226] ioctl32(gnome-terminal:6498): Unknown cmd fd(29)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/6
[...]
[ 139.026724] ioctl32(gnome-terminal:6521): Unknown cmd fd(30)
cmd(530b){t:'S';sz:0} arg(0fd7bbe8) on /dev/pts/7
[...]
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
[...]
[ 218.918388] tg3: eth0: Link is down.
[...]
Yes, these entries really were printed in that order. Btw, what's with
the unknown ioctls?
Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
the pty stuff to find out which ones it is and if it can be a problem...
Kernel version is 2.6.25-rc8-wl-04519-g6648ff7-dirty where -wl/-dirty
refers to wireless patches and the lockdep patches and otherwise it's
just -rc8.
johannes
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2] powerpc: Describe memory-mapped RAMROM chips OF bindings
On Tuesday 01 April 2008 15:16, Grant Likely wrote: On Mon, Mar 31, 2008 at 10:39 AM, Laurent Pinchart [EMAIL PROTECTED] wrote: Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- Documentation/powerpc/booting-without-of.txt | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 7b4e8a7..3e1963b 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -57,7 +57,8 @@ Table of Contents n) 4xx/Axon EMAC ethernet nodes o) Xilinx IP cores p) Freescale Synchronous Serial Interface - q) USB EHCI controllers + q) USB EHCI controllers + r) Memory-mapped RAM ROM VII - Specifying interrupt information for devices 1) interrupts property @@ -2816,6 +2817,16 @@ platforms are moved over to use the flattened-device-tree model. big-endian; }; + r) Memory-mapped RAM ROM + +Dedicated RAM and ROM chips are often used as storage for temporary or +permanent data in embedded devices. Possible usage include non-volatile +storage in battery-backed SRAM, semi-permanent storage in dedicated SRAM +to preserve data accross reboots and firmware storage in dedicated ROM. + + - name : should be either ram or rom + - reg : Address range of the RAM/ROM chip + No compatible prop? How does the OS know what the node is to be used for? If I understood Sergei's arguments properly, the device tree should describe device properties and not their intended usage. With generic devices such as RAM chips, platform code is responsible for binding the device to the appropriate driver (mtd-ram for instance). Cheers, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
printk time confusion?
Hi,
Not sure whether the lockdep patches or something else is causing this
as I haven't checked w/o the patches yet, but I seem to be having some
confusion of printk timestamps:
[...]
[ 176.440255] iwl4965: No space for Tx
[...]
[ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/2
[...]
[ 173.589209] BUG kmalloc-2048: Poison overwritten
[...]
[ 208.385226] ioctl32(gnome-terminal:6498): Unknown cmd fd(29)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/6
[...]
[ 139.026724] ioctl32(gnome-terminal:6521): Unknown cmd fd(30)
cmd(530b){t:'S';sz:0} arg(0fd7bbe8) on /dev/pts/7
[...]
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
[...]
[ 218.918388] tg3: eth0: Link is down.
[...]
Yes, these entries really were printed in that order. Btw, what's with
the unknown ioctls?
Kernel version is 2.6.25-rc8-wl-04519-g6648ff7-dirty where -wl/-dirty
refers to wireless patches and the lockdep patches and otherwise it's
just -rc8.
johannes
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
Haven't tested this version on G5 yet btw :-) (though I had a previous one working internally). I tested on POWER6 pSeries and old iSeries (spent a while fixing the later). I'll run more tests tomorrow hopefully and add a few patch fixing some of the issues that lockdep already starting showing. Works fine, and on my box I don't see lockdep showing issues. Thanks for picking this up from me and rewriting it :) johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [POWERPC] Implement support for the GPIO LIB API
Hi Anton,
On Tuesday 11 March 2008 19:42, Anton Vorontsov wrote:
This patch implements support for the GPIO LIB API. Two calls
unimplemented though: irq_to_gpio and gpio_to_irq.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 52
arch/powerpc/Kconfig |5 ++
include/asm-powerpc/gpio.h | 55
++
3 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 include/asm-powerpc/gpio.h
[snip]
diff --git a/include/asm-powerpc/gpio.h b/include/asm-powerpc/gpio.h
new file mode 100644
index 000..057840d
--- /dev/null
+++ b/include/asm-powerpc/gpio.h
@@ -0,0 +1,55 @@
+/*
+ * Generic GPIO API implementation for PowerPC.
+ *
+ * Copyright (c) 2007-2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * 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.
+ */
+
+#ifndef __ASM_POWERPC_GPIO_H
+#define __ASM_POWERPC_GPIO_H
+
+#include asm-generic/gpio.h
+
+#ifdef CONFIG_HAVE_GPIO_LIB
+
+/*
+ * We don't (yet) implement inlined/rapid versions for on-chip gpios.
+ * Just call gpiolib.
+ */
+static inline int gpio_get_value(unsigned int gpio)
+{
+ return __gpio_get_value(gpio);
+}
+
+static inline void gpio_set_value(unsigned int gpio, int value)
+{
+ __gpio_set_value(gpio, value);
+}
+
+static inline int gpio_cansleep(unsigned int gpio)
+{
+ return __gpio_cansleep(gpio);
+}
+
+/*
+ * Not implemented, yet.
+ */
+static inline int gpio_to_irq(unsigned int gpio)
+{
+ return -ENOSYS;
+}
+
+static inline int irq_to_gpio(unsigned int irq)
+{
+ return -EINVAL;
+}
You should include linux/errno.h.
+#endif /* CONFIG_HAVE_GPIO_LIB */
+
+#endif /* __ASM_POWERPC_GPIO_H */
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpb1UTnwjiuN.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: make mem_map allocation continuous v2.
Yinghai Lu wrote: On Wed, Apr 2, 2008 at 7:22 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu [EMAIL PROTECTED] wrote: v2 replace: [PATCH] mm: make mem_map allocation continuous. [PATCH] mm: allocate section_map for sparse_init [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init err, no. diff --git a/mm/sparse.c b/mm/sparse.c index f6a43c0..2881222 100644 --- a/mm/sparse.c +++ b/mm/sparse.c Sorry, but I'd rather not do it this way. We presently have this: it replaces mm-make-mem_map-allocation-continuous.patch mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch mm-allocate-section_map-for-sparse_init.patch mm-allocate-section_map-for-sparse_init-update.patch mm-allocate-section_map-for-sparse_init-update-fix.patch mm-allocate-section_map-for-sparse_init-powerpc-fix.patch others still needed so mm-make-mem-map-allocation-continuous.patch will not break powerpc and ia64 YH Hi, Thanks, the patch fixes the issue. I am able to bootup without the kernel panic. Tested-by: Kamalesh Babulal [EMAIL PROTECTED] -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk time confusion?
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Wed, 2008-04-02 at 16:23 +0200, Johannes Berg wrote:
[...]
[ 176.440255] iwl4965: No space for Tx
[...]
[ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/2
[...]
[ 173.589209] BUG kmalloc-2048: Poison overwritten
[...]
[ 208.385226] ioctl32(gnome-terminal:6498): Unknown cmd fd(29)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/6
[...]
[ 139.026724] ioctl32(gnome-terminal:6521): Unknown cmd fd(30)
cmd(530b){t:'S';sz:0} arg(0fd7bbe8) on /dev/pts/7
[...]
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
[...]
[ 218.918388] tg3: eth0: Link is down.
[...]
Yes, these entries really were printed in that order. Btw, what's with
the unknown ioctls?
Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
the pty stuff to find out which ones it is and if it can be a problem...
0x53xx is claimed by cdrom.h, and 0x530b is CDROMSUBCHNL. Of course, a
tty does not implement cdrom ioctls.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk time confusion?
Not sure whether the lockdep patches or something else is causing this
as I haven't checked w/o the patches yet, but I seem to be having some
confusion of printk timestamps:
Tried reverting the patches ?
No, not yet, I'll do that later today.
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
Yes, these entries really were printed in that order. Btw, what's with
the unknown ioctls?
Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
the pty stuff to find out which ones it is and if it can be a problem...
Yeah, I'll have to see, I just thought Arnd might already know :)
johannes
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk time confusion?
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
the pty stuff to find out which ones it is and if it can be a problem...
0x53xx is claimed by cdrom.h, and 0x530b is CDROMSUBCHNL. Of course, a
tty does not implement cdrom ioctls.
Humm ok, then the first question is why gnome-terminal tries that, and
the second why it would printk something?
johannes
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
Hi Jochen,
On Tuesday 25 March 2008 17:56, Jochen Friedrich wrote:
Implement GPIO LIB API on CPM1 Freescale SoC.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
This is based on the series starting at
http://patchwork.ozlabs.org/linuxppc/patch?id=17299
arch/powerpc/platforms/8xx/Kconfig |2 +
arch/powerpc/sysdev/cpm1.c | 240
+++-
2 files changed, 241 insertions(+), 1 deletions(-)
[snip]
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index df8bd2b..c3d5df8 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -30,11 +30,14 @@
#include linux/interrupt.h
#include linux/irq.h
#include linux/module.h
+#include linux/spinlock.h
+#include linux/of_gpio.h
#include asm/page.h
#include asm/pgtable.h
#include asm/8xx_immap.h
#include asm/cpm1.h
#include asm/io.h
+#include asm/gpio.h
#include asm/tlbflush.h
#include asm/rheap.h
#include asm/prom.h
@@ -403,7 +406,7 @@ struct cpm_ioport16 {
};
struct cpm_ioport32 {
- __be32 dir, par, sor;
+ __be32 dir, par, sor, dat;
};
I haven't checked all CPM1-based parts, but for the MPC855 family this doesn't
look right. The MPC855 has two 32-bit ports, port B and port E. Registers for
port B are dir, par, odr and dat, and registers for port E are dir, par, sor,
odr and dat.
Are you working on a similar patch for the CPM2 ? CPM2 I/O ports are 32 bit
wide and their registers are layed out like for port E on the MPC855. It
should thus be possible to share code between CPM1 and CPM2.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
pgpQVIjXN1RUr.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk time confusion?
Johannes Berg [EMAIL PROTECTED] writes:
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31)
cmd(530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
the pty stuff to find out which ones it is and if it can be a problem...
0x53xx is claimed by cdrom.h, and 0x530b is CDROMSUBCHNL. Of course, a
tty does not implement cdrom ioctls.
Humm ok, then the first question is why gnome-terminal tries that
Perhaps some misconfiguration, I can't reproduce that here (with
2.18.2).
and the second why it would printk something?
To ease finding missing compat ioctl handlers.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
the divided by 8 value for the bitmask.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/mal.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index 6869f08..fb9c9eb 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -136,6 +136,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int
channel)
{
unsigned long flags;
+ /*
+* On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+* of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+* for the bitmask
+*/
+ if (!(channel % 8))
+ channel = 3;
+
spin_lock_irqsave(mal-lock, flags);
MAL_DBG(mal, enable_rx(%d) NL, channel);
@@ -148,6 +156,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int
channel)
void mal_disable_rx_channel(struct mal_instance *mal, int channel)
{
+ /*
+* On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+* of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+* for the bitmask
+*/
+ if (!(channel % 8))
+ channel = 3;
+
set_mal_dcrn(mal, MAL_RXCARR, MAL_CHAN_MASK(channel));
MAL_DBG(mal, disable_rx(%d) NL, channel);
--
1.5.4.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get some more bug fixes for powerpc, mostly for various embedded platforms. The bulk of the changes are once again in the defconfigs. Thanks, Paul. arch/powerpc/boot/dts/cm5200.dts| 37 +++- arch/powerpc/boot/dts/lite5200.dts | 15 ++ arch/powerpc/boot/dts/motionpro.dts | 63 +++ arch/powerpc/boot/dts/mpc8377_mds.dts |4 +- arch/powerpc/boot/dts/mpc8377_rdb.dts |3 - arch/powerpc/boot/dts/mpc8378_rdb.dts |3 - arch/powerpc/boot/dts/mpc8379_mds.dts |8 ++- arch/powerpc/boot/dts/mpc8379_rdb.dts |3 - arch/powerpc/boot/dts/tqm5200.dts | 42 ++ arch/powerpc/configs/mpc832x_mds_defconfig | 11 + arch/powerpc/configs/mpc834x_mds_defconfig | 11 + arch/powerpc/configs/mpc836x_mds_defconfig | 11 + arch/powerpc/configs/mpc837x_rdb_defconfig | 24 ++ arch/powerpc/configs/mpc83xx_defconfig | 24 ++ arch/powerpc/configs/mpc8544_ds_defconfig | 11 + arch/powerpc/configs/mpc8568mds_defconfig | 11 + arch/powerpc/configs/mpc8572_ds_defconfig | 11 + arch/powerpc/configs/mpc85xx_defconfig | 11 + arch/powerpc/configs/mpc8641_hpcn_defconfig | 11 + arch/powerpc/configs/prpmc2800_defconfig| 11 + arch/powerpc/configs/storcenter_defconfig | 11 + arch/powerpc/kernel/head_64.S | 13 +++--- arch/powerpc/kernel/irq.c |1 arch/powerpc/kernel/rtas_flash.c|2 - arch/powerpc/mm/hash_low_32.S |8 +++ arch/powerpc/sysdev/cpm2.c |1 drivers/ata/sata_fsl.c |5 -- drivers/dma/fsldma.c|8 ++- drivers/net/fec_mpc52xx.c |1 drivers/net/fec_mpc52xx_phy.c |1 30 files changed, 234 insertions(+), 142 deletions(-) commit 8d813941b17626a7610342325be63435282bac02 Author: René Bürgel [EMAIL PROTECTED] Date: Thu Apr 3 19:58:37 2008 +1100 [POWERPC] Fix MPC5200 (not B!) device tree so FEC ethernet works This gets the FEC ethernet driver working again on the lite5200 platform. The FEC driver is also compatible with the MPC5200, not only with the MPC5200B, so this adds a suitable entry to the driver's match list. Furthermore this adds the settings for the PHY in the dts file for the Lite5200. Note, that this is not exactly the same as in the Lite5200B, because the PHY is located at f0003000:01 for the 5200, and at :00 for the 5200B. This was tested on a Lite5200 and a Lite5200B, both booted a kernel via tftp and mounted the root via nfs successfully. Signed-off-by: René Bürgel [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Paul Mackerras [EMAIL PROTECTED] commit 115e1adca3b75a82f24da8b2cc9386eb5b7e2cff Author: Bartlomiej Sieka [EMAIL PROTECTED] Date: Thu Apr 3 01:26:02 2008 +1100 [POWERPC] mpc5200: Amalgamated DTS fixes and updates DTS updates that fix booting problems on mpc5200-based boards: - change to ethernet reg property - addition of mdio and phy nodes - removal of pci node (Motion-Pro board) Other DTS updates: - update i2c device tree nodes - add lpb bus node and flash device (without partitions defined) - add rtc i2c nodes Signed-off-by: Marian Balakowicz [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Paul Mackerras [EMAIL PROTECTED] commit 7484839850d826e14b8b024bb048dca8489140ae Author: Maxim Shchetynin [EMAIL PROTECTED] Date: Wed Apr 2 00:12:20 2008 +1100 [POWERPC] Fix rtas_flash procfs interface Handling of the proc_dir_entry-count was changed in 2.6.24-rc5. After this change, the default value for pde-count is 1 and not 0 as before. Therefore, if we want to check whether our procfs file is already opened (already in use), we have to check if pde-count is greater than 2 rather than 1. Signed-off-by: Maxim Shchetynin [EMAIL PROTECTED] Signed-off-by: Jens Osterkamp [EMAIL PROTECTED] Signed-off-by: Paul Mackerras [EMAIL PROTECTED] commit b991f05f1326fd9e6212851d0f2099875906dd16 Author: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Mon Mar 31 07:49:27 2008 +1100 [POWERPC] Fix deadlock with mmu_hash_lock in hash_page_sync hash_page_sync() takes and releases the low level mmu hash lock in order to sync with other processors disposing of page tables. Because that lock can be needed to service hash misses triggered by interrupt handlers, taking it must be done with interrupts off. However, hash_page_sync() appears to be called with interrupts enabled, thus causing occasional deadlocks. We fix it by
Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
Hello. Stephen Neuendorffer wrote: I don't think big-endian has the same context as reg-shift/reg-offset. The big-endian is about how the byte addresses are laid out, so the context is the same -- in this case, it would determine where each UART register is located within the address stride specified by reg-shift. It'll alwaay be at offset 0 or (2 reg-shift) - 1 (unless some vendor goes and implements something with middle-endian layout of course :-) The OpenPOC is fundamentally a 32 bit device, but ns16550 is not... If So what? we were talking about a 32 bit device, then I'd probably agree with you, There are 16550 clones that *are* 32-bit. but in this case, the reg-shift I'm not arguing about reg-shift already -- look like it's been spec'ed. :-) (and to some extent) reg-offset have been used before and probably make more sense, I think. The reg-offset has been used before? Where? Steve WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [POWERPC] Implement support for the GPIO LIB API
On Thu, Apr 03, 2008 at 01:05:51PM +0200, Laurent Pinchart wrote:
Hi Anton,
On Tuesday 11 March 2008 19:42, Anton Vorontsov wrote:
This patch implements support for the GPIO LIB API. Two calls
unimplemented though: irq_to_gpio and gpio_to_irq.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 52
arch/powerpc/Kconfig |5 ++
include/asm-powerpc/gpio.h | 55
++
3 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 include/asm-powerpc/gpio.h
[snip]
diff --git a/include/asm-powerpc/gpio.h b/include/asm-powerpc/gpio.h
new file mode 100644
index 000..057840d
--- /dev/null
+++ b/include/asm-powerpc/gpio.h
@@ -0,0 +1,55 @@
+/*
+ * Generic GPIO API implementation for PowerPC.
+ *
+ * Copyright (c) 2007-2008 MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * 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.
+ */
+
+#ifndef __ASM_POWERPC_GPIO_H
+#define __ASM_POWERPC_GPIO_H
+
+#include asm-generic/gpio.h
+
+#ifdef CONFIG_HAVE_GPIO_LIB
+
+/*
+ * We don't (yet) implement inlined/rapid versions for on-chip gpios.
+ * Just call gpiolib.
+ */
+static inline int gpio_get_value(unsigned int gpio)
+{
+ return __gpio_get_value(gpio);
+}
+
+static inline void gpio_set_value(unsigned int gpio, int value)
+{
+ __gpio_set_value(gpio, value);
+}
+
+static inline int gpio_cansleep(unsigned int gpio)
+{
+ return __gpio_cansleep(gpio);
+}
+
+/*
+ * Not implemented, yet.
+ */
+static inline int gpio_to_irq(unsigned int gpio)
+{
+ return -ENOSYS;
+}
+
+static inline int irq_to_gpio(unsigned int irq)
+{
+ return -EINVAL;
+}
You should include linux/errno.h.
Yeah, much thanks for catching this!
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
On Thu, 2008-04-03 at 13:45 +0200, Stefan Roese wrote:
On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
the divided by 8 value for the bitmask.
Sounds ok, but I wonder if we ever have a MAL with more than 8 chans, do
we need to make this shift conditional to some device tree prop ?
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/mal.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index 6869f08..fb9c9eb 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -136,6 +136,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int
channel)
{
unsigned long flags;
+ /*
+ * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+ * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+ * for the bitmask
+ */
+ if (!(channel % 8))
+ channel = 3;
+
spin_lock_irqsave(mal-lock, flags);
MAL_DBG(mal, enable_rx(%d) NL, channel);
@@ -148,6 +156,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int
channel)
void mal_disable_rx_channel(struct mal_instance *mal, int channel)
{
+ /*
+ * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+ * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+ * for the bitmask
+ */
+ if (!(channel % 8))
+ channel = 3;
+
set_mal_dcrn(mal, MAL_RXCARR, MAL_CHAN_MASK(channel));
MAL_DBG(mal, disable_rx(%d) NL, channel);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
Hi Laurent, I haven't checked all CPM1-based parts, but for the MPC855 family this doesn't look right. The MPC855 has two 32-bit ports, port B and port E. Registers for port B are dir, par, odr and dat, and registers for port E are dir, par, sor, odr and dat. You probably mean MPC885. Thanks for catching this, the 32bit registers really are a mess on CPM1 platforms. Are you working on a similar patch for the CPM2 ? CPM2 I/O ports are 32 bit wide and their registers are layed out like for port E on the MPC855. It should thus be possible to share code between CPM1 and CPM2. Yes, some common port setup code could probably be moved to cpm.c. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
On Thu, 2008-04-03 at 14:35 +0200, Stefan Roese wrote: On Thursday 03 April 2008, Benjamin Herrenschmidt wrote: On Thu, 2008-04-03 at 13:45 +0200, Stefan Roese wrote: On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs the divided by 8 value for the bitmask. Sounds ok, but I wonder if we ever have a MAL with more than 8 chans, do we need to make this shift conditional to some device tree prop ? I suggest we postpone such a conditional setup until we see such a MAL. OK? Agreed. I got a bit carried away.. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
Hi Johann,
You're right about it being missing. I have another patch for virtex
specific initialization that handles that. I have not submitted it yet
as I was trying to get these patches thru the system.
I have been told in this forum that the bootstrap loader should not be
setting up the baud rate and that normally the boot loader does it.
In the case of FPGAs, we don't always use a boot loader so we need this
to happen in the bootstrap loader. I can forward that patch to you if
you're interested before it goes to this group.
Thanks,
John
From: Johann Baudy [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 7:23 AM
To: John Linn
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx
uart 16550.
Hi John,
I've a small question about ns16550 boot support.
I can't see any code related to either clock-frequency or
current-speed key words.
Such actions are performed in of_serial.c to get appropriate baud rate
(update of UART_DLL and UART_DLM).
Is it needed or is it a misunderstanding?
Personally, I have added this below debug code (dirty :)) to make it
work.
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..850e223 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -26,6 +26,9 @@
#define UART_MSR6/* In: Modem Status Register */
#define UART_SCR7/* I/O: Scratch Register */
+#define UART_LCR_DLAB 0x80 /* Divisor latch access */
+#define UART_LCR_8_DATA_BITS 0x03
+
static unsigned char *reg_base;
static u32 reg_shift;
@@ -56,6 +59,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ unsigned long divisor=0;
+ unsigned long spd=0, clk=0;
+
+
n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -75,5 +82,23 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
scdp-tstc = ns16550_tstc;
scdp-close = NULL;
+n = getprop(devp, current-speed, spd, sizeof(spd));
+
+
+n = getprop(devp, clock-frequency, clk, sizeof(clk));
+
+
+ if(spdclk)
+ {
+
+ divisor = clk / (spd * 16UL);
+
+ out_8(reg_base + (UART_FCR reg_shift), 0x06);
+ out_8(reg_base + (UART_LCR reg_shift),
UART_LCR_8_DATA_BITS|UART_LCR_DLAB);
+ out_8(reg_base + (UART_DLL reg_shift), divisor0xff);
+ out_8(reg_base + (UART_DLM reg_shift), (divisor8)0xff);
+ out_8(reg_base + (UART_LCR reg_shift), UART_LCR_8_DATA_BITS);
+
+ }
return 0;
Best regards,
Johann
On Wed, Apr 2, 2008 at 4:52 PM, John Linn [EMAIL PROTECTED] wrote:
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based adressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the ns16550 driver to use the reg-offset property
so that the Xilinx UART 16550 can be used with it. The reg-shift
was already being handled.
Signed-off-by: John Linn [EMAIL PROTECTED]
---
arch/powerpc/boot/ns16550.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..da9d2c2 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ u32 reg_offset;
n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
+ n = getprop(devp, reg-offset, reg_offset,
sizeof(reg_offset));
+ if (n == sizeof(reg_offset))
+ reg_base += reg_offset;
+
n = getprop(devp, reg-shift, reg_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
--
1.5.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Johann Baudy
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
Thanks Arnd, I apologize for not keeping you in the loop on this. I'm still learning the process and appreciate your help and patience. Thanks to all for the work to get consensus on this, John -Original Message- From: Arnd Bergmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 10:16 PM To: linuxppc-dev@ozlabs.org Cc: Grant Likely; John Linn; Segher Boessenkool; Josh Boyer Subject: Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550. On Thursday 03 April 2008, Grant Likely wrote: Since it is not really compatible with ns16550, shouldn't you at least specify a different compatible property? That way, the driver won't do incorrect accesses when you try to use an old driver with a device tree that specifies one of these. Heh; we've gone back and forth on this issue. The problem is that we have a common case of ns16550 like devices that require a little bit of register address tweaking that spans a whole range of vendors (so adding a compatible match with each of those vendor's prefixes is probably non-scalable). So, if ns16550 is not a good idea, then what should be used? sparse16550 has been suggested more than once. After another IRC discussion between Grant, Segher and myself, we concluded that we don't need to invent a new compatible value, as only new device trees with old kernels will have a problem with this, and they don't work in the first place. The devices will still have their specific compatible value, e.g. xlnx,plb-uart16550-1.00.c, followed by ns16550, and possibly ns16450 and i8250, although the last two do not have an effect on Linux. Josh, can you please forward all three patches in their latest version? Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
Hi John,
I've a small question about ns16550 boot support.
I can't see any code related to either clock-frequency or current-speed
key words.
Such actions are performed in of_serial.c to get appropriate baud rate
(update of UART_DLL and UART_DLM).
Is it needed or is it a misunderstanding?
Personally, I have added this below debug code (dirty :)) to make it work.
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..850e223 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -26,6 +26,9 @@
#define UART_MSR6/* In: Modem Status Register */
#define UART_SCR7/* I/O: Scratch Register */
+#define UART_LCR_DLAB 0x80 /* Divisor latch access */
+#define UART_LCR_8_DATA_BITS 0x03
+
static unsigned char *reg_base;
static u32 reg_shift;
@@ -56,6 +59,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ unsigned long divisor=0;
+ unsigned long spd=0, clk=0;
+
+
n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -75,5 +82,23 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
scdp-tstc = ns16550_tstc;
scdp-close = NULL;
+n = getprop(devp, current-speed, spd, sizeof(spd));
+
+
+n = getprop(devp, clock-frequency, clk, sizeof(clk));
+
+
+ if(spdclk)
+ {
+
+ divisor = clk / (spd * 16UL);
+
+ out_8(reg_base + (UART_FCR reg_shift), 0x06);
+ out_8(reg_base + (UART_LCR reg_shift),
UART_LCR_8_DATA_BITS|UART_LCR_DLAB);
+ out_8(reg_base + (UART_DLL reg_shift), divisor0xff);
+ out_8(reg_base + (UART_DLM reg_shift), (divisor8)0xff);
+ out_8(reg_base + (UART_LCR reg_shift), UART_LCR_8_DATA_BITS);
+
+ }
return 0;
Best regards,
Johann
On Wed, Apr 2, 2008 at 4:52 PM, John Linn [EMAIL PROTECTED] wrote:
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based adressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the ns16550 driver to use the reg-offset property
so that the Xilinx UART 16550 can be used with it. The reg-shift
was already being handled.
Signed-off-by: John Linn [EMAIL PROTECTED]
---
arch/powerpc/boot/ns16550.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..da9d2c2 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ u32 reg_offset;
n = getprop(devp, virtual-reg, reg_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
+ n = getprop(devp, reg-offset, reg_offset, sizeof(reg_offset));
+ if (n == sizeof(reg_offset))
+ reg_base += reg_offset;
+
n = getprop(devp, reg-shift, reg_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
--
1.5.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Johann Baudy
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 4xx: Some EMAC related changes in Canyonlands Glacier dts files
This patch fixes some problems in the Canyonlands 460EX and Glacier 460GT
dts files:
- Add mdio-device = EMAC0 to all all EMAC's except for EMAC0 itself
(the 460EX/GT only can access the PHY via the EMAC0 instance)
- Add TAH support to Canyonlands dts
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/canyonlands.dts | 19 +++
arch/powerpc/boot/dts/glacier.dts |5 -
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 657f2b4..6f3d38a 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -215,6 +215,16 @@
has-mdio;
};
+ TAH0: [EMAIL PROTECTED] {
+ compatible = ibm,tah-460ex, ibm,tah;
+ reg = ef601350 30;
+ };
+
+ TAH1: [EMAIL PROTECTED] {
+ compatible = ibm,tah-460ex, ibm,tah;
+ reg = ef601450 30;
+ };
+
EMAC0: [EMAIL PROTECTED] {
device_type = network;
compatible = ibm,emac-460ex, ibm,emac4;
@@ -236,10 +246,10 @@
tx-fifo-size = 800;
phy-mode = rgmii;
phy-map = ;
- zmii-device = ZMII0;
- zmii-channel = 0;
rgmii-device = RGMII0;
rgmii-channel = 0;
+ tah-device = TAH0;
+ tah-channel = 0;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
@@ -265,12 +275,13 @@
tx-fifo-size = 800;
phy-mode = rgmii;
phy-map = ;
- zmii-device = ZMII0;
- zmii-channel = 1;
rgmii-device = RGMII0;
rgmii-channel = 1;
+ tah-device = TAH1;
+ tah-channel = 1;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = EMAC0;
};
};
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index 7a7c9bf..958a5ca 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -287,9 +287,10 @@
rgmii-device = RGMII0;
rgmii-channel = 1;
tah-device = TAH1;
- tah-channel = 0;
+ tah-channel = 1;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = EMAC0;
};
EMAC2: [EMAIL PROTECTED] {
@@ -317,6 +318,7 @@
rgmii-channel = 0;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = EMAC0;
};
EMAC3: [EMAIL PROTECTED] {
@@ -344,6 +346,7 @@
rgmii-channel = 1;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = EMAC0;
};
};
--
1.5.4.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
interrupt latency spi
hi all of you , I am wndering if someone has already done test for interrupt latency on linx 2.6.23 mpc5200b. I am working on writing a driver which is get SPi involved on design, and I know that the spi interrupt will occurs at every 2 us ( speed 4 MHz interupt occurs when It recieves on bytes) so I am worring about interrupt latency. I dont know if someone has any suggestions or a litle advice. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
Hi Anton, On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote: This is patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Quite a lot hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on the software shoulders. This controller does not integrate the root hub, so this driver also fakes an one-port hub. External hub is required to support more than one device. Would it be possible to use the driver for CPM2-based devices ? The only difference I found between the CPM2 and QE USB controllers is the SOF handling. The QE USB controller increments the frame number itself, while the CPM USB controller requires the host to increment the frame number. At first sight the driver depends on qe_lib for: - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) - GPIO access (qe_gpio_set_dedicated) - clock routing (qe_clock_source, qe_usb_clock_set) - QE commands execution (qe_issue_cmd) It shouldn't be too difficult to abstract those operation in a fashion similar to the cpm_uart driver. Have you already worked on CPM2 support, or thought about any particular issue I should pay attention to ? Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgp07XJ52R2ik.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
On Thu, Apr 3, 2008 at 7:28 AM, John Linn [EMAIL PROTECTED] wrote: Hi Johann, You're right about it being missing. I have another patch for virtex specific initialization that handles that. I have not submitted it yet as I was trying to get these patches thru the system. I have been told in this forum that the bootstrap loader should not be setting up the baud rate and that normally the boot loader does it. In the case of FPGAs, we don't always use a boot loader so we need this to happen in the bootstrap loader. I can forward that patch to you if you're interested before it goes to this group. Yes, the reason for not fiddling with the clock rate divisor at this point is that it increases the chance of getting at least *something* out the serial port if the boot goes bad. For example, if the device tree has the clock rate listed incorrectly and the wrapper sets the serial port baud rate then the serial port will become unusable for bootwrapper debug. So, in the FPGA case or other no-firmware situations there needs to be a place to do this. Thinking on it further, I suppose it really does belong in the serial driver, but it needs to be protected so that only board ports that explicitly request it will do baud rate setup. Perhaps ns16550_console_init() should call a __weak function that can be overridden by a board port with a version that returns 1 instead of 0. (off the top of my head; there may be better approaches). Cheers, g. -- 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
[PATCH] ibm_newemac: Fix problem with jumbo frame support and EMAC V4
This fixes the jumbo frame support on EMAC V4 systems. Now the correct
bit is set depending on the EMAC version configured.
Tested on Kilauea (405EX) and Canyonlands (460EX).
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0789802..486901f 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -524,7 +524,10 @@ static int emac_configure(struct emac_instance *dev)
rx_size = dev-rx_fifo_size_gige;
if (dev-ndev-mtu ETH_DATA_LEN) {
- mr1 |= EMAC_MR1_JPSM;
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4))
+ mr1 |= EMAC4_MR1_JPSM;
+ else
+ mr1 |= EMAC_MR1_JPSM;
dev-stop_timeout = STOP_TIMEOUT_1000_JUMBO;
} else
dev-stop_timeout = STOP_TIMEOUT_1000;
--
1.5.4.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote: Hi Anton, On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote: This is patch adds support for the FHCI USB controller, as found in the Freescale MPC836x and MPC832x processors. It can support Full or Low speed modes. Quite a lot hardware is doing by itself (SOF generation, CRC generation and checking), though scheduling and retransmission is on the software shoulders. This controller does not integrate the root hub, so this driver also fakes an one-port hub. External hub is required to support more than one device. Would it be possible to use the driver for CPM2-based devices ? Probably. But no one had tried this yet. The only difference I found between the CPM2 and QE USB controllers is the SOF handling. The QE USB controller increments the frame number itself, while the CPM USB controller requires the host to increment the frame number. At first sight the driver depends on qe_lib for: - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) Yeah, I already posted a patch to deal with it, see http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html (btw... Scott, Timur did you have a chance to look into this?) - GPIO access (qe_gpio_set_dedicated) This is because of David Brownell. ;-) Specifically, unwillingness to accept that set_dedicated is portable for some scope of GPIO controllers, as well as GPIO users. - clock routing (qe_clock_source, qe_usb_clock_set) Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC doesn't use it yet. Neither I can tell if CLK API is suitable for our needs, or if it needs to be extended. Quickdirty workarounds are still possible though, but clk api is the right way to go. - QE commands execution (qe_issue_cmd) No proper solution yet. It shouldn't be too difficult to abstract those operation in a fashion similar to the cpm_uart driver. Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as separate matters though. ;-) I didn't look for the reasons of this split but I assume there are and they're strong enough. Have you already worked on CPM2 support, Nope, I don't have CPM2 board to work on. or thought about any particular issue I should pay attention to ? Nope, sorry. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 4xx: Change dts files to support jumbo frames
This patch changes the max-frame-size property to 9000 for all gbit enabled 4xx boards. All those ports generally support jumbo frames, so let's give the user a chance to enable it. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- arch/powerpc/boot/dts/haleakala.dts |2 +- arch/powerpc/boot/dts/katmai.dts|2 +- arch/powerpc/boot/dts/kilauea.dts |4 ++-- arch/powerpc/boot/dts/makalu.dts|4 ++-- arch/powerpc/boot/dts/rainier.dts |4 ++-- arch/powerpc/boot/dts/sequoia.dts |4 ++-- arch/powerpc/boot/dts/taishan.dts |4 ++-- 7 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts index 02e4ba3..b5d95ac 100644 --- a/arch/powerpc/boot/dts/haleakala.dts +++ b/arch/powerpc/boot/dts/haleakala.dts @@ -218,7 +218,7 @@ mal-tx-channel = 0; mal-rx-channel = 0; cell-index = 0; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000; tx-fifo-size = 800; phy-mode = rgmii; diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts index fc86e5a..cc2873a 100644 --- a/arch/powerpc/boot/dts/katmai.dts +++ b/arch/powerpc/boot/dts/katmai.dts @@ -212,7 +212,7 @@ mal-tx-channel = 0; mal-rx-channel = 0; cell-index = 0; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000; tx-fifo-size = 800; phy-mode = gmii; diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts index 8baef61..48c9a6e 100644 --- a/arch/powerpc/boot/dts/kilauea.dts +++ b/arch/powerpc/boot/dts/kilauea.dts @@ -219,7 +219,7 @@ mal-tx-channel = 0; mal-rx-channel = 0; cell-index = 0; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000; tx-fifo-size = 800; phy-mode = rgmii; @@ -247,7 +247,7 @@ mal-tx-channel = 1; mal-rx-channel = 1; cell-index = 1; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000; tx-fifo-size = 800; phy-mode = rgmii; diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts index 710c011..84cc5e7 100644 --- a/arch/powerpc/boot/dts/makalu.dts +++ b/arch/powerpc/boot/dts/makalu.dts @@ -219,7 +219,7 @@ mal-tx-channel = 0; mal-rx-channel = 0; cell-index = 0; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000; tx-fifo-size = 800; phy-mode = rgmii; @@ -247,7 +247,7 @@ mal-tx-channel = 1; mal-rx-channel = 1; cell-index = 1; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000; tx-fifo-size = 800; phy-mode = rgmii; diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts index 9f6f58b..6a8fa70 100644 --- a/arch/powerpc/boot/dts/rainier.dts +++ b/arch/powerpc/boot/dts/rainier.dts @@ -269,7 +269,7 @@ mal-tx-channel = 0; mal-rx-channel = 0; cell-index = 0; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000; tx-fifo-size = 800; phy-mode = rgmii; @@ -298,7 +298,7 @@ mal-tx-channel = 1; mal-rx-channel = 1; cell-index = 1; - max-frame-size = 5dc; + max-frame-size = 2328; rx-fifo-size = 1000;
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thu, Apr 03, 2008 at 06:30:52PM +0400, Anton Vorontsov wrote: On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote: At first sight the driver depends on qe_lib for: - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr) Yeah, I already posted a patch to deal with it, see http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html (btw... Scott, Timur did you have a chance to look into this?) It looks fine to me. It shouldn't be too difficult to abstract those operation in a fashion similar to the cpm_uart driver. Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as separate matters though. ;-) I didn't look for the reasons of this split but I assume there are and they're strong enough. Not really. :-) The reason was because the work hasn't been done yet to merge the infrastructure for CPM and QE. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
Anton Vorontsov wrote: Yeah, I already posted a patch to deal with it, see http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html (btw... Scott, Timur did you have a chance to look into this?) Seems to be okay. I presume the code actually works with these changes. :-) My only concern is that the functions are still called cpm_ even though they apply to the CPM and the QE. Sure, the QE is really just CPM3, but I'd like to see a nomenclature that's more inclusive. We should also be able to get rid of cpm_alloc/free functions anyway, since they're just front-ends to the rheap code. But that's a problem for another time. Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC doesn't use it yet. Yeah, I noticed that too. I'll add it to my to-do list, but I suspect that someone else will get around to it before I do. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thu, Apr 03, 2008 at 10:33:04AM -0500, Timur Tabi wrote: My only concern is that the functions are still called cpm_ even though they apply to the CPM and the QE. Sure, the QE is really just CPM3, but I'd like to see a nomenclature that's more inclusive. Yeah, but cpmqe would be too clunky. I went with cpm since it has seniority. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] E500 Make steal_context SMP-safe.
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking to
prevent this as suggested by BenH.
Signed-off-by: Randy Vinson [EMAIL PROTECTED]
---
The previous version of this patch had some unnecessary code which has been
removed in this version.
Note: This is a proof-of-concept patch. This isn't my area of expertise,
so I'd greatly appreciate any guidance I can get. I'm considering the
use of for_each_online_cpu() instead of for_each_possible_cpu() and
possibly putting the changes under a CONFIG_SMP switch to prevent unnecessary
overhead in the non-SMP case.
arch/powerpc/mm/mmu_context_32.c | 29 -
include/asm-powerpc/mmu_context.h |5 +
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_32.c b/arch/powerpc/mm/mmu_context_32.c
index cc32ba4..0dc7b83 100644
--- a/arch/powerpc/mm/mmu_context_32.c
+++ b/arch/powerpc/mm/mmu_context_32.c
@@ -34,6 +34,8 @@ unsigned long context_map[LAST_CONTEXT / BITS_PER_LONG + 1];
atomic_t nr_free_contexts;
struct mm_struct *context_mm[LAST_CONTEXT+1];
void steal_context(void);
+DEFINE_SPINLOCK(mm_lock);
+DEFINE_PER_CPU(struct mm_struct *, curr_mm);
#endif /* FEW_CONTEXTS */
/*
@@ -42,6 +44,9 @@ void steal_context(void);
void __init
mmu_context_init(void)
{
+#ifdef FEW_CONTEXTS
+ int cpu;
+#endif
/*
* Some processors have too few contexts to reserve one for
* init_mm, and require using context 0 for a normal task.
@@ -52,6 +57,8 @@ mmu_context_init(void)
next_mmu_context = FIRST_CONTEXT;
#ifdef FEW_CONTEXTS
atomic_set(nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+ for_each_possible_cpu(cpu)
+ per_cpu(curr_mm, cpu) = NULL;
#endif /* FEW_CONTEXTS */
}
@@ -72,12 +79,24 @@ void
steal_context(void)
{
struct mm_struct *mm;
+ int cpu;
+
+ do {
+ /* free up context `next_mmu_context' */
+ /* if we shouldn't free context 0, don't... */
+ if (next_mmu_context FIRST_CONTEXT)
+ next_mmu_context = FIRST_CONTEXT;
+ mm = context_mm[next_mmu_context];
+ for_each_possible_cpu(cpu) {
+ if ((cpu != smp_processor_id())
+ per_cpu(curr_mm, cpu) == mm) {
+ mm = NULL;
+ next_mmu_context = (next_mmu_context + 1)
+ LAST_CONTEXT;
+ }
+ }
+ } while(!mm);
- /* free up context `next_mmu_context' */
- /* if we shouldn't free context 0, don't... */
- if (next_mmu_context FIRST_CONTEXT)
- next_mmu_context = FIRST_CONTEXT;
- mm = context_mm[next_mmu_context];
flush_tlb_mm(mm);
destroy_context(mm);
}
diff --git a/include/asm-powerpc/mmu_context.h
b/include/asm-powerpc/mmu_context.h
index 9102b8b..e083b25 100644
--- a/include/asm-powerpc/mmu_context.h
+++ b/include/asm-powerpc/mmu_context.h
@@ -113,6 +113,8 @@ extern unsigned long next_mmu_context;
extern atomic_t nr_free_contexts;
extern struct mm_struct *context_mm[LAST_CONTEXT+1];
extern void steal_context(void);
+extern spinlock_t mm_lock;
+DECLARE_PER_CPU(struct mm_struct *, curr_mm);
#endif
/*
@@ -125,6 +127,7 @@ static inline void get_mmu_context(struct mm_struct *mm)
if (mm-context.id != NO_CONTEXT)
return;
#ifdef FEW_CONTEXTS
+ spin_lock(mm_lock);
while (atomic_dec_if_positive(nr_free_contexts) 0)
steal_context();
#endif
@@ -138,6 +141,8 @@ static inline void get_mmu_context(struct mm_struct *mm)
mm-context.id = ctx;
#ifdef FEW_CONTEXTS
context_mm[ctx] = mm;
+ per_cpu(curr_mm, smp_processor_id()) = mm;
+ spin_unlock(mm_lock);
#endif
}
--
1.5.4.4.551.g1658c
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: interrupt latency spi
On Thu, Apr 03, 2008 at 09:09:04AM -0400, mejjad lahcen wrote: hi all of you , I am wndering if someone has already done test for interrupt latency on linx 2.6.23 mpc5200b. I am working on writing a driver which is get SPi involved on design, and I know that the spi interrupt will occurs at every 2 us ( speed 4 MHz interupt occurs when It recieves on bytes) so I am worring about interrupt latency. Expecting to be able to handle an interrupt every 2 microseconds is simply crazy. Your hardware should at least have some FIFO to buffer the data, hey, that's what UART started doing even at much lower bit rates... Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Thursday 03 April 2008, Timur Tabi wrote: Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC doesn't use it yet. Yeah, I noticed that too. I'll add it to my to-do list, but I suspect that someone else will get around to it before I do. Note that there's some work afoot to provide a generic implementation framework for the clk_*() calls. It was last posted on the ARM list ... I'd hope it would make it easier for at least some PowerPC platforms to support that interface. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Thursday 03 April 2008 01:52:36 Kumar Gala wrote: Wanted to get any feedback on this initial port of the fixmap support over from x86. There are a few TODOs: * change HIGHMEM support to use fixmap * fixup up VMALLOC config to respect fixmap (after initial powerpc patch is in tree/accepted): * rework a few bits of fixmap.h into an asm-generic/fixmap.h The reason for introducing fixmap into ppc32 is it provides us with a clean way of getting fixed compile time virtual addresses for things. Beyond the HIGHMEM usage. Ben and I have discussed cleaning up the PCIe 44x config code (and 83xx PCIe cfg) to use it. Also, Dale's kexec/kdump support on ppc32 can take advantage of it. I'm also told this is useful for hypervisor interactions. One question for the guys looking at hypervisor. The x86 code also has a function called reserve_top_address (see arch/x86/mm/pgtable_32.c). Is this functionality something useful on ppc? If so for what? x86 virtualization implementations often needs a trampoline that's mapped into both host and guest virtual address space, so that's part of what you're seeing. In general though, it can be very useful for the host to own a piece of the guest's virtual address space. For example, the host could rewrite problematic guest instructions to branch to host-optimized code which avoids hypercalls. However, this is impossible unless the host knows it can overwrite some portion of the guest's effective address space. reserve_top_address() doesn't look complicated, so we might as well keep it? -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
(cc'ing the mailing list in my reply) On Thu, Apr 3, 2008 at 10:27 AM, Detlev Zundel [EMAIL PROTECTED] wrote: I wrote, debugging a lite5200b kernel (linux-2.6-denx equivalent of 2.6.25-rc8) I noticed that in mpc52xx_map_common_devices (mpc52xx_common.c:161) the cdm module is tentatively mapped. It seems strange to me that there is no error checking here. Is a FDT without an cdm entry usable at all? Sure, why not? If the firmware has already set it up correctly and no devices using it are in use, then the kernel should be okay. :-) That said, I can't imagine choosing to not put the cdm node into the device tree. Checking for the usage of mpc52xx_cdm I found mpc52xx_set_psc_clkdiv (mpc52xx_common.c:186) only returning ENODEV when no CDM module is mapped - but still not even a warning. Now the only user of set_psc_clkdiv seems to be drivers/spi/mpc52xx_psc_spi.c:342 where the return value is not even checked Wouldn't at least a warning on a failed mapping be in order here? By rights, the psc_spi driver should be fixed to report an error. Other than that, there are no users of the CDM in-tree right now. And yes, I've seen that the lite5200 specific code warns on a missing cdm node but thats no help for other platforms And that's because older lite5200 firmware doesn't setup the CDM correctly. Now, all of the mpc5200 common code needs some work I think. There are too many places where bestcomm or other code redundantly goes looking for common device nodes. I'd like to amalgamate a bunch of that stuff to map them all at platform initialization time and provide an api for retrieving the mapped region or for controlling the shared device. Cheers, g. -- 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
[PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
We really need to ack interrupts at mpic_teardown, since
not all platforms reset mpic at kernel start-up. For example,
kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/sysdev/mpic.c |6 +-
1 files changed, 1 insertion(+), 5 deletions(-)
--- powerpc/arch/powerpc/sysdev/mpic.c 2008-02-26 15:56:57.0 +0300
+++ linux-2.6.new/arch/powerpc/sysdev/mpic.c2008-04-03 23:00:45.0
+0400
@@ -1410,11 +1410,6 @@ void mpic_cpu_set_priority(int prio)
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), prio);
}
-/*
- * XXX: someone who knows mpic should check this.
- * do we need to eoi the ipi including for kexec cpu here (see xics comments)?
- * or can we reset the mpic in the new kernel?
- */
void mpic_teardown_this_cpu(int secondary)
{
struct mpic *mpic = mpic_primary;
@@ -1434,6 +1429,7 @@ void mpic_teardown_this_cpu(int secondar
/* Set current processor priority to max */
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
+ mpic_eoi(mpic);
spin_unlock_irqrestore(mpic_lock, flags);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc TLF_RESTORE_SIGMASK
This requires the earlier HAVE_SET_RESTORE_SIGMASK patch series.
This does the same for powerpc that I posted the x86 change for.
---
Replace TIF_RESTORE_SIGMASK with TLF_RESTORE_SIGMASK and define
our own set_restore_sigmask() function. This saves the costly
SMP-safe set_bit operation, which we do not need for the sigmask
flag since TIF_SIGPENDING always has to be set too.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/entry_32.S|4 ++--
arch/powerpc/kernel/signal.c | 12 ++--
arch/powerpc/kernel/signal_32.c |2 +-
include/asm-powerpc/thread_info.h | 17 +
4 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 69a91bd..646daf4 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -661,7 +661,7 @@ user_exc_return:/* r10 contains MSR_KERNEL here
*/
/* Check current_thread_info()-flags */
rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
lwz r9,TI_FLAGS(r9)
- andi. r0,r9,(_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK|_TIF_NEED_RESCHED)
+ andi. r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED)
bne do_work
restore_user:
@@ -912,7 +912,7 @@ recheck:
lwz r9,TI_FLAGS(r9)
andi. r0,r9,_TIF_NEED_RESCHED
bne-do_resched
- andi. r0,r9,_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK
+ andi. r0,r9,_TIF_SIGPENDING
beq restore_user
do_user_signal:/* r10 contains MSR_KERNEL here */
ori r10,r10,MSR_EE
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index a65a44f..ad55488 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -120,7 +120,7 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
int ret;
int is32 = is_32bit_task();
- if (test_thread_flag(TIF_RESTORE_SIGMASK))
+ if (current_thread_info()-local_flags _TLF_RESTORE_SIGMASK)
oldset = current-saved_sigmask;
else if (!oldset)
oldset = current-blocked;
@@ -131,9 +131,10 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
check_syscall_restart(regs, ka, signr 0);
if (signr = 0) {
+ struct thread_info *ti = current_thread_info();
/* No signal to deliver -- put the saved sigmask back */
- if (test_thread_flag(TIF_RESTORE_SIGMASK)) {
- clear_thread_flag(TIF_RESTORE_SIGMASK);
+ if (ti-local_flags _TLF_RESTORE_SIGMASK) {
+ ti-local_flags = ~_TLF_RESTORE_SIGMASK;
sigprocmask(SIG_SETMASK, current-saved_sigmask, NULL);
}
return 0; /* no signals delivered */
@@ -169,10 +170,9 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
/*
* A signal was successfully delivered; the saved sigmask is in
-* its frame, and we can clear the TIF_RESTORE_SIGMASK flag.
+* its frame, and we can clear the TLF_RESTORE_SIGMASK flag.
*/
- if (test_thread_flag(TIF_RESTORE_SIGMASK))
- clear_thread_flag(TIF_RESTORE_SIGMASK);
+ current_thread_info()-local_flags = ~_TLF_RESTORE_SIGMASK;
}
return ret;
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index ad69434..4ae16d1 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -243,7 +243,7 @@ long sys_sigsuspend(old_sigset_t mask)
current-state = TASK_INTERRUPTIBLE;
schedule();
- set_thread_flag(TIF_RESTORE_SIGMASK);
+ set_restore_sigmask();
return -ERESTARTNOHAND;
}
diff --git a/include/asm-powerpc/thread_info.h
b/include/asm-powerpc/thread_info.h
index 40d5f98..3b9271b 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -120,7 +120,6 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_SECCOMP10 /* secure computing */
#define TIF_RESTOREALL 11 /* Restore all regs (implies NOERROR) */
#define TIF_NOERROR12 /* Force successful syscall return */
-#define TIF_RESTORE_SIGMASK13 /* Restore signal mask in do_signal */
#define TIF_FREEZE 14 /* Freezing for suspend */
#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
#define TIF_ABI_PENDING16 /* 32/64 bit switch needed */
@@ -138,21 +137,31 @@ static inline struct thread_info
*current_thread_info(void)
#define _TIF_SECCOMP (1TIF_SECCOMP)
#define _TIF_RESTOREALL(1TIF_RESTOREALL)
#define _TIF_NOERROR (1TIF_NOERROR)
-#define _TIF_RESTORE_SIGMASK (1TIF_RESTORE_SIGMASK)
#define _TIF_FREEZE(1TIF_FREEZE)
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Thu, 2008-04-03 at 13:47 -0500, Hollis Blanchard wrote: x86 virtualization implementations often needs a trampoline that's mapped into both host and guest virtual address space, so that's part of what you're seeing. In general though, it can be very useful for the host to own a piece of the guest's virtual address space. For example, the host could rewrite problematic guest instructions to branch to host-optimized code which avoids hypercalls. However, this is impossible unless the host knows it can overwrite some portion of the guest's effective address space. reserve_top_address() doesn't look complicated, so we might as well keep it ? Agreed. In fact, using the top of the address space for that is a good idea as you can do the branching there using absolute branch instructions which is simpler. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
On Thu, 2008-04-03 at 23:09 +0400, Valentine Barshak wrote:
We really need to ack interrupts at mpic_teardown, since
not all platforms reset mpic at kernel start-up. For example,
kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
Would be interesting to find out why it hangs tho... it shouldn't .
Ben.
arch/powerpc/sysdev/mpic.c |6 +-
1 files changed, 1 insertion(+), 5 deletions(-)
--- powerpc/arch/powerpc/sysdev/mpic.c2008-02-26 15:56:57.0
+0300
+++ linux-2.6.new/arch/powerpc/sysdev/mpic.c 2008-04-03 23:00:45.0
+0400
@@ -1410,11 +1410,6 @@ void mpic_cpu_set_priority(int prio)
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), prio);
}
-/*
- * XXX: someone who knows mpic should check this.
- * do we need to eoi the ipi including for kexec cpu here (see xics
comments)?
- * or can we reset the mpic in the new kernel?
- */
void mpic_teardown_this_cpu(int secondary)
{
struct mpic *mpic = mpic_primary;
@@ -1434,6 +1429,7 @@ void mpic_teardown_this_cpu(int secondar
/* Set current processor priority to max */
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
+ mpic_eoi(mpic);
spin_unlock_irqrestore(mpic_lock, flags);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinxuart 16550.
The device tree generator now reflects this. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Arnd Bergmann Sent: Wednesday, April 02, 2008 9:16 PM To: linuxppc-dev@ozlabs.org Cc: John Linn Subject: Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinxuart 16550. On Thursday 03 April 2008, Grant Likely wrote: Since it is not really compatible with ns16550, shouldn't you at least specify a different compatible property? That way, the driver won't do incorrect accesses when you try to use an old driver with a device tree that specifies one of these. Heh; we've gone back and forth on this issue. The problem is that we have a common case of ns16550 like devices that require a little bit of register address tweaking that spans a whole range of vendors (so adding a compatible match with each of those vendor's prefixes is probably non-scalable). So, if ns16550 is not a good idea, then what should be used? sparse16550 has been suggested more than once. After another IRC discussion between Grant, Segher and myself, we concluded that we don't need to invent a new compatible value, as only new device trees with old kernels will have a problem with this, and they don't work in the first place. The devices will still have their specific compatible value, e.g. xlnx,plb-uart16550-1.00.c, followed by ns16550, and possibly ns16450 and i8250, although the last two do not have an effect on Linux. Josh, can you please forward all three patches in their latest version? Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add idle wait support for 44x platforms
On Thu, Apr 03, 2008 at 05:43:02PM -0500, Jerone Young wrote:
Hi Jerone,
A few minor nits.
Add idle wait support for 44x platforms
This patch adds the ability for the CPU to go into wait state while in
cpu_idle loop. This helps virtulization solutions know when the guest Linux
kernel is in an idle state. There are two ways to do it.
1) Command line
idle=spin -- CPU will spin (this is the default)
idle=wait -- set CPU into wait state when idle
2) The device tree will be checked for the /hypervisor node
If this node is seen it will use wait for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
Can you include a diffstat in here?
+static int current_mode = 0;
Leave this as: static int current_mode;, so it'll end up in the bss
+int __init ppc44x_idle_init(void)
+{
+ if(of_find_node_by_path(/hypervisor) != NULL) {
^ space
+ /* if we find /hypervisor node is in device tree,
+set idle mode to wait */
+ current_mode = 1; /* wait mode */
+ }
You don't really need the braces {} here.
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i sizeof(modes)/sizeof(struct sleep_mode); i++) {
ARRAY_SIZE(modes)
Yours Tony
linux.conf.auhttp://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] RTAS - adapt procfs interface
On Tue, Apr 01, 2008 at 03:12:20PM +0200, Jens Osterkamp wrote: Hi, rtas_flash was broken since 2.6.24-rc5. This patch fixes it. I think this is a good bugfix candidate for 2.6.25. NACK. driver should not poke into the internal count member. Just provide your own inclusion with a new counter or set/test_bit. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [kvm-ppc-devel] [PATCH] Add idle wait support for 44x platforms
On Thu, Apr 03, 2008 at 06:13:59PM -0500, Hollis Blanchard wrote: Stuart, we're getting into ePAPR territory. Do you think we need to worry about a hypervisor not handling mtmsr(MSR_WE)? In that case, we'd need to be more specific than just testing for /hypervisor. IMHO every hypervisor should implement it... but maybe /hypervisor/idle = wait would be more explicit and therefore better? We can't trap on MSR[WE] updates on hypervisor-enabled chips; the write is silently ignored. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add idle wait support for 44x platforms
On Fri, 4 Apr 2008 10:03:56 +1100
[EMAIL PROTECTED] (Tony Breeds) wrote:
+int __init ppc44x_idle_init(void)
+{
+ if(of_find_node_by_path(/hypervisor) != NULL) {
^ space
+ /* if we find /hypervisor node is in device tree,
+ set idle mode to wait */
+ current_mode = 1; /* wait mode */
+ }
You don't really need the braces {} here.
They are technically not required, but I like them there none the
less because of the multi-line comment. I find it to be better style
personally.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add idle wait support for 44x platforms
On Thu, 03 Apr 2008 17:43:02 -0500
Jerone Young [EMAIL PROTECTED] wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1207262487 18000
# Node ID 7226bef216680748a50327900572c2fbc3e762b0
# Parent a5b2aebbc6ebd2439c655f1c047ed7e3c1991ec1
As a complete and unrelated side note to the actual patch, wtf is this
hg stuff? I can't really tell what tree you're even basing this off of.
Add idle wait support for 44x platforms
This patch adds the ability for the CPU to go into wait state while in
cpu_idle loop. This helps virtulization solutions know when the guest Linux
kernel is in an idle state. There are two ways to do it.
This huge single line needs fixing in the next version of the patch.
1) Command line
idle=spin -- CPU will spin (this is the default)
idle=wait -- set CPU into wait state when idle
2) The device tree will be checked for the /hypervisor node
If this node is seen it will use wait for idle, so that
the hypervisor can know when guest Linux kernel it is in
an idle state.
This patch, unlike the last, isolates the code to 44x platforms.
In addition to the comments Tony and Hollis made, I have a few of my
own.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/44x/44x.h
b/arch/powerpc/platforms/44x/44x.h
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -5,4 +5,6 @@ extern void as1_writeb(u8 data, volatile
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
extern void ppc44x_reset_system(char *cmd);
+extern int ppc44x_idle_init(void);
+
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
The changes to this file aren't needed. See below.
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,5 @@ obj-$(CONFIG_44x) := misc_44x.o
obj-$(CONFIG_44x):= misc_44x.o
+obj-$(CONFIG_44x)+= idle.o
Just add this target to the already existing obj-(CONFIG_44x)
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN)+= taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/bamboo.c
b/arch/powerpc/platforms/44x/bamboo.c
--- a/arch/powerpc/platforms/44x/bamboo.c
+++ b/arch/powerpc/platforms/44x/bamboo.c
@@ -61,3 +61,5 @@ define_machine(bamboo) {
.restart= ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
+
+machine_late_initcall(bamboo, ppc44x_idle_init);
Ugh. Don't add an init call to every 4xx board like this. It's not
needed. See below.
diff --git a/arch/powerpc/platforms/44x/idle.c
b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
If you're ever going to extend bare metal support for this to 40x, then
this is the wrong place for it. It should reside in
arch/powerpc/sysdev/ppc4xx_soc.c in that case.
+
+#include linux/of.h
+#include asm/machdep.h
+
+static void ppc44x_idle(void);
This isn't needed. Move the structures below the function.
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static struct sleep_mode modes[] = {
+ { .name = spin, .entry = NULL },
+ { .name = wait, .entry = ppc44x_idle },
+};
snip
+int __init ppc44x_idle_init(void)
+{
+ if(of_find_node_by_path(/hypervisor) != NULL) {
+ /* if we find /hypervisor node is in device tree,
+set idle mode to wait */
+ current_mode = 1; /* wait mode */
+ }
+
+ ppc_md.power_save = modes[current_mode].entry;
+ return 0;
I liked Hollis' method of assignment here.
+}
Add an arch_initcall(ppc44x_idle_init); here and dispense with
changing every board .c file in the 44x directory.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
On Fri, Apr 04, 2008 at 08:50:36AM +1100, Benjamin Herrenschmidt wrote: On Thu, 2008-04-03 at 23:09 +0400, Valentine Barshak wrote: We really need to ack interrupts at mpic_teardown, since not all platforms reset mpic at kernel start-up. For example, kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called. Signed-off-by: Valentine Barshak [EMAIL PROTECTED] --- Would be interesting to find out why it hangs tho... it shouldn't . I haven't reproduced the problem and looked at hardware state yet, but I would expect it to be because the openpic won't send another interrupt until the previous is EOI'd, and the IPI is never EOI'd as far as I can tell. The XICS code does it explicitly already. I'm surprised it doesn't break on the 970-based platforms actually... -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
