15 files changed, 210 insertions, 371 deletions

diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx
index 133c5fa6c7a1..7b9351f2f555 100644
--- a/Documentation/arm/IXP4xx
+++ b/Documentation/arm/IXP4xx
@@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
 - Timers (watchdog, OS)
 
 The following components of the chips are not supported by Linux and
-require the use of Intel's propietary CSR softare:
+require the use of Intel's proprietary CSR softare:
 
 - USB device interface
 - Network interfaces (HSS, Utopia, NPEs, etc)
@@ -47,7 +47,7 @@ software from:
 
    http://developer.intel.com/design/network/products/npfamily/ixp425.htm    
 
-DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
+DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
 SOFTWARE.
 
 There are several websites that provide directions/pointers on using
diff --git a/Documentation/arm/SH-Mobile/Makefile b/Documentation/arm/SH-Mobile/Makefile
new file mode 100644
index 000000000000..8771d832cf8c
--- /dev/null
+++ b/Documentation/arm/SH-Mobile/Makefile
@@ -0,0 +1,8 @@
+BIN := vrl4
+
+.PHONY: all
+all: $(BIN)
+
+.PHONY: clean
+clean:
+        rm -f *.o $(BIN)
diff --git a/Documentation/arm/SH-Mobile/vrl4.c b/Documentation/arm/SH-Mobile/vrl4.c
new file mode 100644
index 000000000000..e8a191358ad2
--- /dev/null
+++ b/Documentation/arm/SH-Mobile/vrl4.c
@@ -0,0 +1,169 @@
+/*
+ * vrl4 format generator
+ *
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+/*
+ * usage: vrl4 < zImage > out
+ *        dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1
+ *
+ * Reads a zImage from stdin and writes a vrl4 image to stdout.
+ * In practice this means writing a padded vrl4 header to stdout followed
+ * by the zImage.
+ *
+ * The padding places the zImage at ALIGN bytes into the output.
+ * The vrl4 uses ALIGN + START_BASE as the start_address.
+ * This is where the mask ROM will jump to after verifying the header.
+ *
+ * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
+ * That is, the mask ROM will load the padded header (ALIGN bytes)
+ * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
+ * whichever is smaller.
+ *
+ * The zImage is not modified in any way.
+ */
+
+#define _BSD_SOURCE
+#include <endian.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <errno.h>
+
+struct hdr {
+        uint32_t magic1;
+        uint32_t reserved1;
+        uint32_t magic2;
+        uint32_t reserved2;
+        uint16_t copy_size;
+        uint16_t boot_options;
+        uint32_t reserved3;
+        uint32_t start_address;
+        uint32_t reserved4;
+        uint32_t reserved5;
+        char     reserved6[308];
+};
+
+#define DECLARE_HDR(h)                                  \
+        struct hdr (h) = {                              \
+                .magic1 =       htole32(0xea000000),    \
+                .reserved1 =    htole32(0x56),          \
+                .magic2 =       htole32(0xe59ff008),    \
+                .reserved3 =    htole16(0x1) }
+
+/* Align to 512 bytes, the MMCIF sector size */
+#define ALIGN_BITS      9
+#define ALIGN           (1 << ALIGN_BITS)
+
+#define START_BASE      0xe55b0000
+
+/*
+ * With an alignment of 512 the header uses the first sector.
+ * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
+ * So there are 127 sectors left for the boot programme. But in practice
+ * Only a small portion of a zImage is needed, 16 sectors should be more
+ * than enough.
+ *
+ * Note that this sets how much of the zImage is copied by the mask ROM.
+ * The entire zImage is present after the header and is loaded
+ * by the code in the boot program (which is the first portion of the zImage).
+ */
+#define MAX_BOOT_PROG_LEN (16 * 512)
+
+#define ROUND_UP(x)     ((x + ALIGN - 1) & ~(ALIGN - 1))
+
+ssize_t do_read(int fd, void *buf, size_t count)
+{
+        size_t offset = 0;
+        ssize_t l;
+
+        while (offset < count) {
+                l = read(fd, buf + offset, count - offset);
+                if (!l)
+                        break;
+                if (l < 0) {
+                        if (errno == EAGAIN || errno == EWOULDBLOCK)
+                                continue;
+                        perror("read");
+                        return -1;
+                }
+                offset += l;
+        }
+
+        return offset;
+}
+
+ssize_t do_write(int fd, const void *buf, size_t count)
+{
+        size_t offset = 0;
+        ssize_t l;
+
+        while (offset < count) {
+                l = write(fd, buf + offset, count - offset);
+                if (l < 0) {
+                        if (errno == EAGAIN || errno == EWOULDBLOCK)
+                                continue;
+                        perror("write");
+                        return -1;
+                }
+                offset += l;
+        }
+
+        return offset;
+}
+
+ssize_t write_zero(int fd, size_t len)
+{
+        size_t i = len;
+
+        while (i--) {
+                const char x = 0;
+                if (do_write(fd, &x, 1) < 0)
+                        return -1;
+        }
+
+        return len;
+}
+
+int main(void)
+{
+        DECLARE_HDR(hdr);
+        char boot_program[MAX_BOOT_PROG_LEN];
+        size_t aligned_hdr_len, alligned_prog_len;
+        ssize_t prog_len;
+
+        prog_len = do_read(0, boot_program, sizeof(boot_program));
+        if (prog_len <= 0)
+                return -1;
+
+        aligned_hdr_len = ROUND_UP(sizeof(hdr));
+        hdr.start_address = htole32(START_BASE + aligned_hdr_len);
+        alligned_prog_len = ROUND_UP(prog_len);
+        hdr.copy_size = htole16(aligned_hdr_len + alligned_prog_len);
+
+        if (do_write(1, &hdr, sizeof(hdr)) < 0)
+                return -1;
+        if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
+                return -1;
+
+        if (do_write(1, boot_program, prog_len) < 0)
+                return 1;
+
+        /* Write out the rest of the kernel */
+        while (1) {
+                prog_len = do_read(0, boot_program, sizeof(boot_program));
+                if (prog_len < 0)
+                        return 1;
+                if (prog_len == 0)
+                        break;
+                if (do_write(1, boot_program, prog_len) < 0)
+                        return 1;
+        }
+
+        return 0;
+}
diff --git a/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
new file mode 100644
index 000000000000..efff8ae2713d
--- /dev/null
+++ b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
@@ -0,0 +1,29 @@
+ROM-able zImage boot from MMC
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
+SuperH Mobile ARM will to boot directly from the MMCIF hardware block.
+
+This is achieved by the mask ROM loading the first portion of the image into
+MERAM and then jumping to it. This portion contains loader code which
+copies the entire image to SDRAM and jumps to it. From there the zImage
+boot code proceeds as normal, uncompressing the image into its final
+location and then jumping to it.
+
+This code has been tested on an AP4EB board using the developer 1A eMMC
+boot mode which is configured using the following jumper settings.
+The board used for testing required a patched mask ROM in order for
+this mode to function.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x|x| |x|
+S4 -+-+-+-+-+-+-+-
+    | | | | |x| |x on
+
+The zImage must be written to the MMC card at sector 1 (512 bytes) in
+vrl4 format. A utility vrl4 is supplied to accomplish this.
+
+e.g.
+        vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1
+
+A dual-voltage MMC 4.0 card was used for testing.
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
index 7edd0e2e6c5b..1ca63b3e5635 100644
--- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt
+++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
@@ -116,7 +116,7 @@ Configuration
     Allows the entire memory to be checksummed before and after the
     suspend to see if there has been any corruption of the contents.
 
-    Note, the time to calculate the CRC is dependant on the CPU speed
+    Note, the time to calculate the CRC is dependent on the CPU speed
     and the size of memory. For an 64Mbyte RAM area on an 200MHz
     S3C2410, this can take approximately 4 seconds to complete.
 
diff --git a/Documentation/arm/Samsung/GPIO.txt b/Documentation/arm/Samsung/GPIO.txt
index 05850c62abeb..513f2562c1a3 100644
--- a/Documentation/arm/Samsung/GPIO.txt
+++ b/Documentation/arm/Samsung/GPIO.txt
@@ -5,7 +5,7 @@ Introduction
 ------------
 
 This outlines the Samsung GPIO implementation and the architecture
-specfic calls provided alongisde the drivers/gpio core.
+specific calls provided alongisde the drivers/gpio core.
 
 
 S3C24XX (Legacy)
diff --git a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
deleted file mode 100644
index dc460f055647..000000000000
--- a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
+++ /dev/null
@@ -1,61 +0,0 @@
-README on the ADC/Touchscreen Controller
-========================================
-
-The LH79524 and LH7A404 include a built-in Analog to Digital
-controller (ADC) that is used to process input from a touchscreen.
-The driver only implements a four-wire touch panel protocol.
-
-The touchscreen driver is maintenance free except for the pen-down or
-touch threshold.  Some resistive displays and board combinations may
-require tuning of this threshold.  The driver exposes some of its
-internal state in the sys filesystem.  If the kernel is configured
-with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a
-directory
-
-  /sys/devices/platform/adc-lh7.0
-
-containing these files.
-
-  -r--r--r--    1 root     root         4096 Jan  1 00:00 samples
-  -rw-r--r--    1 root     root         4096 Jan  1 00:00 threshold
-  -r--r--r--    1 root     root         4096 Jan  1 00:00 threshold_range
-
-The threshold is the current touch threshold.  It defaults to 750 on
-most targets.
-
-  # cat threshold
- 750
-
-The threshold_range contains the range of valid values for the
-threshold.  Values outside of this range will be silently ignored.
-
-  # cat threshold_range
-  0 1023
-
-To change the threshold, write a value to the threshold file.
-
-  # echo 500 > threshold
-  # cat threshold
-  500
-
-The samples file contains the most recently sampled values from the
-ADC.  There are 12.  Below are typical of the last sampled values when
-the pen has been released.  The first two and last two samples are for
-detecting whether or not the pen is down.  The third through sixth are
-X coordinate samples.  The seventh through tenth are Y coordinate
-samples.
-
-  # cat samples
-  1023 1023 0 0 0 0 530 529 530 529 1023 1023
-
-To determine a reasonable threshold, press on the touch panel with an
-appropriate stylus and read the values from samples.
-
-  # cat samples
-  1023 676 92 103 101 102 855 919 922 922 1023 679
-
-The first and eleventh samples are discarded.  Thus, the important
-values are the second and twelfth which are used to determine if the
-pen is down.  When both are below the threshold, the driver registers
-that the pen is down.  When either is above the threshold, it
-registers then pen is up.
diff --git a/Documentation/arm/Sharp-LH/CompactFlash b/Documentation/arm/Sharp-LH/CompactFlash
deleted file mode 100644
index 8616d877df9e..000000000000
--- a/Documentation/arm/Sharp-LH/CompactFlash
+++ /dev/null
@@ -1,32 +0,0 @@
-README on the Compact Flash for Card Engines
-============================================
-
-There are three challenges in supporting the CF interface of the Card
-Engines.  First, every IO operation must be followed with IO to
-another memory region.  Second, the slot is wired for one-to-one
-address mapping *and* it is wired for 16 bit access only.  Second, the
-interrupt request line from the CF device isn't wired.
-
-The IOBARRIER issue is covered in README.IOBARRIER.  This isn't an
-onerous problem.  Enough said here.
-
-The addressing issue is solved in the
-arch/arm/mach-lh7a40x/ide-lpd7a40x.c file with some awkward
-work-arounds.  We implement a special SELECT_DRIVE routine that is
-called before the IDE driver performs its own SELECT_DRIVE.  Our code
-recognizes that the SELECT register cannot be modified without also
-writing a command.  It send an IDLE_IMMEDIATE command on selecting a
-drive.  The function also prevents drive select to the slave drive
-since there can be only one.  The awkward part is that the IDE driver,
-even though we have a select procedure, also attempts to change the
-drive by writing directly the SELECT register.  This attempt is
-explicitly blocked by the OUTB function--not pretty, but effective.
-
-The lack of interrupts is a more serious problem.  Even though the CF
-card is fast when compared to a normal IDE device, we don't know that
-the CF is really flash.  A user could use one of the very small hard
-drives being shipped with a CF interface.  The IDE code includes a
-check for interfaces that lack an IRQ.  In these cases, submitting a
-command to the IDE controller is followed by a call to poll for
-completion.  If the device isn't immediately ready, it schedules a
-timer to poll again later.
diff --git a/Documentation/arm/Sharp-LH/IOBarrier b/Documentation/arm/Sharp-LH/IOBarrier
deleted file mode 100644
index 2e953e228f4d..000000000000
--- a/Documentation/arm/Sharp-LH/IOBarrier
+++ /dev/null
@@ -1,45 +0,0 @@
-README on the IOBARRIER for CardEngine IO
-=========================================
-
-Due to an unfortunate oversight when the Card Engines were designed,
-the signals that control access to some peripherals, most notably the
-SMC91C9111 ethernet controller, are not properly handled.
-
-The symptom is that some back to back IO with the peripheral returns
-unreliable data.  With the SMC chip, you'll see errors about the bank
-register being 'screwed'.
-
-The cause is that the AEN signal to the SMC chip does not transition
-for every memory access.  It is driven through the CPLD from the CS7
-line of the CPU's static memory controller which is optimized to
-eliminate unnecessary transitions.  Yet, the SMC requires a transition
-for every write access.  The Sharp website has more information about
-the effect this power-conserving feature has on peripheral
-interfacing.
-
-The solution is to follow every write access to the SMC chip with an
-access to another memory region that will force the CPU to release the
-chip select line.  It is important to guarantee that this access
-forces the CPU off-chip.  We map a page of SDRAM as if it were an
-uncacheable IO device and read from it after every SMC IO write
-operation.
-
-  SMC IO
-  BARRIER IO
-
-Only this sequence is important.  It does not matter that there is no
-BARRIER IO before the access to the SMC chip because the AEN latch
-only needs occurs after the SMC IO write cycle.  The routines that
-implement this work-around make an additional concession which is to
-disable interrupts during the IO sequence.  Other hardware devices
-(the LogicPD CPLD) have registers in the same physical memory
-region as the SMC chip.  An interrupt might allow an access to one of
-those registers while SMC IO is being performed.
-
-You might be tempted to think that we have to access another device
-attached to the static memory controller, but the empirical evidence
-indicates that this is not so.  Mapping 0x00000000 (flash) and
-0xc0000000 (SDRAM) appear to have the same effect.  Using SDRAM seems
-to be faster.  Choosing to access an undecoded memory region is not
-desirable as there is no way to know how that chip select will be used
-in the future.
diff --git a/Documentation/arm/Sharp-LH/KEV7A400 b/Documentation/arm/Sharp-LH/KEV7A400
deleted file mode 100644
index be32b14cd535..000000000000
--- a/Documentation/arm/Sharp-LH/KEV7A400
+++ /dev/null
@@ -1,8 +0,0 @@
-README on Implementing Linux for Sharp's KEV7a400
-=================================================
-
-This product has been discontinued by Sharp.  For the time being, the
-partially implemented code remains in the kernel.  At some point in
-the future, either the code will be finished or it will be removed
-completely.  This depends primarily on how many of the development
-boards are in the field.
diff --git a/Documentation/arm/Sharp-LH/LCDPanels b/Documentation/arm/Sharp-LH/LCDPanels
deleted file mode 100644
index fb1b21c2f2f4..000000000000
--- a/Documentation/arm/Sharp-LH/LCDPanels
+++ /dev/null
@@ -1,59 +0,0 @@
-README on the LCD Panels
-========================
-
-Configuration options for several LCD panels, available from Logic PD,
-are included in the kernel source.  This README will help you
-understand the configuration data and give you some guidance for
-adding support for other panels if you wish.
-
-
-lcd-panels.h
-------------
-
-There is no way, at present, to detect which panel is attached to the
-system at runtime.  Thus the kernel configuration is static.  The file
-arch/arm/mach-ld7a40x/lcd-panels.h (or similar) defines all of the
-panel specific parameters.
-
-It should be possible for this data to be shared among several device
-families.  The current layout may be insufficiently general, but it is
-amenable to improvement.
-
-
-PIXEL_CLOCK
------------
-
-The panel data sheets will give a range of acceptable pixel clocks.
-The fundamental LCDCLK input frequency is divided down by a PCD
-constant in field '.tim2'.  It may happen that it is impossible to set
-the pixel clock within this range.  A clock which is too slow will
-tend to flicker.  For the highest quality image, set the clock as high
-as possible.
-
-
-MARGINS
--------
-
-These values may be difficult to glean from the panel data sheet.  In
-the case of the Sharp panels, the upper margin is explicitly called
-out as a specific number of lines from the top of the frame.  The
-other values may not matter as much as the panels tend to
-automatically center the image.
-
-
-Sync Sense
-----------
-
-The sense of the hsync and vsync pulses may be called out in the data
-sheet.  On one panel, the sense of these pulses determine the height
-of the visible region on the panel.  Most of the Sharp panels use
-negative sense sync pulses set by the TIM2_IHS and TIM2_IVS bits in
-'.tim2'.
-
-
-Pel Layout
-----------
-
-The Sharp color TFT panels are all configured for 16 bit direct color
-modes.  The amba-lcd driver sets the pel mode to 565 for 5 bits of
-each red and blue and 6 bits of green.
diff --git a/Documentation/arm/Sharp-LH/LPD7A400 b/Documentation/arm/Sharp-LH/LPD7A400
deleted file mode 100644
index 3275b453bfdf..000000000000
--- a/Documentation/arm/Sharp-LH/LPD7A400
+++ /dev/null
@@ -1,15 +0,0 @@
-README on Implementing Linux for the Logic PD LPD7A400-10
-=========================================================
-
-- CPLD memory mapping
-
-  The board designers chose to use high address lines for controlling
-  access to the CPLD registers.  It turns out to be a big waste
-  because we're using an MMU and must map IO space into virtual
-  memory.  The result is that we have to make a mapping for every
-  register.
-
-- Serial Console
-
-  It may be OK not to use the serial console option if the user passes
-  the console device name to the kernel.  This deserves some exploration.
diff --git a/Documentation/arm/Sharp-LH/LPD7A40X b/Documentation/arm/Sharp-LH/LPD7A40X
deleted file mode 100644
index 8c29a27e208f..000000000000
--- a/Documentation/arm/Sharp-LH/LPD7A40X
+++ /dev/null
@@ -1,16 +0,0 @@
-README on Implementing Linux for the Logic PD LPD7A40X-10
-=========================================================
-
-- CPLD memory mapping
-
-  The board designers chose to use high address lines for controlling
-  access to the CPLD registers.  It turns out to be a big waste
-  because we're using an MMU and must map IO space into virtual
-  memory.  The result is that we have to make a mapping for every
-  register.
-
-- Serial Console
-
-  It may be OK not to use the serial console option if the user passes
-  the console device name to the kernel.  This deserves some exploration.
-
diff --git a/Documentation/arm/Sharp-LH/SDRAM b/Documentation/arm/Sharp-LH/SDRAM
deleted file mode 100644
index 93ddc23c2faa..000000000000
--- a/Documentation/arm/Sharp-LH/SDRAM
+++ /dev/null
@@ -1,51 +0,0 @@
-README on the SDRAM Controller for the LH7a40X
-==============================================
-
-The standard configuration for the SDRAM controller generates a sparse
-memory array.  The precise layout is determined by the SDRAM chips.  A
-default kernel configuration assembles the discontiguous memory
-regions into separate memory nodes via the NUMA (Non-Uniform Memory
-Architecture) facilities.  In this default configuration, the kernel
-is forgiving about the precise layout.  As long as it is given an
-accurate picture of available memory by the bootloader the kernel will
-execute correctly.
-
-The SDRC supports a mode where some of the chip select lines are
-swapped in order to make SDRAM look like a synchronous ROM.  Setting
-this bit means that the RAM will present as a contiguous array.  Some
-programmers prefer this to the discontiguous layout.  Be aware that
-may be a penalty for this feature where some some configurations of
-memory are significantly reduced; i.e. 64MiB of RAM appears as only 32
-MiB.
-
-There are a couple of configuration options to override the default
-behavior.  When the SROMLL bit is set and memory appears as a
-contiguous array, there is no reason to support NUMA.
-CONFIG_LH7A40X_CONTIGMEM disables NUMA support.  When physical memory
-is discontiguous, the memory tables are organized such that there are
-two banks per nodes with a small gap between them.  This layout wastes
-some kernel memory for page tables representing non-existent memory.
-CONFIG_LH7A40X_ONE_BANK_PER_NODE optimizes the node tables such that
-there are no gaps.  These options control the low level organization
-of the memory management tables in ways that may prevent the kernel
-from booting or may cause the kernel to allocated excessively large
-page tables.  Be warned.  Only change these options if you know what
-you are doing.  The default behavior is a reasonable compromise that
-will suit all users.
-
---
-
-A typical 32MiB system with the default configuration options will
-find physical memory managed as follows.
-
-   node 0: 0xc0000000 4MiB
-           0xc1000000 4MiB
-   node 1: 0xc4000000 4MiB
-           0xc5000000 4MiB
-   node 2: 0xc8000000 4MiB
-           0xc9000000 4MiB
-   node 3: 0xcc000000 4MiB
-           0xcd000000 4MiB
-
-Setting CONFIG_LH7A40X_ONE_BANK_PER_NODE will put each bank into a
-separate node.
diff --git a/Documentation/arm/Sharp-LH/VectoredInterruptController b/Documentation/arm/Sharp-LH/VectoredInterruptController
deleted file mode 100644
index 23047e9861ee..000000000000
--- a/Documentation/arm/Sharp-LH/VectoredInterruptController
+++ /dev/null
@@ -1,80 +0,0 @@
-README on the Vectored Interrupt Controller of the LH7A404
-==========================================================
-
-The 404 revision of the LH7A40X series comes with two vectored
-interrupts controllers.  While the kernel does use some of the
-features of these devices, it is far from the purpose for which they
-were designed.
-
-When this README was written, the implementation of the VICs was in
-flux.  It is possible that some details, especially with priorities,
-will change.
-
-The VIC support code is inspired by routines written by Sharp.
-
-
-Priority Control
-----------------
-
-The significant reason for using the VIC's vectoring is to control
-interrupt priorities.  There are two tables in
-arch/arm/mach-lh7a40x/irq-lh7a404.c that look something like this.
-
-  static unsigned char irq_pri_vic1[] = { IRQ_GPIO3INTR, };
-  static unsigned char irq_pri_vic2[] = {
-        IRQ_T3UI, IRQ_GPIO7INTR,
-        IRQ_UART1INTR, IRQ_UART2INTR, IRQ_UART3INTR, };
-
-The initialization code reads these tables and inserts a vector
-address and enable for each indicated IRQ.  Vectored interrupts have
-higher priority than non-vectored interrupts.  So, on VIC1,
-IRQ_GPIO3INTR will be served before any other non-FIQ interrupt.  Due
-to the way that the vectoring works, IRQ_T3UI is the next highest
-priority followed by the other vectored interrupts on VIC2.  After
-that, the non-vectored interrupts are scanned in VIC1 then in VIC2.
-
-
-ISR
----
-
-The interrupt service routine macro get_irqnr() in
-arch/arm/kernel/entry-armv.S scans the VICs for the next active
-interrupt.  The vectoring makes this code somewhat larger than it was
-before using vectoring (refer to the LH7A400 implementation).  In the
-case where an interrupt is vectored, the implementation will tend to
-be faster than the non-vectored version.  However, the worst-case path
-is longer.
-
-It is worth noting that at present, there is no need to read
-VIC2_VECTADDR because the register appears to be shared between the
-controllers.  The code is written such that if this changes, it ought
-to still work properly.
-
-
-Vector Addresses
-----------------
-
-The proper use of the vectoring hardware would jump to the ISR
-specified by the vectoring address.  Linux isn't structured to take
-advantage of this feature, though it might be possible to change
-things to support it.
-
-In this implementation, the vectoring address is used to speed the
-search for the active IRQ.  The address is coded such that the lowest
-6 bits store the IRQ number for vectored interrupts.  These numbers
-correspond to the bits in the interrupt status registers.  IRQ zero is
-the lowest interrupt bit in VIC1.  IRQ 32 is the lowest interrupt bit
-in VIC2.  Because zero is a valid IRQ number and because we cannot
-detect whether or not there is a valid vectoring address if that
-address is zero, the eigth bit (0x100) is set for vectored interrupts.
-The address for IRQ 0x18 (VIC2) is 0x118.  Only the ninth bit is set
-for the default handler on VIC1 and only the tenth bit is set for the
-default handler on VIC2.
-
-In other words.
-
-  0x000         - no active interrupt
-  0x1ii         - vectored interrupt 0xii
-  0x2xx         - unvectored interrupt on VIC1 (xx is don't care)
-  0x4xx         - unvectored interrupt on VIC2 (xx is don't care)
-