avr32: Retire AVR32 for good

AVR32 is gone. It's already more than two years for no support in Buildroot,
even longer there is no support in GCC (last version is heavily patched 4.2.4).

Linux kernel v4.12 got rid of it (and v4.11 didn't build successfully).

There is no good point to keep this support in U-Boot either.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

5 files changed, 2 insertions, 243 deletions

diff --git a/doc/README.AVR32 b/doc/README.AVR32
deleted file mode 100644
index 632cc0546da..00000000000
--- a/doc/README.AVR32
+++ /dev/null
@@ -1,25 +0,0 @@
-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
-
-A GNU toolchain with support for AVR32, along with non-GNU programming
-and debugging support, can be downloaded from
-
-http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118
-
-A full set of u-boot, kernel and filesystem images can be built using
-buildroot. This will also produce a working toolchain which can be
-used instead of the official GNU toolchain above. A customized version
-of buildroot for AVR32 can be downloaded here:
-
-http://www.atmel.no/buildroot/
-
-The AVR32 ports of u-boot, the Linux kernel, the GNU toolchain and
-other associated software are actively supported by Atmel Corporation.
diff --git a/doc/README.AVR32-port-muxing b/doc/README.AVR32-port-muxing
deleted file mode 100644
index 8c1718cdca1..00000000000
--- a/doc/README.AVR32-port-muxing
+++ /dev/null
@@ -1,208 +0,0 @@
-AVR32 Port multiplexer configuration
-====================================
-
-On AVR32 chips, most external I/O pins are routed through a port
-multiplexer. There are currently two kinds of port multiplexer
-hardware around with different register interfaces:
-
-  * PIO (AT32AP700x; this is also used on ARM AT91 chips)
-  * GPIO (all other AVR32 chips)
-
-The "PIO" variant supports multiplexing up to two peripherals per pin
-in addition to GPIO (software control). Each pin has configurable
-pull-up, glitch filter, interrupt and multi-drive capabilities.
-
-The "GPIO" variant supports multiplexing up to four peripherals per
-pin in addition to GPIO. Each pin has configurable
-pull-up/pull-down/buskeeper, glitch filter, interrupt, open-drain and
-schmitt-trigger capabilities, as well as configurable drive strength
-and slew rate control.
-
-Both controllers are configured using the same API, but the functions
-may accept different values for some parameters depending on the
-actual portmux implementation, and some parameters may be ignored by
-one of the implementation (e.g. the "PIO" implementation will ignore
-the drive strength flags since the hardware doesn't support
-configurable drive strength.)
-
-Selecting the portmux implementation
-------------------------------------
-Since u-boot is lacking a Kconfig-style configuration engine, the
-portmux implementation must be selected manually by defining one of
-the following symbols:
-
-	CONFIG_PORTMUX_PIO
-	CONFIG_PORTMUX_GPIO
-
-depending on which implementation the chip in question uses.
-
-Identifying pins
-----------------
-The portmux configuration functions described below identify the pins
-to act on based on two parameters: A "port" (i.e. a block of pins
-that somehow belong together) and a pin mask. Both are defined in an
-implementation-specific manner.
-
-The available ports are defined on the form
-
-  #define PORTMUX_PORT_A	(something)
-
-where "A" matches the identifier given in the chip's data sheet, and
-"something" is whatever the portmux implementation needs to identify
-the port (usually a memory address).
-
-The pin mask is a bitmask where each '1' bit indicates a pin to apply
-the current operation to. The width of the bitmask may vary from port
-to port, but it is never wider than 32 bits (which is the width of
-'unsigned long' on avr32).
-
-Selecting functions
--------------------
-Each pin can either be assigned to one of a predefined set of on-chip
-peripherals, or it can be set up to be controlled by software. For the
-former case, the portmux implementation defines an enum containing all
-the possible peripheral functions that can be selected. For example,
-the PIO implementation, which allows multiplexing two peripherals per
-pin, defines it like this:
-
-	enum portmux_function {
-		PORTMUX_FUNC_A,
-		PORTMUX_FUNC_B,
-	};
-
-To configure a set of pins to be connected to a given peripheral
-function, the following function is used.
-
-	void portmux_select_peripheral(void *port, unsigned long pin_mask,
-			enum portmux_function func, unsigned long flags);
-
-To configure a set of pins to be controlled by software (GPIO), the
-following function is used. In this case, no "function" argument is
-required since "GPIO" is a function in its own right.
-
-	void portmux_select_gpio(void *port, unsigned int pin_mask,
-			unsigned long flags);
-
-Both of these functions take a "flags" parameter which may be used to
-alter the default configuration of the pin. This is a bitmask of
-various flags defined in an implementation-specific way, but the names
-of the flags are the same on all implementations.
-
-	PORTMUX_DIR_OUTPUT
-	PORTMUX_DIR_INPUT
-
-These mutually-exclusive flags configure the initial direction of the
-pins. PORTMUX_DIR_OUTPUT means that the pins are driven by the CPU,
-while PORTMUX_DIR_INPUT means that the pins are tristated by the CPU.
-These flags are ignored by portmux_select_peripheral().
-
-	PORTMUX_INIT_HIGH
-	PORTMUX_INIT_LOW
-
-These mutually-exclusive flags configure the initial state of the
-pins: High (Vdd) or low (Vss). They are only effective when
-portmux_select_gpio() is called with the PORTMUX_DIR_OUTPUT flag set.
-
-	PORTMUX_PULL_UP
-	PORTMUX_PULL_DOWN
-	PORTMUX_BUSKEEPER
-
-These mutually-exclusive flags are used to enable any on-chip CMOS
-resistors connected to the pins. PORTMUX_PULL_UP causes the pins to be
-pulled up to Vdd, PORTMUX_PULL_DOWN causes the pins to be pulled down
-to Vss, and PORTMUX_BUSKEEPER will keep the pins in whatever state
-they were left in by whatever was driving them last. If none of the
-flags are specified, the pins are left floating if no one are driving
-them; this is only recommended for always-output pins (e.g. extern
-address and control lines driven by the CPU.)
-
-Note that the "PIO" implementation will silently ignore the
-PORTMUX_PULL_DOWN flag and interpret PORTMUX_BUSKEEPER as
-PORTMUX_PULL_UP.
-
-	PORTMUX_DRIVE_MIN
-	PORTMUX_DRIVE_LOW
-	PORTMUX_DRIVE_HIGH
-	PORTMUX_DRIVE_MAX
-
-These mutually-exclusive flags determine the drive strength of the
-pins. PORTMUX_DRIVE_MIN will give low power-consumption, but may cause
-corruption of high-speed signals. PORTMUX_DRIVE_MAX will give high
-power-consumption, but may be necessary on pins toggling at very high
-speeds. PORTMUX_DRIVE_LOW and PORTMUX_DRIVE_HIGH specify something in
-between the other two.
-
-Note that setting the drive strength too high may cause excessive
-overshoot and EMI problems, which may in turn cause signal corruption.
-Also note that the "PIO" implementation will silently ignore these
-flags.
-
-	PORTMUX_OPEN_DRAIN
-
-This flag will configure the pins as "open drain", i.e. setting the
-pin state to 0 will drive it low, while setting it to 1 will leave it
-floating (or, in most cases, let it be pulled high by an internal or
-external pull-up resistor.) In the data sheet for chips using the
-"PIO" variant, this mode is called "multi-driver".
-
-Enabling specific peripherals
------------------------------
-In addition to the above functions, each chip provides a set of
-functions for setting up the port multiplexer to use a given
-peripheral. The following are some of the functions available.
-
-All the functions below take a "drive_strength" parameter, which must
-be one of the PORTMUX_DRIVE_x flags specified above.  Any other
-portmux flags will be silently filtered out.
-
-To set up the External Bus Interface (EBI), call
-
-	void portmux_enable_ebi(unsigned int bus_width,
-			unsigned long flags, unsigned long drive_strength)
-
-where "bus_width" must be either 16 or 32. "flags" can be any
-combination of the following flags.
-
-	PORTMUX_EBI_CS(x)	/* Enable chip select x */
-	PORTMUX_EBI_NAND	/* Enable NAND flash interface */
-	PORTMUX_EBI_CF(x)	/* Enable CompactFlash interface x */
-	PORTMUX_EBI_NWAIT	/* Enable NWAIT signal */
-
-To set up a USART, call
-
-	void portmux_enable_usartX(unsigned long drive_strength);
-
-where X is replaced by the USART instance to be configured.
-
-To set up an ethernet MAC:
-
-	void portmux_enable_macbX(unsigned long flags,
-			unsigned long drive_strength);
-
-where X is replaced by the MACB instance to be configured. "flags" can
-be any combination of the following flags.
-
-	PORTMUX_MACB_RMII	/* Just set up the RMII interface */
-	PORTMUX_MACB_MII	/* Set up full MII interface */
-	PORTMUX_MACB_SPEED	/* Enable the SPEED pin */
-
-To set up the MMC controller:
-
-	void portmux_enable_mmci(unsigned long slot, unsigned long flags
-			unsigned long drive_strength);
-
-where "slot" identifies which of the alternative SD card slots to
-enable. "flags" can be any combination of the following flags:
-
-	PORTMUX_MMCI_4BIT	/* Enable 4-bit SD card interface */
-	PORTMUX_MMCI_8BIT	/* Enable 8-bit MMC+ interface */
-	PORTMUX_MMCI_EXT_PULLUP	/* Board has external pull-ups */
-
-To set up a SPI controller:
-
-	void portmux_enable_spiX(unsigned long cs_mask,
-			unsigned long drive_strength);
-
-where X is replaced by the SPI instance to be configured. "cs_mask" is
-a 4-bit bitmask specifying which of the four standard chip select
-lines to set up as GPIOs.
diff --git a/doc/README.atmel_mci b/doc/README.atmel_mci
index 6043dabff79..6c027b089f2 100644
--- a/doc/README.atmel_mci
+++ b/doc/README.atmel_mci
@@ -11,8 +11,7 @@ to write blocks.
 - AT91SAM9260 (not tested, but MCI is to AT91SAM9XE)
 - AT91SAM9G20 (not tested, should work)
 
-It should work with all other ATMEL devices that have MCI,
-including AVR32.
+It should work with all other ATMEL devices that have MCI.
 
 The generic driver does NOT assign port pins to the MCI block
 nor does it start the MCI clock. This has to be handled in a
diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index 5e5b07d95e6..fc0873431aa 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -94,12 +94,6 @@ vpac270_ond_256  arm         pxa            452ef830    2015-08-30  Marek Vasut
 xaeniax          arm         pxa            1c87dd76    2015-08-30
 zipitz2          arm         pxa            49d8899b    2015-08-30  Cliff Brake <cliff.brake@gmail.com>
 cam_enc_4xx      arm         arm926ejs      8d775763    2015-08-20  Heiko Schocher <hs@denx.de>
-atstk1003        avr32       -              e5354b8a    2015-06-10  Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
-atstk1004        avr32       -              e5354b8a    2015-06-10  Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
-atstk1006        avr32       -              e5354b8a    2015-06-10  Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
-mimc200          avr32       -              c62d2f8f    2015-06-10  Mark Jackson <mpfj@mimc.co.uk>
-hammerhead       avr32       -              e3693076    2015-06-10  Alex Raimondi <alex.raimondi@miromico.ch>
-favr-32-ezkit    avr32       -              9eb45aab    2015-06-10  Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
 afeb9260         arm         arm926ejs      f6b42c14    2015-05-13  Sergey Lapin <slapin@ossfans.org>
 tny_a9260        arm         arm926ejs      f6b42c14    2015-05-13  Albin Tonnerre <albin.tonnerre@free-electrons.com>
 sbc35_a9g20      arm         arm926ejs      f6b42c14    2015-05-13  Albin Tonnerre <albin.tonnerre@free-electrons.com>
diff --git a/doc/git-mailrc b/doc/git-mailrc
index 04c6c8df9d7..af10a3d68e2 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -54,7 +54,7 @@ alias vapier         Mike Frysinger <vapier@gentoo.org>
 alias wd             Wolfgang Denk <wd@denx.de>
 
 # Architecture aliases
-alias arch           arc, arm, avr32, bfin, m68k, microblaze, mips, nds32, nios2, powerpc, sandbox, superh, sparc, x86
+alias arch           arc, arm, bfin, m68k, microblaze, mips, nds32, nios2, powerpc, sandbox, superh, sparc, x86
 alias arches         arch
 
 alias arc            uboot, abrodkin
@@ -79,7 +79,6 @@ alias ti             uboot, trini
 alias uniphier       uboot, masahiro
 alias zynq           uboot, monstr
 alias rockchip       uboot, sjg, Kever Yang <kever.yang@rock-chips.com>, ptomsich
-alias avr32          uboot, abiessmann
 
 alias bfin           uboot, vapier, sonic
 alias blackfin       bfin