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!

57 files changed, 17255 insertions, 0 deletions

diff --git a/arch/cris/arch-v10/Kconfig b/arch/cris/arch-v10/Kconfig
new file mode 100644
index 00000000000..2ca64cc40c6
--- /dev/null
+++ b/arch/cris/arch-v10/Kconfig
@@ -0,0 +1,422 @@
+# ETRAX 100LX v1 has a MMU "feature" requiring a low mapping
+config CRIS_LOW_MAP
+	bool
+	depends on ETRAX_ARCH_V10 && ETRAX100LX
+	default y
+
+config ETRAX_DRAM_VIRTUAL_BASE
+	hex
+	depends on ETRAX_ARCH_V10
+	default "c0000000" if !ETRAX100LX
+	default "60000000" if ETRAX100LX
+
+choice
+	prompt "Product LED port"
+	depends on ETRAX_ARCH_V10
+	default ETRAX_PA_LEDS
+
+config ETRAX_PA_LEDS
+	bool "Port-PA-LEDs"
+	help
+	  The ETRAX network driver is responsible for flashing LED's when
+	  packets arrive and are sent.  It uses macros defined in
+	  <file:include/asm-cris/io.h>, and those macros are defined after what
+	  YOU choose in this option.  The actual bits used are configured
+	  separately.  Select this if the LEDs are on port PA.  Some products
+	  put the leds on PB or a memory-mapped latch (CSP0) instead.
+
+config ETRAX_PB_LEDS
+	bool "Port-PB-LEDs"
+	help
+	  The ETRAX network driver is responsible for flashing LED's when
+	  packets arrive and are sent.  It uses macros defined in
+	  <file:include/asm-cris/io.h>, and those macros are defined after what
+	  YOU choose in this option.  The actual bits used are configured
+	  separately.  Select this if the LEDs are on port PB.  Some products
+	  put the leds on PA or a memory-mapped latch (CSP0) instead.
+
+config ETRAX_CSP0_LEDS
+	bool "Port-CSP0-LEDs"
+	help
+	  The ETRAX network driver is responsible for flashing LED's when
+	  packets arrive and are sent. It uses macros defined in
+	  <file:include/asm-cris/io.h>, and those macros are defined after what
+	  YOU choose in this option.  The actual bits used are configured
+	  separately.  Select this if the LEDs are on a memory-mapped latch
+	  using chip select CSP0, this is mapped at 0x90000000.
+	  Some products put the leds on PA or PB instead.
+
+config ETRAX_NO_LEDS
+	bool "None"
+	help
+	  Select this option if you don't have any LED at all.
+
+endchoice
+
+config ETRAX_LED1G
+	int "First green LED bit"
+	depends on ETRAX_ARCH_V10 && !ETRAX_NO_LEDS
+	default "2"
+	help
+	  Bit to use for the first green LED.
+	  Most Axis products use bit 2 here.
+
+config ETRAX_LED1R
+	int "First red LED bit"
+	depends on ETRAX_ARCH_V10 && !ETRAX_NO_LEDS
+	default "3"
+	help
+	  Bit to use for the first red LED.
+	  Most Axis products use bit 3 here.
+	  For products with only one controllable LED,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED2G
+	int "Second green LED bit"
+	depends on ETRAX_ARCH_V10 && !ETRAX_NO_LEDS
+	default "4"
+	help
+	  Bit to use for the second green LED. The "Active" LED.
+	  Most Axis products use bit 4 here.
+	  For products with only one controllable LED,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED2R
+	int "Second red LED bit"
+	depends on ETRAX_ARCH_V10 && !ETRAX_NO_LEDS
+	default "5"
+	help
+	  Bit to use for the second red LED.
+	  Most Axis products use bit 5 here.
+	  For products with only one controllable LED,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED3G
+	int "Third green LED bit"
+	depends on ETRAX_ARCH_V10 && !ETRAX_NO_LEDS
+	default "2"
+	help
+	  Bit to use for the third green LED. The "Drive" LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED3R
+	int "Third red LED bit"
+	depends on ETRAX_ARCH_V10 && !ETRAX_NO_LEDS
+	default "2"
+	help
+	  Bit to use for the third red LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED4R
+	int "Fourth red LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the fourth red LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED4G
+	int "Fourth green LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the fourth green LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED5R
+	int "Fifth red LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the fifth red LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED5G
+	int "Fifth green LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the fifth green LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED6R
+	int "Sixth red LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the sixth red LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED6G
+	int "Sixth green LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the sixth green LED. The "Drive" LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED7R
+	int "Seventh red LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the seventh red LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED7G
+	int "Seventh green LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the seventh green LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED8Y
+	int "Eigth yellow LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the eighth yellow LED. The "Drive" LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED9Y
+	int "Ninth yellow LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the ninth yellow LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED10Y
+	int "Tenth yellow LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the tenth yellow LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED11Y
+	int "Eleventh yellow LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the eleventh yellow LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+config ETRAX_LED12R
+	int "Twelfth red LED bit"
+	depends on ETRAX_CSP0_LEDS
+	default "2"
+	help
+	  Bit to use for the twelfth red LED.
+	  For products with only one or two controllable LEDs,
+	  set this to same as CONFIG_ETRAX_LED1G (normally 2).
+
+choice
+	prompt "Product debug-port"
+	depends on ETRAX_ARCH_V10
+	default ETRAX_DEBUG_PORT0
+
+config ETRAX_DEBUG_PORT0
+	bool "Serial-0"
+	help
+	  Choose a serial port for the ETRAX debug console.  Default to
+	  port 0.
+
+config ETRAX_DEBUG_PORT1
+	bool "Serial-1"
+	help
+	  Use serial port 1 for the console.
+
+config ETRAX_DEBUG_PORT2
+	bool "Serial-2"
+	help
+	  Use serial port 2 for the console.
+
+config ETRAX_DEBUG_PORT3
+	bool "Serial-3"
+	help
+	  Use serial port 3 for the console.
+
+config ETRAX_DEBUG_PORT_NULL
+	bool "disabled"
+	help
+	  Disable serial-port debugging.
+
+endchoice
+
+choice
+	prompt "Product rescue-port"
+	depends on ETRAX_ARCH_V10
+	default ETRAX_RESCUE_SER0
+
+config ETRAX_RESCUE_SER0
+	bool "Serial-0"
+	help
+	  Select one of the four serial ports as a rescue port.  The default
+	  is port 0.
+
+config ETRAX_RESCUE_SER1
+	bool "Serial-1"
+	help
+	  Use serial port 1 as the rescue port.
+
+config ETRAX_RESCUE_SER2
+	bool "Serial-2"
+	help
+	  Use serial port 2 as the rescue port.
+
+config ETRAX_RESCUE_SER3
+	bool "Serial-3"
+	help
+	  Use serial port 3 as the rescue port.
+
+endchoice
+
+config ETRAX_DEF_R_WAITSTATES
+	hex "R_WAITSTATES"
+	depends on ETRAX_ARCH_V10
+	default "95a6"
+	help
+	  Waitstates for SRAM, Flash and peripherials (not DRAM).  95f8 is a
+	  good choice for most Axis products...
+
+config ETRAX_DEF_R_BUS_CONFIG
+	hex "R_BUS_CONFIG"
+	depends on ETRAX_ARCH_V10
+	default "104"
+	help
+	  Assorted bits controlling write mode, DMA burst length etc.  104 is
+	  a good choice for most Axis products...
+
+config ETRAX_SDRAM
+	bool "SDRAM support"
+	depends on ETRAX_ARCH_V10
+	help
+	  Enable this if you use SDRAM chips and configure
+	  R_SDRAM_CONFIG and R_SDRAM_TIMING as well.
+
+config ETRAX_DEF_R_DRAM_CONFIG
+	hex "R_DRAM_CONFIG"
+	depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM
+	default "1a200040"
+	help
+	  The R_DRAM_CONFIG register specifies everything on how the DRAM
+	  chips in the system are connected to the ETRAX CPU.  This is
+	  different depending on the manufacturer, chip type and number of
+	  chips.  So this value often needs to be different for each Axis
+	  product.
+
+config ETRAX_DEF_R_DRAM_TIMING
+	hex "R_DRAM_TIMING"
+	depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM
+	default "5611"
+	help
+	  Different DRAM chips have different speeds.  Current Axis products
+	  use 50ns DRAM chips which can use the timing: 5611.
+
+config ETRAX_DEF_R_SDRAM_CONFIG
+	hex "R_SDRAM_CONFIG"
+	depends on ETRAX_ARCH_V10 && ETRAX_SDRAM
+	default "d2fa7878"
+	help
+	  The R_SDRAM_CONFIG register specifies everything on how the SDRAM
+	  chips in the system are connected to the ETRAX CPU.  This is
+	  different depending on the manufacturer, chip type and number of
+	  chips.  So this value often needs to be different for each Axis
+	  product.
+
+config ETRAX_DEF_R_SDRAM_TIMING
+	hex "R_SDRAM_TIMING"
+	depends on ETRAX_ARCH_V10 && ETRAX_SDRAM
+	default "80004801"
+	help
+	  Different SDRAM chips have different timing.
+
+config ETRAX_DEF_R_PORT_PA_DIR
+	hex "R_PORT_PA_DIR"
+	depends on ETRAX_ARCH_V10
+	default "1c"
+	help
+	  Configures the direction of general port A bits.  1 is out, 0 is in.
+	  This is often totally different depending on the product used.
+	  There are some guidelines though - if you know that only LED's are
+	  connected to port PA, then they are usually connected to bits 2-4
+	  and you can therefore use 1c.  On other boards which don't have the
+	  LED's at the general ports, these bits are used for all kinds of
+	  stuff.  If you don't know what to use, it is always safe to put all
+	  as inputs, although floating inputs isn't good.
+
+config ETRAX_DEF_R_PORT_PA_DATA
+	hex "R_PORT_PA_DATA"
+	depends on ETRAX_ARCH_V10
+	default "00"
+	help
+	  Configures the initial data for the general port A bits.  Most
+	  products should use 00 here.
+
+config ETRAX_DEF_R_PORT_PB_CONFIG
+	hex "R_PORT_PB_CONFIG"
+	depends on ETRAX_ARCH_V10
+	default "00"
+	help
+	  Configures the type of the general port B bits.  1 is chip select,
+	  0 is port.  Most products should use 00 here.
+
+config ETRAX_DEF_R_PORT_PB_DIR
+	hex "R_PORT_PB_DIR"
+	depends on ETRAX_ARCH_V10
+	default "00"
+	help
+	  Configures the direction of general port B bits. 1 is out, 0 is in.
+	  This is often totally different depending on the product used.  Bits
+	  0 and 1 on port PB are usually used for I2C communication, but the
+	  kernel I2C driver sets the appropriate directions itself so you
+	  don't need to take that into consideration when setting this option.
+	  If you don't know what to use, it is always safe to put all as
+	  inputs.
+
+config ETRAX_DEF_R_PORT_PB_DATA
+	hex "R_PORT_PB_DATA"
+	depends on ETRAX_ARCH_V10
+	default "ff"
+	help
+	  Configures the initial data for the general port A bits.  Most
+	  products should use FF here.
+
+config ETRAX_SOFT_SHUTDOWN
+	bool "Software Shutdown Support"
+	depends on ETRAX_ARCH_V10
+	help
+	  Enable this if ETRAX is used with a power-supply that can be turned
+	  off and on with PS_ON signal. Gives the possibility to detect
+	  powerbutton and then do a power off after unmounting disks.
+
+config ETRAX_SHUTDOWN_BIT
+	int "Shutdown bit on port CSP0"
+	depends on ETRAX_SOFT_SHUTDOWN
+	default "12"
+	help
+	  Configure what pin on CSPO-port that is used for controlling power
+	  supply.
+
+config ETRAX_POWERBUTTON_BIT
+	int "Power button bit on port G"
+	depends on ETRAX_SOFT_SHUTDOWN
+	default "25"
+	help
+	  Configure where power button is connected.
diff --git a/arch/cris/arch-v10/README.mm b/arch/cris/arch-v10/README.mm
new file mode 100644
index 00000000000..6f08903f313
--- /dev/null
+++ b/arch/cris/arch-v10/README.mm
@@ -0,0 +1,244 @@
+Memory management for CRIS/MMU
+------------------------------
+HISTORY:
+
+$Log: README.mm,v $
+Revision 1.1  2001/12/17 13:59:27  bjornw
+Initial revision
+
+Revision 1.1  2000/07/10 16:25:21  bjornw
+Initial revision
+
+Revision 1.4  2000/01/17 02:31:59  bjornw
+Added discussion of paging and VM.
+
+Revision 1.3  1999/12/03 16:43:23  hp
+Blurb about that the 3.5G-limitation is not a MMU limitation
+
+Revision 1.2  1999/12/03 16:04:21  hp
+Picky comment about not mapping the first page
+
+Revision 1.1  1999/12/03 15:41:30  bjornw
+First version of CRIS/MMU memory layout specification.
+
+
+
+
+
+------------------------------
+
+See the ETRAX-NG HSDD for reference.
+
+We use the page-size of 8 kbytes, as opposed to the i386 page-size of 4 kbytes.
+
+The MMU can, apart from the normal mapping of pages, also do a top-level
+segmentation of the kernel memory space. We use this feature to avoid having
+to use page-tables to map the physical memory into the kernel's address
+space. We also use it to keep the user-mode virtual mapping in the same
+map during kernel-mode, so that the kernel easily can access the corresponding
+user-mode process' data.
+
+As a comparision, the Linux/i386 2.0 puts the kernel and physical RAM at
+address 0, overlapping with the user-mode virtual space, so that descriptor
+registers are needed for each memory access to specify which MMU space to
+map through. That changed in 2.2, putting the kernel/physical RAM at 
+0xc0000000, to co-exist with the user-mode mapping. We will do something
+quite similar, but with the additional complexity of having to map the
+internal chip I/O registers and the flash memory area (including SRAM
+and peripherial chip-selets).
+
+The kernel-mode segmentation map:
+
+        ------------------------                ------------------------
+FFFFFFFF|                      | => cached      |                      | 
+        |    kernel seg_f      |    flash       |                      |
+F0000000|______________________|                |                      |
+EFFFFFFF|                      | => uncached    |                      | 
+        |    kernel seg_e      |    flash       |                      |
+E0000000|______________________|                |        DRAM          |
+DFFFFFFF|                      |  paged to any  |      Un-cached       | 
+        |    kernel seg_d      |    =======>    |                      |
+D0000000|______________________|                |                      |
+CFFFFFFF|                      |                |                      | 
+        |    kernel seg_c      |==\             |                      |
+C0000000|______________________|   \            |______________________|
+BFFFFFFF|                      |  uncached      |                      |
+        |    kernel seg_b      |=====\=========>|       Registers      |
+B0000000|______________________|      \c        |______________________|
+AFFFFFFF|                      |       \a       |                      |
+        |                      |        \c      | FLASH/SRAM/Peripheral|
+        |                      |         \h     |______________________|
+        |                      |          \e    |                      |
+        |                      |           \d   |                      |
+        | kernel seg_0 - seg_a |            \==>|         DRAM         | 
+        |                      |                |        Cached        |
+        |                      |  paged to any  |                      |
+        |                      |    =======>    |______________________| 
+        |                      |                |                      |
+        |                      |                |        Illegal       |
+        |                      |                |______________________|
+        |                      |                |                      |      
+        |                      |                | FLASH/SRAM/Peripheral|
+00000000|______________________|                |______________________|
+
+In user-mode it looks the same except that only the space 0-AFFFFFFF is
+available. Therefore, in this model, the virtual address space per process
+is limited to 0xb0000000 bytes (minus 8192 bytes, since the first page,
+0..8191, is never mapped, in order to trap NULL references).
+
+It also means that the total physical RAM that can be mapped is 256 MB
+(kseg_c above). More RAM can be mapped by choosing a different segmentation
+and shrinking the user-mode memory space.
+
+The MMU can map all 4 GB in user mode, but doing that would mean that a
+few extra instructions would be needed for each access to user mode
+memory.
+
+The kernel needs access to both cached and uncached flash. Uncached is
+necessary because of the special write/erase sequences. Also, the 
+peripherial chip-selects are decoded from that region.
+
+The kernel also needs its own virtual memory space. That is kseg_d. It
+is used by the vmalloc() kernel function to allocate virtual contiguous
+chunks of memory not possible using the normal kmalloc physical RAM 
+allocator.
+
+The setting of the actual MMU control registers to use this layout would
+be something like this:
+
+R_MMU_KSEG = ( ( seg_f, seg     ) |   // Flash cached
+               ( seg_e, seg     ) |   // Flash uncached
+               ( seg_d, page    ) |   // kernel vmalloc area    
+               ( seg_c, seg     ) |   // kernel linear segment
+               ( seg_b, seg     ) |   // kernel linear segment
+               ( seg_a, page    ) |
+               ( seg_9, page    ) |
+               ( seg_8, page    ) |
+               ( seg_7, page    ) |
+               ( seg_6, page    ) |
+               ( seg_5, page    ) |
+               ( seg_4, page    ) |
+               ( seg_3, page    ) |
+               ( seg_2, page    ) |
+               ( seg_1, page    ) |
+               ( seg_0, page    ) );
+
+R_MMU_KBASE_HI = ( ( base_f, 0x0 ) |   // flash/sram/periph cached
+                   ( base_e, 0x8 ) |   // flash/sram/periph uncached
+                   ( base_d, 0x0 ) |   // don't care
+                   ( base_c, 0x4 ) |   // physical RAM cached area
+                   ( base_b, 0xb ) |   // uncached on-chip registers
+                   ( base_a, 0x0 ) |   // don't care
+                   ( base_9, 0x0 ) |   // don't care
+                   ( base_8, 0x0 ) );  // don't care
+
+R_MMU_KBASE_LO = ( ( base_7, 0x0 ) |   // don't care
+                   ( base_6, 0x0 ) |   // don't care
+                   ( base_5, 0x0 ) |   // don't care
+                   ( base_4, 0x0 ) |   // don't care
+                   ( base_3, 0x0 ) |   // don't care
+                   ( base_2, 0x0 ) |   // don't care
+                   ( base_1, 0x0 ) |   // don't care
+                   ( base_0, 0x0 ) );  // don't care
+
+NOTE: while setting up the MMU, we run in a non-mapped mode in the DRAM (0x40
+segment) and need to setup the seg_4 to a unity mapping, so that we don't get
+a fault before we have had time to jump into the real kernel segment (0xc0). This
+is done in head.S temporarily, but fixed by the kernel later in paging_init.
+
+
+Paging - PTE's, PMD's and PGD's
+-------------------------------
+
+[ References: asm/pgtable.h, asm/page.h, asm/mmu.h ]
+
+The paging mechanism uses virtual addresses to split a process memory-space into
+pages, a page being the smallest unit that can be freely remapped in memory. On
+Linux/CRIS, a page is 8192 bytes (for technical reasons not equal to 4096 as in 
+most other 32-bit architectures). It would be inefficient to let a virtual memory
+mapping be controlled by a long table of page mappings, so it is broken down into
+a 2-level structure with a Page Directory containing pointers to Page Tables which
+each have maps of