Linux-2.6.12-rc2v2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

1 files changed, 127 insertions, 0 deletions

diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
new file mode 100644
index 00000000000..aacb5f9200e
--- /dev/null
+++ b/arch/arm/mach-ixp4xx/Kconfig
@@ -0,0 +1,127 @@
+if ARCH_IXP4XX
+
+config ARCH_SUPPORTS_BIG_ENDIAN
+	bool
+	default y
+
+menu "Intel IXP4xx Implementation Options"
+
+comment "IXP4xx Platforms"
+
+config ARCH_AVILA
+	bool "Avila"
+	help
+	  Say 'Y' here if you want your kernel to support the Gateworks
+	  Avila Network Platform. For more information on this platform,
+	  see <file:Documentation/arm/IXP4xx>.
+
+config ARCH_ADI_COYOTE
+	bool "Coyote"
+	help
+	  Say 'Y' here if you want your kernel to support the ADI 
+	  Engineering Coyote Gateway Reference Platform. For more
+	  information on this platform, see <file:Documentation/arm/IXP4xx>.
+
+config ARCH_IXDP425
+	bool "IXDP425"
+	help
+	  Say 'Y' here if you want your kernel to support Intel's 
+	  IXDP425 Development Platform (Also known as Richfield).  
+	  For more information on this platform, see <file:Documentation/arm/IXP4xx>.
+
+config MACH_IXDPG425
+	bool "IXDPG425"
+	help
+	  Say 'Y' here if you want your kernel to support Intel's
+	  IXDPG425 Development Platform (Also known as Montajade).
+	  For more information on this platform, see <file:Documentation/arm/IXP4xx>.
+
+config MACH_IXDP465
+	bool "IXDP465"
+	help
+	  Say 'Y' here if you want your kernel to support Intel's
+	  IXDP465 Development Platform (Also known as BMP).
+	  For more information on this platform, see Documentation/arm/IXP4xx.
+
+
+#
+# IXCDP1100 is the exact same HW as IXDP425, but with a different machine 
+# number from the bootloader due to marketing monkeys, so we just enable it 
+# by default if IXDP425 is enabled.
+#
+config ARCH_IXCDP1100
+	bool 
+	depends on ARCH_IXDP425
+	default y
+
+config ARCH_PRPMC1100
+	bool "PrPMC1100"
+	help
+	  Say 'Y' here if you want your kernel to support the Motorola
+	  PrPCM1100 Processor Mezanine Module. For more information on
+	  this platform, see <file:Documentation/arm/IXP4xx>.
+
+#
+# Avila and IXDP share the same source for now. Will change in future
+#
+config	ARCH_IXDP4XX
+	bool
+	depends on ARCH_IXDP425 || ARCH_AVILA || MACH_IXDP465
+	default y
+
+#
+# Certain registers and IRQs are only enabled if supporting IXP465 CPUs
+#
+config CPU_IXP46X
+	bool
+	depends on MACH_IXDP465
+	default y
+
+config MACH_GTWX5715
+	bool "Gemtek WX5715 (Linksys WRV54G)"
+	depends on ARCH_IXP4XX
+	help
+		This board is currently inside the Linksys WRV54G Gateways.
+
+		IXP425 - 266mhz
+		32mb SDRAM
+		8mb Flash
+		miniPCI slot 0 does not have a card connector soldered to the board
+		miniPCI slot 1 has an ISL3880 802.11g card (Prism54)
+		npe0 is connected to a Kendin KS8995M Switch (4 ports)
+		npe1 is the "wan" port
+		"Console" UART is available on J11 as console
+		"High Speed" UART is n/c (as far as I can tell)
+		20 Pin ARM/Xscale JTAG interface on J2
+
+
+comment "IXP4xx Options"
+
+config IXP4XX_INDIRECT_PCI
+	bool "Use indirect PCI memory access"
+	help
+          IXP4xx provides two methods of accessing PCI memory space:
+
+          1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
+             To access PCI via this space, we simply ioremap() the BAR
+             into the kernel and we can use the standard read[bwl]/write[bwl]
+             macros. This is the preferred method due to speed but it
+             limits the system to just 64MB of PCI memory. This can be 
+             problamatic if using video cards and other memory-heavy devices.
+          
+          2) If > 64MB of memory space is required, the IXP4xx can be 
+	     configured to use indirect registers to access PCI This allows 
+	     for up to 128MB (0x48000000 to 0x4fffffff) of memory on the bus. 
+	     The disadvantadge of this is that every PCI access requires 
+	     three local register accesses plus a spinlock, but in some 
+	     cases the performance hit is acceptable. In addition, you cannot 
+	     mmap() PCI devices in this case due to the indirect nature
+	     of the PCI window.
+
+	  By default, the direct method is used. Choose this option if you
+	  need to use the indirect method instead. If you don't know
+	  what you need, leave this option unselected.
+
+endmenu
+
+endif