Add the rt linux 4.1.3-rt3 as base

Import the rt linux 4.1.3-rt3 as OPNFV kvm base.

It's from git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git linux-4.1.y-rt and
the base is:

commit 0917f823c59692d751951bf5ea699a2d1e2f26a2
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Sat Jul 25 12:13:34 2015 +0200

    Prepare v4.1.3-rt3

    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

We lose all the git history this way and it's not good. We
should apply another opnfv project repo in future.

Change-Id: I87543d81c9df70d99c5001fbdf646b202c19f423
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>

1 files changed, 57 insertions, 0 deletions

diff --git a/kernel/drivers/staging/iio/Documentation/overview.txt b/kernel/drivers/staging/iio/Documentation/overview.txt
new file mode 100644
index 000000000..43f92b06b
--- /dev/null
+++ b/kernel/drivers/staging/iio/Documentation/overview.txt
@@ -0,0 +1,57 @@
+Overview of IIO
+
+The Industrial I/O subsystem is intended to provide support for devices
+that in some sense are analog to digital converters (ADCs). As many
+actual devices combine some ADCs with digital to analog converters
+(DACs) that functionality is also supported.
+
+The aim is to fill the gap between the somewhat similar hwmon and
+input subsystems.  Hwmon is very much directed at low sample rate
+sensors used in applications such as fan speed control and temperature
+measurement.  Input is, as its name suggests focused on input
+devices. In some cases there is considerable overlap between these and
+IIO.
+
+A typical device falling into this category would be connected via SPI
+or I2C.
+
+Functionality of IIO
+
+* Basic device registration and handling. This is very similar to
+hwmon with simple polled access to device channels via sysfs.
+
+* Event chrdevs.  These are similar to input in that they provide a
+route to user space for hardware triggered events. Such events include
+threshold detectors, free-fall detectors and more complex action
+detection.  The events themselves are currently very simple with
+merely an event code and a timestamp.  Any data associated with the
+event must be accessed via polling.
+
+Note: A given device may have one or more event channel.  These events are
+turned on or off (if possible) via sysfs interfaces.
+
+* Hardware buffer support.  Some recent sensors have included
+fifo / ring buffers on the sensor chip.  These greatly reduce the load
+on the host CPU by buffering relatively large numbers of data samples
+based on an internal sampling clock. Examples include VTI SCA3000
+series and Analog Device ADXL345 accelerometers.  Each buffer supports
+polling to establish when data is available.
+
+* Trigger and software buffer support. In many data analysis
+applications it it useful to be able to capture data based on some
+external signal (trigger).  These triggers might be a data ready
+signal, a gpio line connected to some external system or an on
+processor periodic interrupt.  A single trigger may initialize data
+capture or reading from a number of sensors.  These triggers are
+used in IIO to fill software buffers acting in a very similar
+fashion to the hardware buffers described above.
+
+Other documentation:
+
+device.txt - elements of a typical device driver.
+
+trigger.txt - elements of a typical trigger driver.
+
+ring.txt - additional elements required for buffer support.
+
+sysfs-bus-iio - abi documentation file.