Re: [PATCH v2] using mii-bitbang on different processor ports
Am Dienstag, den 30.10.2007, 13:23 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > + if( !of_address_to_resource(np, 1, &res[1])) {
>
> The spacing is still wrong.
>
> > - iounmap(bitbang->dir);
> > + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> > + iounmap(bitbang->mdio.dir);
> > + iounmap(bitbang->mdc.dir);
>
> And here.
>
> -Scott
Oh, sorry.
--
Sergej I. Stepanov
E-PA
IDS GmbH
Nobelstr. 18, Zim. 2.1.05
D-76275 Ettlingen
T +49 (0) 72 43/2 18-615
F +49 (0) 72 43/2 18-400
Email: <[EMAIL PROTECTED]>
Geschäftsführer: Norbert Wagner, Friedrich Abriß
Sitz der Gesellschaft: Ettlingen
Amtsgericht Mannheim HRB 362503
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M
From: Grant Likely <[EMAIL PROTECTED]>
mmu_mapin_ram() loops over total_lowmem to setup page tables. However, if
total_lowmem is less that 16M, the subtraction rolls over and results in
a number just under 4G (because total_lowmem is an unsigned value).
This patch rejigs the loop from countup to countdown to eliminate the
bug.
Special thanks to Magnus Hjorth who wrote the original patch to fix this
bug. This patch improves on his by making the loop code simpler (which
also eliminates the possibility of another rollover at the high end)
and also applies the change to arch/powerpc.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
Josh, I've tested this change on arch/ppc, but not arch/powerpc. The
ppc and powerpc code are darn near identical so it should be correct,
but you might want to boot a kernel before you push it to Paulus
anyway.
Cheers,
g.
arch/powerpc/mm/40x_mmu.c | 17 -
arch/ppc/mm/4xx_mmu.c | 17 -
2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
index e067df8..3899ea9 100644
--- a/arch/powerpc/mm/40x_mmu.c
+++ b/arch/powerpc/mm/40x_mmu.c
@@ -98,13 +98,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s >= LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -116,10 +115,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s >= LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -128,8 +127,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
diff --git a/arch/ppc/mm/4xx_mmu.c b/arch/ppc/mm/4xx_mmu.c
index 838e09d..ea785db 100644
--- a/arch/ppc/mm/4xx_mmu.c
+++ b/arch/ppc/mm/4xx_mmu.c
@@ -99,13 +99,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s >= LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -117,10 +116,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s >= LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC |
_PAGE_HWWRITE;
@@ -129,8 +128,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [POWERPC] mpc5200: Fix Kconfig dependancies on MPC5200 FEC device driver
From: Grant Likely <[EMAIL PROTECTED]> When not building an arch/powerpc kernel, the mpc5200 FEC driver depends on some symbols which are not defined (BESTCOMM & BESTCOMM_FEC). This patch flips around the dependancy logic so that it cannot be selected unless BESTCOMM_FEC is selected first. Kconfig stops complaining this way. Also, the driver only works for arch/powerpc (not arch/ppc) anyway so it should depend on PPC_MERGE also. Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- drivers/net/Kconfig |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 867cb73..5f800a6 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1883,9 +1883,7 @@ config FEC2 config FEC_MPC52xx tristate "MPC52xx FEC driver" - depends on PPC_MPC52xx - select PPC_BESTCOMM - select PPC_BESTCOMM_FEC + depends on PPC_MERGE && PPC_MPC52xx && PPC_BESTCOMM_FEC select CRC32 select PHYLIB ---help--- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] Fix region size check in mpc5200 FEC driver
From: Grant Likely <[EMAIL PROTECTED]>
Driver shouldn't complain if the register range is larger than what
it expects. This works around failures with some device trees.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/net/fec_mpc52xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index fc1cf0b..a8a0ee2 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -879,9 +879,9 @@ mpc52xx_fec_probe(struct of_device *op, const struct
of_device_id *match)
"Error while parsing device node resource\n" );
return rv;
}
- if ((mem.end - mem.start + 1) != sizeof(struct mpc52xx_fec)) {
+ if ((mem.end - mem.start + 1) < sizeof(struct mpc52xx_fec)) {
printk(KERN_ERR DRIVER_NAME
- " - invalid resource size (%lx != %x), check
mpc52xx_devices.c\n",
+ " - invalid resource size (%lx < %x), check
mpc52xx_devices.c\n",
(unsigned long)(mem.end - mem.start + 1), sizeof(struct
mpc52xx_fec));
return -EINVAL;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Deal with 44x virtually tagged icache
The 44x family has an interesting "feature" which is a virtually tagged instruction cache (yuck !). So far, we haven't dealt with it properly, which means we've been mostly lucky or people didn't report the problems, unless people have been running custom patches in their distro... This is an attempt at fixing it properly. I chose to do it by setting a global flag whenever we change a PTE that was previously marked executable, and flush the entire instruction cache upon return to user space when that happens. This is a bit heavy handed, but it's hard to do more fine grained flushes as the icbi instruction, on those processor, for some very strange reasons (since the cache is virtually mapped) still requires a valid TLB entry for reading in the target address space, which isn't something I want to deal with. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- This version fixes the double iccci noticed by josh and does arch/ppc (untested). arch/powerpc/kernel/entry_32.S | 23 +++ arch/powerpc/kernel/misc_32.S |9 + arch/powerpc/mm/44x_mmu.c |1 + arch/ppc/kernel/entry.S | 23 +++ arch/ppc/kernel/misc.S |9 + arch/ppc/mm/44x_mmu.c |1 + include/asm-powerpc/pgtable-ppc32.h | 13 + 7 files changed, 79 insertions(+) Index: linux-work/arch/powerpc/kernel/entry_32.S === --- linux-work.orig/arch/powerpc/kernel/entry_32.S 2007-10-15 11:19:35.0 +1000 +++ linux-work/arch/powerpc/kernel/entry_32.S 2007-10-31 10:40:45.0 +1100 @@ -244,6 +244,13 @@ syscall_exit_cont: andis. r10,r0,[EMAIL PROTECTED] bnel- load_dbcr0 #endif +#ifdef CONFIG_44x + lis r4,[EMAIL PROTECTED] + lwz r5,[EMAIL PROTECTED](r4) + cmplwi cr0,r5,0 + bne-2f +1: +#endif /* CONFIG_44x */ stwcx. r0,0,r1 /* to clear the reservation */ lwz r4,_LINK(r1) lwz r5,_CCR(r1) @@ -258,6 +265,12 @@ syscall_exit_cont: mtspr SPRN_SRR1,r8 SYNC RFI +#ifdef CONFIG_44x +2: li r7,0 + iccci r0,r0 + stw r7,[EMAIL PROTECTED](r4) + b 1b +#endif /* CONFIG_44x */ 66:li r3,-ENOSYS b ret_from_syscall @@ -683,6 +696,16 @@ resume_kernel: /* interrupts are hard-disabled at this point */ restore: +#ifdef CONFIG_44x + lis r4,[EMAIL PROTECTED] + lwz r5,[EMAIL PROTECTED](r4) + cmplwi cr0,r5,0 + beq+1f + li r6,0 + iccci r0,r0 + stw r6,[EMAIL PROTECTED](r4) +1: +#endif /* CONFIG_44x */ lwz r0,GPR0(r1) lwz r2,GPR2(r1) REST_4GPRS(3, r1) Index: linux-work/arch/powerpc/mm/44x_mmu.c === --- linux-work.orig/arch/powerpc/mm/44x_mmu.c 2007-09-28 11:42:05.0 +1000 +++ linux-work/arch/powerpc/mm/44x_mmu.c2007-10-30 15:30:50.0 +1100 @@ -35,6 +35,7 @@ */ unsigned int tlb_44x_index; /* = 0 */ unsigned int tlb_44x_hwater = PPC44x_TLB_SIZE - 1 - PPC44x_EARLY_TLBS; +int icache_44x_need_flush; /* * "Pins" a 256MB TLB entry in AS0 for kernel lowmem Index: linux-work/include/asm-powerpc/pgtable-ppc32.h === --- linux-work.orig/include/asm-powerpc/pgtable-ppc32.h 2007-09-28 11:42:10.0 +1000 +++ linux-work/include/asm-powerpc/pgtable-ppc32.h 2007-10-30 15:30:50.0 +1100 @@ -11,6 +11,11 @@ extern unsigned long va_to_phys(unsigned long address); extern pte_t *va_to_pte(unsigned long address); extern unsigned long ioremap_bot, ioremap_base; + +#ifdef CONFIG_44x +extern int icache_44x_need_flush; +#endif + #endif /* __ASSEMBLY__ */ /* @@ -562,6 +567,10 @@ static inline unsigned long pte_update(p : "=&r" (old), "=&r" (tmp), "=m" (*p) : "r" (p), "r" (clr), "r" (set), "m" (*p) : "cc" ); +#ifdef CONFIG_44x + if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC)) + icache_44x_need_flush = 1; +#endif return old; } #else @@ -582,6 +591,10 @@ static inline unsigned long long pte_upd : "=&r" (old), "=&r" (tmp), "=m" (*p) : "r" (p), "r" ((unsigned long)(p) + 4), "r" (clr), "r" (set), "m" (*p) : "cc" ); +#ifdef CONFIG_44x + if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC)) + icache_44x_need_flush = 1; +#endif return old; } #endif Index: linux-work/arch/powerpc/kernel/misc_32.S === --- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-10-30 15:15:03.0 +1100 +++ linux-work/arch/powerpc/kernel/misc_32.S2007-10-30 15:30:50.0 +1100 @@ -543,12 +543,21 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_I a
Re: ring on PowerPC
On Tue, 2007-10-30 at 23:18 -0600, Grant Likely wrote: > On 10/30/07, Bai Shuwei <[EMAIL PROTECTED]> wrote: > > Hi, everyone > >As we know, the program on the X86 can run on the differnt ring(0, 1, 2, > > 3) and the linux kernel run in the ring 0 and user program in the ring 3. > > And now I want to know wether there is a simple mechanism on the PowerPC > > architecture? thx all! > > Powerpc has 2 privilege levels; user and supervisor. The kernel runs > in supervisor mode, and user-space runs in user mode. To be complete here, some implementations have 3 :-) Don't forget hypervisor mode ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
On Wed, 31 Oct 2007 14:28:46 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > ioresource was good structure for remembering "which memory is conventional > memory" and i386/x86_64/ia64 registered conventional memory as "System RAM", > when I posted patch. (just say "System Ram" is not for memory hotplug.) > If I remember correctly, System RAM is for kdump (to know which memory should be dumped.) Then, memory-hotadd/remove has to modify it anyway. Thanks, -Kame ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
On Tue, 30 Oct 2007 11:19:11 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote: > Hi KAME, > > As I mentioned while ago, ppc64 does not export information about > "system RAM" in /proc/iomem. Looking at the code and usage > scenerios I am not sure what its really serving. Could you > explain what its purpose & how the range can be invalid ? > Hm, I added walk_memory_resource() for hot-add, at first. Size of memory section is fixed and just depend on architecture, but any machine can have any memory-hole within continuous memory-section-size range of physical memory. Then we have to detect which page can be target of online_page() and which are leaved as Reserved. ioresource was good structure for remembering "which memory is conventional memory" and i386/x86_64/ia64 registered conventional memory as "System RAM", when I posted patch. (just say "System Ram" is not for memory hotplug.) I used walk_memory_resource() again in memory hotremove. (If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add. than our ia64 box. In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some "for firmware" area in newly-added node.) > At least on ppc64, all the memory ranges we get passed comes from > /sysfs memblock information and they are guaranteed to match > device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry > and it will be part of the /proc/device-tree entry. Since we do > "online" or "offline" to /sysfs entries to add/remove pages - > these ranges are guaranteed to be valid. > ok. > Since this check is redundant for ppc64, I propose following patch. > Is this acceptable ? If some one really really wants, I can code > up this to walk lmb or /proc/device-tree and verify the range & > adjust the entries for overlap (I don't see how that can happen). > ok. If ppc64 guarantees "there is no memory hole in section", please try. I have no objection. I just would like to ask to add some text to explain "ppc64 doesn't need to care memory hole in a section." Thanks, -Kame ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ring on PowerPC
On 10/30/07, Bai Shuwei <[EMAIL PROTECTED]> wrote: > Hi, everyone >As we know, the program on the X86 can run on the differnt ring(0, 1, 2, > 3) and the linux kernel run in the ring 0 and user program in the ring 3. > And now I want to know wether there is a simple mechanism on the PowerPC > architecture? thx all! Powerpc has 2 privilege levels; user and supervisor. The kernel runs in supervisor mode, and user-space runs in user mode. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ring on PowerPC
Hi, everyone As we know, the program on the X86 can run on the differnt ring(0, 1, 2, 3) and the linux kernel run in the ring 0 and user program in the ring 3. And now I want to know wether there is a simple mechanism on the PowerPC architecture? thx all! best regards! Buroc -- Add: Tianshui South Road 222, Lanzhou, P.R.China Tel: +86-931-8912025 Zip Code: 73 URL: oss.lzu.edu.cn Email: [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [0/2] Embed a copy of dtc in the kernel source
On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote: > > On Oct 30, 2007, at 10:24 PM, David Gibson wrote: > > > These two patches are a respin of my previous patch to merge a copy of > > dtc into the kernel tree, so that kernel builds no longer depend on an > > externally installed copy of dtc. > > > > This respin embeds a newer revision of dtc, and incorporates Sam > > Ravnborg's preferred approach to Makefile integration. Also, since so > > many people whinged about it last time, I've split the patch into two > > parts, the first is the too-large-for-the-list patch just verbatim > > adding files and the second has the changes to existing kernel files > > to build and use the embedded code. > > What about doing part of this via git-submodule? Uh.. where do I find out what that does? My version of git (Ubuntu gutsy) doesn't seem to know anything about it... -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [0/2] Embed a copy of dtc in the kernel source
On Oct 30, 2007, at 10:24 PM, David Gibson wrote: > These two patches are a respin of my previous patch to merge a copy of > dtc into the kernel tree, so that kernel builds no longer depend on an > externally installed copy of dtc. > > This respin embeds a newer revision of dtc, and incorporates Sam > Ravnborg's preferred approach to Makefile integration. Also, since so > many people whinged about it last time, I've split the patch into two > parts, the first is the too-large-for-the-list patch just verbatim > adding files and the second has the changes to existing kernel files > to build and use the embedded code. What about doing part of this via git-submodule? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[2/2] Use embedded dtc in kernel builds
This patch alters the kernel makefiles to build dtc from the sources embedded in the previous patch. It also changes the arch/powerpc/boot/wrapper script to use the embedded dtc, rather than expecting a copy of dtc already installed on the system. Signed-off-by: David Gibson <[EMAIL PROTECTED]> Index: working-2.6/arch/powerpc/boot/Makefile === --- working-2.6.orig/arch/powerpc/boot/Makefile 2007-10-22 13:55:49.0 +1000 +++ working-2.6/arch/powerpc/boot/Makefile 2007-10-31 14:02:40.0 +1100 @@ -108,17 +108,52 @@ $(patsubst %.S,%.o, $(filter %.S, $(src- $(obj)/wrapper.a: $(obj-wlib) FORCE $(call if_changed,bootar) -hostprogs-y:= addnote addRamDisk hack-coff mktree +hostprogs-y:= addnote addRamDisk hack-coff mktree dtc targets+= $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a) extra-y:= $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \ $(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds wrapper:=$(srctree)/$(src)/wrapper -wrapperbits:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \ +wrapperbits:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \ $(wrapper) FORCE # +# Bits for building dtc +# DTC_GENPARSER := 1# Uncomment to rebuild flex/bison output + +dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o +dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o +dtc-objs := $(addprefix dtc-src/, $(dtc-objs)) + +# prerequisites on generated files needs to be explicit +$(obj)/dtc-src/dtc-parser.tab.o: $(obj)/dtc-src/dtc-parser.tab.c $(obj)/dtc-src/dtc-parser.tab.h +$(obj)/dtc-src/dtc-lexer.lex.o: $(obj)/dtc-src/dtc-lexer.lex.c $(obj)/dtc-src/dtc-parser.tab.h + +HOSTCFLAGS += -I$(src)/dtc-src/ + +targets += dtc-src/dtc-parser.tab.c +targets += dtc-src/dtc-lexer.lex.c + +ifdef DTC_GENPARSER +BISON = bison +FLEX = flex + +quiet_cmd_bison = BISON $@ + cmd_bison = $(BISON) -o$@ -d $<; cp $@ [EMAIL PROTECTED] +quiet_cmd_flex = FLEX$@ + cmd_flex = $(FLEX) -o$@ $<; cp $@ [EMAIL PROTECTED] + +$(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE + $(call if_changed,bison) + +$(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c + +$(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE + $(call if_changed,flex) +endif + +# # Bits for building various flavours of zImage ifneq ($(CROSS32_COMPILE),) @@ -236,7 +271,7 @@ install: $(CONFIGURE) $(addprefix $(obj) # anything not in $(targets) clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.* \ - otheros.bld + otheros.bld $(dtc-clean-files) # clean up files cached by wrapper clean-kernel := vmlinux.strip vmlinux.bin Index: working-2.6/arch/powerpc/boot/wrapper === --- working-2.6.orig/arch/powerpc/boot/wrapper 2007-10-22 13:55:50.0 +1000 +++ working-2.6/arch/powerpc/boot/wrapper 2007-10-31 14:02:40.0 +1100 @@ -111,7 +111,7 @@ if [ -n "$dts" ]; then if [ -z "$dtb" ]; then dtb="$platform.dtb" fi -dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1 +$object/dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1 fi if [ -z "$kernel" ]; then -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[1/2] Merge dtc
This very large patch incorporates a copy of dtc into the kernel source, in arch/powerpc/boot/dtc-src. This patch only imports the dtc sources verbatim, another patch coming to actually link it into the kernel Makefiles and use the embedded copy of dtc for kernel builds. Signed-off-by: David Gibson <[EMAIL PROTECTED]> Too big for this list. Full patch at: http://ozlabs.org/~dgibson/home/merge-dtc.patch -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[0/2] Embed a copy of dtc in the kernel source
These two patches are a respin of my previous patch to merge a copy of dtc into the kernel tree, so that kernel builds no longer depend on an externally installed copy of dtc. This respin embeds a newer revision of dtc, and incorporates Sam Ravnborg's preferred approach to Makefile integration. Also, since so many people whinged about it last time, I've split the patch into two parts, the first is the too-large-for-the-list patch just verbatim adding files and the second has the changes to existing kernel files to build and use the embedded code. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak <[EMAIL PROTECTED]> wrote: > > +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c2007-10-30 > 18:00:15.0 +0300 > +#include > +#include > +#include > +#include > +#include > +#include > +#include You want -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpLSdUhmE65u.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
On Tue, Oct 30, 2007 at 09:09:17PM -0500, Josh Boyer wrote:
> On Tue, 30 Oct 2007 20:56:51 -0500
> Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > > PowerPC 440GRx Rainier DTS.
> > > [snip]
> > > > + SDRAM0: sdram {
> > > > + device_type = "memory-controller";
> > >
> > > How many times do we need to say it...
> > >
> > > Don't make up random device_type values. This does not belong here.
> >
> > Maybe there should be something like checkpatch.pl that warns about
> > these kinds of things so people can check for it without getting flamed
> > first. :-)
I'd be gentler; except that I know Valentine has been active on this
list recently, so has almost certainly seen similar comments before.
> That's actually a decent idea. We could even have this thing that
> takes DTS files and processes them... oh wait.
>
> So why can't we make a whitelist of "allowed" device_types in DTC and
> make it whine about anything outside of that?
Well, that sort of thing is the idea for dtc to check, when it has
checks enabled anyway. Getting it so that it doesn't have too many
false positives is the tricky bit, as we've seen with some of the
existing checks (where "too many" is "almost any").
Patches welcome...
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt as its own repo and submodule of dtc?
Jon Loeliger wrote: > So, like, the other day Kumar Gala mumbled: >> Jon, >> >> It seems like have libfdt as a unique git repo that is a submodule of >> the things that need it (dtc, u-boot, etc.) might make some sense and >> it easier for the projects that need to pull it in. >> >> Is this something you can take a look at? (or have other ideas on). > > I would be fine with making libfdt a git repository separate > from the DTC repository if that makes it easier to integrate > it with other projects. > > jdl That sounds like a good idea to me. I would really prefer pulling patches out of a libfdt repo into the u-boot repo rather than trying to kerchunk upgrade lumps. While we can do this with a dtc repo, it potentially makes it a lot more difficult. gvb ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] using mii-bitbang on different processor ports
On Tue, 30 Oct 2007 17:09:19 +0100 Sergej Stepanov <[EMAIL PROTECTED]> wrote:
>
> static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
> struct device_node *np)
> {
> - struct resource res;
> + struct resource res[2];
Why not just reuse the same resource structure? You don't seem to need
them both at the same time.
> + if( !of_address_to_resource(np, 1, &res[1]))
> + {
> + bitbang->mdio.dir = ioremap(res[1].start, res[1].end -
> res[1].start + 1);
> + if (!bitbang->mdio.dir)
> + {
> + iounmap(bitbang->mdc.dir);
> + return -ENOMEM;
> + }
> + bitbang->mdio.dat = bitbang->mdio.dir + 4;
> + }
> + else{
Formatting:
if () {
} else {
}
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
No spaces after (, please. Here and elsewhere.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpLXwBz76Ck0.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
On Tue, 30 Oct 2007 20:56:51 -0500
Olof Johansson <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > PowerPC 440GRx Rainier DTS.
> > [snip]
> > > + SDRAM0: sdram {
> > > + device_type = "memory-controller";
> >
> > How many times do we need to say it...
> >
> > Don't make up random device_type values. This does not belong here.
>
> Maybe there should be something like checkpatch.pl that warns about
> these kinds of things so people can check for it without getting flamed
> first. :-)
That's actually a decent idea. We could even have this thing that
takes DTS files and processes them... oh wait.
So why can't we make a whitelist of "allowed" device_types in DTC and
make it whine about anything outside of that?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > PowerPC 440GRx Rainier DTS.
> [snip]
> > + SDRAM0: sdram {
> > + device_type = "memory-controller";
>
> How many times do we need to say it...
>
> Don't make up random device_type values. This does not belong here.
Maybe there should be something like checkpatch.pl that warns about
these kinds of things so people can check for it without getting flamed
first. :-)
Lots of people base their dts'es on other ones, so until the kernel has
bene clean a while, this will happen all the time. I'm saying "a while"
because people tend to base them on what's fresh when they do the work,
but it might take a few months between then and when they post, etc.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc v2] update xmon slb code
Will Schmidt writes: > This adds a bit more detail to the xmon SLB output. When the valid bit is > set, This displays the ESID and VSID values, as well as decoding the > segment size. (1T or 256M). This supresses the output for any slb entries > that contain only zeros. > > sample output from power6 (1T segment support): > > 00 c800 40004f7ca3000500 1T ESID= c0 VSID=40004f7ca3 LLP > bits:100 The "4" at the top of the VSID is actually the B (segment size) field, isn't it? Shouldn't that get masked off, since you have already printed the segment size separately? Also, if you removed the "bits" text, it would just about fit into 80 columns. I think "LLP" is sufficient, the "bits" is redundant. Apart from that it looks good. Regards, Paul, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405GP Walnut irq patch
On Tue, 30 Oct 2007 17:41:27 -0400
"Steven A. Falco" <[EMAIL PROTECTED]> wrote:
> From: "Steven A. Falco" <[EMAIL PROTECTED]>
> To: linuxppc-dev@ozlabs.org
> Subject: Re: PPC405GP Walnut irq patch
> Date: Tue, 30 Oct 2007 17:41:27 -0400
> Sender: [EMAIL PROTECTED]
> User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
>
> I realized that I should have done this from the root level. So here is
> the corrected patch.
>
> Signed-off-by: Steve Falco
>
>
> Steven A. Falco wrote:
> > Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
> > the ethernet interrupts in the walnut.dts file doesn't match the
> > documentation. I discovered this when porting the BSP to a custom
> > board - the ethernet would not work. The attached patch corrects that.
> >
> > This is the first patch I am submitting, so please advise me if there
> > is anything I should do differently.
> >
> > Signed-off-by: Steve Falco
> >
> >
>
> diff --git a/arch/powerpc/boot/dts/walnut.dts
> b/arch/powerpc/boot/dts/walnut.dts
> index 27bef06..dd65115 100644
> --- a/arch/powerpc/boot/dts/walnut.dts
> +++ b/arch/powerpc/boot/dts/walnut.dts
> @@ -67,7 +67,7 @@
> num-tx-chans = <2>;
> num-rx-chans = <1>;
> interrupt-parent = <&UIC0>;
> - interrupts = ;
> + interrupts = ;
> };
I fixed this part already. Seems your tree is slightly old.
>
> POB0: opb {
> @@ -117,7 +117,7 @@
> device_type = "network";
> compatible = "ibm,emac-405gp", "ibm,emac";
> interrupt-parent = <&UIC0>;
> - interrupts = <9 4 f 4>;
> + interrupts = ;
Could you redo the patch with just this bit and send it again?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc v2] update xmon slb code
On Tue, Oct 30, 2007 at 04:50:39PM -0500, Will Schmidt wrote: > > [powerpc] update xmon slb code > > This adds a bit more detail to the xmon SLB output. When the valid bit is > set, This displays the ESID and VSID values, as well as decoding the > segment size. (1T or 256M). This supresses the output for any slb entries > that contain only zeros. > > sample output from power6 (1T segment support): > > 00 c800 40004f7ca3000500 1T ESID= c0 VSID=40004f7ca3 LLP > bits:100 > 01 d800 4000eb71b400 1T ESID= d0 VSID=4000eb71b0 LLP > bits: 0 > 03 0800 628021c6ac80 256M ESID=0 VSID= 628021c6a LLP > bits: 0 > 04 0f000800 400095c1e8000c80 1T ESID=f VSID=400095c1e8 LLP > bits: 0 > 22 cf000800 400011b26500 1T ESID= cf VSID=400011b260 LLP > bits:100 > 62 04000800 40005d488d000c80 1T ESID=4 VSID=40005d488d LLP > bits: 0 > 63 1800 633f90285c80 256M ESID=1 VSID= 633f90285 LLP > bits: 0 > > sample output from power5 (notice the non-valid but non-zero entries) > > 00 c800 408f92c94500 256M ESID=c VSID= 408f92c94 LLP > bits:100 > 01 d800 f09b89af5400 256M ESID=d VSID= f09b89af5 LLP > bits: 0 > 03 1000 136eafb0bc80 > 11 0800 5928811f2c80 256M ESID=0 VSID= 5928811f2 LLP > bits: 0 > 12 f800 645ff8d87c80 256M ESID=f VSID= 645ff8d87 LLP > bits: 0 > 13 4800 5c263aa5ec80 256M ESID=4 VSID= 5c263aa5e LLP > bits: 0 > 14 1800 59e7ef80dc80 256M ESID=1 VSID= 59e7ef80d LLP > bits: 0 > 15 1000 59e7ef80dc80 > > Tested on power5 and power6. > > Signed-Off-By: Will Schmidt <[EMAIL PROTECTED]> Acked-by: Olof Johansson <[EMAIL PROTECTED]> This makes the output wider than 80 characters, but that's fine with me. Thanks! -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [powerpc v2] update xmon slb code
On Tue, 2007-10-30 at 16:50 -0500, Will Schmidt wrote:
> [powerpc] update xmon slb code
>
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from power6 (1T segment support):
.../
>
> Tested on power5 and power6.
>
> Signed-Off-By: Will Schmidt <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> This version adds padding around the ESID and VSID fields, and the LLP bits
> are displayed too. (Per request from Olof and Ben).
> I'll try to follow up sometime later with code that will handle decoding page
> sizes. I dont have a testcase handy to properly exercise that yet. :-)
> ---
>
> arch/powerpc/xmon/xmon.c | 27 +--
> 1 files changed, 21 insertions(+), 6 deletions(-)
>
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 121b04d..93c26c3 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address,
> const char *mid,
> static void dump_slb(void)
> {
> int i;
> - unsigned long tmp;
> + unsigned long esid,vsid,valid;
> + unsigned long llp_bits;
>
> printf("SLB contents of cpu %x\n", smp_processor_id());
>
> for (i = 0; i < SLB_NUM_ENTRIES; i++) {
> - asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
> - printf("%02d %016lx ", i, tmp);
> -
> - asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
> - printf("%016lx\n", tmp);
> + asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
> + asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
> + valid = (esid & SLB_ESID_V);
> + if (valid | esid | vsid) {
> + printf("%02d %016lx %016lx", i, esid, vsid);
> + if (valid) {
> + llp_bits = vsid & SLB_VSID_LLP;
> + if (vsid & SLB_VSID_B_1T) {
> + printf(" 1T ESID=%9lx VSID=%10lx LLP
> bits:%3lx \n",
> + GET_ESID_1T(esid),vsid >>
> SLB_VSID_SHIFT_1T,
> + llp_bits);
> + } else {
> + printf(" 256M ESID=%9lx VSID=%10lx LLP
> bits:%3lx \n",
> + GET_ESID(esid),vsid >>
> SLB_VSID_SHIFT,
> + llp_bits);
> + }
> + } else
> + printf("\n");
> + }
> }
> }
>
>
>
> ___
> 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] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
On Tue, 2007-10-30 at 13:59 -0500, Will Schmidt wrote:
> [Powerpc] fix switch_slb handling of 1T ESID values
>
> Now that we have 1TB segment size support, we need to be using the
> GET_ESID_1T macro when comparing ESID values for pc,stack, and
> unmapped_base within switch_slb().A new helper function called
> esids_match() contains the logic for deciding when to call GET_ESID
> and GET_ESID_1T.
>
> This also happens to fix a duplicate-slb-entry inspired machine-check
> exception I was seeing when trying to run java on a power6 partition.
>
> Tested on power6 and power5.
>
> Signed-Off-By: Will Schmidt <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
>
> ---
>
> Just a bit of whitespace cosmetic touchup in this version, as suggested
> by Stephen Rothwell.
> ---
>
> arch/powerpc/mm/slb.c | 34 +++---
> 1 files changed, 31 insertions(+), 3 deletions(-)
>
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index bbd2c51..8cbbfab 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
> slb_flush_and_rebolt();
> }
>
> +/* Helper function to compare esids. There are four cases to handle.
> + * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
> + * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID
> compare.
> + * 3. The system is 1T capable, only one of the two addresses is > 1T. This
> is not a match.
> + * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T
> macro to compare.
> + */
> +static inline int esids_match(unsigned long addr1, unsigned long addr2)
> +{
> + int esid_1t_count;
> +
> + /* System is not 1T segment size capable. */
> + if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + esid_1t_count = (((addr1 >> SID_SHIFT_1T) != 0) +
> + ((addr2 >> SID_SHIFT_1T) != 0));
> +
> + /* both addresses are < 1T */
> + if (esid_1t_count == 0)
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + /* One address < 1T, the other > 1T. Not a match */
> + if (esid_1t_count == 1)
> + return 0;
> +
> + /* Both addresses are > 1T. */
> + return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
> +}
> +
> /* Flush all user entries from the segment table of the current processor. */
> void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> {
> @@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct
> mm_struct *mm)
> return;
> slb_allocate(pc);
>
> - if (GET_ESID(pc) == GET_ESID(stack))
> + if (esids_match(pc,stack))
> return;
>
> if (is_kernel_addr(stack))
> return;
> slb_allocate(stack);
>
> - if ((GET_ESID(pc) == GET_ESID(unmapped_base))
> - || (GET_ESID(stack) == GET_ESID(unmapped_base)))
> + if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
> return;
>
> if (is_kernel_addr(unmapped_base))
>
>
> ___
> 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: libfdt as its own repo and submodule of dtc?
On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote: > Jon Loeliger wrote: >> So, like, the other day Kumar Gala mumbled: >>> Jon, >>> >>> It seems like have libfdt as a unique git repo that is a submodule of >>> the things that need it (dtc, u-boot, etc.) might make some sense and it >>> easier for the projects that need to pull it in. >>> >>> Is this something you can take a look at? (or have other ideas on). >> I would be fine with making libfdt a git repository separate >> from the DTC repository if that makes it easier to integrate >> it with other projects. I don't think it's a good idea to make dtc and libfdt entirely seperate repositories (again). Being able to use both together in their combined testsuite is very useful (libfdt is used to check trees generated by dtc, dtc is used to generate example trees for libfdt testing). I'm not sure how submodules/subrepositories work so I don't know if that makes sense. > That sounds like a good idea to me. I would really prefer pulling patches > out of a libfdt repo into the u-boot repo rather than trying to kerchunk > upgrade lumps. While we can do this with a dtc repo, it potentially makes > it a lot more difficult. I don't think upgrading embedded copies by diff is a good way to go. The upgrade method I had in mind was to pull out a whole new copy of libfdt, drop that into the embedding project verbatim and generate a new diff there in whatever their source tracking system is. I set out the repository to make this easy. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote: [snip] > > Yeah.. what he said. > > > > The *only* substantive change with the "class" proposal is the fact > > that multiple classes can be specified. That's nice, but I don't > > think it's worth the trouble of attempting to define a whole new chunk > > of standard for. > > I tend to agree, but I think device_type serves a useful > purpose. I don't think we should deprecate it. > > > Stuart, I think you overestimate the value of this class property to a > > human reader. The generic names convention (not followed as much as > > it should be) means the name should give the reader some idea of what > > the device is, in most cases. For trickier cases, if we really want > > something for humans reading the tree, we could add an optional > > "comment" or "description" property with purely human readable > > information. > > > > I think we should leave existing IEEE1275 defined uses of device_type, > > in order not to make flat trees gratuitously different from real-OF > > trees, but we should avoid any new use of device_type. > > I'm fine with keeping device_type, but there are a few > of things I don't like about the 'no new use'. > > 1. There are types of nodes that don't have a programming > inteface per se and thus no compatible. > "cpu", "memory", "cache" are 3 that come to mind. Well, yes, this is why I suggested treating these "fundamental" nodes as a special case in an earlier mail. > What if there is a _new_ class of nodes of this type? > What is wrong with a new use of device_type for something > say like "i2c"? Memory and cpu are pretty clearly special cases - if they're not there, you don't have a computer at all. The programming model for "memory" is always the same", and the programming model for the cpu has to be known before reading the device tree anyway. I don't think we need to worry about new classes of such things - i2c is *certainly* not an example of such. cache is a bit weird, because although there can be different types, the programming model is essentially determined by the cpu to which it is attached, and the nodes for cache are really just to give details of sizes and levels. > Conceptually and ideally, what _is_ the right way to > represent these types of devices. > > 2. 'Existing IEEE1275 defined uses' of device_type is > actually very vague. There are a conglomeration of > old bindings, recommended practices, proposals and > it is not clear at all which are useful or not. What > are the existing IEEE1275 uses??? I actually went > through all the OF documents and there are dozens > of device types that have no practical use. > > Also, many 'real-OF' trees seem to follow no published > binding at all. > > Conceptually, I'd like to a crisp list of 'official' > bindings and hope that the current ePAPR work in > power.org will establish this list. Yeah, sorry, I am being a bit vauge here and we do need to be more specific. My point is that if you take a tree from a real OF, with lots of device_type values representing programming interfaces, then flatten it, it shouldn't be considered "bad" as a flattened tree. It's fine if most or all of the device_type values are optional in the flattened tree, so that it's ok whether or not they're present. > 3. You're advocating deprecating device_class, but still > requiring it for certain node types. So a "network" > node is _required_ to have the deprecated > device_type="network". But a "i2c" node is required > _not_ to have device_type. Long term, I'd like to see > any inconsitency be removed. If device_type is > deprecated, it's use should be optional in flat > device trees. That goes for "cpu", "memory", etc. > > I think what we should do is keep device_type, including > permitting new uses of it in a limited way-- only permitting > the use of device_type when there is an official binding > (like in the power.org ePAPR) defined. That's what I was thinking when we first started defining flat tree bindings. But the more time I've spent thinking about it, and the more time I've spent reviewing people's proposed bindings, the less useful I think it is. The *only* reason I'm suggesting leaving device_type values for IEEE1275 defined classes is so that flat trees written as flat trees look more similar to OF derived trees. > > Explicitly specifying what device class bindings / conventions the > > node complies with is cute, but not actually all that useful in > > practice. If it looks like a "duck" class device node, and it > > quacks^Whas the properties of a "duck" class device node, it's "duck" > > class compliant. > > > > Or to look at it another way, "class bindings" aren't really bindings, > > but rather a set of conventions that device bindings for specific > > devices in that class ought to follow. > > I tend to th
Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> PowerPC 440GRx Rainier DTS.
[snip]
> + SDRAM0: sdram {
> + device_type = "memory-controller";
How many times do we need to say it...
Don't make up random device_type values. This does not belong here.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote:
>
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 30, 2007 11:34 AM
> > To: Yoder Stuart-B08248
> > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> > Subject: Re: RFC: replace device_type with new "class" property?
> >
> > On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> > > mpic: [EMAIL PROTECTED] {
> > > clock-frequency = <0>;
> > > interrupt-controller;
> > > #address-cells = <0>;
> > > #interrupt-cells = <2>;
> > > reg = <4 4>;
> > > compatible = "fsl,xyz";
> > > big-endian;
> > > }
> > >
> > > Note-- I removed the device_type property and changed
> > > compatible somewhat. How are you going to find where
> > > the meaning interrupt controller's interrupt cells are
> > > defined? What spec will you look at?
> >
> > The binding for fsl,xyz.
>
> Not every string listed in compatible has a spec
> backing it (or should be required to). You would
> have to go look at the source code and cross your
> fingers that the comments were sufficient.
But that's true in general. open-pic is practically the only time
device_type will let you avoid that.
> Another good reason for device_type-- it helps
> distinguish between two similar classes of devices.
> Both "open-pic" and "isa-pic" look very similar but
> have different encodings of their interrupt cells.
> Without a device_type it may be difficult or impossible
> to distinguish them unless the "name" and
> "compatible" are luckily clear enough.
This is a totally misleading argument. There may be one or two cases
where the device_type is useful, but in most cases device_type will be
either not specific enough to give you the information you need, or it
we add lots of new device_type values, it will be so specific that it
suffers the same problem as looking at name or compatible - you have
to find the finding that goes with a particular device_type.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
>
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the properties of a "duck" class device node, it's "duck"
> > class compliant.
>
> Don't know how cute it is, but I think it is practically
> helpful. Take another example:
>
> Say you-- a human reader-- see this in a device
> tree:
>
> ...
> interrupts = ;
> interrupt-parent = < &mpic >;
> ...
>
> What does the 'b' and '8' mean? You look
> at the interrupt controller node--
>
> mpic: [EMAIL PROTECTED] {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <4 4>;
> compatible = "fsl,xyz";
> big-endian;
> }
>
> Note-- I removed the device_type property and changed
> compatible somewhat. How are you going to find where
> the meaning interrupt controller's interrupt cells are
> defined? What spec will you look at?
>
> device_type = "open-pic"; makes it perfectly clear.
> It's an open-pic type controller and follows that
> binding.
That's an extremely contrived example - it only works because for
historical reasons the "open-pic" device_type describes a programming
model as well as an OF method interface. In general, you always need
to look at a node's "compatible" and the binding for that to work out
what it's properties mean, or if it's an interrupt controller what the
format of its interrupt specifiers is.
open-pic is the *only* example I can think of where device_type will
tell you this. In fact, "open-pic" really belongs in compatible.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: add kexec support
On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote: > > Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17: > > > > > > How do you plan to support kdump? > > > > When kexec is fully supported kdump should work out of the box > as for any other ethernet card (if you load the right eth driver). > There's nothing specific to kdump you have to handle in > ethernet device drivers. > Hope I didn't miss anything here... Perhaps. When we kdump the kernel does not call the reboot notifiers, so the code Jan-Bernd just added won't get called. So the eHEA resources won't be freed. When the kdump kernel tries to load the eHEA driver what will happen? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person 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
[PATCH] [powerpc v2] update xmon slb code
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
sample output from power6 (1T segment support):
00 c800 40004f7ca3000500 1T ESID= c0 VSID=40004f7ca3 LLP
bits:100
01 d800 4000eb71b400 1T ESID= d0 VSID=4000eb71b0 LLP
bits: 0
03 0800 628021c6ac80 256M ESID=0 VSID= 628021c6a LLP
bits: 0
04 0f000800 400095c1e8000c80 1T ESID=f VSID=400095c1e8 LLP
bits: 0
22 cf000800 400011b26500 1T ESID= cf VSID=400011b260 LLP
bits:100
62 04000800 40005d488d000c80 1T ESID=4 VSID=40005d488d LLP
bits: 0
63 1800 633f90285c80 256M ESID=1 VSID= 633f90285 LLP
bits: 0
sample output from power5 (notice the non-valid but non-zero entries)
00 c800 408f92c94500 256M ESID=c VSID= 408f92c94 LLP
bits:100
01 d800 f09b89af5400 256M ESID=d VSID= f09b89af5 LLP
bits: 0
03 1000 136eafb0bc80
11 0800 5928811f2c80 256M ESID=0 VSID= 5928811f2 LLP
bits: 0
12 f800 645ff8d87c80 256M ESID=f VSID= 645ff8d87 LLP
bits: 0
13 4800 5c263aa5ec80 256M ESID=4 VSID= 5c263aa5e LLP
bits: 0
14 1800 59e7ef80dc80 256M ESID=1 VSID= 59e7ef80d LLP
bits: 0
15 1000 59e7ef80dc80
Tested on power5 and power6.
Signed-Off-By: Will Schmidt <[EMAIL PROTECTED]>
---
This version adds padding around the ESID and VSID fields, and the LLP bits
are displayed too. (Per request from Olof and Ben).
I'll try to follow up sometime later with code that will handle decoding page
sizes. I dont have a testcase handy to properly exercise that yet. :-)
---
arch/powerpc/xmon/xmon.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..93c26c3 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address,
const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
+ unsigned long llp_bits;
printf("SLB contents of cpu %x\n", smp_processor_id());
for (i = 0; i < SLB_NUM_ENTRIES; i++) {
- asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
- printf("%02d %016lx ", i, tmp);
-
- asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
- printf("%016lx\n", tmp);
+ asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
+ asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
+ valid = (esid & SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf("%02d %016lx %016lx", i, esid, vsid);
+ if (valid) {
+ llp_bits = vsid & SLB_VSID_LLP;
+ if (vsid & SLB_VSID_B_1T) {
+ printf(" 1T ESID=%9lx VSID=%10lx LLP
bits:%3lx \n",
+ GET_ESID_1T(esid),vsid >>
SLB_VSID_SHIFT_1T,
+ llp_bits);
+ } else {
+ printf(" 256M ESID=%9lx VSID=%10lx LLP
bits:%3lx \n",
+ GET_ESID(esid),vsid >>
SLB_VSID_SHIFT,
+ llp_bits);
+ }
+ } else
+ printf("\n");
+ }
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405GP Walnut irq patch
I realized that I should have done this from the root level. So here is
the corrected patch.
Signed-off-by: Steve Falco
Steven A. Falco wrote:
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom
board - the ethernet would not work. The attached patch corrects that.
This is the first patch I am submitting, so please advise me if there
is anything I should do differently.
Signed-off-by: Steve Falco
diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
index 27bef06..dd65115 100644
--- a/arch/powerpc/boot/dts/walnut.dts
+++ b/arch/powerpc/boot/dts/walnut.dts
@@ -67,7 +67,7 @@
num-tx-chans = <2>;
num-rx-chans = <1>;
interrupt-parent = <&UIC0>;
- interrupts = ;
+ interrupts = ;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
-interrupts = <9 4 f 4>;
+interrupts = ;
reg = ;
mal-device = <&MAL>;
mal-tx-channel = <0 1>;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC405GP Walnut irq patch
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom board
- the ethernet would not work. The attached patch corrects that.
This is the first patch I am submitting, so please advise me if there is
anything I should do differently.
Signed-off-by: Steve Falco
--- walnut.dts.orig 2007-10-30 15:27:49.0 -0400
+++ walnut.dts 2007-10-30 15:29:40.0 -0400
@@ -67,7 +67,7 @@
num-tx-chans = <2>;
num-rx-chans = <1>;
interrupt-parent = <&UIC0>;
- interrupts = ;
+ interrupts = ;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
-interrupts = <9 4 f 4>;
+interrupts = ;
reg = ;
mal-device = <&MAL>;
mal-tx-channel = <0 1>;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)
Hello Stefan, In message <[EMAIL PROTECTED]> you wrote: > > I already have it running on my system using a quick hack (see patch below) > in > include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean > implementation, that has chances for upstream merge (in arch/powerpc later), > I would really like to hear if I should move on further this way. > > My impression is, that changing the name from touch_nmi_watchdog() to > something like touch_watchdog(), and therefore touching lots of files, makes > it more unlikely that this resulting patch will get accepted. But > implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h > header seems also not totally correct, since it's not really an NMI in this > case. Indeed. Using the header file is seriously misleading for the PowerPC version, as is the function name touch_nmi_watchdog() - thius has nothing to do with NMIs on PowerPC, and most probably not on any other non-x86 architecture as well. To make this mechanism generally usable (which is a good idea IMO) the names should be changed to get rid of the "nmi" reference. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] It may be that your whole purpose in life is simply to serve as a warning to others. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
On Wed, 31 Oct 2007 07:16:31 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > Fortunately, we don't support SMP on these or this solution wouldn't > > > work. > > > > We should mark 44x BROKEN on SMP in Kconfig. > > Can we enable SMP on 44x at all currently ? Not without editing the Kconfig.cputypes file. I was thinking of being a bit proactive so people didn't just add || 44x to it and think it would work. But it's minor. > > No arch/ppc fix? I know we all want it to die as soon as possible, but > > still... :) > > Yeah, I didn't do it yet, which is one reason this patch is marked > RFC :-) Fair enough. > > > /* interrupts are hard-disabled at this point */ > > > restore: > > > +#ifdef CONFIG_44x > > > + lis r4,[EMAIL PROTECTED] > > > + lwz r5,[EMAIL PROTECTED](r4) > > > + cmplwi cr0,r5,0 > > > + beq+1f > > > + iccci r0,r0 > > > + li r6,0 > > > + iccci r0,r0 > > > + stw r6,[EMAIL PROTECTED](r4) > > > +1: > > > > Why two iccci's here? > > No idea... thinko/typo. And here I thought you were being extra careful ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
> > Fortunately, we don't support SMP on these or this solution wouldn't > > work. > > We should mark 44x BROKEN on SMP in Kconfig. Can we enable SMP on 44x at all currently ? > No arch/ppc fix? I know we all want it to die as soon as possible, but > still... :) Yeah, I didn't do it yet, which is one reason this patch is marked RFC :-) > > /* interrupts are hard-disabled at this point */ > > restore: > > +#ifdef CONFIG_44x > > + lis r4,[EMAIL PROTECTED] > > + lwz r5,[EMAIL PROTECTED](r4) > > + cmplwi cr0,r5,0 > > + beq+1f > > + iccci r0,r0 > > + li r6,0 > > + iccci r0,r0 > > + stw r6,[EMAIL PROTECTED](r4) > > +1: > > Why two iccci's here? No idea... thinko/typo. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
On Tue, 30 Oct 2007 19:45:11 +0300 Valentine Barshak <[EMAIL PROTECTED]> wrote: > The following patches add PowerPC 440GRx Rainier board support. > The board is almost identical to Sequoia, but doesn't have USB > and FPU is not supported. So why do we need anything other than the DTS and the defconfig? I would think the sequoia wrapper and platform files would suffice completely for this. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
On Tuesday 30 October 2007, Valentine Barshak wrote:
> +static struct of_device_id rainier_of_bus[] = {
> + { .compatible = "ibm,plb4", },
> + { .compatible = "ibm,opb", },
> + { .compatible = "ibm,ebc", },
> + {},
> +};
> +
> +static int __init rainier_device_probe(void)
> +{
> + if (!machine_is(rainier))
> + return 0;
> +
> + of_platform_bus_probe(NULL, rainier_of_bus, NULL);
> +
> + return 0;
> +}
> +device_initcall(rainier_device_probe);
> +
> +static int __init rainier_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + if (!of_flat_dt_is_compatible(root, "amcc,rainier"))
> + return 0;
> +
> + return 1;
> +}
> +
> +define_machine(rainier) {
> + .name = "Rainier",
> + .probe = rainier_probe,
> + .progress = udbg_progress,
> + .init_IRQ = uic_init_tree,
> + .get_irq = uic_get_irq,
> + .restart= ppc44x_reset_system,
> + .calibrate_decr = generic_calibrate_decr,
> +};
Wow, this is getting really small these days. I wonder if we should add two
more generic helpers to turn this into just
define_machine(rainier) {
.name = "Rainier",
.compatible = "amcc,rainier", /* new */
.probe_buses= &4xx_generic_bus_probe, /* new */
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq= uic_get_irq,
.restart= ppc44x_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 05/28] Add cmpxchg64 and cmpxchg64_local to powerpc
Make sure that at least cmpxchg64_local is available on all architectures to use for unsigned long long values. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> Acked-by: Paul Mackerras <[EMAIL PROTECTED]> CC: linuxppc-dev@ozlabs.org --- include/asm-powerpc/system.h |6 ++ 1 file changed, 6 insertions(+) Index: linux-2.6-lttng/include/asm-powerpc/system.h === --- linux-2.6-lttng.orig/include/asm-powerpc/system.h 2007-09-24 10:50:11.0 -0400 +++ linux-2.6-lttng/include/asm-powerpc/system.h2007-09-24 11:01:04.0 -0400 @@ -488,6 +488,12 @@ __cmpxchg_local(volatile void *ptr, unsi */ #define NET_IP_ALIGN 0 #define NET_SKB_PADL1_CACHE_BYTES + +#define cmpxchg64 cmpxchg +#define cmpxchg64_localcmpxchg_local +#else +#include +#define cmpxchg64_local(ptr,o,n) __cmpxchg64_local_generic((ptr), (o), (n)) #endif #define arch_align_stack(x) (x) -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On 10/30/07, Yoder Stuart-B08248 <[EMAIL PROTECTED]> wrote: > Another good reason for device_type-- it helps > distinguish between two similar classes of devices. > Both "open-pic" and "isa-pic" look very similar but > have different encodings of their interrupt cells. > Without a device_type it may be difficult or impossible > to distinguish them unless the "name" and > "compatible" are luckily clear enough. I don't think you want to go down that path. If your compatible list does not uniquely describe what the device is (followed by a list of devices it is compatible with); then it is not specific enough. It's fine for a device driver to go looking at other properties to get more details; but drivers should primarily bind on the compatible list. In other words; device_type and/or class are a coarser grained description of the device than the compatible list. If you match on compatible; why would there be any need at all to look at 'name', 'device_type' or the proposed 'class' properties? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar skb panic when bonding a VLAN interface
Demke Torsten-atd012 <[EMAIL PROTECTED]> wrote: >I tried to ping over a bonded VLAN tagged interface. >(e.g -> ifenslave bond0 eth3.24) [...] >It seems that the skb headroom is to small. How can I solve this? >I could insert skb_realloc_headroom() call, but where it's the best >place then? >What about alignement? What kernel are you using? There was a fix applied to the bonding driver about a year ago to resolve this problem with gianfar: commit 54ef313714070b397d3857289f0fd099b7643631 Author: Jay Vosburgh <[EMAIL PROTECTED]> Date: Fri Sep 22 21:53:39 2006 -0700 [PATCH] bonding: Handle large hard_header_len The bonding driver fails to adjust its hard_header_len when enslaving interfaces. Whenever an interface with a hard_header_len greater than the ETH_HLEN default is enslaved, the potential for an oops exists, and if the oops happens while responding to an arp request, for example, the system panics. GIANFAR devices may use an extended hard_header for VLAN or hardware checksumming. Enslaving such a device and then transmitting over it causes a kernel panic. Patch modified from submitter's original, but submitter agreed with this patch in private email. Signed-off-by: Mark Huth <[EMAIL PROTECTED]> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 30, 2007 11:34 AM
> To: Yoder Stuart-B08248
> Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>
> On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> > mpic: [EMAIL PROTECTED] {
> > clock-frequency = <0>;
> > interrupt-controller;
> > #address-cells = <0>;
> > #interrupt-cells = <2>;
> > reg = <4 4>;
> > compatible = "fsl,xyz";
> > big-endian;
> > }
> >
> > Note-- I removed the device_type property and changed
> > compatible somewhat. How are you going to find where
> > the meaning interrupt controller's interrupt cells are
> > defined? What spec will you look at?
>
> The binding for fsl,xyz.
Not every string listed in compatible has a spec
backing it (or should be required to). You would
have to go look at the source code and cross your
fingers that the comments were sufficient.
Another good reason for device_type-- it helps
distinguish between two similar classes of devices.
Both "open-pic" and "isa-pic" look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be difficult or impossible
to distinguish them unless the "name" and
"compatible" are luckily clear enough.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
[Powerpc] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb().A new helper function called
esids_match() contains the logic for deciding when to call GET_ESID
and GET_ESID_1T.
This also happens to fix a duplicate-slb-entry inspired machine-check
exception I was seeing when trying to run java on a power6 partition.
Tested on power6 and power5.
Signed-Off-By: Will Schmidt <[EMAIL PROTECTED]>
---
Just a bit of whitespace cosmetic touchup in this version, as suggested
by Stephen Rothwell.
---
arch/powerpc/mm/slb.c | 34 +++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..8cbbfab 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
slb_flush_and_rebolt();
}
+/* Helper function to compare esids. There are four cases to handle.
+ * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
+ * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID
compare.
+ * 3. The system is 1T capable, only one of the two addresses is > 1T. This
is not a match.
+ * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T
macro to compare.
+ */
+static inline int esids_match(unsigned long addr1, unsigned long addr2)
+{
+ int esid_1t_count;
+
+ /* System is not 1T segment size capable. */
+ if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ esid_1t_count = (((addr1 >> SID_SHIFT_1T) != 0) +
+ ((addr2 >> SID_SHIFT_1T) != 0));
+
+ /* both addresses are < 1T */
+ if (esid_1t_count == 0)
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ /* One address < 1T, the other > 1T. Not a match */
+ if (esid_1t_count == 1)
+ return 0;
+
+ /* Both addresses are > 1T. */
+ return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct
*mm)
return;
slb_allocate(pc);
- if (GET_ESID(pc) == GET_ESID(stack))
+ if (esids_match(pc,stack))
return;
if (is_kernel_addr(stack))
return;
slb_allocate(stack);
- if ((GET_ESID(pc) == GET_ESID(unmapped_base))
- || (GET_ESID(stack) == GET_ESID(unmapped_base)))
+ if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
return;
if (is_kernel_addr(unmapped_base))
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
Dale Farnsworth wrote: > On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote: >> This commit made an incorrect assumption: >> -- >> Author: Lennert Buytenhek <[EMAIL PROTECTED]> >> Date: Fri Oct 19 04:10:10 2007 +0200 >> >> mv643xx_eth: Move ethernet register definitions into private header >> >> Move the mv643xx's ethernet-related register definitions from >> include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since >> they aren't of any use outside the ethernet driver. >> >> Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]> >> Acked-by: Tzachi Perelstein <[EMAIL PROTECTED]> >> Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> >> -- >> >> arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there. >> >> [EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe >> >> v2.6.24-rc1-138-g0119130 >> >> This patch fixes this by internalizing 3 defines onto pegasos which are >> simply no longer available elsewhere. Without this your compile will fail > > That compile failure was fixed in commit > 30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro. > > However, as I examine that commit, I see that it defines offsets from > the eth block in the chip, rather than the full chip registeri block > as the Pegasos 2 code expects. So, I think it fixes the compile > failure, but leaves the Pegasos 2 broken. > > Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that > the following patch is needed for the Pegasos 2? > > Thanks, > -Dale > > - > > mv643xx_eth: Fix MV643XX_ETH offsets used by Pegasos 2 > > In the mv643xx_eth driver, we now use offsets from the ethernet > register block within the chip, but the pegasos 2 platform still > needs offsets from the full chip's register base address. > > Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> > --- > include/linux/mv643xx_eth.h |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h > index 8df230a..30e11aa 100644 > --- a/include/linux/mv643xx_eth.h > +++ b/include/linux/mv643xx_eth.h > @@ -8,9 +8,9 @@ > #define MV643XX_ETH_NAME "mv643xx_eth" > #define MV643XX_ETH_SHARED_REGS 0x2000 > #define MV643XX_ETH_SHARED_REGS_SIZE 0x2000 > -#define MV643XX_ETH_BAR_40x220 > -#define MV643XX_ETH_SIZE_REG_4 0x224 > -#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x0290 > +#define MV643XX_ETH_BAR_40x2220 > +#define MV643XX_ETH_SIZE_REG_4 0x2224 > +#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x2290 applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
Josh Boyer wrote: > On Tue, 30 Oct 2007 19:45:11 +0300 > Valentine Barshak <[EMAIL PROTECTED]> wrote: > >> The following patches add PowerPC 440GRx Rainier board support. >> The board is almost identical to Sequoia, but doesn't have USB >> and FPU is not supported. > > General FYI, I'm probably going to queue these up for .25. We should > be in bug-fix mode for .24. OK, thanks, Valentine. > > josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] using mii-bitbang on different processor ports
Sergej Stepanov wrote:
> + if( !of_address_to_resource(np, 1, &res[1])) {
The spacing is still wrong.
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
And here.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
On Tue, 30 Oct 2007 19:45:11 +0300 Valentine Barshak <[EMAIL PROTECTED]> wrote: > The following patches add PowerPC 440GRx Rainier board support. > The board is almost identical to Sequoia, but doesn't have USB > and FPU is not supported. General FYI, I'm probably going to queue these up for .25. We should be in bug-fix mode for .24. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] hotplug memory remove - walk_memory_resource for ppc64
Hi KAME,
As I mentioned while ago, ppc64 does not export information about
"system RAM" in /proc/iomem. Looking at the code and usage
scenerios I am not sure what its really serving. Could you
explain what its purpose & how the range can be invalid ?
At least on ppc64, all the memory ranges we get passed comes from
/sysfs memblock information and they are guaranteed to match
device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
and it will be part of the /proc/device-tree entry. Since we do
"online" or "offline" to /sysfs entries to add/remove pages -
these ranges are guaranteed to be valid.
Since this check is redundant for ppc64, I propose following patch.
Is this acceptable ? If some one really really wants, I can code
up this to walk lmb or /proc/device-tree and verify the range &
adjust the entries for overlap (I don't see how that can happen).
Paul & Kame, please comment.
Thanks,
Badari
---
arch/powerpc/Kconfig |3 +++
arch/powerpc/mm/mem.c | 13 +
kernel/resource.c |2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc1/arch/powerpc/mm/mem.c
===
--- linux-2.6.24-rc1.orig/arch/powerpc/mm/mem.c 2007-10-30 07:39:16.0
-0800
+++ linux-2.6.24-rc1/arch/powerpc/mm/mem.c 2007-10-30 10:05:09.0
-0800
@@ -129,6 +129,19 @@ int __devinit arch_add_memory(int nid, u
return __add_pages(zone, start_pfn, nr_pages);
}
+/*
+ * I don't think we really need to do anything here to validate the memory
+ * range or walk the memory resource in lmb or device-tree. Only way we get
+ * the memory range here is through /sysfs in 16MB chunks and we are guaranteed
+ * to have a corresponding device-tree entry.
+ */
+int
+walk_memory_resource(unsigned long start_pfn, unsigned long nr_pages, void
*arg,
+ int (*func)(unsigned long, unsigned long, void *))
+{
+ return (*func)(start_pfn, nr_pages, arg);
+}
+
#endif /* CONFIG_MEMORY_HOTPLUG */
#ifdef CONFIG_MEMORY_HOTREMOVE
Index: linux-2.6.24-rc1/kernel/resource.c
===
--- linux-2.6.24-rc1.orig/kernel/resource.c 2007-10-23 20:50:57.0
-0700
+++ linux-2.6.24-rc1/kernel/resource.c 2007-10-30 08:58:41.0 -0800
@@ -228,7 +228,7 @@ int release_resource(struct resource *ol
EXPORT_SYMBOL(release_resource);
-#ifdef CONFIG_MEMORY_HOTPLUG
+#if defined(CONFIG_MEMORY_HOTPLUG) && !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
/*
* Finds the lowest memory reosurce exists within [res->start.res->end)
* the caller must specify res->start, res->end, res->flags.
Index: linux-2.6.24-rc1/arch/powerpc/Kconfig
===
--- linux-2.6.24-rc1.orig/arch/powerpc/Kconfig 2007-10-30 07:39:17.0
-0800
+++ linux-2.6.24-rc1/arch/powerpc/Kconfig 2007-10-30 08:54:57.0
-0800
@@ -234,6 +234,9 @@ config HOTPLUG_CPU
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_HAS_WALK_MEMORY
+ def_bool y
+
config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] using mii-bitbang on different processor ports
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc: 0x10d40, mdio: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov <[EMAIL PROTECTED]>
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c
b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..eea5feb 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include "fs_enet.h"
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int
dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang->dir, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dir, bitbang->mdio.msk);
else
- bb_clr(bitbang->dir, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dir, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dir);
+ in_be32(bitbang->mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang->dat, bitbang->mdio_msk);
+ return bb_read(bitbang->mdio.dat, bitbang->mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dat, bitbang->mdio.msk);
else
- bb_clr(bitbang->dat, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dat, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdc_msk);
+ bb_set(bitbang->mdc.dat, bitbang->mdc.msk);
else
- bb_clr(bitbang->dat, bitbang->mdc_msk);
+ bb_clr(bitbang->mdc.dat, bitbang->mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -114,23 +118,23 @@ static struct mdiobb_ops bb_ops = {
static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
struct device_node *np)
{
- struct resource res;
+ struct resource res[2];
const u32 *data;
int mdio_pin, mdc_pin, len;
struct bb_info *bitbang = bus->priv;
- int ret = of_address_to_resource(np, 0, &res);
+ int ret = of_address_to_resource(np, 0, &res[0]);
if (ret)
return ret;
- if (res.end - res.start < 13)
+ if (res[0].end - res[0].start < 13)
return -ENODEV;
/* This should really encode the pin number as well, but all
* we get is an int, and the odds of multiple bitbang mdio buses
* is low enough that it's not worth going too crazy.
*/
- bus->id = res.start;
+ bus->id = res[0].start;
data = of_get_property(np, "fsl,mdio-pin", &len);
if (!data || len != 4)
@@ -142,15 +146,32 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus
*bus,
return -ENODEV;
mdc_pin = *data;
- bitbang->dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang->dir)
+ bitbang->mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
+ if (!bitbang->mdc.dir)
return -ENOMEM;
- bitbang->dat = bitbang->dir + 4;
- bitbang->mdio_msk = 1 << (31 - mdio_pin);
- bitbang->mdc_msk = 1 << (31 - mdc_pin);
+ bitbang->mdc.dat = bitbang->mdc.dir + 4;
+ if( !of_address_to_resource(np, 1, &res[1])) {
+ if (res[1].end - res[1].start < 13)
+ goto bad_resource;
+ bitbang->mdio.dir = ioremap(res[1].start, res[1].end -
res[1].start + 1);
+ if (!bitbang->mdio.dir)
+ goto unmap_and_exit;
+ bitbang->mdio.dat = bitbang->mdio.dir + 4;
+
Re: Continued serial headaches
Alan Bennett wrote: > Am I missing something in the PRAM areas? > SMC1 (ttyCPM0...) > e0008000 : 00c000e0 30300020 eefe3e7a > e0008010 : 00c07331 11b6b05f 3044 07f4d082 > e0008020 : 00e3 746562ec d98ceffd 0dec67e3 > e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001 > e0008040 : fc9d d08a > e0008050 : 80008000 80008000 80008000 80008000 > SCC1 > e0008000 : 00c000e0 30300020 eefe3e7a > e0008010 : 00c07331 11b6b05f 3044 07f4d082 > e0008020 : 00e3 746562ec d98ceffd 0dec67e3 > e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001 > e0008040 : fc9d d08a > e0008050 : 80008000 80008000 80008000 80008000 I'm fairly sure you don't want SMC1 and SCC1 to have the same PRAM areas... Assuming that was just a typo, I don't know what could be wrong. You'll just have to debug it. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Continued serial headaches
Well, now that I've got IRQs requestable, I'm back to battling SCC1 / SCC4
initialization,
I've verified the iop structures, and things look set-up correctly.
/* SCC1 */
{2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{3, 31, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
/* SCC4 */
{3, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
I've also verified that upon first use (echo "test" > /dev/ttyCPM[12] the
brgs are configured)
SCC1
cpm_uart_startup:417
CPM uart[1]:startup on IRQ: 40 - request returned 0
cpm_uart_startup:432 CPM uart[1] is scc
CPM uart[1]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119f0:00010140
CPM uart[1]:shutdown
SCC4
cpm_uart_startup:417
CPM uart[2]:startup on IRQ: 43 - request returned 0
cpm_uart_startup:432 CPM uart[2] is scc
CPM uart[2]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119fc:00010140
CPM uart[2]:shutdown
CPM uart[2]:initbd
However, SCC1 continues to get locked.
Am I missing something in the PRAM areas?
SMC1 (ttyCPM0...)
e0008000 : 00c000e0 30300020 eefe3e7a
e0008010 : 00c07331 11b6b05f 3044 07f4d082
e0008020 : 00e3 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001
e0008040 : fc9d d08a
e0008050 : 80008000 80008000 80008000 80008000
SCC1
e0008000 : 00c000e0 30300020 eefe3e7a
e0008010 : 00c07331 11b6b05f 3044 07f4d082
e0008020 : 00e3 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001
e0008040 : fc9d d08a
e0008050 : 80008000 80008000 80008000 80008000
SCC4
e0008300 : 01000120 30300020 30401000 07f4e001
e0008310 : 011f 993fb24d 30004000 07f4e0a2
e0008320 : 0130 0d0a8379 fedddfdc 94a967eb
e0008330 : 5d2b06bd 4708b3ce 0020001f 0001
e0008340 : 2804 e8a6
e0008350 : 80008000 80008000 80008000 80008000
-Alan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Gianfar skb panic when bonding a VLAN interface
Hi, I tried to ping over a bonded VLAN tagged interface. (e.g -> ifenslave bond0 eth3.24) This fails with following output: [EMAIL PROTECTED]:/root> ping 192.168.24.101 PING 192.168.24.skb_under_panic: text:c01bbdf8 len:50 put:8 head:dd27a3a0 data:dd27a39a tail:dd27a3cc end:dd27a3e0 dev:eth3 Oops: Exception in kernel mode, sig: 5 [#1] NIP: C01E9110 LR: C01E9110 SP: C03479F0 REGS: c0347940 TRAP: 0700 Tainted: PF MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 TASK = c03031a0[0] 'swapper' THREAD: c0346000 Last syscall: 120 GPR00: C01E9110 C03479F0 C03031A0 0072 2D03 0030 3FFF GPR08: C037D0AC C034 65F51C00 6000 0FFE3900 C0347A7C GPR16: DFC1FD60 C0347DD0 C0B94800 0FFF3D0C C0347A80 007FD890 GPR24: C0A81865 C0A81805 C0B94800 DFC1FD60 C0B94A40 DF10C128 NIP [c01e9110] skb_under_panic+0x50/0x64 LR [c01e9110] skb_under_panic+0x50/0x64 Call trace: [c01bbe0c] gfar_add_fcb+0x7c/0xb4 [c01bbfc0] gfar_start_xmit+0x160/0x268 [c01c] qdisc_restart+0x100/0x1fc [c01f04c4] dev_queue_xmit+0xc88/0xde0 [c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0 [c01f054c] dev_queue_xmit+0xd10/0xde0 [c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4 [c01b4464] bond_xmit_roundrobin+0x94/0x108 [c01f054c] dev_queue_xmit+0xd10/0xde0 [c022f6cc] arp_xmit+0x5c/0x6c [c022f704] arp_send+0x28/0x38 [c022ef48] arp_solicit+0x1a0/0x1c0 [c01f81b0] neigh_timer_handler+0x294/0x31c [c0043310] run_timer_softirq+0xa7c/0xaec [c0039b68] __do_softirq+0xabc/0x15a0 101 (192.168.24.Kernel panic - not syncing: Aiee, killing interrupt handler! 101) 56(84) byte s of data. Call trace: [c0008258] dump_stack+0x18/0x28 [c002fa50] panic+0xa8/0x190 [c0033690] do_exit+0x3c/0xdec [c0002fb4] _exception+0x0/0x1558 [c0002ff0] _exception+0x3c/0x1558 [c0004d70] ProgramCheckException+0x11c/0x1c4 [c00029ac] ret_from_except_full+0x0/0x4c [c01e9110] skb_under_panic+0x50/0x64 [c01bbe0c] gfar_add_fcb+0x7c/0xb4 [c01bbfc0] gfar_start_xmit+0x160/0x268 [c01c] qdisc_restart+0x100/0x1fc [c01f04c4] dev_queue_xmit+0xc88/0xde0 [c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0 [c01f054c] dev_queue_xmit+0xd10/0xde0 [c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4 Rebooting in 180 seconds.. It seems that the skb headroom is to small. How can I solve this? I could insert skb_realloc_headroom() call, but where it's the best place then? What about alignement? Regards, Torsten ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] using mii-bitbang on different processor ports
Sergej Stepanov wrote: > Hello Scott. > Thank you for reply. > Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood: >> On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote: > >> You could just use of_iomap() for the second one, since we don't need >> the physical address for bus->id. > Nice tip. > Than it would be needless--- > | > \/ >>> + iounmap(bitbang->mdc.dir); >>> + return -ENOMEM; >> Please use the goto-style error handling that's used elsewhere in the >> function. Hmm... in this case, it'd be impossible to tell using of_iomap() whether a failure was due to reg only having one resource (and thus meaning the same one should be used for both), or due to ioremap() failure. Maybe we should keep it separate. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] PowerPC: 440GRx Rainier default config
PowerPC 440GRx Rainier default config. Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> --- arch/powerpc/configs/rainier_defconfig | 868 + 1 files changed, 868 insertions(+) diff -pruN linux-2.6.orig/arch/powerpc/configs/rainier_defconfig linux-2.6/arch/powerpc/configs/rainier_defconfig --- linux-2.6.orig/arch/powerpc/configs/rainier_defconfig 1970-01-01 03:00:00.0 +0300 +++ linux-2.6/arch/powerpc/configs/rainier_defconfig2007-10-30 18:19:59.0 +0300 @@ -0,0 +1,868 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.24-rc1 +# Tue Oct 30 18:19:49 2007 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +CONFIG_44x=y +# CONFIG_E200 is not set +CONFIG_4xx=y +CONFIG_BOOKE=y +CONFIG_PTE_64BIT=y +CONFIG_PHYS_64BIT=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_NOT_COHERENT_CACHE=y +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +CONFIG_PPC_DCR_NATIVE=y +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_PPC_DCR=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Platform support +# +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +# CONFIG_BAMBOO is not set +# CONFIG_EBONY is not set +# CONFIG_SEQUOIA is not set +CONFIG_RAINIER=y +CONFIG_440GRX=y +CONFIG_440A=y +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +# CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_MATH_EMULATION=y +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_F
[PATCH 3/4] PowerPC: 440GRx Rainier board support.
PowerPC 440GRx Rainier board support.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig | 16 -
arch/powerpc/platforms/44x/Makefile |3 +
arch/powerpc/platforms/44x/rainier.c | 61 +++
3 files changed, 78 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig
linux-2.6/arch/powerpc/platforms/44x/Kconfig
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig 2007-10-30
17:44:42.0 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig2007-10-30
18:04:28.0 +0300
@@ -22,6 +22,14 @@ config SEQUOIA
help
This option enables support for the AMCC PPC440EPX evaluation board.
+config RAINIER
+ bool "Rainier"
+ depends on 44x
+ default n
+ select 440GRX
+ help
+ This option enables support for the AMCC PPC440GRX evaluation board.
+
#config LUAN
# bool "Luan"
# depends on 44x
@@ -52,6 +60,12 @@ config 440EPX
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII
+config 440GRX
+ bool
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+ select IBM_NEW_EMAC_ZMII
+
config 440GP
bool
select IBM_NEW_EMAC_ZMII
@@ -64,7 +78,7 @@ config 440SP
config 440A
bool
- depends on 440GX || 440EPX
+ depends on 440GX || 440EPX || 440GRX
default y
# 44x errata/workaround config symbols, selected by the CPU models above
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/Makefile
linux-2.6/arch/powerpc/platforms/44x/Makefile
--- linux-2.6.orig/arch/powerpc/platforms/44x/Makefile 2007-10-30
17:44:42.0 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/Makefile 2007-10-30
18:00:15.0 +0300
@@ -1,4 +1,5 @@
obj-$(CONFIG_44x) := misc_44x.o
obj-$(CONFIG_EBONY)+= ebony.o
-obj-$(CONFIG_BAMBOO) += bamboo.o
+obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
+obj-$(CONFIG_RAINIER) += rainier.o
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/rainier.c
linux-2.6/arch/powerpc/platforms/44x/rainier.c
--- linux-2.6.orig/arch/powerpc/platforms/44x/rainier.c 1970-01-01
03:00:00.0 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30
18:00:15.0 +0300
@@ -0,0 +1,61 @@
+/*
+ * Rainier board specific routines
+ *
+ * Valentine Barshak <[EMAIL PROTECTED]>
+ * Copyright 2007 MontaVista Software Inc.
+ *
+ * Based on the Bamboo code by
+ * Josh Boyer <[EMAIL PROTECTED]>
+ * Copyright 2007 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "44x.h"
+
+static struct of_device_id rainier_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init rainier_device_probe(void)
+{
+ if (!machine_is(rainier))
+ return 0;
+
+ of_platform_bus_probe(NULL, rainier_of_bus, NULL);
+
+ return 0;
+}
+device_initcall(rainier_device_probe);
+
+static int __init rainier_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "amcc,rainier"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(rainier) {
+ .name = "Rainier",
+ .probe = rainier_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] using mii-bitbang on different processor ports
Hello Scott. Thank you for reply. Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood: > On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote: > You could just use of_iomap() for the second one, since we don't need > the physical address for bus->id. Nice tip. Than it would be needless--- | \/ > > + iounmap(bitbang->mdc.dir); > > + return -ENOMEM; > > Please use the goto-style error handling that's used elsewhere in the > function. Regards Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] PowerPC: 440GRx Rainier DTS.
PowerPC 440GRx Rainier DTS.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/rainier.dts | 312 ++
1 files changed, 312 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts
linux-2.6/arch/powerpc/boot/dts/rainier.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts1970-01-01
03:00:00.0 +0300
+++ linux-2.6/arch/powerpc/boot/dts/rainier.dts 2007-10-30 18:00:15.0
+0300
@@ -0,0 +1,312 @@
+/*
+ * Device Tree Source for AMCC Rainier
+ *
+ * Based on Sequoia code
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ *
+ * FIXME: Draft only!
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,rainier";
+ compatible = "amcc,rainier";
+ dcr-parent = <&/cpus/PowerPC,[EMAIL PROTECTED]>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-440grx","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-440grx","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-440grx","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-440grx", "ibm,sdr-440ep";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-440grx", "ibm,cpr-440ep";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-440grx", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ device_type = "memory-controller";
+ compatible = "ibm,sdram-440grx",
"ibm,sdram-44x-ddr2denali";
+ dcr-reg = <010 2>;
+ };
+
+ DMA0: dma {
+ compatible = "ibm,dma-440grx", "ibm,dma-4xx";
+ dcr-reg = <100 027>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-440grx", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = ;
+ interrupt-map-mask = ;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-440grx", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = < 1 8000
+ 8000 1 8000 8000>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <7 4>;
+ clock-freq
[PATCH 1/4] PowerPC: 440GRx Rainier bootwrapper.
Bootwrapper code for PowerPC 440GRx Rainier board.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile |3 +
arch/powerpc/boot/cuboot-rainier.c | 56 +
2 files changed, 58 insertions(+), 1 deletion(-)
diff -pruN linux-2.6.orig/arch/powerpc/boot/cuboot-rainier.c
linux-2.6/arch/powerpc/boot/cuboot-rainier.c
--- linux-2.6.orig/arch/powerpc/boot/cuboot-rainier.c 1970-01-01
03:00:00.0 +0300
+++ linux-2.6/arch/powerpc/boot/cuboot-rainier.c2007-10-30
18:00:15.0 +0300
@@ -0,0 +1,56 @@
+/*
+ * Old U-boot compatibility for Rainier
+ *
+ * Valentine Barshak <[EMAIL PROTECTED]>
+ * Copyright 2007 MontaVista Software, Inc
+ *
+ * Based on Ebony code by David Gibson <[EMAIL PROTECTED]>
+ * Copyright IBM Corporation, 2007
+ *
+ * Based on Bamboo code by Josh Boyer <[EMAIL PROTECTED]>
+ * Copyright IBM Corporation, 2007
+ *
+ * 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; version 2 of the License
+ */
+
+#include
+#include
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+
+static void rainier_fixups(void)
+{
+ unsigned long sysclk = ;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200);
+ ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
+ ibm4xx_denali_fixup_memsize();
+ dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ platform_ops.fixups = rainier_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ ft_init(_dtb_start, 0, 32);
+ serial_console_init();
+}
diff -pruN linux-2.6.orig/arch/powerpc/boot/Makefile
linux-2.6/arch/powerpc/boot/Makefile
--- linux-2.6.orig/arch/powerpc/boot/Makefile 2007-10-30 17:44:27.0
+0300
+++ linux-2.6/arch/powerpc/boot/Makefile2007-10-30 18:00:15.0
+0300
@@ -56,7 +56,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
- fixed-head.S ep88xc.c cuboot-hpc2.c
+ fixed-head.S ep88xc.c cuboot-hpc2.c cuboot-rainier.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -158,6 +158,7 @@ image-$(CONFIG_MPC7448HPC2) += cuImage.
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA)+= cuImage.sequoia
+image-$(CONFIG_RAINIER)+= cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] PowerPC: 440GRx Rainier board support.
The following patches add PowerPC 440GRx Rainier board support. The board is almost identical to Sequoia, but doesn't have USB and FPU is not supported. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] Add device-tree aware NDFC driver
On Tue, 30 October 2007 17:13:08 +0300, Valentine Barshak wrote: > > I'm not saying my approach is the best, but I was hoping for a discussion. That is good. So please take a moment to listen. > I've reworked the patches according to the comments to the previous > version and used my arguments to explain why I don't see much reason to > mess with the code we currently have and added a separate _of version. Ok. > This is the last time I disturb you with my e-mail, so please, forget it. Thomas words were harsh. Nothing unusual so far. Some people deserve harsh words, some don't and some simply are doing a good job to invite them. You mails so far were inviting harsh words. So how did you invite harsh words and what can you change to prevent this in the future? 1. Develop a thicker skin. No matter how well you do, there will always be the occasional harsh words, deserved or not. It is ok to get angry and call the person names - but do that at home and leave it out of your responses. Ignore the flamebait, at least in public. 2. Follow local customs. In particular you should follow the style of discussion commonly used in mailing lists: >>> I'm doing this. >> Crap! Never do that! > Why not? Can you explain? Because... >>> Then I do that. >> Wouldn't ABCD be better? > ABCD wouldn't work for me because of XYZ. Fair enough. Respond to individual comments _directly_following_the_comment_ do not collect comments from 10 mails, then respond to them all in a long paragraph. Noone will read that. I didn't read it either. 3. Be concise. When quoting someone, remove everything but the relevant bits. Respond only with relevant information. People regularly read 10+ mailing lists. Their attention span is short. If you manage to annoy them with irrelevant information in the first 10 lines, they will skip any amount of wisdom below. 4. Be polite. Even if the responses you get are not. Flamewars get you nowhere. 5. Have sound technical arguments. "mtd concat adds a slight overhead" is not for two reasons. First, it is lacking numbers. People's guesses about perceived overhead or usually wrong, so knowledgeable readers will immediately question such arguments. Secondly, you didn't explain _why_ mtdconcat adds overhead. In particular, why didn't you reduce the mtdconcat overhead instead of essentially copying its functionality? 6. Be structured. Empty lines are cheap. Use them. Add structure to your mails. Above you can see several paragraphs. You can quickly go back to a previous one. You can skip one after reading just the first sentence. After several attempts I still haven't read your 46-line monologue. I don't even know how far I made it because it is so damn hard to find the spot again. If you are willing to change the style of your mails, maybe people will actually read them and respond to you in ways you expected. Otherwise it may indeed be a wise choice not to come back. Some people simply just don't get along. Sometimes a proxy is needed to translate between people. But my hope is that you are willing and able to work with us directly. Jörn -- There is no worse hell than that provided by the regrets for wasted opportunities. -- Andre-Louis Moreau in Scarabouche ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> mpic: [EMAIL PROTECTED] {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <4 4>;
> compatible = "fsl,xyz";
> big-endian;
> }
>
> Note-- I removed the device_type property and changed
> compatible somewhat. How are you going to find where
> the meaning interrupt controller's interrupt cells are
> defined? What spec will you look at?
The binding for fsl,xyz.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> Explicitly specifying what device class bindings / conventions the
> node complies with is cute, but not actually all that useful in
> practice. If it looks like a "duck" class device node, and it
> quacks^Whas the properties of a "duck" class device node, it's "duck"
> class compliant.
Don't know how cute it is, but I think it is practically
helpful. Take another example:
Say you-- a human reader-- see this in a device
tree:
...
interrupts = ;
interrupt-parent = < &mpic >;
...
What does the 'b' and '8' mean? You look
at the interrupt controller node--
mpic: [EMAIL PROTECTED] {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <4 4>;
compatible = "fsl,xyz";
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
device_type = "open-pic"; makes it perfectly clear.
It's an open-pic type controller and follows that
binding.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: > Jan Dittmer <[EMAIL PROTECTED]> writes: > >> Your mail from 2007-10-29 4:39 pm (CET) >> Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). >> See the 'still' ? > > How would the compiler know whether to generate 64bit or 32bit code?? ... and it works again with .24-rc1-git6. So whatever the problem was. Consider it resolved. Jan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Andreas Schwab wrote: > Jan Dittmer <[EMAIL PROTECTED]> writes: > >> Your mail from 2007-10-29 4:39 pm (CET) >> Your compiler still needs -m32 to generate 32-bit code (or use --with-cpu=default32 to make that the default). >> See the 'still' ? > > How would the compiler know whether to generate 64bit or 32bit code?? Andreas, I think we both got a bit lost. Lets take a step back. The original problem was that after 2.6.23 cross compiling powerpc/g5_defconfig broke (Regression). Using gcc 4.0.4, powerpc64 target as cross compiler and powerpc target as 32-bit cross compiler. Since 2.6.23-git1 it is now broken. Using gcc 4.1.2 didn't fix this. Neither with "--with-cpu=default32" present nor without. So could you please explain to me how I'm supposed to cross compile powerpc/g5_defconfig now? Passing CFLAGS=-m32 didn't help too. Or is it just a new bug in the kernel make system? Just for reference up till 2.6.23 I used the following command: make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- \ CROSS32_COMPILE=powerpc-linux- Thanks, Jan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] using mii-bitbang on different processor ports
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc-offset: 0x10d40, mdio-offset: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 0x10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov <[EMAIL PROTECTED]>
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c
b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..86b73ea 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include "fs_enet.h"
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int
dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang->dir, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dir, bitbang->mdio.msk);
else
- bb_clr(bitbang->dir, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dir, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dir);
+ in_be32(bitbang->mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang->dat, bitbang->mdio_msk);
+ return bb_read(bitbang->mdio.dat, bitbang->mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dat, bitbang->mdio.msk);
else
- bb_clr(bitbang->dat, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dat, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdc_msk);
+ bb_set(bitbang->mdc.dat, bitbang->mdc.msk);
else
- bb_clr(bitbang->dat, bitbang->mdc_msk);
+ bb_clr(bitbang->mdc.dat, bitbang->mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -114,23 +118,23 @@ static struct mdiobb_ops bb_ops = {
static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
struct device_node *np)
{
- struct resource res;
+ struct resource res[2];
const u32 *data;
int mdio_pin, mdc_pin, len;
struct bb_info *bitbang = bus->priv;
- int ret = of_address_to_resource(np, 0, &res);
+ int ret = of_address_to_resource(np, 0, &res[0]);
if (ret)
return ret;
- if (res.end - res.start < 13)
+ if (res[0].end - res[0].start < 13)
return -ENODEV;
/* This should really encode the pin number as well, but all
* we get is an int, and the odds of multiple bitbang mdio buses
* is low enough that it's not worth going too crazy.
*/
- bus->id = res.start;
+ bus->id = res[0].start;
data = of_get_property(np, "fsl,mdio-pin", &len);
if (!data || len != 4)
@@ -142,13 +146,27 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus
*bus,
return -ENODEV;
mdc_pin = *data;
- bitbang->dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang->dir)
+ bitbang->mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
+ if (!bitbang->mdc.dir)
return -ENOMEM;
- bitbang->dat = bitbang->dir + 4;
- bitbang->mdio_msk = 1 << (31 - mdio_pin);
- bitbang->mdc_msk = 1 << (31 - mdc_pin);
+ bitbang->mdc.dat = bitbang->mdc.dir + 4;
+ if( !of_address_to_resource(np, 1, &res[1]))
+ {
+ bitbang->mdio.dir = ioremap(res[1].start, res[1].end -
res[1].start + 1);
+ if (!bitbang->mdio.dir)
+ {
+ iounmap(bitbang->mdc.dir);
+ return -ENOMEM;
+ }
+ bitbang->mdio.dat = bitbang->mdio.dir
Re: libfdt as its own repo and submodule of dtc?
So, like, the other day Kumar Gala mumbled: > Jon, > > It seems like have libfdt as a unique git repo that is a submodule of > the things that need it (dtc, u-boot, etc.) might make some sense and > it easier for the projects that need to pull it in. > > Is this something you can take a look at? (or have other ideas on). I would be fine with making libfdt a git repository separate from the DTC repository if that makes it easier to integrate it with other projects. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
Grant Likely wrote: > On 10/29/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote: >> David Gibson wrote: >>> On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote: Grant Likely wrote: > On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote: >>> [snip] >> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc" >> partition could not be used. "big-fs", because the memory is too small >> (which is OK) and "misc", because it overlaps 1 MiB over the physikal >> flash border. So only the first 9 MiB of the flash could be used in >> Linux. >> The remaining 7 MiB couldn't be accessed. > Perhaps it would be better to drop the flash layout from the in-kernel > dts files entirely since flash layout can be a fluid thing. Well, but that would not be really user friendly, I'd rather stick with some default config. >>> Strictly speaking the device-tree is not the right place for flash >>> partitioning information. We put it there because it's preferable to >>> having hardcoded per-board flash layouts in the code itself. >>> >>> It only really works well, though, when there are strong conventions >>> (shared with the firmware) about how to partition the flash. >>> >>> Where it's really up to the user to determine how they want to lay out >>> their flash, putting things in the device tree isn't a really good >>> idea. >> In principle, you are right, we should not be putting a user dependent >> configuration into .dts files. But on the other hand, bindings have >> been defined for flash-like devices and their partition layouts and >> physmap_of device driver is expecting to get this information from the >> blob. So, it is the place for it. But if we are not to put partition >> layouts into the default kernel .dts files then we should >> provide/maintain some examples an that may be a even bigger mess. >> >>> Incidentally, it's not required that *all* the flash address space be >>> in partitions, so it is possible only give partitions for those flash >>> chunks which the firmware needs to know about. >> That might be nicer solution but different variants of TQM5200 boards >> do not share the same subset of partitions (default u-boot partitions >> at least), so it will not help much. > > It's probably more appropriate to have the flash partition layout in > the u-boot environment and have u-boot populate the partition > information in the device tree. Yes, it's more appropriate but such feature is not currently available in U-boot, so it has to be hand crafted until then. It just seemed more convenient to have some reference example before there is a support for passing partition layout from firmware. But all right, will remove flash layouts from in-kernel .dts files. Cheers, m. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfdt as its own repo and submodule of dtc?
Jon, It seems like have libfdt as a unique git repo that is a submodule of the things that need it (dtc, u-boot, etc.) might make some sense and it easier for the projects that need to pull it in. Is this something you can take a look at? (or have other ideas on). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> -Original Message- > From: David Gibson [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 7:52 PM > To: Olof Johansson > Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > > On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote: > [snip] > > I don't see how switching the property name from "device_type" to > > "class" is going to stop people from misunderstanding it's intended > > use. There's nothing inherently more understandable in calling it > > "class" -- it also invites people to make up their own class names > > as they go along, just as what happened to "device_type". > > > > I also don't understand the people wanting to use "compatible" > > for _everything_. It's just mashing together two separate pieces of > > information into one property, and I seriously don't see > how that helps > > anything or anyone. It's absolutely useless for a driver to > be able to > > bind to a compatible field of "standard,network" or > whatever it might be, > > since there's no way that "standard," will imply that the > register layout > > and programming model is somehow the same as all other > standard-labelled > > devices. > > > > So yes, there is a problem with the device trees and how > people build > > them, and it requires education on how to properly craft > one. I don't > > think changing the layout to either be flatter (only using > compatible), > > or changing names of a property (device_type->class) will > help anything > > at all. > > > > I actually prefer keeping device_type myself, since it > means existing > > OF-based device trees will already have some of the labels. > > Yeah.. what he said. > > The *only* substantive change with the "class" proposal is the fact > that multiple classes can be specified. That's nice, but I don't > think it's worth the trouble of attempting to define a whole new chunk > of standard for. I tend to agree, but I think device_type serves a useful purpose. I don't think we should deprecate it. > Stuart, I think you overestimate the value of this class property to a > human reader. The generic names convention (not followed as much as > it should be) means the name should give the reader some idea of what > the device is, in most cases. For trickier cases, if we really want > something for humans reading the tree, we could add an optional > "comment" or "description" property with purely human readable > information. > > I think we should leave existing IEEE1275 defined uses of device_type, > in order not to make flat trees gratuitously different from real-OF > trees, but we should avoid any new use of device_type. I'm fine with keeping device_type, but there are a few of things I don't like about the 'no new use'. 1. There are types of nodes that don't have a programming inteface per se and thus no compatible. "cpu", "memory", "cache" are 3 that come to mind. What if there is a _new_ class of nodes of this type? What is wrong with a new use of device_type for something say like "i2c"? Conceptually and ideally, what _is_ the right way to represent these types of devices. 2. 'Existing IEEE1275 defined uses' of device_type is actually very vague. There are a conglomeration of old bindings, recommended practices, proposals and it is not clear at all which are useful or not. What are the existing IEEE1275 uses??? I actually went through all the OF documents and there are dozens of device types that have no practical use. Also, many 'real-OF' trees seem to follow no published binding at all. Conceptually, I'd like to a crisp list of 'official' bindings and hope that the current ePAPR work in power.org will establish this list. 3. You're advocating deprecating device_class, but still requiring it for certain node types. So a "network" node is _required_ to have the deprecated device_type="network". But a "i2c" node is required _not_ to have device_type. Long term, I'd like to see any inconsitency be removed. If device_type is deprecated, it's use should be optional in flat device trees. That goes for "cpu", "memory", etc. I think what we should do is keep device_type, including permitting new uses of it in a limited way-- only permitting the use of device_type when there is an official binding (like in the power.org ePAPR) defined. > Explicitly specifying what device class bindings / conventions the > node complies with is cute, but not actually all that useful in > practice. If it looks like a "duck" class device node, and it > quacks^Whas the properties of a "duck" class device node, it's "duck" > class compliant. > > Or to look at it another way, "class bindings" aren't really bindings, > but rather a set of conventions that device bindings for specific > devices in that class ought to follow. I tend to think of a 'bindi
Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
Hello.
Kumar Gala wrote:
>>The decrementer in Book E and 4xx processors interrupts on the
>>transition from 1 to 0, rather than on the 0 to -1 transition as on
>>64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors.
>>This fixes the problem by making set_dec subtract 1 from the count for
>>server and classic processors. Since set_dec already had a bunch of
>>ifdefs to handle different processor types, there is no net increase
>>in ugliness. :)
>>This also removes a redundant call to set the decrementer to
>>0x7fff - it was already set to that earlier in timer_interrupt.
>>Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
>>---
> ...
>>diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
>>index f058955..eed64bd 100644
>>--- a/include/asm-powerpc/time.h
>>+++ b/include/asm-powerpc/time.h
>>@@ -183,6 +183,7 @@ static inline void set_dec(int val)
>> #elif defined(CONFIG_8xx_CPU6)
>> set_dec_cpu6(val);
>> #else
>>+ --val; /* classic decrementer interrupts when dec goes negative */
>> #ifdef CONFIG_PPC_ISERIES
>> int cur_dec;
> Unless I'm reading set_dec() you are getting --val on booke.
You meant "misreading"?
Indeed the patch is decrementing count for *both* book E and classic CPUs
now, and that slipped past my attention the first time. The patch summary
("Fix off-by-one error in setting decrementer on Book E") also looks stange --
there is *no* off-by-one error on Book E, and the description correctly says
that we're fixing off-by-one on classic/server CPUs.
Maybe I should even go and post my patch variant instead...
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] Add device-tree aware NDFC driver
Thomas Gleixner wrote: > On Mon, 29 Oct 2007, Valentine Barshak wrote: > >> This adds a device-tree aware PowerPC 44x NanD Flash Controller driver >> The code is based on the original NDFC driver by Thomas Gleixner, but >> since it's been changed much and has initialization/clean-up completely >> reworked it's been put into a separate ndfc_of.c file. This version >> supports both separate mtd devices on each chip attached to NDFC banks and >> single mtd device spread across identical chips (not using mtdconcat) as >> well. >> The choice is selected with device tree settings. This has been tested >> on PowerPC 440EPx Sequoia board. >> Any comments are greatly appreciated. > > Did I express myself not clear enough in my first reply or is this > just a repeated epiphany in my inbox ? > > You got plenty of comments to your patches, but you decided to ignore > them silently. > > Darn, fix it the right way once and forever and please don't try to > tell me another heartrending "why I did it my way" story. > > This all can be done with a nice series of incremental patches > including a fixup to the existing users. > > We have enough dump and run shit in the kernel already. > > No thanks, > >tglx You know, you're really too tense Thomas. I'm not sure of the reason why you're being a complete nerve, but I'm feeling sorry for you. I'm not saying my approach is the best, but I was hoping for a discussion. I've reworked the patches according to the comments to the previous version and used my arguments to explain why I don't see much reason to mess with the code we currently have and added a separate _of version. I'm sure you'd find some time to do it yourself "the right way once and forever" with a "nice series of incremental patches" to fix what we currently have (call it a "dump" or anything you like) and even maybe add new device tree support. I'm sorry if for some reason I've made you feel bad. This is the last time I disturb you with my e-mail, so please, forget it. Thank you very much for your comments anyway. It's been nice talking to you, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Correctly handle versions > 17
So, like, the other day David Gibson mumbled: > If future dtb version > 17 are defined, that are still backwards > compatible with v16, libfdt will of course be able to read and > understand them. However, when modifying such a tree, it can't > guarantee that it won't clobber additional structure from the new > version which it doesn't know about. Therefore, before making > modifications to a tree of version >17, we must change it's version to > be exactly 17. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Remove leftover debugging printf() from mangle-layout
So, like, the other day David Gibson mumbled: > The mangle-layout testcase/utility had a leftover debugging printf(). > This patch removes it. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)
[added linuxppc-dev since it's PPC relevant too]
On Tuesday 30 October 2007, Josh Boyer wrote:
> On Mon, 29 Oct 2007 15:45:03 -0400
>
> [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> > On Mon, Oct 29, 2007 at 03:22:27PM +0100, Stefan Roese wrote:
> > > I'm trying to implement support for a board specific watchdog on a
> > > PPC440EPx board with a very short timeout. In this case, the watchdog
> > > has to be "kicked" at least every 100ms, even while booting and the
> > > real watchdog driver not running yet. While looking for trigger places
> > > in the kernel source, I noticed the already existing
> > > "touch_nmi_watchdog()" function, which seems to be doing what I need.
> > > Even if the name not exactly matches my hardware setup.
> > >
> > > My question now is, is it recommended to use this
> > > touch_nmi_watchdog() "infrastructure" for my PPC custom specific
> > > watchdog during bootup? And if yes, should it perhaps be renamed to a
> > > more generic name, like "touch_watchdog"?
> > >
> > > Please advise. Thanks.
> >
> > No idea really. Who would design a watchdog with such a short trigger
> > time? That doesn't seem to be useful in any way.
It definitely is useful in our case, since its a requirement for
this "critical" project. It's not needed to have such a short trigger time
while booting, but unfortunately this external watchdog only supports one
fixed timeout.
> To some degree, it's configurable.
No, I'm afraid it's not configurable in this case.
> But the generic question still
> stands. It seems like a decent idea to me. Making touch_watchdog (or
> whatever it winds up being called) nice across arches might be fun.
I already have it running on my system using a quick hack (see patch below) in
include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean
implementation, that has chances for upstream merge (in arch/powerpc later),
I would really like to hear if I should move on further this way.
My impression is, that changing the name from touch_nmi_watchdog() to
something like touch_watchdog(), and therefore touching lots of files, makes
it more unlikely that this resulting patch will get accepted. But
implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h
header seems also not totally correct, since it's not really an NMI in this
case.
Any thoughts on this?
Thanks.
Best regards,
Stefan
diff --git a/include/asm-ppc/nmi.h b/include/asm-ppc/nmi.h
new file mode 100644
index 000..f18862b
--- /dev/null
+++ b/include/asm-ppc/nmi.h
@@ -0,0 +1,16 @@
+/*
+ * linux/include/asm-ppc/nmi.h
+ */
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#ifdef BOARD_WATCHDOG_FUNC
+#define touch_nmi_watchdog BOARD_WATCHDOG_FUNC
+#else
+static inline void touch_nmi_watchdog(void)
+{
+ touch_softlockup_watchdog();
+}
+#endif
+
+#endif /* ASM_NMI_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
On Tue, 30 Oct 2007 16:16:54 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > The 44x family has an interesting "feature" which is a virtually > tagged instruction cache (yuck !). So far, we haven't dealt with > it properly, which means we've been mostly lucky or people didn't > report the problems, unless people have been running custom patches > in their distro... > > This is an attempt at fixing it properly. I chose to do it by > setting a global flag whenever we change a PTE that was previously > marked executable, and flush the entire instruction cache upon > return to user space when that happens. > > This is a bit heavy handed, but it's hard to do more fine grained > flushes as the icbi instruction, on those processor, for some very > strange reasons (since the cache is virtually mapped) still requires > a valid TLB entry for reading in the target address space, which > isn't something I want to deal with. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > Fortunately, we don't support SMP on these or this solution wouldn't > work. We should mark 44x BROKEN on SMP in Kconfig. > > It does mean we do a bit of over-flushing on swap but on the > other hand, the code is simple. Another option would have been > to do the iccci after any syscall that potentially unmaps or > changes a mapping, like sys_munmap, sys_mremap, sys_sbrk, but > also the shmem stuff etc... I decided there was just too many > and was worried I would miss one. > > This not very tested as I don't have a test case at hand showing the > problem and didn't feel like writing one today :-) It boots though. > > Careful eyes will notice I didn't do the flush on fast_exception_return, > which shouldn't be necessary. > > arch/powerpc/kernel/entry_32.S | 25 + > arch/powerpc/kernel/misc_32.S |9 + > arch/powerpc/mm/44x_mmu.c |1 + > include/asm-powerpc/pgtable-ppc32.h | 13 + > 4 files changed, 48 insertions(+) No arch/ppc fix? I know we all want it to die as soon as possible, but still... :) > Index: linux-work/arch/powerpc/kernel/entry_32.S > === > --- linux-work.orig/arch/powerpc/kernel/entry_32.S2007-10-15 > 11:19:35.0 +1000 > +++ linux-work/arch/powerpc/kernel/entry_32.S 2007-10-30 16:09:51.0 > +1100 > @@ -244,6 +244,13 @@ syscall_exit_cont: > andis. r10,r0,[EMAIL PROTECTED] > bnel- load_dbcr0 > #endif > +#ifdef CONFIG_44x > + lis r4,[EMAIL PROTECTED] > + lwz r5,[EMAIL PROTECTED](r4) > + cmplwi cr0,r5,0 > + bne-2f > +1: > +#endif /* CONFIG_44x */ > stwcx. r0,0,r1 /* to clear the reservation */ > lwz r4,_LINK(r1) > lwz r5,_CCR(r1) > @@ -259,6 +266,13 @@ syscall_exit_cont: > SYNC > RFI > > +#ifdef CONFIG_44x > +2: li r7,0 > + iccci r0,r0 > + stw r7,[EMAIL PROTECTED](r4) > + b 1b > +#endif /* CONFIG_44x */ > + > 66: li r3,-ENOSYS > b ret_from_syscall > > @@ -683,6 +697,17 @@ resume_kernel: > > /* interrupts are hard-disabled at this point */ > restore: > +#ifdef CONFIG_44x > + lis r4,[EMAIL PROTECTED] > + lwz r5,[EMAIL PROTECTED](r4) > + cmplwi cr0,r5,0 > + beq+1f > + iccci r0,r0 > + li r6,0 > + iccci r0,r0 > + stw r6,[EMAIL PROTECTED](r4) > +1: Why two iccci's here? > +#endif /* CONFIG_44x */ > lwz r0,GPR0(r1) > lwz r2,GPR2(r1) > REST_4GPRS(3, r1) > Index: linux-work/arch/powerpc/mm/44x_mmu.c > === > --- linux-work.orig/arch/powerpc/mm/44x_mmu.c 2007-09-28 11:42:05.0 > +1000 > +++ linux-work/arch/powerpc/mm/44x_mmu.c 2007-10-30 15:30:50.0 > +1100 > @@ -35,6 +35,7 @@ > */ > unsigned int tlb_44x_index; /* = 0 */ > unsigned int tlb_44x_hwater = PPC44x_TLB_SIZE - 1 - PPC44x_EARLY_TLBS; > +int icache_44x_need_flush; > > /* > * "Pins" a 256MB TLB entry in AS0 for kernel lowmem > Index: linux-work/include/asm-powerpc/pgtable-ppc32.h > === > --- linux-work.orig/include/asm-powerpc/pgtable-ppc32.h 2007-09-28 > 11:42:10.0 +1000 > +++ linux-work/include/asm-powerpc/pgtable-ppc32.h2007-10-30 > 15:30:50.0 +1100 > @@ -11,6 +11,11 @@ > extern unsigned long va_to_phys(unsigned long address); > extern pte_t *va_to_pte(unsigned long address); > extern unsigned long ioremap_bot, ioremap_base; > + > +#ifdef CONFIG_44x > +extern int icache_44x_need_flush; > +#endif > + > #endif /* __ASSEMBLY__ */ > > /* > @@ -562,6 +567,10 @@ static inline unsigned long pte_update(p > : "=&r" (old), "=&r" (tmp), "=m" (*p) > : "r" (p), "r" (clr), "r" (set), "m" (*p) > : "cc" ); > +#ifdef CONFIG_44x > + if ((old & _PAGE_US
Execute user program in kernel mode?
hi,
Is it possible to run user program (statically linked) in kernel mode? for
example the user program entry is 0x1000, can we call it directly from
kernel? I've tried many times, but I got the following Error(Oops):
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: 1094 LR: 1094 CTR: C001CBF4
REGS: d1072e90 TRAP: 0700 Not tainted (2.6.19.2-eldk-xm.1.0)
MSR: 00021000 CR: XER:
TASK = cf31dc70[809385534] '�1� �˸' THREAD: c001ca38
GPR00: D1072F40 C0555B70 1094 C02C41C0 D1066000 1094 D106C000
GPR08: C02CCAE4 D106A000 2822 00021000
GPR16:
GPR24:
NIP [1094] 0x1094
LR [1094] 0x1094
Call Trace:
Instruction dump:
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C00598C8 LR: C000A108 CTR: C001C2A4
REGS: d1072060 TRAP: 0300 Not tainted (2.6.19.2-eldk-xm.1.0)
MSR: 00021000 CR: 8444 XER:
DAR: 3E20736D, DSISR:
TASK = cf31dc70[809385534] '�1� �˸' THREAD: c001ca38
GPR00: C000A0FC D1072110 CF31DC70 3E207365 3E20736D C024
GPR08: CF31DD14 D1072000 00021002 C0002038 C001CBE8
GPR16:
GPR24: CF31DD48 D10721E0 3E20736D CF31DD14 CF31DD48
NIP [C00598C8] find_vma+0x24/0x90
LR [C000A108] do_page_fault+0x50/0x3e0
Call Trace:
Instruction dump:
4c9d0020 91230020 4e800020 7c681b79 3860 4d820020 480c 7d2a4b78
4870 80680008 2f83 419e001c <80030008> 7f802040 409d0010 80030004
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
Does that mean we can not call user space entry code directly, can we?
Regards,
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering [EMAIL PROTECTED]
Tianshui South Road 222. Lanzhou 73 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
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] pegasos_eth.c: Fix compile error over MV643XX_ defines
On Tue, Oct 30, 2007 at 10:36:06AM +0100, Sven Luther wrote: > On Tue, Oct 30, 2007 at 03:44:59AM -0400, Luis R. Rodriguez wrote: > > On 10/29/07, Dale Farnsworth <[EMAIL PROTECTED]> wrote: > > > On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote: > > > > This commit made an incorrect assumption: > > > > -- > > > > Author: Lennert Buytenhek <[EMAIL PROTECTED]> > > > > Date: Fri Oct 19 04:10:10 2007 +0200 > > > > > > > > mv643xx_eth: Move ethernet register definitions into private header > > > > > > > > Move the mv643xx's ethernet-related register definitions from > > > > include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since > > > > they aren't of any use outside the ethernet driver. > > > > > > > > Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]> > > > > Acked-by: Tzachi Perelstein <[EMAIL PROTECTED]> > > > > Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> > > > > -- > > > > > > > > arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there. > > > > > > > > [EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe > > > > > > > > v2.6.24-rc1-138-g0119130 > > > > > > > > This patch fixes this by internalizing 3 defines onto pegasos which are > > > > simply no longer available elsewhere. Without this your compile will > > > > fail > > > > > > That compile failure was fixed in commit > > > 30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro. > > > > > > However, as I examine that commit, I see that it defines offsets from > > > the eth block in the chip, rather than the full chip registeri block > > > as the Pegasos 2 code expects. So, I think it fixes the compile > > > failure, but leaves the Pegasos 2 broken. > > > > > > Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that > > > the following patch is needed for the Pegasos 2? > > > > Nope, sorry. > > I am busy right now, but have various pegasos machines available for > testing. What exactly should i test ? Thanks Sven. Test whether an Ethernet port works at all. I think it's currently broken, but should work with the patch I supplied. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
On Tue, Oct 30, 2007 at 03:44:59AM -0400, Luis R. Rodriguez wrote: > On 10/29/07, Dale Farnsworth <[EMAIL PROTECTED]> wrote: > > On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote: > > > This commit made an incorrect assumption: > > > -- > > > Author: Lennert Buytenhek <[EMAIL PROTECTED]> > > > Date: Fri Oct 19 04:10:10 2007 +0200 > > > > > > mv643xx_eth: Move ethernet register definitions into private header > > > > > > Move the mv643xx's ethernet-related register definitions from > > > include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since > > > they aren't of any use outside the ethernet driver. > > > > > > Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]> > > > Acked-by: Tzachi Perelstein <[EMAIL PROTECTED]> > > > Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> > > > -- > > > > > > arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there. > > > > > > [EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe > > > > > > v2.6.24-rc1-138-g0119130 > > > > > > This patch fixes this by internalizing 3 defines onto pegasos which are > > > simply no longer available elsewhere. Without this your compile will fail > > > > That compile failure was fixed in commit > > 30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro. > > > > However, as I examine that commit, I see that it defines offsets from > > the eth block in the chip, rather than the full chip registeri block > > as the Pegasos 2 code expects. So, I think it fixes the compile > > failure, but leaves the Pegasos 2 broken. > > > > Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that > > the following patch is needed for the Pegasos 2? > > Nope, sorry. I am busy right now, but have various pegasos machines available for testing. What exactly should i test ? Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot/wrap assumes a biarch toolchain?
Jan Dittmer <[EMAIL PROTECTED]> writes: > Your mail from 2007-10-29 4:39 pm (CET) > >>> Your compiler still needs -m32 to generate 32-bit code (or use >>> --with-cpu=default32 to make that the default). > > See the 'still' ? How would the compiler know whether to generate 64bit or 32bit code?? 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 2/2 v2] Add DMA engine and SOC device support to mpc8641hpcn board
Add DMA engine and SOC device support to mpc8641hpcn board
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 32
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 16 ++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 3677659..ad6c528 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -380,5 +380,37 @@
0100 0
0 0010>;
};
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma";
+ reg = <21300 4>;
+ ranges = <0 21100 200>;
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <0 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <14 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <80 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <15 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <100 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <180 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <17 2>;
+ };
+ };
};
};
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 32a531a..92dcc22 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -227,3 +228,18 @@ define_machine(mpc86xx_hpcn) {
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
#endif
};
+
+static struct of_device_id mpc86xx_of_ids[] = {
+ { .type = "soc", },
+ {},
+};
+
+static __init int mpc86xx_of_device_init(void)
+{
+ if (!machine_is(mpc86xx_hpcn))
+ return 0;
+
+ return of_platform_bus_probe(NULL, mpc86xx_of_ids, NULL);
+}
+
+device_initcall(mpc86xx_of_device_init);
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2 v2] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
This patch adds Freescale DMA and DMA channel definition to
Documentation/powerpc/booting-without-of.txt file.
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 59 ++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index a96e853..bc3f250 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -52,6 +52,8 @@ Table of Contents
i) Freescale QUICC Engine module (QE)
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
+ l) Freescale DMA
+ m) Freescale DMA channel
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2242,6 +2244,63 @@ platforms are moved over to use the
flattened-device-tree model.
available.
For Axon: 0x012a
+ l) Freescale DMA
+
+ The DMA for dma-engine driver of Freescale MPC8540 silicon DMA
+ controller which also fit for MPC8560, MPC8555,
+ MPC8548, MPC8641 and MPC8349 silicon DMA controller,
+
+ For each DMA node, you should define channels included.
+ Please see below 'm) Freescale DMA channel' for DMA channel's definition.
+
+ Required properties:
+
+- compatible : Should be "fsl,mpc8540-dma" or "fsl,mpc8349-dma"
+- reg : Offset and length of DMA general status register.
+- ranges : Should be defined as specified in 1) to describe the
+ DMA controller channels.
+
+ Example:
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma";
+ reg = <21300 4>;
+ ranges = <0 21100 200>;
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <0 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <14 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <80 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <15 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <100 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel";
+ reg = <180 80>;
+ interrupt-parent = <&mpic>;
+ interrupts = <17 2>;
+ };
+ };
+
+ m) Freescale DMA channel
+
+ Required properties:
+
+- compatible : Should be "fsl,mpc8540-dma-channel"
+ or "fsl,mpc8349-dma-channel"
+- reg : Offset and length of the register set for the DMA channel.
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: compile warning
On Tuesday 30 October 2007, Sergej Stepanov wrote:
> -void
> +void __init
> cpm2_reset(void)
> {
> #ifdef CONFIG_PPC_85xx
>
> --
> I am not sure it is ok.
Yes, this looks good.
>
> But i have other 2 warnings (no modules).
>
> WARNING: vmlinux.o(.exit.text+0x5da): Section mismatch: reference to
> .init.data:of_platform_serial_driver (between 'of_platform_serial_exit'
> and 'phy_exit')
> WARNING: vmlinux.o(.exit.text+0x5e2): Section mismatch: reference to
> .init.data:of_platform_serial_driver (between 'of_platform_serial_exit'
> and 'phy_exit')
This seems to be my fault. I'll try to come up with the right fix.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Fix build failure in platforms/celleb/setup.c which CONFIG_VIRT_CPU_ACCOUNTING is not defined.
On Tuesday 30 October 2007, Tony Breeds wrote: > Without this patch I get the following build failure > CC arch/powerpc/platforms/celleb/setup.o > arch/powerpc/platforms/celleb/setup.c:151: error: 'generic_calibrate_decr' > undeclared here (not in a function) > > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
Yes, I'm working on it. Do not worry about it. Wei. > -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 30, 2007 4:31 AM > To: [EMAIL PROTECTED] > Cc: Zhang Wei-r63237; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; > [EMAIL PROTECTED] > Subject: Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc > to powerpc architecture and adding memory mapped RapidIO driver. > > > On Oct 29, 2007, at 2:38 PM, Phil Terry wrote: > > > Can anyone tell me what the status of these are? What kernel > > release are > > they targetted for? Currently I'm trying to work with 2.6.23 plus > > these > > patches locally. > > hopefully 2.6.25. I'd like to get the documentation updates in > 2.6.24 if we have agreement on them. > > - k > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ehea: add kexec support
Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17: > > > How do you plan to support kdump? > When kexec is fully supported kdump should work out of the box as for any other ethernet card (if you load the right eth driver). There's nothing specific to kdump you have to handle in ethernet device drivers. Hope I didn't miss anything here... Gruss / Regards Christoph R ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
