From 9ca8dbcc65cfc63d6f5ef3312a33184e1d726e00 Mon Sep 17 00:00:00 2001 From: Yunhong Jiang Date: Tue, 4 Aug 2015 12:17:53 -0700 Subject: 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 Date: Sat Jul 25 12:13:34 2015 +0200 Prepare v4.1.3-rt3 Signed-off-by: Sebastian Andrzej Siewior 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 --- .../drivers/staging/iio/Documentation/overview.txt | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 kernel/drivers/staging/iio/Documentation/overview.txt (limited to 'kernel/drivers/staging/iio/Documentation/overview.txt') 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. -- cgit 1.2.3-korg