Add the following fields to /proc/cpuinfo:
  * chip type and revision (from the JTAG chip id)
  * cpu MHz (from clk_get_rate())
  * features (from the CONFIG0 register)

Also rename "cpu family" to "cpu arch" and "cpu type" to "cpu core" to
remove some ambiguity.

Show chip type and revision at bootup, and clarify that the other
kinds of IDs that we're already printing are for the cpu core and
architecture. Rename "AP7000" to "AP7" since that's the name of the
core.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>

The current debug trap handling code does a number of things that are
illegal according to the AVR32 Architecture manual. Most importantly,
it may try to schedule from Debug Mode, thus clearing the D bit, which
can lead to "undefined behaviour".

It seems like this works in most cases, but several people have
observed somewhat unstable behaviour when debugging programs,
including soft lockups. So there's definitely something which is not
right with the existing code.

The new code will never schedule from Debug mode, it will always exit
Debug mode with a "retd" instruction, and if something not running in
Debug mode needs to do something debug-related (like doing a single
step), it will enter debug mode through a "breakpoint" instruction.
The monitor code will then return directly to user space, bypassing
its own saved registers if necessary (since we don't actually care
about the trapped context, only the one that came before.)

This adds three instructions to the common exception handling code,
including one branch. It does not touch super-hot paths like the TLB
miss handler.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>

  * Use generic BUG() handling
  * Remove some useless debug statements
  * Use a common function _exception() to send signals or oops when
    an exception can't be handled. This makes sure init doesn't
    enter an infinite exception loop as well. Borrowed from powerpc.
  * Add some basic exception tracing support to the page fault code.
  * Rework dump_stack(), show_regs() and friends and move everything
    into process.c
  * Print information about configuration options and chip type when
    oopsing
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>

Clean up the cpu identification code, using definitions from
<asm/sysreg.h> instead of hardcoded constants. Also, add a features
bitmap to struct avr32_cpuinfo to allow other code to make decisions
based upon what the running cpu is actually capable of.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>

This adds support for the Atmel AVR32 architecture as well as the AT32AP7000
CPU and the AT32STK1000 development board.

AVR32 is a new high-performance 32-bit RISC microprocessor core, designed for
cost-sensitive embedded applications, with particular emphasis on low power
consumption and high code density.  The AVR32 architecture is not binary
compatible with earlier 8-bit AVR architectures.

The AVR32 architecture, including the instruction set, is described by the
AVR32 Architecture Manual, available from

http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf

The Atmel AT32AP7000 is the first CPU implementing the AVR32 architecture.  It
features a 7-stage pipeline, 16KB instruction and data caches and a full
Memory Management Unit.  It also comes with a large set of integrated
peripherals, many of which are shared with the AT91 ARM-based controllers from
Atmel.

Full data sheet is available from

http://www.atmel.com/dyn/resources/prod_documents/doc32003.pdf

while the CPU core implementation including caches and MMU is documented by
the AVR32 AP Technical Reference, available from

http://www.atmel.com/dyn/resources/prod_documents/doc32001.pdf

Information about the AT32STK1000 development board can be found at

http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918

including a BSP CD image with an earlier version of this patch, development
tools (binaries and source/patches) and a root filesystem image suitable for
booting from SD card.

Alternatively, there's a preliminary "getting started" guide available at
http://avr32linux.org/twiki/bin/view/Main/GettingStarted which provides links
to the sources and patches you will need in order to set up a cross-compiling
environment for avr32-linux.

This patch, as well as the other patches included with the BSP and the
toolchain patches, is actively supported by Atmel Corporation.

[dmccr@us.ibm.com: Fix more pxx_page macro locations]
[bunk@stusta.de: fix `make defconfig']
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave McCracken <dmccr@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>