Commit f5a8eb63 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'arch-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic

Pul removal of obsolete architecture ports from Arnd Bergmann:
 "This removes the entire architecture code for blackfin, cris, frv,
  m32r, metag, mn10300, score, and tile, including the associated device
  drivers.

  I have been working with the (former) maintainers for each one to
  ensure that my interpretation was right and the code is definitely
  unused in mainline kernels. Many had fond memories of working on the
  respective ports to start with and getting them included in upstream,
  but also saw no point in keeping the port alive without any users.

  In the end, it seems that while the eight architectures are extremely
  different, they all suffered the same fate: There was one company in
  charge of an SoC line, a CPU microarchitecture and a software
  ecosystem, which was more costly than licensing newer off-the-shelf
  CPU cores from a third party (typically ARM, MIPS, or RISC-V). It
  seems that all the SoC product lines are still around, but have not
  used the custom CPU architectures for several years at this point. In
  contrast, CPU instruction sets that remain popular and have actively
  maintained kernel ports tend to all be used across multiple licensees.

  [ See the new nds32 port merged in the previous commit for the next
    generation of "one company in charge of an SoC line, a CPU
    microarchitecture and a software ecosystem"   - Linus ]

  The removal came out of a discussion that is now documented at
  https://lwn.net/Articles/748074/. Unlike the original plans, I'm not
  marking any ports as deprecated but remove them all at once after I
  made sure that they are all unused. Some architectures (notably tile,
  mn10300, and blackfin) are still being shipped in products with old
  kernels, but those products will never be updated to newer kernel
  releases.

  After this series, we still have a few architectures without mainline
  gcc support:

   - unicore32 and hexagon both have very outdated gcc releases, but the
     maintainers promised to work on providing something newer. At least
     in case of hexagon, this will only be llvm, not gcc.

   - openrisc, risc-v and nds32 are still in the process of finishing
     their support or getting it added to mainline gcc in the first
     place. They all have patched gcc-7.3 ports that work to some
     degree, but complete upstream support won't happen before gcc-8.1.
     Csky posted their first kernel patch set last week, their situation
     will be similar

  [ Palmer Dabbelt points out that RISC-V support is in mainline gcc
    since gcc-7, although gcc-7.3.0 is the recommended minimum  - Linus ]"

This really says it all:

 2498 files changed, 95 insertions(+), 467668 deletions(-)

* tag 'arch-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: (74 commits)
  MAINTAINERS: UNICORE32: Change email account
  staging: iio: remove iio-trig-bfin-timer driver
  tty: hvc: remove tile driver
  tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
  serial: remove tile uart driver
  serial: remove m32r_sio driver
  serial: remove blackfin drivers
  serial: remove cris/etrax uart drivers
  usb: Remove Blackfin references in USB support
  usb: isp1362: remove blackfin arch glue
  usb: musb: remove blackfin port
  usb: host: remove tilegx platform glue
  pwm: remove pwm-bfin driver
  i2c: remove bfin-twi driver
  spi: remove blackfin related host drivers
  watchdog: remove bfin_wdt driver
  can: remove bfin_can driver
  mmc: remove bfin_sdh driver
  input: misc: remove blackfin rotary driver
  input: keyboard: remove bf54x driver
  ...
parents c9297d28 dd3b8c32

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

......@@ -1564,6 +1564,11 @@ W: http://www.carumba.com/
D: bug toaster (A1 sauce makes all the difference)
D: Random linux hacker
N: James Hogan
E: jhogan@kernel.org
D: Metag architecture maintainer
D: TZ1090 SoC maintainer
N: Tim Hockin
E: thockin@hockin.org
W: http://www.hockin.org/~thockin
......
......@@ -66,8 +66,6 @@ backlight/
- directory with info on controlling backlights in flat panel displays
bcache.txt
- Block-layer cache on fast SSDs to improve slow (raid) I/O performance.
blackfin/
- directory with documentation for the Blackfin arch.
block/
- info on the Block I/O (BIO) layer.
blockdev/
......@@ -114,8 +112,6 @@ cputopology.txt
- documentation on how CPU topology info is exported via sysfs.
crc32.txt
- brief tutorial on CRC computation
cris/
- directory with info about Linux on CRIS architecture.
crypto/
- directory with info on the Crypto API.
dcdbas.txt
......@@ -172,8 +168,6 @@ fmc/
- information about the FMC bus abstraction
fpga/
- FPGA Manager Core.
frv/
- Fujitsu FR-V Linux documentation.
futex-requeue-pi.txt
- info on requeueing of tasks from a non-PI futex to a PI futex
gcc-plugins.txt
......@@ -276,8 +270,6 @@ memory-hotplug.txt
- Hotpluggable memory support, how to use and current status.
men-chameleon-bus.txt
- info on MEN chameleon bus.
metag/
- directory with info about Linux on Meta architecture.
mic/
- Intel Many Integrated Core (MIC) architecture device driver.
mips/
......@@ -286,8 +278,6 @@ misc-devices/
- directory with info about devices using the misc dev subsystem
mmc/
- directory with info about the MMC subsystem
mn10300/
- directory with info about the mn10300 architecture port
mtd/
- directory with info about memory technology devices (flash)
namespaces/
......
......@@ -26,8 +26,8 @@ On what hardware does it run?
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
Xtensa, Tilera TILE, ARC and Renesas M32R architectures.
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 Xtensa, and
ARC architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
......
......@@ -89,7 +89,6 @@ parameter is applicable::
APM Advanced Power Management support is enabled.
ARM ARM architecture is enabled.
AX25 Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled.
CLK Common clock infrastructure is enabled.
CMA Contiguous Memory Area support is enabled.
DRM Direct Rendering Management support is enabled.
......
......@@ -1025,7 +1025,7 @@
address. The serial port must already be setup
and configured. Options are not yet supported.
earlyprintk= [X86,SH,BLACKFIN,ARM,M68k,S390]
earlyprintk= [X86,SH,ARM,M68k,S390]
earlyprintk=vga
earlyprintk=efi
earlyprintk=sclp
......@@ -1347,10 +1347,6 @@
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
hwthread_map= [METAG] Comma-separated list of Linux cpu id to
hardware thread id mappings.
Format: <cpu>:<hwthread>
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the window
......
00-INDEX
- This file
bfin-gpio-notes.txt
- Notes in developing/using bfin-gpio driver.
bfin-spi-notes.txt
- Notes for using bfin spi bus driver.
/*
* File: Documentation/blackfin/bfin-gpio-notes.txt
* Based on:
* Author:
*
* Created: $Id: bfin-gpio-note.txt 2008-11-24 16:42 grafyang $
* Description: This file contains the notes in developing/using bfin-gpio.
*
*
* Rev:
*
* Modified:
* Copyright 2004-2008 Analog Devices Inc.
*
* Bugs: Enter bugs at http://blackfin.uclinux.org/
*
*/
1. Blackfin GPIO introduction
There are many GPIO pins on Blackfin. Most of these pins are muxed to
multi-functions. They can be configured as peripheral, or just as GPIO,
configured to input with interrupt enabled, or output.
For detailed information, please see "arch/blackfin/kernel/bfin_gpio.c",
or the relevant HRM.
2. Avoiding resource conflict
Followed function groups are used to avoiding resource conflict,
- Use the pin as peripheral,
int peripheral_request(unsigned short per, const char *label);
int peripheral_request_list(const unsigned short per[], const char *label);
void peripheral_free(unsigned short per);
void peripheral_free_list(const unsigned short per[]);
- Use the pin as GPIO,
int bfin_gpio_request(unsigned gpio, const char *label);
void bfin_gpio_free(unsigned gpio);
- Use the pin as GPIO interrupt,
int bfin_gpio_irq_request(unsigned gpio, const char *label);
void bfin_gpio_irq_free(unsigned gpio);
The request functions will record the function state for a certain pin,
the free functions will clear its function state.
Once a pin is requested, it can't be requested again before it is freed by
previous caller, otherwise kernel will dump stacks, and the request
function fail.
These functions are wrapped by other functions, most of the users need not
care.
3. But there are some exceptions
- Kernel permit the identical GPIO be requested both as GPIO and GPIO
interrupt.
Some drivers, like gpio-keys, need this behavior. Kernel only print out
warning messages like,
bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
configuring it as IRQ!
Note: Consider the case that, if there are two drivers need the
identical GPIO, one of them use it as GPIO, the other use it as
GPIO interrupt. This will really cause resource conflict. So if
there is any abnormal driver behavior, please check the bfin-gpio
warning messages.
- Kernel permit the identical GPIO be requested from the same driver twice.
SPI Chip Select behavior:
With the Blackfin on-chip SPI peripheral, there is some logic tied to the CPHA
bit whether the Slave Select Line is controlled by hardware (CPHA=0) or
controlled by software (CPHA=1). However, the Linux SPI bus driver assumes that
the Slave Select is always under software control and being asserted during
the entire SPI transfer. - And not just bits_per_word duration.
In most cases you can utilize SPI MODE_3 instead of MODE_0 to work-around this
behavior. If your SPI slave device in question requires SPI MODE_0 or MODE_2
timing, you can utilize the GPIO controlled SPI Slave Select option instead.
In this case, you should use GPIO based CS for all of your slaves and not just
the ones using mode 0 or 2 in order to guarantee correct CS toggling behavior.
You can even use the same pin whose peripheral role is a SSEL,
but use it as a GPIO instead.
Linux on the CRIS architecture
==============================
This is a port of Linux to Axis Communications ETRAX 100LX,
ETRAX FS and ARTPEC-3 embedded network CPUs.
For more information about CRIS and ETRAX please see further below.
In order to compile this you need a version of gcc with support for the
ETRAX chip family. Please see this link for more information on how to
download the compiler and other tools useful when building and booting
software for the ETRAX platform:
http://developer.axis.com/wiki/doku.php?id=axis:install-howto-2_20
What is CRIS ?
--------------
CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU
architecture in Axis Communication AB's range of embedded network CPU's,
called ETRAX.
The ETRAX 100LX chip
--------------------
For reference, please see the following link:
http://www.axis.com/products/dev_etrax_100lx/index.htm
The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad
range of built-in interfaces, all with modern scatter/gather DMA.
Memory interfaces:
* SRAM
* NOR-flash/ROM
* EDO or page-mode DRAM
* SDRAM
I/O interfaces:
* one 10/100 Mbit/s ethernet controller
* four serial-ports (up to 6 Mbit/s)
* two synchronous serial-ports for multimedia codec's etc.
* USB host controller and USB slave
* ATA
* SCSI
* two parallel-ports
* two generic 8-bit ports
(not all interfaces are available at the same time due to chip pin
multiplexing)
ETRAX 100LX is CRISv10 architecture.
The ETRAX FS and ARTPEC-3 chips
-------------------------------
The ETRAX FS is a 200MHz 32-bit RISC processor with on-chip 16kB
I-cache and 16kB D-cache and with a wide range of device interfaces
including multiple high speed serial ports and an integrated USB 1.1 PHY.
The ARTPEC-3 is a variant of the ETRAX FS with additional IO-units
used by the Axis Communications network cameras.
See below link for more information:
http://www.axis.com/products/dev_etrax_fs/index.htm
ETRAX FS and ARTPEC-3 are both CRISv32 architectures.
Bootlog
-------
Just as an example, this is the debug-output from a boot of Linux 2.4 on