[RFC][PATCH 0/8] arch/powerpc support for Walnut Board

[RFC][PATCH 0/8] arch/powerpc support for Walnut Board

[Josh Boyer]

For those interested, here's my current patch set to get PPC405 support
working in arch/powerpc.

Patches 1, 2, 3, 4, and 5 are probably ready to merge whenever.  The
patches specific to Walnut need some more work before I would consider
those remotely usable.  However, you can use them to build a zImage that
correctly determines the clocking and has a working serial console.

As always, comments welcome.

josh

[RFC][PATCH 1/8] 4xx Kconfig cleanup

[Josh Boyer]

Remove some leftover cruft in the 40x Kconfig file.  Also make sure we
select WANT_DEVICE_TREE for 40x.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/platforms/4xx/Kconfig     |   77 ---------------------------------
 arch/powerpc/platforms/Kconfig.cputype |    1 
 2 files changed, 1 insertion(+), 77 deletions(-)

--- linux-2.6.orig/arch/powerpc/platforms/4xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/4xx/Kconfig
@@ -1,16 +1,3 @@
-config 4xx
-	bool
-	depends on 40x || 44x
-	default y
-
-config BOOKE
-	bool
-	depends on 44x
-	default y
-
-menu "AMCC 40x options"
-	depends on 40x
-
 #config BUBINGA
 #	bool "Bubinga"
 #	depends on 40x
@@ -82,8 +69,6 @@ menu "AMCC 40x options"
 #	help
 #	  This option enables support for the Xilinx ML300 evaluation board.
 
-endmenu
-
 # 40x specific CPU modules, selected based on the board above.
 config NP405H
 	bool
@@ -126,68 +111,6 @@ config IBM405_ERR77
 config IBM405_ERR51
 	bool
 
-menu "AMCC 44x options"
-	depends on 44x
-
-#config BAMBOO
-#	bool "Bamboo"
-#	depends on 44x
-#	default n
-#	select 440EP
-#	help
-#	  This option enables support for the IBM PPC440EP evaluation board.
-
-config EBONY
-	bool "Ebony"
-	depends on 44x
-	default y
-	select 440GP
-	help
-	  This option enables support for the IBM PPC440GP evaluation board.
-
-#config LUAN
-#	bool "Luan"
-#	depends on 44x
-#	default n
-#	select 440SP
-#	help
-#	  This option enables support for the IBM PPC440SP evaluation board.
-
-#config OCOTEA
-#	bool "Ocotea"
-#	depends on 44x
-#	default n
-#	select 440GX
-#	help
-#	  This option enables support for the IBM PPC440GX evaluation board.
-
-endmenu
-
-# 44x specific CPU modules, selected based on the board above.
-config 440EP
-	bool
-	select PPC_FPU
-	select IBM440EP_ERR42
-
-config 440GP
-	bool
-	select IBM_NEW_EMAC_ZMII
-
-config 440GX
-	bool
-
-config 440SP
-	bool
-
-config 440A
-	bool
-	depends on 440GX
-	default y
-
-# 44x errata/workaround config symbols, selected by the CPU models above
-config IBM440EP_ERR42
-	bool
-
 #config XILINX_OCP
 #	bool
 #	depends on XILINX_ML300
--- linux-2.6.orig/arch/powerpc/platforms/Kconfig.cputype
+++ linux-2.6/arch/powerpc/platforms/Kconfig.cputype
@@ -40,6 +40,7 @@ config PPC_8xx
 config 40x
 	bool "AMCC 40x"
 	select PPC_DCR_NATIVE
+	select WANT_DEVICE_TREE
 
 config 44x
 	bool "AMCC 44x"

[RFC][PATCH 2/8] 4xx boot wrapper reworks

[Josh Boyer]

Rename the 44x.c wrapper file to 4xx.c and make the fixup_memsize function
common for all of 4xx.  Also adds a common function to reset ethernet and a
40x reset function.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/boot/44x.c    |   85 ----------------------------------
 arch/powerpc/boot/44x.h    |    4 -
 arch/powerpc/boot/4xx.c    |  111 +++++++++++++++++++++++++++++++++++++++++++++
 arch/powerpc/boot/4xx.h    |   20 ++++++++
 arch/powerpc/boot/Makefile |    4 -
 arch/powerpc/boot/dcr.h    |    2 
 arch/powerpc/boot/ebony.c  |    3 -
 7 files changed, 137 insertions(+), 92 deletions(-)

--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -10,10 +10,6 @@
 #ifndef _PPC_BOOT_44X_H_
 #define _PPC_BOOT_44X_H_
 
-void ibm44x_fixup_memsize(void);
-void ibm4xx_fixup_ebc_ranges(const char *ebc);
-
-void ibm44x_dbcr_reset(void);
 void ebony_init(void *mac0, void *mac1);
 
 #endif /* _PPC_BOOT_44X_H_ */
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/4xx.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright 2007 David Gibson, IBM Corporation.
+ *
+ * Based on earlier code:
+ *   Matt Porter <mporter@kernel.crashing.org>
+ *   Copyright 2002-2005 MontaVista Software Inc.
+ *
+ *   Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
+ *   Copyright (c) 2003, 2004 Zultys Technologies
+ *
+ * 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 <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "ops.h"
+#include "reg.h"
+#include "dcr.h"
+
+/* Read the 4xx SDRAM controller to get size of system memory. */
+void ibm4xx_fixup_memsize(void)
+{
+	int i;
+	unsigned long memsize, bank_config;
+
+	memsize = 0;
+	for (i = 0; i < ARRAY_SIZE(sdram_bxcr); i++) {
+		mtdcr(DCRN_SDRAM0_CFGADDR, sdram_bxcr[i]);
+		bank_config = mfdcr(DCRN_SDRAM0_CFGDATA);
+
+		if (bank_config & SDRAM_CONFIG_BANK_ENABLE)
+			memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
+	}
+
+	dt_fixup_memory(0, memsize);
+}
+
+#define DBCR0_RST_SYSTEM 0x30000000
+
+void ibm44x_dbcr_reset(void)
+{
+	unsigned long tmp;
+
+	/* DBCR0 on 44x is SPRN 0x134 */
+	asm volatile (
+		"mfspr	%0,%1\n"
+		"oris	%0,%0,%2@h\n"
+		"mtspr	%1,%0"
+		: "=&r"(tmp) : "i"(0x134), "i"(DBCR0_RST_SYSTEM)
+		);
+
+}
+
+void ibm40x_dbcr_reset(void)
+{
+	unsigned long tmp;
+
+	/* DBCR0 on 4xx is SPRN 0x3F2 */
+	asm volatile (
+		"mfspr	%0,%1\n"
+		"oris	%0,%0,%2@h\n"
+		"mtspr	%1,%0"
+		: "=&r"(tmp) : "i"(0x3F2), "i"(DBCR0_RST_SYSTEM)
+		);
+}
+
+#define EMAC_RESET 0x20000000
+#define MAL_RESET 0x80000000
+void ibm4xx_reset_eth(u32 *emac0, u32 *emac1)
+{
+	/* Reset the MAL and EMAC(s) since PIBS/OpenBIOS don't do this for us */
+	if (emac0)
+		*emac0 = EMAC_RESET;
+	if (emac1)
+		*emac1 = EMAC_RESET;
+
+	mtdcr(DCRN_MAL0_CFG, MAL_RESET);
+}
+
+/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
+ * banks into the OPB address space */
+void ibm4xx_fixup_ebc_ranges(const char *ebc)
+{
+	void *devp;
+	u32 bxcr;
+	u32 ranges[EBC_NUM_BANKS*4];
+	u32 *p = ranges;
+	int i;
+
+	for (i = 0; i < EBC_NUM_BANKS; i++) {
+		mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
+		bxcr = mfdcr(DCRN_EBC0_CFGDATA);
+
+		if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
+			*p++ = i;
+			*p++ = 0;
+			*p++ = bxcr & EBC_BXCR_BAS;
+			*p++ = EBC_BXCR_BANK_SIZE(bxcr);
+		}
+	}
+
+	devp = finddevice(ebc);
+	if (! devp)
+		fatal("Couldn't locate EBC node %s\n\r", ebc);
+
+	setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
+}
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/4xx.h
@@ -0,0 +1,20 @@
+/*
+ * PowerPC 4xx related functions
+ *
+ * Copyright 2007 IBM Corporation.
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * 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.
+ */
+#ifndef _POWERPC_BOOT_4XX_H_
+#define _POWERPC_BOOT_4XX_H_
+
+void ibm4xx_fixup_memsize(void);
+void ibm44x_dbcr_reset(void);
+void ibm40x_dbcr_reset(void);
+void ibm4xx_reset_eth(u32 *emac0, u32 *emac1);
+void ibm4xx_fixup_ebc_ranges(const char *ebc);
+
+#endif /* _POWERPC_BOOT_4XX_H_ */
--- linux-2.6.orig/arch/powerpc/boot/dcr.h
+++ linux-2.6/arch/powerpc/boot/dcr.h
@@ -121,4 +121,6 @@ static const unsigned long sdram_bxcr[] 
 #define DCRN_CPC0_MIRQ1					0x0ed
 #define DCRN_CPC0_JTAGID				0x0ef
 
+#define DCRN_MAL0_CFG					0x180
+
 #endif	/* _PPC_BOOT_DCR_H_ */
--- linux-2.6.orig/arch/powerpc/boot/ebony.c
+++ linux-2.6/arch/powerpc/boot/ebony.c
@@ -25,6 +25,7 @@
 #include "ops.h"
 #include "reg.h"
 #include "dcr.h"
+#include "4xx.h"
 #include "44x.h"
 
 extern char _dtb_start[];
@@ -98,7 +99,7 @@ static void ebony_fixups(void)
 	unsigned long sysclk = 33000000;
 
 	ibm440gp_fixup_clocks(sysclk, 6 * 1843200);
-	ibm44x_fixup_memsize();
+	ibm4xx_fixup_memsize();
 	dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
 	ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
 }
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -31,7 +31,7 @@ endif
 
 BOOTCFLAGS	+= -I$(obj) -I$(srctree)/$(obj)
 
-$(obj)/44x.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
 
 zlib       := inffast.c inflate.c inftrees.c
@@ -44,7 +44,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
 src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
 		ns16550.c serial.c simple_alloc.c div64.S util.S \
 		gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
-		44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
+		4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
 src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
 		cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
 		ps3-head.S ps3-hvcall.S ps3.c
--- linux-2.6.orig/arch/powerpc/boot/44x.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * Copyright 2007 David Gibson, IBM Corporation.
- *
- * Based on earlier code:
- *   Matt Porter <mporter@kernel.crashing.org>
- *   Copyright 2002-2005 MontaVista Software Inc.
- *
- *   Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
- *   Copyright (c) 2003, 2004 Zultys Technologies
- *
- * 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 <stddef.h>
-#include "types.h"
-#include "string.h"
-#include "stdio.h"
-#include "ops.h"
-#include "reg.h"
-#include "dcr.h"
-
-/* Read the 44x memory controller to get size of system memory. */
-void ibm44x_fixup_memsize(void)
-{
-	int i;
-	unsigned long memsize, bank_config;
-
-	memsize = 0;
-	for (i = 0; i < ARRAY_SIZE(sdram_bxcr); i++) {
-		mtdcr(DCRN_SDRAM0_CFGADDR, sdram_bxcr[i]);
-		bank_config = mfdcr(DCRN_SDRAM0_CFGDATA);
-
-		if (bank_config & SDRAM_CONFIG_BANK_ENABLE)
-			memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
-	}
-
-	dt_fixup_memory(0, memsize);
-}
-
-#define SPRN_DBCR0		0x134
-#define   DBCR0_RST_SYSTEM	0x30000000
-
-void ibm44x_dbcr_reset(void)
-{
-	unsigned long tmp;
-
-	asm volatile (
-		"mfspr	%0,%1\n"
-		"oris	%0,%0,%2@h\n"
-		"mtspr	%1,%0"
-		: "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
-		);
-
-}
-
-/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
- * banks into the OPB address space */
-void ibm4xx_fixup_ebc_ranges(const char *ebc)
-{
-	void *devp;
-	u32 bxcr;
-	u32 ranges[EBC_NUM_BANKS*4];
-	u32 *p = ranges;
-	int i;
-
-	for (i = 0; i < EBC_NUM_BANKS; i++) {
-		mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
-		bxcr = mfdcr(DCRN_EBC0_CFGDATA);
-
-		if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
-			*p++ = i;
-			*p++ = 0;
-			*p++ = bxcr & EBC_BXCR_BAS;
-			*p++ = EBC_BXCR_BANK_SIZE(bxcr);
-		}
-	}
-
-	devp = finddevice(ebc);
-	if (! devp)
-		fatal("Couldn't locate EBC node %s\n\r", ebc);
-
-	setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
-}

[RFC][PATCH 3/8] 4xx MMU

[Josh Boyer]

Add MMU definitions for 40x platforms.  Also fixes two warnings in 4xx_mmu.c.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/mm/4xx_mmu.c     |    4 +-
 include/asm-powerpc/mmu-4xx.h |   65 ++++++++++++++++++++++++++++++++++++++++++
 include/asm-powerpc/mmu.h     |    3 +
 3 files changed, 70 insertions(+), 2 deletions(-)

--- /dev/null
+++ linux-2.6/include/asm-powerpc/mmu-4xx.h
@@ -0,0 +1,65 @@
+#ifndef _ASM_POWERPC_MMU_4XX_H_
+#define _ASM_POWERPC_MMU_4XX_H_
+
+/*
+ * PPC40x support
+ */
+
+#define PPC4XX_TLB_SIZE 64
+
+/*
+ * TLB entries are defined by a "high" tag portion and a "low" data
+ * portion.  On all architectures, the data portion is 32-bits.
+ *
+ * TLB entries are managed entirely under software control by reading,
+ * writing, and searchoing using the 4xx-specific tlbre, tlbwr, and tlbsx
+ * instructions.
+ */
+
+#define	TLB_LO          1
+#define	TLB_HI          0
+
+#define	TLB_DATA        TLB_LO
+#define	TLB_TAG         TLB_HI
+
+/* Tag portion */
+
+#define TLB_EPN_MASK    0xFFFFFC00      /* Effective Page Number */
+#define TLB_PAGESZ_MASK 0x00000380
+#define TLB_PAGESZ(x)   (((x) & 0x7) << 7)
+#define   PAGESZ_1K		0
+#define   PAGESZ_4K             1
+#define   PAGESZ_16K            2
+#define   PAGESZ_64K            3
+#define   PAGESZ_256K           4
+#define   PAGESZ_1M             5
+#define   PAGESZ_4M             6
+#define   PAGESZ_16M            7
+#define TLB_VALID       0x00000040      /* Entry is valid */
+
+/* Data portion */
+
+#define TLB_RPN_MASK    0xFFFFFC00      /* Real Page Number */
+#define TLB_PERM_MASK   0x00000300
+#define TLB_EX          0x00000200      /* Instruction execution allowed */
+#define TLB_WR          0x00000100      /* Writes permitted */
+#define TLB_ZSEL_MASK   0x000000F0
+#define TLB_ZSEL(x)     (((x) & 0xF) << 4)
+#define TLB_ATTR_MASK   0x0000000F
+#define TLB_W           0x00000008      /* Caching is write-through */
+#define TLB_I           0x00000004      /* Caching is inhibited */
+#define TLB_M           0x00000002      /* Memory is coherent */
+#define TLB_G           0x00000001      /* Memory is guarded from prefetch */
+
+#ifndef __ASSEMBLY__
+
+typedef unsigned long phys_addr_t;
+
+typedef struct {
+	unsigned long id;
+	unsigned long vdso_base;
+} mm_context_t;
+
+#endif /* !__ASSEMBLY__ */
+
+#endif /* _ASM_POWERPC_MMU_4XX_H_ */
--- linux-2.6.orig/include/asm-powerpc/mmu.h
+++ linux-2.6/include/asm-powerpc/mmu.h
@@ -8,6 +8,9 @@
 #elif defined(CONFIG_PPC_STD_MMU)
 /* 32-bit classic hash table MMU */
 #  include <asm/mmu-hash32.h>
+#elif defined(CONFIG_40x)
+/* 40x-style software loaded TLB */
+#  include <asm/mmu-4xx.h>
 #elif defined(CONFIG_44x)
 /* 44x-style software loaded TLB */
 #  include <asm/mmu-44x.h>
--- linux-2.6.orig/arch/powerpc/mm/4xx_mmu.c
+++ linux-2.6/arch/powerpc/mm/4xx_mmu.c
@@ -108,7 +108,7 @@ unsigned long __init mmu_mapin_ram(void)
 		pmd_t *pmdp;
 		unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
 
-		pmdp = pmd_offset(pgd_offset_k(v), v);
+		pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
 		pmd_val(*pmdp++) = val;
 		pmd_val(*pmdp++) = val;
 		pmd_val(*pmdp++) = val;
@@ -123,7 +123,7 @@ unsigned long __init mmu_mapin_ram(void)
 		pmd_t *pmdp;
 		unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
 
-		pmdp = pmd_offset(pgd_offset_k(v), v);
+		pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
 		pmd_val(*pmdp) = val;
 
 		v += LARGE_PAGE_SIZE_4M;

Re: [RFC][PATCH 3/8] 4xx MMU

[Arnd Bergmann]

On Wednesday 11 July 2007, Josh Boyer wrote:
> +#elif defined(CONFIG_40x)
> +/* 40x-style software loaded TLB */
> +# =A0include <asm/mmu-4xx.h>
> =A0#elif defined(CONFIG_44x)
> =A0/* 44x-style software loaded TLB */
> =A0# =A0include <asm/mmu-44x.h>

If you call it mmu-4xx, shouldn't it be used
for 44x as well? I would think this either
should be

> +#elif defined(CONFIG_4xx)
> +/* 40x-style software loaded TLB */
> +#  include <asm/mmu-4xx.h>
> -#elif defined(CONFIG_44x)
> -/* 44x-style software loaded TLB */
> -#  include <asm/mmu-44x.h>

or=20

> +#elif defined(CONFIG_40x)
> +/* 40x-style software loaded TLB */
> +#  include <asm/mmu-40x.h>
>  #elif defined(CONFIG_44x)
>  /* 44x-style software loaded TLB */
>  #  include <asm/mmu-44x.h>

Is it actually feasible to get to a point where
you can build a kernel that boots on both
40x and 44x, or is it just too different?

	Arnd <><

Re: [RFC][PATCH 3/8] 4xx MMU

[Josh Boyer]

On Wed, 2007-07-11 at 22:56 +0200, Arnd Bergmann wrote:
> On Wednesday 11 July 2007, Josh Boyer wrote:
> > +#elif defined(CONFIG_40x)
> > +/* 40x-style software loaded TLB */
> > +#  include <asm/mmu-4xx.h>
> >  #elif defined(CONFIG_44x)
> >  /* 44x-style software loaded TLB */
> >  #  include <asm/mmu-44x.h>
> 
> If you call it mmu-4xx, shouldn't it be used
> for 44x as well? I would think this either
> should be

No.  I was following the established convention that's been there for
years.  Which sucks I suppose for people not familiar with 40x/44x.
That would be a lot of stuff to change though...  e.g.:

arch/powerpc/platforms/4xx -> arch/powerpc/platforms/40x
arch/powerpc/kernel/head_4xx.S -> arch/powerpc/platforms/head_40x.S

etc.  I'd need a git tree to do that cleanly.  I've been toying with
creating one for powerpc4xx anyway so I might do that.

> 
> > +#elif defined(CONFIG_4xx)
> > +/* 40x-style software loaded TLB */
> > +#  include <asm/mmu-4xx.h>
> > -#elif defined(CONFIG_44x)
> > -/* 44x-style software loaded TLB */
> > -#  include <asm/mmu-44x.h>
> 
> or 
> 
> > +#elif defined(CONFIG_40x)
> > +/* 40x-style software loaded TLB */
> > +#  include <asm/mmu-40x.h>
> >  #elif defined(CONFIG_44x)
> >  /* 44x-style software loaded TLB */
> >  #  include <asm/mmu-44x.h>

I'll probably change it to this.  Will look a bit odd, given that C file
is arch/powerpc/mm/4xx_mmu.c.

> Is it actually feasible to get to a point where
> you can build a kernel that boots on both
> 40x and 44x, or is it just too different?

The MMUs are entirely different.  40x has real-mode and is 32-bit.  44x
is always virtual and is 36-bit.

josh

Re: [RFC][PATCH 3/8] 4xx MMU

[Kumar Gala]

On Jul 11, 2007, at 3:56 PM, Arnd Bergmann wrote:

> On Wednesday 11 July 2007, Josh Boyer wrote:
>> +#elif defined(CONFIG_40x)
>> +/* 40x-style software loaded TLB */
>> +#  include <asm/mmu-4xx.h>
>>  #elif defined(CONFIG_44x)
>>  /* 44x-style software loaded TLB */
>>  #  include <asm/mmu-44x.h>
>
> If you call it mmu-4xx, shouldn't it be used
> for 44x as well? I would think this either
> should be
>
>> +#elif defined(CONFIG_4xx)
>> +/* 40x-style software loaded TLB */
>> +#  include <asm/mmu-4xx.h>
>> -#elif defined(CONFIG_44x)
>> -/* 44x-style software loaded TLB */
>> -#  include <asm/mmu-44x.h>
>
> or
>
>> +#elif defined(CONFIG_40x)
>> +/* 40x-style software loaded TLB */
>> +#  include <asm/mmu-40x.h>
>>  #elif defined(CONFIG_44x)
>>  /* 44x-style software loaded TLB */
>>  #  include <asm/mmu-44x.h>
>
> Is it actually feasible to get to a point where
> you can build a kernel that boots on both
> 40x and 44x, or is it just too different?

I'm guessing its too different since 40x probably has a real mode and  
44x doesnt.

However, I agree we should go ahead and rename 4xx to 40x at this  
point in arch/powerpc.

- k

Re: [RFC][PATCH 3/8] 4xx MMU

[Josh Boyer]

On Thu, 2007-07-12 at 02:09 -0500, Kumar Gala wrote:
> > Is it actually feasible to get to a point where
> > you can build a kernel that boots on both
> > 40x and 44x, or is it just too different?
> 
> I'm guessing its too different since 40x probably has a real mode and  
> 44x doesnt.

Among other things.

> However, I agree we should go ahead and rename 4xx to 40x at this  
> point in arch/powerpc.

Yeah.  See my response to Arnd about getting a git tree in place to do
it.  RSN :)

josh

[RFC][PATCH 4/8] 4xx decrementer fixes

[Josh Boyer]

Allow generic_calibrate_decr to work for 40x platforms.  Given that the hardware
behavior is identical, this also changes the set_dec function to reload the PIT
on 40x to match the behavior 44x currently has.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/kernel/time.c |    2 +-
 include/asm-powerpc/time.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
@@ -866,7 +866,7 @@ void __init generic_calibrate_decr(void)
 				"(not found)\n");
 	}
 
-#ifdef CONFIG_BOOKE
+#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
 	/* Set the time base to zero */
 	mtspr(SPRN_TBWL, 0);
 	mtspr(SPRN_TBWU, 0);
--- linux-2.6.orig/include/asm-powerpc/time.h
+++ linux-2.6/include/asm-powerpc/time.h
@@ -174,7 +174,7 @@ static inline unsigned int get_dec(void)
 static inline void set_dec(int val)
 {
 #if defined(CONFIG_40x)
-	return;		/* Have to let it auto-reload */
+	mtspr(SPRN_PIT, val);
 #elif defined(CONFIG_8xx_CPU6)
 	set_dec_cpu6(val);
 #else

[RFC][PATCH 5/8] Fix 4xx build

[Josh Boyer]

Remove inclusion of __res on 40x.  We don't need it in arch/powerpc

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/kernel/head_4xx.S  |    1 -
 arch/powerpc/kernel/ppc_ksyms.c |    2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.orig/arch/powerpc/kernel/ppc_ksyms.c
+++ linux-2.6/arch/powerpc/kernel/ppc_ksyms.c
@@ -180,7 +180,7 @@ EXPORT_SYMBOL(cacheable_memcpy);
 EXPORT_SYMBOL(cpm_install_handler);
 EXPORT_SYMBOL(cpm_free_handler);
 #endif /* CONFIG_8xx */
-#if defined(CONFIG_8xx) || defined(CONFIG_40x)
+#if defined(CONFIG_8xx)
 EXPORT_SYMBOL(__res);
 #endif
 
--- linux-2.6.orig/arch/powerpc/kernel/head_4xx.S
+++ linux-2.6/arch/powerpc/kernel/head_4xx.S
@@ -35,7 +35,6 @@
 #include <asm/page.h>
 #include <asm/mmu.h>
 #include <asm/pgtable.h>
-#include <asm/ibm4xx.h>
 #include <asm/cputable.h>
 #include <asm/thread_info.h>
 #include <asm/ppc_asm.h>

Re: [RFC][PATCH 5/8] Fix 4xx build

[Arnd Bergmann]

On Wednesday 11 July 2007, Josh Boyer wrote:
> -#if defined(CONFIG_8xx) || defined(CONFIG_40x)
> +#if defined(CONFIG_8xx)
> =A0EXPORT_SYMBOL(__res);
> =A0#endif


Actually, __res also isn't defined on 8xx, so the export
should probably go away entirely.=20

	Arnd <><

[RFC][PATCH 6/8] Walnut DTS

[Josh Boyer]

Device tree source file for the PPC405 Walnut evaluation board.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/boot/dts/walnut.dts |  113 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 113 insertions(+)

--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
@@ -0,0 +1,113 @@
+/*
+ * Device Tree Source for IBM Walnut
+ *
+ * Copyright 2007 IBM Corp.
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * 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.
+ *
+ * To build:
+ *   dtc -I dts -O asm -o walnut.S -b 0 walnut.dts
+ *   dtc -I dts -O dtb -o walnut.dtb -b 0 walnut.dts
+ */
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	model = "ibm,walnut";
+	compatible = "ibm,walnut";
+	dcr-parent = <&/cpus/PowerPC,405GP@0>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		PowerPC,405GP@0 {
+			device_type = "cpu";
+			reg = <0>;
+			clock-frequency = <bebc200>; /* 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>; /* Filled in by zImage */
+	};
+
+	UIC0: interrupt-controller0 {
+		compatible = "ibm,uic";
+		interrupt-controller;
+		cell-index = <0>;
+		dcr-reg = <0c0 9>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+	};
+
+	plb {
+		compatible = "ibm,plb";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		clock-frequency = <0>; /* Filled in by zImage */
+
+		SDRAM0: memory-controller {
+			compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";
+			dcr-reg = <010 2>;
+		};
+
+		POB0: opb {
+			compatible = "ibm,opb";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+			dcr-reg = <0a0 5>;
+			clock-frequency = <0>; /* Filled in by zImage */
+
+			UART0: serial@ef600300 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600300 8>;
+				virtual-reg = <ef600300>;
+				clock-frequency = <0>; /* Filled in by zImage */
+				current-speed = <2580>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <0 4>;
+			};
+
+			UART1: serial@ef600400 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600400 8>;
+				virtual-reg = <ef600400>;
+				clock-frequency = <0>; /* Filled in by zImage */
+				current-speed = <2580>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <1 4>;
+			};
+
+			EBC0: ebc {
+				compatible = "ibm,ebc-405gp", "ibm,ebc";
+				dcr-reg = <012 2>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				clock-frequency = <0>; /* Filled in by zImage */
+			};
+		};
+	};
+
+	chosen {
+		linux,stdout-path = "/plb/opb/serial@ef600300";
+	};
+};

Re: [RFC][PATCH 6/8] Walnut DTS

[Stefan Roese]

On Wednesday 11 July 2007, Josh Boyer wrote:
> +		PowerPC,405GP@0 {
> +			device_type = "cpu";
> +			reg = <0>;
> +			clock-frequency = <bebc200>; /* 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>;

405 platforms have 16k cache at most.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
=====================================================================

Re: [RFC][PATCH 6/8] Walnut DTS

[Josh Boyer]

On Wed, 2007-07-11 at 16:26 +0200, Stefan Roese wrote:
> On Wednesday 11 July 2007, Josh Boyer wrote:
> > +		PowerPC,405GP@0 {
> > +			device_type = "cpu";
> > +			reg = <0>;
> > +			clock-frequency = <bebc200>; /* 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>;
> 
> 405 platforms have 16k cache at most.

Indeed they do.  Copy/paste error.  Will fix before actually submitting
things.  Thanks for the catch!

josh

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

> +	UIC0: interrupt-controller0 {

Why not just "interrupt-controller"?

> +		#address-cells = <0>;
> +		#size-cells = <0>;

No need for these.
>
> +	plb {
> +		ranges;

Please make the valid address ranges explicit here.

> +		SDRAM0: memory-controller {
> +			compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";

It's a bit weird to mention 440 here, since 405 is older.
Not a real problem, but if you still can change all relevant
OS code and device trees, I'd swap it around (make 440 trees
include the 405 "compatible" value).  Can you still do that
or is there a too big installed base already?

> +		POB0: opb {
> +			ranges;

Similar question as for PLB here.

> +			UART0: serial@ef600300 {
> +				current-speed = <2580>;

Write this in decimal?

Quite a nice tree btw :-)


Segher

Re: [RFC][PATCH 6/8] Walnut DTS

[Josh Boyer]

On Wed, 2007-07-11 at 19:49 +0200, Segher Boessenkool wrote:
> > +	UIC0: interrupt-controller0 {
> 
> Why not just "interrupt-controller"?

Copy/paste error from Ebony DTS, which has multiple UICs.  Will fix.

> 
> > +		#address-cells = <0>;
> > +		#size-cells = <0>;
> 
> No need for these.

Ok.

> >
> > +	plb {
> > +		ranges;
> 
> Please make the valid address ranges explicit here.

Meaning what exactly?  I thought just specifying "ranges;" simply said
"the addresses from this node don't have any translation from the parent
node" (or something like that).

> 
> > +		SDRAM0: memory-controller {
> > +			compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";
> 
> It's a bit weird to mention 440 here, since 405 is older.
> Not a real problem, but if you still can change all relevant
> OS code and device trees, I'd swap it around (make 440 trees
> include the 405 "compatible" value).  Can you still do that
> or is there a too big installed base already?

The installed base for 440 exists of exactly 1 completely non-functional
board ;).  I can change it.

> 
> > +		POB0: opb {
> > +			ranges;
> 
> Similar question as for PLB here.
> 
> > +			UART0: serial@ef600300 {
> > +				current-speed = <2580>;
> 
> Write this in decimal?

In a comment?  Or?

> Quite a nice tree btw :-)

Thanks!  Easy to do when there's nothing in it ;)

josh

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

>>> +	plb {
>>> +		ranges;
>>
>> Please make the valid address ranges explicit here.
>
> Meaning what exactly?  I thought just specifying "ranges;" simply said
> "the addresses from this node don't have any translation from the  
> parent
> node" (or something like that).

Just list the actual ranges that sit on the PLB bus.  It is
good to be more explicit with these things (for example, the
kernel will have more information to work from when deciding
whether to apply a certain workaround for broken device trees
or not).

>>> +		SDRAM0: memory-controller {
>>> +			compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";
>>
>> It's a bit weird to mention 440 here, since 405 is older.
>> Not a real problem, but if you still can change all relevant
>> OS code and device trees, I'd swap it around (make 440 trees
>> include the 405 "compatible" value).  Can you still do that
>> or is there a too big installed base already?
>
> The installed base for 440 exists of exactly 1 completely non- 
> functional
> board ;).  I can change it.

Yes exactly, let's do that while we still can.

>>> +			UART0: serial@ef600300 {
>>> +				current-speed = <2580>;
>>
>> Write this in decimal?
>
> In a comment?  Or?

Just in the code.  The syntax is <d#9600> I believe?

>> Quite a nice tree btw :-)
>
> Thanks!  Easy to do when there's nothing in it ;)

Well I didn't want to put it like that, but since you bring it
up yourself... :-)


Segher

Re: [RFC][PATCH 6/8] Walnut DTS

[David Gibson]

On Wed, Jul 11, 2007 at 12:55:31PM -0500, Josh Boyer wrote:
> On Wed, 2007-07-11 at 19:49 +0200, Segher Boessenkool wrote:
> > > +	UIC0: interrupt-controller0 {
> > 
> > Why not just "interrupt-controller"?
> 
> Copy/paste error from Ebony DTS, which has multiple UICs.  Will fix.
> 
> > 
> > > +		#address-cells = <0>;
> > > +		#size-cells = <0>;
> > 
> > No need for these.
> 
> Ok.
> 
> > >
> > > +	plb {
> > > +		ranges;
> > 
> > Please make the valid address ranges explicit here.
> 
> Meaning what exactly?  I thought just specifying "ranges;" simply said
> "the addresses from this node don't have any translation from the parent
> node" (or something like that).
> 
> > 
> > > +		SDRAM0: memory-controller {
> > > +			compatible = "ibm,sdram-405gp", "ibm,sdram-440gp";
> > 
> > It's a bit weird to mention 440 here, since 405 is older.
> > Not a real problem, but if you still can change all relevant
> > OS code and device trees, I'd swap it around (make 440 trees
> > include the 405 "compatible" value).  Can you still do that
> > or is there a too big installed base already?
> 
> The installed base for 440 exists of exactly 1 completely non-functional
> board ;).  I can change it.

And I don't think we even actually look at this compatible property in
practice.

-- 
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

RE: [RFC][PATCH 6/8] Walnut DTS

[Yoder Stuart-B08248]

=20

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Segher Boessenkool
> Sent: Wednesday, July 11, 2007 12:50 PM
> To: Josh Boyer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [RFC][PATCH 6/8] Walnut DTS
>=20
> > +	UIC0: interrupt-controller0 {
>=20
> Why not just "interrupt-controller"?
>=20
> > +		#address-cells =3D <0>;
> > +		#size-cells =3D <0>;
>=20
> No need for these.

Isn't a good practice to put #address-cells in interrupt controller
nodes?

If the device tree has an interrupt map defined the interrupt
parent 'unit interrupt specifier' has to be interpreted according
to the #address-cells of the interrupt parent.  It seems like=20
typical practice in the current DTS files to explicitly define this
in the interrupt controller.

Of course this particular device tree doesn't have an interrupt
map...

#size-cells is not needed.

Stuart

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

>>> +		#address-cells = <0>;
>>> +		#size-cells = <0>;
>>
>> No need for these.
>
> Isn't a good practice to put #address-cells in interrupt controller
> nodes?

It is not.

> If the device tree has an interrupt map defined the interrupt
> parent 'unit interrupt specifier' has to be interpreted according
> to the #address-cells of the interrupt parent.

And "#address-cells" is defaulted to 0 if it is absent,
for the purpose of interrupt mapping (but not for its
other purposes).  Typically, such interrupt controllers
don't have device tree children so it doesn't make sense
to give them an "#address-cells" anyway.

> It seems like
> typical practice in the current DTS files to explicitly define this
> in the interrupt controller.

That "typical practice" is inspired by the need to explicitly
put #address-cells and #size-cells into the device tree if you
want Linux to properly parse the device tree, even if the default
values would work perfectly (if Linux would work correctly,
that is).

> Of course this particular device tree doesn't have an interrupt
> map...
>
> #size-cells is not needed.

There are no child nodes, and no binding that says there can
be any; neither #address-cells not #size-cells should be there.


Segher

Re: [RFC][PATCH 6/8] Walnut DTS

[Benjamin Herrenschmidt]

On Mon, 2007-07-16 at 16:34 +0200, Segher Boessenkool wrote:
> >>> +		#address-cells = <0>;
> >>> +		#size-cells = <0>;
> >>
> >> No need for these.
> >
> > Isn't a good practice to put #address-cells in interrupt controller
> > nodes?
> 
> It is not.

Well, that's debatable... but yes, a strict reading of the spec would
say that you should put neither #address-cells nor #size-cells in a leaf
interrupt controller.

> > If the device tree has an interrupt map defined the interrupt
> > parent 'unit interrupt specifier' has to be interpreted according
> > to the #address-cells of the interrupt parent.
> 
> And "#address-cells" is defaulted to 0 if it is absent,
> for the purpose of interrupt mapping (but not for its
> other purposes). 

This is a bit confusing though, which is why I tend to prefer having it
explicitely in the interrupt controller node :-) I tend to dislike
"magic" defaults, we've had problems with them in the past and will have
in the future, I much prefer having things explicit whenever possible.

> Typically, such interrupt controllers
> don't have device tree children so it doesn't make sense
> to give them an "#address-cells" anyway.

Somewhat...

> > It seems like
> > typical practice in the current DTS files to explicitly define this
> > in the interrupt controller.
> 
> That "typical practice" is inspired by the need to explicitly
> put #address-cells and #size-cells into the device tree if you
> want Linux to properly parse the device tree, even if the default
> values would work perfectly (if Linux would work correctly,
> that is).

Linux does handle default values in some areas. The problem with default
values is that they are badly defined and the spec contains gray areas
and contradictions as to what the default values should be in some
circumstances. As a general matter, I dislike default values because
they somewhat require background knowledge of what default values should
be in different contexts to "read" a device-tree. To be simple, I
believe default values are a bad idea.

> There are no child nodes, and no binding that says there can
> be any; neither #address-cells not #size-cells should be there.

You are being way too pedantic here. The interrupt-tree uses those two
properties, thus "there is no child node" is open to interpretation.
There is no child device node, but there are child interrupt nodes, and
since the interrupt-tree uses #address/size-cells, it does make some
sense to specify them.

Yes, there is a default value when absent, but the simple fact that the
default is different depending if you are doing a device walk or an
interrupt tree walk is very confusing. As I said above, the default
values are a source of more problem than anything else and I tend to
think they should be banned.

I would personally be inclined to define that whatever spec we come up
with always require #address-cells/#size-cells for any node that can
have either device children or interrupt children, and ban default
values alltogether.

Cheers,
Ben. 

Re: [RFC][PATCH 6/8] Walnut DTS

[Scott Wood]

Benjamin Herrenschmidt wrote:
> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children or interrupt children, and ban default
> values alltogether.

When is #size-cells used in the interrupt tree at all?

And given the odd behavior of using an interrupt map in an interrupt 
parent that is not the device parent (you're potentially using keys from 
different domains that could clash, be a different sizes, etc), if we 
make any changes in that regard, I'd forbid interrupt maps in interrupt 
controllers with no device children, and thus #address-cells has no 
meaning there.

-Scott

Re: [RFC][PATCH 6/8] Walnut DTS

[Benjamin Herrenschmidt]

On Mon, 2007-07-16 at 16:55 -0500, Scott Wood wrote:
> Benjamin Herrenschmidt wrote:
> > I would personally be inclined to define that whatever spec we come up
> > with always require #address-cells/#size-cells for any node that can
> > have either device children or interrupt children, and ban default
> > values alltogether.
> 
> When is #size-cells used in the interrupt tree at all?

It's not, sorry, my fingers typed a bit too fast :-)

> And given the odd behavior of using an interrupt map in an interrupt 
> parent that is not the device parent (you're potentially using keys from 
> different domains that could clash, be a different sizes, etc), if we 
> make any changes in that regard, I'd forbid interrupt maps in interrupt 
> controllers with no device children, and thus #address-cells has no 
> meaning there.

No, interrupt maps are useful in devices with no children in some corner
cases. Remember that a map doesnt need to use the address part of the
source specifier, thus it can be used to do a pure domain->domain
conversion of the irq numbers, what sort of thing. The map has the added
advantage that today, it's the only mechanism that allows you to specify
different interrupt-parents through the same nexus, which is useful for
4xx.

Ben.

Re: [RFC][PATCH 6/8] Walnut DTS

[Scott Wood]

Benjamin Herrenschmidt wrote:
> No, interrupt maps are useful in devices with no children in some corner
> cases. Remember that a map doesnt need to use the address part of the
> source specifier, thus it can be used to do a pure domain->domain
> conversion of the irq numbers, what sort of thing. The map has the added
> advantage that today, it's the only mechanism that allows you to specify
> different interrupt-parents through the same nexus, which is useful for
> 4xx.

OK...  but if you're doing a pure IRQ number conversion, the only useful 
#address-cells would be zero, which makes it a reasonable default IMHO 
(unlike the arbitrary 2 for regular traversal).

-Scott

Re: [RFC][PATCH 6/8] Walnut DTS

[Benjamin Herrenschmidt]

On Mon, 2007-07-16 at 17:18 -0500, Scott Wood wrote:
> 
> OK...  but if you're doing a pure IRQ number conversion, the only useful 
> #address-cells would be zero, which makes it a reasonable default IMHO 
> (unlike the arbitrary 2 for regular traversal).

It does make a reasonable default. The thing, as I exlained, is I
dislike the whole idea of "default" values in the first place.

Cheers,
Ben.

RE: [RFC][PATCH 6/8] Walnut DTS

[Yoder Stuart-B08248]

[snip]
> There is no child device node, but there are child interrupt=20
> nodes, and
> since the interrupt-tree uses #address/size-cells, it does make some
> sense to specify them.
>=20
> Yes, there is a default value when absent, but the simple=20
> fact that the
> default is different depending if you are doing a device walk or an
> interrupt tree walk is very confusing. As I said above, the default
> values are a source of more problem than anything else and I tend to
> think they should be banned.
>=20
> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children or interrupt children, and ban default
> values alltogether.

Did you really mean #size-cells here?  Shouldn't it be #interrupt-cells?

Stuart

RE: [RFC][PATCH 6/8] Walnut DTS

[Benjamin Herrenschmidt]

> > I would personally be inclined to define that whatever spec we come up
> > with always require #address-cells/#size-cells for any node that can
> > have either device children or interrupt children, and ban default
> > values alltogether.
> 
> Did you really mean #size-cells here?  Shouldn't it be #interrupt-cells?

Yup, as I said, my fingers got a bit too fast on the keyboard. I means
#interrupt-cells.

Ben.

Re: [RFC][PATCH 6/8] Walnut DTS

[Josh Boyer]

On Tue, Jul 17, 2007 at 07:47:26AM +1000, Benjamin Herrenschmidt wrote:
> > That "typical practice" is inspired by the need to explicitly
> > put #address-cells and #size-cells into the device tree if you
> > want Linux to properly parse the device tree, even if the default
> > values would work perfectly (if Linux would work correctly,
> > that is).
> 
> Linux does handle default values in some areas. The problem with default
> values is that they are badly defined and the spec contains gray areas
> and contradictions as to what the default values should be in some
> circumstances. As a general matter, I dislike default values because
> they somewhat require background knowledge of what default values should
> be in different contexts to "read" a device-tree. To be simple, I
> believe default values are a bad idea.

Right.  See, there are people like me that don't know what the default values
are/should be.  Having them explicitly listed, even if it's redundant, serves
as a good learning aid.

Now, realistically I do know what the default is in this case.  But I only
learned that recently.  With hopefully more people starting to port things
over to arch/powerpc it might be a good idea to document them at least.
Otherwise, I fear we'd wind up repeating ourselves over and over.

Could we get a 'thou shalt not rely on defaults' added to
booting-without-of.txt?  Or maybe something less draconian ;).

josh

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

> Right.  See, there are people like me that don't know what the  
> default values
> are/should be.  Having them explicitly listed, even if it's  
> redundant, serves
> as a good learning aid.

_Only_ if it's redundant.  Not if it has a meaning different
from having the property not there at all.

> Now, realistically I do know what the default is in this case.  But  
> I only
> learned that recently.  With hopefully more people starting to port  
> things
> over to arch/powerpc it might be a good idea to document them at  
> least.

Definitely, we need more good examples, and maybe some
public stonings or something like that.

> Otherwise, I fear we'd wind up repeating ourselves over and over.
>
> Could we get a 'thou shalt not rely on defaults' added to
> booting-without-of.txt?  Or maybe something less draconian ;).

Such a statement is too vague to be meaningful.  It would
be a good idea in separate cases; but _do_ describe it more
carefully than just talking about "defaults", and _do_ put
a comment at any such entry that this is different from how
Open Firmware defines this, so that people looking at the
Linux code won't get hopelessly confused.


Segher

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

>>>>> +		#address-cells =3D <0>;
>>>>> +		#size-cells =3D <0>;
>>>>
>>>> No need for these.
>>>
>>> Isn't a good practice to put #address-cells in interrupt controller
>>> nodes?
>>
>> It is not.
>
> Well, that's debatable... but yes, a strict reading of the spec would
> say that you should put neither #address-cells nor #size-cells in a =20=

> leaf
> interrupt controller.

Yes.

>>> If the device tree has an interrupt map defined the interrupt
>>> parent 'unit interrupt specifier' has to be interpreted according
>>> to the #address-cells of the interrupt parent.
>>
>> And "#address-cells" is defaulted to 0 if it is absent,
>> for the purpose of interrupt mapping (but not for its
>> other purposes).
>
> This is a bit confusing though,

Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
simply has no unit address part, in an interrupt domain that
doesn't correspond to a "normal" bus.  But saying it like this
is a little bit inexact, and it uses more words.

> which is why I tend to prefer having it
> explicitely in the interrupt controller node :-)

Which is simply incorrect.

> I tend to dislike
> "magic" defaults, we've had problems with them in the past and will =20=

> have
> in the future, I much prefer having things explicit whenever possible.

You mean, the magic default values you used for #address-cells
and #size-cells?  That was simply a bug, someone forgot to read
the documentation...

>> That "typical practice" is inspired by the need to explicitly
>> put #address-cells and #size-cells into the device tree if you
>> want Linux to properly parse the device tree, even if the default
>> values would work perfectly (if Linux would work correctly,
>> that is).
>
> Linux does handle default values in some areas. The problem with =20
> default
> values is that they are badly defined

For this?  No way:

[=46rom the base spec]:

=93#address-cells=94 S
	Standard property name to define the package=92s address format.
	prop-encoded-array: Integer, encoded with encode-int.

	This property applies to packages that define a physical
	address space, i.e., those packages with =93decode-unit=94
	methods. The property value specifies the number of cells
	that are used to encode a physical address within that
	address space. The value of this property affects the other
	functions, commands, and methods that deal with physical
	addresses. In a package with a =93decode-unit=94 method, a =
missing
	=93#address-cells=94 property signifies that the number of
	address cells is two.

See?  The flat device tree unfortunately has no decode-unit, but
it is still pretty clear which nodes "define a physical address
space" and which do not.

There is nothing badly defined here.

Nothing in the "interrupt mapping" spec redefines #address-cells
(OF isn't all that stupid you know); it simply says that a /unit
interrupt specifier/ has no /unit address/ part if there is no
#address-cells.  The algorithm in paragraph 7 makes it super
clear how exactly this should work.

> and the spec contains gray areas
> and contradictions as to what the default values should be in some
> circumstances.

In some areas, perhaps.  And it would be nice to bring those
areas to the attention of the working group, instead of just
to complain.

There is no such issue in this area, anyway.

> As a general matter, I dislike default values because
> they somewhat require background knowledge of what default values =20
> should
> be in different contexts to "read" a device-tree.

Of course, you need way more than that knowledge to properly
parse or read a device tree *at all*.

> To be simple, I
> believe default values are a bad idea.

Linux will have to keep supporting them for "real OF", so
requiring an explicit #address-cells where its value is 2
doesn't really help much.  I'm not opposed to this though,
for flat device trees at least (I think it's a good thing
for OF trees as well, but for different reasons; and that's
beside the point here).

On the other hand, requiring an #address-cells where it is
supposed to be absent, and you only want it so you can wrap
your head around the interrupt mapping recommended practice
in a more confusing and confused way, is simply WRONG.

>> There are no child nodes, and no binding that says there can
>> be any; neither #address-cells not #size-cells should be there.
>
> You are being way too pedantic here.

No I'm not.

> The interrupt-tree uses those two properties, thus "there is
> no child node" is open to interpretation.

It isn't.  Not a bus -> no child node in the device tree.
The interrupt tree is a completely separate thing.

> There is no child device node, but there are child interrupt nodes, =20=

> and
> since the interrupt-tree uses #address/size-cells,

It doesn't.

> it does make some sense to specify them.

If it would, the interrupt mapping spec would have had to say
how the semantics of #address-cells were changed (and they
weren't, and they shouldn't, and this is such a laughable idea
I wonder why anyone would suggest it did).

What the interrupt mapping spec defines is how to _use_ the
value of #address-cells, and how to interpret its absence;
what should be put in #address-cells for separate nodes is
defined elsewhere (namely, in the base spec, and in relevant
device bindings).

> Yes, there is a default value when absent, but the simple fact that =20=

> the
> default is different depending if you are doing a device walk or an
> interrupt tree walk is very confusing.

Yes, perhaps there shouldn't be a default value for #a
in the device structure; this is legacy compatibility
though, way way way too late to change this.  You can do
this for the flat device tree though, since a) there are
no legacy trees around that you care about, and b) you
need to do something to get around the fact you don't have
decode-unit and encode-unit anyway, so little changes
around that area should be expected.

> As I said above, the default
> values are a source of more problem than anything else and I tend to
> think they should be banned.

You cannot ban them in the Linux code.  With that in mind,
what good would it do?  There are thousands of cases where
absence of a property signifies something that you simply
*cannot* forbid, period.  So why do it to this one?

> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children

That is fine, for the flat device tree.  Note that this would
be implicit in all separate device bindings, anyway.

> or interrupt children,

Nope.  I hope I explained my reasoning.

> and ban default values alltogether.

That is simply impossible.


Segher

Re: [RFC][PATCH 6/8] Walnut DTS

[Benjamin Herrenschmidt]

> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
> simply has no unit address part, in an interrupt domain that
> doesn't correspond to a "normal" bus.  But saying it like this
> is a little bit inexact, and it uses more words.
> 
> > which is why I tend to prefer having it
> > explicitely in the interrupt controller node :-)
> 
> Which is simply incorrect.

It's absolutely not. Please, stop that moronic pin-head behaviour and
find me a single case where that would actually be a problem of any sort
or form.

> You mean, the magic default values you used for #address-cells
> and #size-cells?  That was simply a bug, someone forgot to read
> the documentation...

No, defaults are crap, period. This is a general thing. Besides, the
spec itself has issues about the default values (remember those blurbs
about PCI and ISA supposedly having different defaults ?) In any way,
defaults are a bad idea and I'm happy to say don't use them.

> For this?  No way:
> 
> [From the base spec]:
> 
> “#address-cells” S
> 	Standard property name to define the package’s address format.
> 	prop-encoded-array: Integer, encoded with encode-int.
> 
> 	This property applies to packages that define a physical
> 	address space, i.e., those packages with “decode-unit”
> 	methods. The property value specifies the number of cells
> 	that are used to encode a physical address within that
> 	address space. The value of this property affects the other
> 	functions, commands, and methods that deal with physical
> 	addresses. In a package with a “decode-unit” method, a missing
> 	“#address-cells” property signifies that the number of
> 	address cells is two.

And you omit the various bus bindings that have come up with different
defaults...

> See?  The flat device tree unfortunately has no decode-unit, but
> it is still pretty clear which nodes "define a physical address
> space" and which do not.
> 
> There is nothing badly defined here.

See above. Besides, as I said, default values are crap. And no, it's not
obvious which nodes define a physical address space or not, at least not
for a generic parser. Defaults are a bad idea, just get it and move on
and stop arguing just for the sake of arguing. Pointing out the letter
of the spec is not a constructive attitude here.

> Nothing in the "interrupt mapping" spec redefines #address-cells
> (OF isn't all that stupid you know); it simply says that a /unit
> interrupt specifier/ has no /unit address/ part if there is no
> #address-cells.  The algorithm in paragraph 7 makes it super
> clear how exactly this should work.

No, the algorithm provided isn't clear and is buggy. I have implemented
it so I know what I'm talking about. The fact that basically you end up
with "different" defaults for what is essentially the value
#address-cells depending on whether you are walking the device-tree for
address resolution or for interrupt resolution is stupid. Thus, the
solution is simple: don't do defaults. Explicit values are good.

> > and the spec contains gray areas
> > and contradictions as to what the default values should be in some
> > circumstances.
> 
> In some areas, perhaps.  And it would be nice to bring those
> areas to the attention of the working group, instead of just
> to complain.

The working group is dead and some of the ex members of it expressed
their lack of interest in pursuing these matters.

> Linux will have to keep supporting them for "real OF", so
> requiring an explicit #address-cells where its value is 2
> doesn't really help much.  I'm not opposed to this though,
> for flat device trees at least (I think it's a good thing
> for OF trees as well, but for different reasons; and that's
> beside the point here).
> 
> On the other hand, requiring an #address-cells where it is
> supposed to be absent, and you only want it so you can wrap
> your head around the interrupt mapping recommended practice
> in a more confusing and confused way, is simply WRONG.

No, it's not, It's purely having an explicit representation of what was
a stupid default behaviour.

> If it would, the interrupt mapping spec would have had to say
> how the semantics of #address-cells were changed (and they
> weren't, and they shouldn't, and this is such a laughable idea
> I wonder why anyone would suggest it did).

That's bullshit. The semantics are exactly the same. You obviously
decided to be immune to any kind of common sense today.

> What the interrupt mapping spec defines is how to _use_ the
> value of #address-cells, and how to interpret its absence;
> what should be put in #address-cells for separate nodes is
> defined elsewhere (namely, in the base spec, and in relevant
> device bindings).

There is no such crackpot interpretation. A unit interrupt specifier
contains ... an address. An address format/size is defined by a
#address-cells. Period. That's not an "interpretation", that's the
basic, primary semantic of #address-cells. The fact that the absence of
#address-cells will give a different "default" for the address size
depending on "how" you walk the tree is just a plain wrong bad idea. I
see no reason why it would be or cause or be in any way shape or form
wrong or against the "spirit" of the spec (if not the letter) to
explicitely specify in the case of leaf interrupt controllers, that
their #address-cells is 0 and be done with it.

Ben.

Re: [RFC][PATCH 6/8] Walnut DTS

[Scott Wood]

On Wed, Jul 18, 2007 at 07:25:57AM +1000, Benjamin Herrenschmidt wrote:
> > > which is why I tend to prefer having it
> > > explicitely in the interrupt controller node :-)
> > 
> > Which is simply incorrect.
> 
> It's absolutely not. Please, stop that moronic pin-head behaviour and
> find me a single case where that would actually be a problem of any sort
> or form.

It could lead someone to the erroneous conclusion that an #address-cells
other than zero in an interrupt controller that is not a device parent is
in any way a sane or supported thing to do.

It could lead people to write code that doesn't handle the absence of
#address-cells in such a node properly.

It could lead to flamewars. :-)

> > You mean, the magic default values you used for #address-cells
> > and #size-cells?  That was simply a bug, someone forgot to read
> > the documentation...
> 
> No, defaults are crap, period.

If there's only one value that could possibly make sense, it *not* being
the default is crap.

> See above. Besides, as I said, default values are crap. And no, it's not
> obvious which nodes define a physical address space or not, at least not
> for a generic parser.

The obvious way (which indeed isn't what the suggested algorithm does --
but the suggested algorithm doesn't do anything sensible) is that if you
got to the node via an interrupt-parent or interrupt-map, it doesn't use
#address-cells, and if you got to it by going to the regular device tree
parent, it does.

Pretty much any time you use the unit address in a context other than the
bus parent, things cease making sense.

> > In some areas, perhaps.  And it would be nice to bring those
> > areas to the attention of the working group, instead of just
> > to complain.
> 
> The working group is dead and some of the ex members of it expressed
> their lack of interest in pursuing these matters.

There is the ePAPR working group, though.

-Scott

Re: [RFC][PATCH 6/8] Walnut DTS

[Benjamin Herrenschmidt]

> It could lead someone to the erroneous conclusion that an #address-cells
> other than zero in an interrupt controller that is not a device parent is
> in any way a sane or supported thing to do.

I fail why anyone would ever want to do it though :-)

> It could lead people to write code that doesn't handle the absence of
> #address-cells in such a node properly.

We just need to make mention that it can be absent in the spec, there
shouldn't be that many parsers out there.

> It could lead to flamewars. :-)

Yeah well.

> If there's only one value that could possibly make sense, it *not* being
> the default is crap.

Only for leaf nodes. Other values do make sense for non-leaf nodes.

> The obvious way (which indeed isn't what the suggested algorithm does --
> but the suggested algorithm doesn't do anything sensible) is that if you
> got to the node via an interrupt-parent or interrupt-map, it doesn't use
> #address-cells, and if you got to it by going to the regular device tree
> parent, it does.

Yeah well, that's also somewhat debatable too. You need a #address-cells
to be able to parse an interrupt-map. You can imagine cross-links and
special maps used to handle things like the multiple UICs as David did
in the past. I wouldn't get rid of that flexibility to handle corner
cases that aren't easily represented by the "standard" stuff.

> Pretty much any time you use the unit address in a context other than the
> bus parent, things cease making sense.

I tend to agree.

> There is the ePAPR working group, though.

Yup, true.

Ben.

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

>> See above. Besides, as I said, default values are crap. And no,  
>> it's not
>> obvious which nodes define a physical address space or not, at  
>> least not
>> for a generic parser.
>
> The obvious way (which indeed isn't what the suggested algorithm  
> does --
> but the suggested algorithm doesn't do anything sensible) is that  
> if you
> got to the node via an interrupt-parent or interrupt-map, it  
> doesn't use
> #address-cells, and if you got to it by going to the regular device  
> tree
> parent, it does.
>
> Pretty much any time you use the unit address in a context other  
> than the
> bus parent, things cease making sense.

Yes indeed.  The problem with your suggested "obvious way"
is that you wouldn't get a unit address included if your
interrupt-map points (for some entry) at your device tree
parent, either.  Not all that hypothetical.


Segher

Re: [RFC][PATCH 6/8] Walnut DTS

[Scott Wood]

Segher Boessenkool wrote:
> Yes indeed.  The problem with your suggested "obvious way"

I said it was obvious, not obviously correct. :-)

> is that you wouldn't get a unit address included if your
> interrupt-map points (for some entry) at your device tree
> parent, either.  Not all that hypothetical.

Ah, good point.  My inclination would be to, rather than check how we 
got to the node, check whether it's the device's parent.  If not, then 
the presence of #address-cells (other than zero for compatibility) is an 
error.  Otherwise, #address-cells is used, and defaults are handled the 
same as with reg/ranges translation.

-Scott

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

>> Yes indeed.  The problem with your suggested "obvious way"
>
> I said it was obvious, not obviously correct. :-)

I know :-)

>> is that you wouldn't get a unit address included if your
>> interrupt-map points (for some entry) at your device tree
>> parent, either.  Not all that hypothetical.
>
> Ah, good point.  My inclination would be to, rather than check how  
> we got to the node, check whether it's the device's parent.  If  
> not, then the presence of #address-cells (other than zero for  
> compatibility) is an error.  Otherwise, #address-cells is used, and  
> defaults are handled the same as with reg/ranges translation.

This might work; it is less flexible than the actual interrupt
mapping definition though (and such flexibility is good, as long
as you don't abuse it ;-) ).  Anyway, we're stuck with the actual
current imap recommended practice.  It might not be perfect but
it does work, is proven in the field, and is the standard.


Segher

Re: [RFC][PATCH 6/8] Walnut DTS

[Segher Boessenkool]

>> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
>> simply has no unit address part, in an interrupt domain that
>> doesn't correspond to a "normal" bus.  But saying it like this
>> is a little bit inexact, and it uses more words.
>>
>>> which is why I tend to prefer having it
>>> explicitely in the interrupt controller node :-)
>>
>> Which is simply incorrect.
>
> It's absolutely not.

Of course it is.  #address-cells is a property for
bus nodes, you don't go around putting it in unrelated
places, just like you don't put "slot-names" properties
where it has no business.

Oh, wait, you're going to say that is a stupid comparison.
Yeah it is, "slot-names" would be way more harmless, #a is
such a fundamental low-level building block of the OF device
tree that the imap people didn't dare change it semantics
(or, were simply smart enough to not try).

> Please, stop that moronic pin-head behaviour and
> find me a single case where that would actually be a problem of any =20=

> sort
> or form.

You want all DTS authors to put properties where they do
not belong, confusing them even further about what all this
stuff is.  You want to make this a "requirement", although
it of course won't help anything anywhere, since *even you
_do_ have to follow the rules*, because the Linux code has
to support proper standards-compliant OF device trees, too.

>> You mean, the magic default values you used for #address-cells
>> and #size-cells?  That was simply a bug, someone forgot to read
>> the documentation...
>
> No, defaults are crap, period. This is a general thing.

I'm sorry if you feel that way, but there simply is no
way you can do anything about it; defaults exist, you
have to support them.

> Besides, the
> spec itself has issues about the default values (remember those blurbs
> about PCI and ISA supposedly having different defaults ?)

I remember those very very vaguely.  The conclusion was that
people have trouble understanding what they read, if I
remember it right.

Anyway, quit saying vague things about supposed bugs in the
OF documents without pointing them out; it is less than
helpful.

> In any way,
> defaults are a bad idea and I'm happy to say don't use them.

Sure, feel free to recommend people to explicitly write out
default values.  Nothing wrong there, it's just one particular
coding style.

As I've explained enough times though, the issue at hand isn't
about writing out a default value though; you want to require
(not recommend) a completely bogus property where it doesn't
belong.  And none of the code will benefit, either.  I don't
see the point.

>> For this?  No way:
>>
>> [=46rom the base spec]:
>>
>> =93#address-cells=94 S
>> 	Standard property name to define the package=92s address format.
>> 	prop-encoded-array: Integer, encoded with encode-int.
>>
>> 	This property applies to packages that define a physical
>> 	address space, i.e., those packages with =93decode-unit=94
>> 	methods. The property value specifies the number of cells
>> 	that are used to encode a physical address within that
>> 	address space. The value of this property affects the other
>> 	functions, commands, and methods that deal with physical
>> 	addresses. In a package with a =93decode-unit=94 method, a =
missing
>> 	=93#address-cells=94 property signifies that the number of
>> 	address cells is two.
>
> And you omit the various bus bindings that have come up with different
> defaults...

a) Do you expect me to quote every OF document in every post?
    That would easily exceed the message limits on this list,
    sorry.
b) There are no such bindings.  Stop confusing people.  There
    might be a bug in one such binding or so, but that would be
    just that, a bug; or maybe it uses confusing language; or
    maybe some people just don't know how to read [that would
    include me, I'm not trying to escalate this, ahem, polite
    conversation].  In any case, please point out the exact
    spot where you say this happens.

>> See?  The flat device tree unfortunately has no decode-unit, but
>> it is still pretty clear which nodes "define a physical address
>> space" and which do not.
>>
>> There is nothing badly defined here.
>
> See above. Besides, as I said, default values are crap.

Hey, maybe if you repeat it often enough, I might start to
believe it.  Not that that will help your point, since it
is absolutely irrelevant.

> And no, it's not
> obvious which nodes define a physical address space or not, at =20
> least not
> for a generic parser.

"Everything which can have kids with an @ in your DTB full
name thingie".  That includes everything with a #address-cells.

> Defaults are a bad idea, just get it

I'm getting tired of repeating myself, I hope you do, too.

> and move on and stop arguing just for the sake of arguing.

Would you please stop using that childish argument when
you've run out of real ones?

> Pointing out the letter
> of the spec is not a constructive attitude here.

Not just the letter, also the spirit, and the history.

And of course it _is_ constructive; you want to make a
useless, non-compatible change, are we peasants allowed
to quote the law that even you the mighty king must follow?
It's the only weapon we have you know.  Oh, if you discount
the pitchforks ;-)

>> Nothing in the "interrupt mapping" spec redefines #address-cells
>> (OF isn't all that stupid you know); it simply says that a /unit
>> interrupt specifier/ has no /unit address/ part if there is no
>> #address-cells.  The algorithm in paragraph 7 makes it super
>> clear how exactly this should work.
>
> No, the algorithm provided isn't clear and is buggy.

Yes it is clear.  No it isn't buggy (it _does_ state right
before the algo that some details are left out, maybe that
hurt you?)

>  I have implemented it so I know what I'm talking about.

Me too.

> The fact that basically you end up
> with "different" defaults for what is essentially the value
> #address-cells depending on whether you are walking the device-tree =20=

> for
> address resolution or for interrupt resolution is stupid.

Until you realise #address-cells is missing in those two
cases for completely different reasons.  In the first case,
#address-cells is missing for historic reasons; there didn't
use to be a #address-cells, everyone implicitly assumed it
was 2, it wasn't a default as such.  After #a was introduced,
not specifying it if it was 2 had to be allowed, for compatibility
reasons.  To this day, people routinely write trees with implicit
#address-cells =3D <2>, simply since they find it handy [<-- this
is the only thing you can fight with that "defaults are bad"
argument, btw, and you won't get far; most people feel passionately
about their own coding style].

In the interrupt "tree" case though, #address-cells is missing
in certain nodes ***because it simply doesn't belong there!***
The imap spec doesn't put any new rules on #address-cells [how
could it, without risking serious damage], it simply specifies
how to deal with the existing bus tree structure.  And not every
node in the interrupt graph is a bus node, so it says how to
form a unit interrupt specifier when there is no #address-cells:
you simply leave out the unit part.  Wow.  Now that was hard.
And there is no "default" (in your sense) in sight.

> Thus, the
> solution is simple: don't do defaults. Explicit values are good.

Except where the decisive thing is whether there _is_ a value
at all.

>>> and the spec contains gray areas
>>> and contradictions as to what the default values should be in some
>>> circumstances.
>>
>> In some areas, perhaps.  And it would be nice to bring those
>> areas to the attention of the working group, instead of just
>> to complain.
>
> The working group is dead

"It's just resting".

> and some of the ex members of it expressed
> their lack of interest in pursuing these matters.

Some, yes.  Even if the WG wouldn't help, there are some other
forums where you can discuss OF bugs; if all else fails, you
could try this mailing list even.

Point remains: it is a terribly bad argument to say "defaults
are bad, ooh I'm creating a rumour there are some vague defaults
in the OF standard right here, without pointing out anything,
ever".


[Here you cut out the part of our little chat where you
suggest the interrupt mapping spec should have said that
if there is no #address-cells in a node, just put something
there]

>> If it would, the interrupt mapping spec would have had to say
>> how the semantics of #address-cells were changed (and they
>> weren't, and they shouldn't, and this is such a laughable idea
>> I wonder why anyone would suggest it did).
>
> That's bullshit. The semantics are exactly the same. You obviously
> decided to be immune to any kind of common sense today.

Huh?  Let me write more abstractly what I said:

	"If you change A, A gets changed".

Hard to argue with that I would think, but hey.

>> What the interrupt mapping spec defines is how to _use_ the
>> value of #address-cells, and how to interpret its absence;
>> what should be put in #address-cells for separate nodes is
>> defined elsewhere (namely, in the base spec, and in relevant
>> device bindings).
>
> There is no such crackpot interpretation.

Well please read it again, if that's what you think.  Obviously
you didn't understand it on the first try.  This is really basic
stuff; it's how standards work.

> A unit interrupt specifier
> contains ... an address. An address format/size is defined by a
> #address-cells.

No.  A unit address format is defined by its device binding.
Luckily, for (PCI) interrupt mapping, nothing more than the
unit address _size_ is needed since the imap spec doesn't
concern itself with the semantics of the unit addresses in
question; it just needs some way to get unique identifiers.

> Period. That's not an "interpretation", that's the
> basic, primary semantic of #address-cells.

Pretty much, yes...

> The fact that the absence of
> #address-cells will give a different "default" for the address size
> depending on "how" you walk the tree is just a plain wrong bad idea.

...so I don't see how you made _this_ mental jump.

There _is_ no default, there is just a different way to
form unit interrupt specifiers for nodes with or without
#address-cells.  They are treated differently, because
they _are_ different.  Yes you can try to shoehorn them
into one mould by pretending #address-cells exists and
has the value 0; this might be okay for an interrupt tree
walker implementation [or it might not -- the writers of
the example algorithm that you so despise probably had
a reason for writing it out all three times, even though
they aren't all that careful in other places], maybe it
isn't too confusing there, but it certainly is if you put
it in a device tree.

> I
> see no reason why it would be or cause or be in any way shape or form
> wrong or against the "spirit" of the spec (if not the letter) to
> explicitely specify in the case of leaf interrupt controllers, that
> their #address-cells is 0 and be done with it.

Maybe you don't see it.  But the specs make abundantly
clear that _not_ putting an #address-cells here is perfectly
fine, which I thought would have prevented this particular
flame war from happening at all.  Oh well.


Segher

[RFC][PATCH 7/8] Walnut defconfig

[Josh Boyer]

Walnut board defconfig

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/configs/walnut_defconfig |  776 ++++++++++++++++++++++++++++++++++
 1 file changed, 776 insertions(+)

--- /dev/null
+++ linux-2.6/arch/powerpc/configs/walnut_defconfig
@@ -0,0 +1,776 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.22-rc4
+# Tue Jul 10 11:16:06 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=y
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_4xx=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_PPC32=y
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=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_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_PPC_UDBG_16550 is not set
+# 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"
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+# CONFIG_IPC_NS is not set
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_UTS_NS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+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=y
+CONFIG_KALLSYMS_EXTRA_PASS=y
+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_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+
+#
+# Loadable module support
+#
+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
+
+#
+# Block layer
+#
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF 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_WALNUT=y
+CONFIG_405GP=y
+CONFIG_IBM405_ERR77=y
+CONFIG_IBM405_ERR51=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
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+# 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 is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_PROC_DEVICETREE=y
+# CONFIG_CMDLINE_BOOL is not set
+# CONFIG_PM is not set
+CONFIG_SECCOMP=y
+CONFIG_WANT_DEVICE_TREE=y
+CONFIG_DEVICE_TREE="walnut.dts"
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+# CONFIG_PCI is not set
+# CONFIG_PCI_DOMAINS is not set
+# CONFIG_ARCH_SUPPORTS_MSI is not set
+
+#
+# PCCARD (PCMCIA/CardBus) support
+#
+# CONFIG_PCCARD is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x00400000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_ARPD is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NETFILTER is not set
+# CONFIG_IP_DCCP is not set
+# CONFIG_IP_SCTP is not set
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_AF_RXRPC is not set
+
+#
+# Wireless
+#
+# CONFIG_CFG80211 is not set
+# CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
+# CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+CONFIG_FW_LOADER=y
+# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
+# CONFIG_SYS_HYPERVISOR is not set
+
+#
+# Connector - unified userspace <-> kernelspace linker
+#
+CONFIG_CONNECTOR=y
+CONFIG_PROC_EVENTS=y
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play support
+#
+# CONFIG_PNPACPI is not set
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=35000
+CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# Misc devices
+#
+# CONFIG_BLINK is not set
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_NETLINK is not set
+# CONFIG_ATA is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+# CONFIG_NET_ETHERNET is not set
+# CONFIG_IBM_EMAC is not set
+CONFIG_NETDEV_1000=y
+CONFIG_NETDEV_10000=y
+
+#
+# Wireless LAN
+#
+# CONFIG_WLAN_PRE80211 is not set
+# CONFIG_WLAN_80211 is not set
+# CONFIG_WAN is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_UARTLITE is not set
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+
+#
+# IPMI
+#
+# CONFIG_IPMI_HANDLER is not set
+# CONFIG_WATCHDOG is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_R3964 is not set
+# CONFIG_RAW_DRIVER is not set
+
+#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+# CONFIG_I2C is not set
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+
+#
+# Dallas's 1-wire bus
+#
+# CONFIG_W1 is not set
+# CONFIG_HWMON is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_SM501 is not set
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+# CONFIG_DAB is not set
+
+#
+# Graphics support
+#
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+# CONFIG_VGASTATE is not set
+# CONFIG_FB is not set
+# CONFIG_FB_IBM_GXT4500 is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+# CONFIG_USB_ARCH_HAS_HCD is not set
+# CONFIG_USB_ARCH_HAS_OHCI is not set
+# CONFIG_USB_ARCH_HAS_EHCI is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# USB Gadget Support
+#
+# CONFIG_USB_GADGET is not set
+# CONFIG_MMC is not set
+
+#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
+# InfiniBand support
+#
+
+#
+# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
+#
+
+#
+# Real Time Clock
+#
+# CONFIG_RTC_CLASS is not set
+
+#
+# DMA Engine support
+#
+# CONFIG_DMA_ENGINE is not set
+
+#
+# DMA Clients
+#
+
+#
+# DMA Devices
+#
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_EXT4DEV_FS is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_GFS2_FS is not set
+# CONFIG_OCFS2_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROC_SYSCTL=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
+# CONFIG_HUGETLB_PAGE is not set
+CONFIG_RAMFS=y
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+
+#
+# Network File Systems
+#
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFS_DIRECTIO is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+# CONFIG_9P_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+
+#
+# Native Language Support
+#
+# CONFIG_NLS is not set
+
+#
+# Distributed Lock Manager
+#
+# CONFIG_DLM is not set
+# CONFIG_UCC_SLOW is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
+CONFIG_CRC32=y
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
+
+#
+# Instrumentation Support
+#
+# CONFIG_PROFILING is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_FS is not set
+# CONFIG_HEADERS_CHECK is not set
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_DETECT_SOFTLOCKUP=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
+# CONFIG_DEBUG_SLAB is not set
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_RT_MUTEX_TESTER is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+# CONFIG_DEBUG_KOBJECT is not set
+CONFIG_DEBUG_BUGVERBOSE=y
+# CONFIG_DEBUG_INFO is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_LIST is not set
+CONFIG_FORCED_INLINING=y
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_FAULT_INJECTION is not set
+# CONFIG_DEBUG_STACKOVERFLOW is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_DEBUG_PAGEALLOC is not set
+# CONFIG_DEBUGGER is not set
+# CONFIG_BDI_SWITCH is not set
+# CONFIG_BOOTX_TEXT is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+
+#
+# Cryptographic options
+#
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_BLKCIPHER=y
+CONFIG_CRYPTO_MANAGER=y
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_XCBC is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_MD4 is not set
+CONFIG_CRYPTO_MD5=y
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+# CONFIG_CRYPTO_GF128MUL is not set
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=y
+# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_CRYPTD is not set
+CONFIG_CRYPTO_DES=y
+# CONFIG_CRYPTO_FCRYPT is not set
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_AES is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_CAMELLIA is not set
+# CONFIG_CRYPTO_TEST is not set
+
+#
+# Hardware crypto devices
+#

[RFC][PATCH 8/8] Walnut board support

[Josh Boyer]

Board support for the PPC405 Walnut evaluation board

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/platforms/4xx/Kconfig  |   14 +++----
 arch/powerpc/platforms/4xx/Makefile |    2 -
 arch/powerpc/platforms/4xx/walnut.c |   68 ++++++++++++++++++++++++++++++++++++
 arch/powerpc/platforms/Kconfig      |    2 -
 arch/powerpc/platforms/Makefile     |    2 -
 5 files changed, 78 insertions(+), 10 deletions(-)

--- linux-2.6.orig/arch/powerpc/platforms/4xx/Makefile
+++ linux-2.6/arch/powerpc/platforms/4xx/Makefile
@@ -1 +1 @@
-# empty makefile so make clean works
\ No newline at end of file
+obj-$(CONFIG_WALNUT) += walnut.o
--- /dev/null
+++ linux-2.6/arch/powerpc/platforms/4xx/walnut.c
@@ -0,0 +1,68 @@
+/*
+ * Architecture- / platform-specific boot-time initialization code for
+ * IBM PowerPC 4xx based boards. Adapted from original
+ * code by Gary Thomas, Cort Dougan <cort@fsmlabs.com>, and Dan Malek
+ * <dan@net4x.com>.
+ *
+ * Copyright(c) 1999-2000 Grant Erickson <grant@lcse.umn.edu>
+ *
+ * Rewritten and ported to the merged powerpc tree:
+ * Copyright 2007 IBM Corporation
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * 2002 (c) MontaVista, Software, Inc.  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.
+ */
+
+#include <linux/init.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/of_platform.h>
+
+static struct of_device_id walnut_of_bus[] = {
+	{ .compatible = "ibm,plb", },
+	{ .compatible = "ibm,opb", },
+	{ .compatible = "ibm,ebc", },
+	{},
+};
+
+static int __init walnut_device_probe(void)
+{
+	if (!machine_is(walnut))
+		return 0;
+
+	/* FIXME: do bus probe here */
+	of_platform_bus_probe(NULL, walnut_of_bus, NULL);
+
+	return 0;
+}
+device_initcall(walnut_device_probe);
+
+static int __init walnut_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+
+	if (!of_flat_dt_is_compatible(root, "ibm,walnut"))
+		return 0;
+
+	return 1;
+}
+
+static void __init walnut_setup_arch(void)
+{
+}
+
+define_machine(walnut) {
+	.name			= "Walnut",
+	.probe			= walnut_probe,
+	.setup_arch		= walnut_setup_arch,
+	.progress		= udbg_progress,
+	.init_IRQ		= uic_init_tree,
+	.get_irq		= uic_get_irq,
+	.calibrate_decr	= generic_calibrate_decr,
+};
--- linux-2.6.orig/arch/powerpc/platforms/4xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/4xx/Kconfig
@@ -53,13 +53,13 @@
 #	help
 #	  This option enables support for the IBM PPC405GPr evaluation board.
 
-#config WALNUT
-#	bool "Walnut"
-#	depends on 40x
-#	default y
-#	select 405GP
-#	help
-#	  This option enables support for the IBM PPC405GP evaluation board.
+config WALNUT
+	bool "Walnut"
+	depends on 40x
+	default y
+	select 405GP
+	help
+	  This option enables support for the IBM PPC405GP evaluation board.
 
 #config XILINX_ML300
 #	bool "Xilinx-ML300"
--- linux-2.6.orig/arch/powerpc/platforms/Kconfig
+++ linux-2.6/arch/powerpc/platforms/Kconfig
@@ -58,7 +58,7 @@ source "arch/powerpc/platforms/85xx/Kcon
 source "arch/powerpc/platforms/86xx/Kconfig"
 source "arch/powerpc/platforms/embedded6xx/Kconfig"
 source "arch/powerpc/platforms/44x/Kconfig"
-#source "arch/powerpc/platforms/4xx/Kconfig
+source "arch/powerpc/platforms/4xx/Kconfig"
 
 config PPC_NATIVE
 	bool
--- linux-2.6.orig/arch/powerpc/platforms/Makefile
+++ linux-2.6/arch/powerpc/platforms/Makefile
@@ -6,7 +6,7 @@ obj-$(CONFIG_PPC_PMAC)		+= powermac/
 endif
 endif
 obj-$(CONFIG_PPC_CHRP)		+= chrp/
-#obj-$(CONFIG_4xx)		+= 4xx/
+obj-$(CONFIG_4xx)		+= 4xx/
 obj-$(CONFIG_44x)		+= 44x/
 obj-$(CONFIG_PPC_MPC52xx)	+= 52xx/
 obj-$(CONFIG_PPC_8xx)		+= 8xx/

[RFC][PATCH 9/8] Walnut zImage wrapper

[Josh Boyer]

Apparently I can't count, so here's one more patch.

Add zImage wrapper for walnut board

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

---
 arch/powerpc/boot/Makefile          |    3 -
 arch/powerpc/boot/treeboot-walnut.c |   92 ++++++++++++++++++++++++++++++++++++
 2 files changed, 94 insertions(+), 1 deletion(-)

--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -47,7 +47,7 @@ src-wlib := string.S crt0.S stdio.c main
 		4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
 src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
 		cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
-		ps3-head.S ps3-hvcall.S ps3.c
+		ps3-head.S ps3-hvcall.S ps3.c treeboot-walnut.c
 src-boot := $(src-wlib) $(src-plat) empty.c
 
 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -142,6 +142,7 @@ ifneq ($(CONFIG_DEVICE_TREE),"")
 image-$(CONFIG_PPC_83xx)		+= cuImage.83xx
 image-$(CONFIG_PPC_85xx)		+= cuImage.85xx
 image-$(CONFIG_EBONY)			+= treeImage.ebony cuImage.ebony
+image-$(CONFIG_WALNUT)			+= treeImage.walnut
 endif
 
 # For 32-bit powermacs, build the COFF and miboot images
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/treeboot-walnut.c
@@ -0,0 +1,92 @@
+/*
+ * Old U-boot compatibility for Walnut
+ *
+ * Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Copyright 2007 IBM Corporation
+ *   Based on cuboot-83xx.c, which is:
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "dcr.h"
+#include "4xx.h"
+
+extern char _end[];
+extern char _dtb_start[];
+extern char _dtb_end[];
+
+BSS_STACK(4096);
+
+void ibm405gp_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
+{
+	u32 pllmr = mfdcr(0xb0);
+	u32 cpc0_cr0 = mfdcr(0xb1);
+	u32 cpc0_cr1 = mfdcr(0xb2);
+	u32 cpu, plb, opb, ebc, tb, uart0, uart1, m;
+	u32 fwdv, fbdv, cbdv, opdv, epdv, udiv;
+
+	fwdv = (8 - ((pllmr & 0xe0000000) >> 29));
+	fbdv = (pllmr & 0x1e000000) >> 25;
+	cbdv = ((pllmr & 0x00060000) >> 17) + 1;
+	opdv = ((pllmr & 0x00018000) >> 15) + 1;
+	epdv = ((pllmr & 0x00001800) >> 13) + 2;
+	udiv = ((cpc0_cr0 & 0x3e) >> 1) + 1;
+
+	m = fwdv * fbdv * cbdv;
+
+	cpu = sysclk * m / fwdv;
+	plb = cpu / cbdv;
+	opb = plb / opdv;
+	ebc = plb / epdv;
+
+	if (cpc0_cr0 & 0x80) {
+		/* uart0 uses the external clock */
+		uart0 = ser_clk;
+	} else {
+		uart0 = cpu / udiv;
+	}
+
+	if (cpc0_cr0 & 0x40) {
+		/* uart1 uses the external clock */
+		uart1 = ser_clk;
+	} else {
+		uart1 = cpu / udiv;
+	}
+
+	/* setup the timebase clock to tick at the cpu frequency */
+	cpc0_cr1 = cpc0_cr1 & ~ 0x00800000;
+	mtdcr(0xb2, cpc0_cr1);
+	tb = cpu;
+
+	dt_fixup_cpu_clocks(cpu, tb, 0);
+	dt_fixup_clock("/plb", plb);
+	dt_fixup_clock("/plb/opb", opb);
+	dt_fixup_clock("/plb/opb/ebc", ebc);
+	dt_fixup_clock("/plb/opb/serial@ef600300", uart0);
+	dt_fixup_clock("/plb/opb/serial@ef600400", uart1);
+}
+
+static void walnut_fixups(void)
+{
+	ibm4xx_fixup_memsize();
+	ibm405gp_fixup_clocks(33330000, 0xa8c000);
+	ibm4xx_reset_eth((u32 *)0xef600800, NULL);
+}
+
+void platform_init(void)
+{
+	unsigned long end_of_ram = 0x2000000;
+	unsigned long avail_ram = end_of_ram - (unsigned long) _end;
+
+	simple_alloc_init(_end, avail_ram, 32, 32);
+	platform_ops.fixups = walnut_fixups;
+	platform_ops.exit = ibm40x_dbcr_reset;
+	ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+	serial_console_init();
+}