Linux-2.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!
diff --git a/arch/arm/mach-ixp4xx/Kconfig b/arch/arm/mach-ixp4xx/Kconfig
new file mode 100644
index 0000000..aacb5f9
--- /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