[RFC PATCH 3/3] iio: Move files from drivers/staging/iio/Documentation/ to Documentation/iio/
Roberta Dobrescu
roberta.dobrescu at gmail.com
Sun Feb 1 02:03:23 EET 2015
This patch moves iio documentation files from
drivers/staging/iio/Documentation/ to Documentation/iio/.
Signed-off-by: Roberta Dobrescu <roberta.dobrescu at gmail.com>
---
Documentation/iio/dac/max517 | 41 ++++++++
Documentation/iio/device.txt | 79 +++++++++++++++
Documentation/iio/inkernel.txt | 58 +++++++++++
.../iio/light/sysfs-bus-iio-light-tsl2583 | 6 ++
.../iio/light/sysfs-bus-iio-light-tsl2x7x | 13 +++
Documentation/iio/overview.txt | 57 +++++++++++
Documentation/iio/ring.txt | 47 +++++++++
Documentation/iio/sysfs-bus-iio-ad7192 | 20 ++++
Documentation/iio/sysfs-bus-iio-adc-ad7280a | 21 ++++
Documentation/iio/sysfs-bus-iio-dds | 96 ++++++++++++++++++
.../iio/sysfs-bus-iio-impedance-analyzer-ad5933 | 30 ++++++
Documentation/iio/sysfs-bus-iio-light | 107 +++++++++++++++++++++
Documentation/iio/sysfs-bus-iio-light-tsl2583 | 20 ++++
Documentation/iio/trigger.txt | 35 +++++++
drivers/staging/iio/Documentation/dac/max517 | 41 --------
drivers/staging/iio/Documentation/device.txt | 79 ---------------
drivers/staging/iio/Documentation/inkernel.txt | 58 -----------
.../light/sysfs-bus-iio-light-tsl2583 | 6 --
.../light/sysfs-bus-iio-light-tsl2x7x | 13 ---
drivers/staging/iio/Documentation/overview.txt | 57 -----------
drivers/staging/iio/Documentation/ring.txt | 47 ---------
.../staging/iio/Documentation/sysfs-bus-iio-ad7192 | 20 ----
.../iio/Documentation/sysfs-bus-iio-adc-ad7280a | 21 ----
.../staging/iio/Documentation/sysfs-bus-iio-dds | 96 ------------------
.../sysfs-bus-iio-impedance-analyzer-ad5933 | 30 ------
.../staging/iio/Documentation/sysfs-bus-iio-light | 107 ---------------------
.../iio/Documentation/sysfs-bus-iio-light-tsl2583 | 20 ----
drivers/staging/iio/Documentation/trigger.txt | 35 -------
28 files changed, 630 insertions(+), 630 deletions(-)
create mode 100644 Documentation/iio/dac/max517
create mode 100644 Documentation/iio/device.txt
create mode 100644 Documentation/iio/inkernel.txt
create mode 100644 Documentation/iio/light/sysfs-bus-iio-light-tsl2583
create mode 100644 Documentation/iio/light/sysfs-bus-iio-light-tsl2x7x
create mode 100644 Documentation/iio/overview.txt
create mode 100644 Documentation/iio/ring.txt
create mode 100644 Documentation/iio/sysfs-bus-iio-ad7192
create mode 100644 Documentation/iio/sysfs-bus-iio-adc-ad7280a
create mode 100644 Documentation/iio/sysfs-bus-iio-dds
create mode 100644 Documentation/iio/sysfs-bus-iio-impedance-analyzer-ad5933
create mode 100644 Documentation/iio/sysfs-bus-iio-light
create mode 100644 Documentation/iio/sysfs-bus-iio-light-tsl2583
create mode 100644 Documentation/iio/trigger.txt
delete mode 100644 drivers/staging/iio/Documentation/dac/max517
delete mode 100644 drivers/staging/iio/Documentation/device.txt
delete mode 100644 drivers/staging/iio/Documentation/inkernel.txt
delete mode 100644 drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2583
delete mode 100644 drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2x7x
delete mode 100644 drivers/staging/iio/Documentation/overview.txt
delete mode 100644 drivers/staging/iio/Documentation/ring.txt
delete mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192
delete mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-adc-ad7280a
delete mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-dds
delete mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933
delete mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light
delete mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light-tsl2583
delete mode 100644 drivers/staging/iio/Documentation/trigger.txt
diff --git a/Documentation/iio/dac/max517 b/Documentation/iio/dac/max517
new file mode 100644
index 0000000..e60ec2f
--- /dev/null
+++ b/Documentation/iio/dac/max517
@@ -0,0 +1,41 @@
+Kernel driver max517
+====================
+
+Supported chips:
+ * Maxim MAX517, MAX518, MAX519
+ Prefix: 'max517'
+ Datasheet: Publicly available at the Maxim website
+ http://www.maxim-ic.com/
+
+Author:
+ Roland Stigge <stigge at antcom.de>
+
+Description
+-----------
+
+The Maxim MAX517/518/519 is an 8-bit DAC on the I2C bus. The following table
+shows the different feature sets of the variants MAX517, MAX518 and MAX519:
+
+Feature MAX517 MAX518 MAX519
+--------------------------------------------------------------------------
+One output channel X
+Two output channels X X
+Simultaneous output updates X X
+Supply voltage as reference X
+Separate reference input X
+Reference input for each DAC X
+
+Via the iio sysfs interface, there are three attributes available: out1_raw,
+out2_raw and out12_raw. With out1_raw and out2_raw, the current output values
+(0..255) of the DACs can be written to the device. out12_raw can be used to set
+both output channel values simultaneously.
+
+With MAX517, only out1_raw is available.
+
+Via out1_scale (and where appropriate, out2_scale), the current scaling factor
+in mV can be read.
+
+When the operating system goes to a power down state, the Power Down function
+of the chip is activated, reducing the supply current to 4uA.
+
+On power-up, the device is in 0V-output state.
diff --git a/Documentation/iio/device.txt b/Documentation/iio/device.txt
new file mode 100644
index 0000000..8be32e5
--- /dev/null
+++ b/Documentation/iio/device.txt
@@ -0,0 +1,79 @@
+IIO Device drivers
+
+This is not intended to provide a comprehensive guide to writing an
+IIO device driver. For further information see the drivers within the
+subsystem.
+
+The crucial structure for device drivers in iio is iio_dev.
+
+First allocate one using:
+
+struct iio_dev *indio_dev = iio_device_alloc(sizeof(struct chip_state));
+where chip_state is a structure of local state data for this instance of
+the chip.
+
+That data can be accessed using iio_priv(struct iio_dev *).
+
+Then fill in the following:
+
+- indio_dev->dev.parent
+ Struct device associated with the underlying hardware.
+- indio_dev->name
+ Name of the device being driven - made available as the name
+ attribute in sysfs.
+
+- indio_dev->info
+ pointer to a structure with elements that tend to be fixed for
+ large sets of different parts supported by a given driver.
+ This contains:
+ * info->driver_module:
+ Set to THIS_MODULE. Used to ensure correct ownership
+ of various resources allocate by the core.
+ * info->event_attrs:
+ Attributes used to enable / disable hardware events.
+ * info->attrs:
+ General device attributes. Typically used for the weird
+ and the wonderful bits not covered by the channel specification.
+ * info->read_raw:
+ Raw data reading function. Used for both raw channel access
+ and for associate parameters such as offsets and scales.
+ * info->write_raw:
+ Raw value writing function. Used for writable device values such
+ as DAC values and calibbias.
+ * info->read_event_config:
+ Typically only set if there are some interrupt lines. This
+ is used to read if an on sensor event detector is enabled.
+ * info->write_event_config:
+ Enable / disable an on sensor event detector.
+ * info->read_event_value:
+ Read value associated with on sensor event detectors. Note that
+ the meaning of the returned value is dependent on the event
+ type.
+ * info->write_event_value:
+ Write the value associated with on sensor event detectors. E.g.
+ a threshold above which an interrupt occurs. Note that the
+ meaning of the value to be set is event type dependant.
+
+- indio_dev->modes:
+ Specify whether direct access and / or ring buffer access is supported.
+- indio_dev->buffer:
+ An optional associated buffer.
+- indio_dev->pollfunc:
+ Poll function related elements. This controls what occurs when a trigger
+ to which this device is attached sends an event.
+- indio_dev->channels:
+ Specification of device channels. Most attributes etc. are built
+ from this spec.
+- indio_dev->num_channels:
+ How many channels are there?
+
+Once these are set up, a call to iio_device_register(indio_dev)
+will register the device with the iio core.
+
+Worth noting here is that, if a ring buffer is to be used, it can be
+allocated prior to registering the device with the iio-core, but must
+be registered afterwards (otherwise the whole parentage of devices
+gets confused)
+
+On remove, iio_device_unregister(indio_dev) will remove the device from
+the core, and iio_device_free(indio_dev) will clean up.
diff --git a/Documentation/iio/inkernel.txt b/Documentation/iio/inkernel.txt
new file mode 100644
index 0000000..ab528409
--- /dev/null
+++ b/Documentation/iio/inkernel.txt
@@ -0,0 +1,58 @@
+Industrial I/O Subsystem in kernel consumers.
+
+The IIO subsystem can act as a layer under other elements of the kernel
+providing a means of obtaining ADC type readings or of driving DAC type
+signals. The functionality supported will grow as use cases arise.
+
+Describing the channel mapping (iio/machine.h)
+
+Channel associations are described using:
+
+struct iio_map {
+ const char *adc_channel_label;
+ const char *consumer_dev_name;
+ const char *consumer_channel;
+};
+
+adc_channel_label identifies the channel on the IIO device by being
+matched against the datasheet_name field of the iio_chan_spec.
+
+consumer_dev_name allows identification of the consumer device.
+This are then used to find the channel mapping from the consumer device (see
+below).
+
+Finally consumer_channel is a string identifying the channel to the consumer.
+(Perhaps 'battery_voltage' or similar).
+
+An array of these structures is then passed to the IIO driver.
+
+Supporting in kernel interfaces in the driver (driver.h)
+
+The driver must provide datasheet_name values for its channels and
+must pass the iio_map structures and a pointer to its own iio_dev structure
+ on to the core via a call to iio_map_array_register. On removal,
+iio_map_array_unregister reverses this process.
+
+The result of this is that the IIO core now has all the information needed
+to associate a given channel with the consumer requesting it.
+
+Acting as an IIO consumer (consumer.h)
+
+The consumer first has to obtain an iio_channel structure from the core
+by calling iio_channel_get(). The correct channel is identified by:
+
+* matching dev or dev_name against consumer_dev and consumer_dev_name
+* matching consumer_channel against consumer_channel in the map
+
+There are then a number of functions that can be used to get information
+about this channel such as it's current reading.
+
+e.g.
+iio_read_channel_raw() - get a reading
+iio_get_channel_type() - get the type of channel
+
+There is also provision for retrieving all of the channels associated
+with a given consumer. This is useful for generic drivers such as
+iio_hwmon where the number and naming of channels is not known by the
+consumer driver. To do this, use iio_channel_get_all.
+
diff --git a/Documentation/iio/light/sysfs-bus-iio-light-tsl2583 b/Documentation/iio/light/sysfs-bus-iio-light-tsl2583
new file mode 100644
index 0000000..470f7ad
--- /dev/null
+++ b/Documentation/iio/light/sysfs-bus-iio-light-tsl2583
@@ -0,0 +1,6 @@
+What: /sys/bus/iio/devices/device[n]/in_illuminance0_calibrate
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property causes an internal calibration of the als gain trim
+ value which is later used in calculating illuminance in lux.
diff --git a/Documentation/iio/light/sysfs-bus-iio-light-tsl2x7x b/Documentation/iio/light/sysfs-bus-iio-light-tsl2x7x
new file mode 100644
index 0000000..b2798b2
--- /dev/null
+++ b/Documentation/iio/light/sysfs-bus-iio-light-tsl2x7x
@@ -0,0 +1,13 @@
+What: /sys/bus/iio/devices/device[n]/in_illuminance0_calibrate
+KernelVersion: 3.3-rc1
+Contact: linux-iio at vger.kernel.org
+Description:
+ Causes an internal calibration of the als gain trim
+ value which is later used in calculating illuminance in lux.
+
+What: /sys/bus/iio/devices/device[n]/in_proximity0_calibrate
+KernelVersion: 3.3-rc1
+Contact: linux-iio at vger.kernel.org
+Description:
+ Causes a recalculation and adjustment to the
+ proximity_thresh_rising_value.
diff --git a/Documentation/iio/overview.txt b/Documentation/iio/overview.txt
new file mode 100644
index 0000000..43f92b0
--- /dev/null
+++ b/Documentation/iio/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.
diff --git a/Documentation/iio/ring.txt b/Documentation/iio/ring.txt
new file mode 100644
index 0000000..18718fc
--- /dev/null
+++ b/Documentation/iio/ring.txt
@@ -0,0 +1,47 @@
+Buffer support within IIO
+
+This document is intended as a general overview of the functionality
+a buffer may supply and how it is specified within IIO. For more
+specific information on a given buffer implementation, see the
+comments in the source code. Note that some drivers allow buffer
+implementation to be selected at compile time via Kconfig options.
+
+A given buffer implementation typically embeds a struct
+iio_ring_buffer and it is a pointer to this that is provided to the
+IIO core. Access to the embedding structure is typically done via
+container_of functions.
+
+struct iio_ring_buffer contains a struct iio_ring_setup_ops *setup_ops
+which in turn contains the 4 function pointers
+(preenable, postenable, predisable and postdisable).
+These are used to perform device specific steps on either side
+of the core changing its current mode to indicate that the buffer
+is enabled or disabled (along with enabling triggering etc. as appropriate).
+
+Also in struct iio_ring_buffer is a struct iio_ring_access_funcs.
+The function pointers within here are used to allow the core to handle
+as much buffer functionality as possible. Note almost all of these
+are optional.
+
+store_to
+ If possible, push data to the buffer.
+
+read_last
+ If possible, get the most recent scan from the buffer (without removal).
+ This provides polling like functionality whilst the ring buffering is in
+ use without a separate read from the device.
+
+rip_first_n
+ The primary buffer reading function. Note that it may well not return
+ as much data as requested.
+
+request_update
+ If parameters have changed that require reinitialization or configuration of
+ the buffer this will trigger it.
+
+set_bytes_per_datum
+ Set the number of bytes for a complete scan. (All samples + timestamp)
+
+set_length
+ Set the number of complete scans that may be held by the buffer.
+
diff --git a/Documentation/iio/sysfs-bus-iio-ad7192 b/Documentation/iio/sysfs-bus-iio-ad7192
new file mode 100644
index 0000000..1c35c50
--- /dev/null
+++ b/Documentation/iio/sysfs-bus-iio-ad7192
@@ -0,0 +1,20 @@
+What: /sys/.../iio:deviceX/ac_excitation_en
+KernelVersion: 3.1.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ This attribute, if available, is used to enable the AC
+ excitation mode found on some converters. In ac excitation mode,
+ the polarity of the excitation voltage is reversed on
+ alternate cycles, to eliminate DC errors.
+
+What: /sys/.../iio:deviceX/bridge_switch_en
+KernelVersion: 3.1.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ This attribute, if available, is used to close or open the
+ bridge power down switch found on some converters.
+ In bridge applications, such as strain gauges and load cells,
+ the bridge itself consumes the majority of the current in the
+ system. To minimize the current consumption of the system,
+ the bridge can be disconnected (when it is not being used
+ using the bridge_switch_en attribute.
diff --git a/Documentation/iio/sysfs-bus-iio-adc-ad7280a b/Documentation/iio/sysfs-bus-iio-adc-ad7280a
new file mode 100644
index 0000000..863d385
--- /dev/null
+++ b/Documentation/iio/sysfs-bus-iio-adc-ad7280a
@@ -0,0 +1,21 @@
+What: /sys/bus/iio/devices/deviceX/inY-inZ_balance_switch_en
+KernelVersion: 3.0.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ Writing 1 enables the cell balance output switch corresponding
+ to input Y. Writing 0 disables it. If the inY-inZ_balance_timer
+ is set to a none zero value, the corresponding switch will
+ enable for the programmed amount of time, before it
+ automatically disables.
+
+What: /sys/bus/iio/devices/deviceX/inY-inZ_balance_timer
+KernelVersion: 3.0.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ The inY-inZ_balance_timer file allows the user to program
+ individual times for each cell balance output. The AD7280A
+ allows the user to set the timer to a value from 0 minutes to
+ 36.9 minutes. The resolution of the timer is 71.5 sec.
+ The value written is the on-time in milliseconds. When the
+ timer value is set 0, the timer is disabled. The cell balance
+ outputs are controlled only by inY-inZ_balance_switch_en.
diff --git a/Documentation/iio/sysfs-bus-iio-dds b/Documentation/iio/sysfs-bus-iio-dds
new file mode 100644
index 0000000..ee8c509
--- /dev/null
+++ b/Documentation/iio/sysfs-bus-iio-dds
@@ -0,0 +1,96 @@
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_frequencyY
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Stores frequency into tuning word Y.
+ There will be more than one out_altvoltageX_frequencyY file,
+ which allows for pin controlled FSK Frequency Shift Keying
+ (out_altvoltageX_pincontrol_frequency_en is active) or the user
+ can control the desired active tuning word by writing Y to the
+ out_altvoltageX_frequencysymbol file.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_frequencyY_scale
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Scale to be applied to out_altvoltageX_frequencyY in order to
+ obtain the desired value in Hz. If shared across all frequency
+ registers Y is not present. It is also possible X is not present
+ if shared across all channels.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_frequencysymbol
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Specifies the active output frequency tuning word. The value
+ corresponds to the Y in out_altvoltageX_frequencyY.
+ To exit this mode the user can write
+ out_altvoltageX_pincontrol_frequency_en or
+ out_altvoltageX_out_enable file.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_phaseY
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Stores phase into Y.
+ There will be more than one out_altvoltageX_phaseY file, which
+ allows for pin controlled PSK Phase Shift Keying
+ (out_altvoltageX_pincontrol_phase_en is active) or the user can
+ control the desired phase Y which is added to the phase
+ accumulator output by writing Y to the phase_en file.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_phaseY_scale
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Scale to be applied to out_altvoltageX_phaseY in order to obtain
+ the desired value in rad. If shared across all phase registers
+ Y is not present. It is also possible X is not present if
+ shared across all channels.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_phasesymbol
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Specifies the active phase Y which is added to the phase
+ accumulator output. The value corresponds to the Y in
+ out_altvoltageX_phaseY. To exit this mode the user can write
+ out_altvoltageX_pincontrol_phase_en or disable file.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_pincontrol_en
+What: /sys/bus/iio/devices/.../out_altvoltageX_pincontrol_frequency_en
+What: /sys/bus/iio/devices/.../out_altvoltageX_pincontrol_phase_en
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ out_altvoltageX_pincontrol_en: Both, the active frequency and
+ phase is controlled by the respective phase and frequency
+ control inputs. In case the device in features independent
+ controls, then there are dedicated files
+ (out_altvoltageX_pincontrol_frequency_en,
+ out_altvoltageX_pincontrol_phase_en).
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_out_enable
+What: /sys/bus/iio/devices/.../out_altvoltageX_outY_enable
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ out_altvoltageX_outY_enable controls signal generation on
+ output Y of channel X. Y may be suppressed if all channels are
+ controlled together.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_outY_wavetype
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Specifies the output waveform.
+ (sine, triangle, ramp, square, ...)
+ For a list of available output waveform options read
+ available_output_modes.
+
+What: /sys/bus/iio/devices/.../out_altvoltageX_outY_wavetype_available
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Lists all available output waveform options.
diff --git a/Documentation/iio/sysfs-bus-iio-impedance-analyzer-ad5933 b/Documentation/iio/sysfs-bus-iio-impedance-analyzer-ad5933
new file mode 100644
index 0000000..79c7e88
--- /dev/null
+++ b/Documentation/iio/sysfs-bus-iio-impedance-analyzer-ad5933
@@ -0,0 +1,30 @@
+What: /sys/bus/iio/devices/iio:deviceX/outY_freq_start
+KernelVersion: 3.1.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ Frequency sweep start frequency in Hz.
+
+What: /sys/bus/iio/devices/iio:deviceX/outY_freq_increment
+KernelVersion: 3.1.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ Frequency increment in Hz (step size) between consecutive
+ frequency points along the sweep.
+
+What: /sys/bus/iio/devices/iio:deviceX/outY_freq_points
+KernelVersion: 3.1.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ Number of frequency points (steps) in the frequency sweep.
+ This value, in conjunction with the outY_freq_start and the
+ outY_freq_increment, determines the frequency sweep range
+ for the sweep operation.
+
+What: /sys/bus/iio/devices/iio:deviceX/outY_settling_cycles
+KernelVersion: 3.1.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ Number of output excitation cycles (settling time cycles)
+ that are allowed to pass through the unknown impedance,
+ after each frequency increment, and before the ADC is triggered
+ to perform a conversion sequence of the response signal.
diff --git a/Documentation/iio/sysfs-bus-iio-light b/Documentation/iio/sysfs-bus-iio-light
new file mode 100644
index 0000000..17e5c9c
--- /dev/null
+++ b/Documentation/iio/sysfs-bus-iio-light
@@ -0,0 +1,107 @@
+
+What: /sys/bus/iio/devices/device[n]/range
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Hardware dependent ADC Full Scale Range used for some ambient
+ light sensors in calculating lux.
+
+What: /sys/bus/iio/devices/device[n]/range_available
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Hardware dependent supported vales for ADC Full Scale Range.
+
+What: /sys/bus/iio/devices/device[n]/adc_resolution
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Hardware dependent ADC resolution of the ambient light sensor
+ used in calculating the lux.
+
+What: /sys/bus/iio/devices/device[n]/adc_resolution_available
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Hardware dependent list of possible values supported for the
+ adc_resolution of the given sensor.
+
+What: /sys/bus/iio/devices/device[n]/in_illuminance0[_input|_raw]
+KernelVersion: 2.6.35
+Contact: linux-iio at vger.kernel.org
+Description:
+ This should return the calculated lux from the light sensor. If
+ it comes back in SI units, it should also include _input else it
+ should include _raw to signify it is not in SI units.
+
+What: /sys/.../device[n]/proximity_on_chip_ambient_infrared_suppression
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ Hardware dependent mode for an ALS device to calculate the value
+ in proximity mode. When this is enabled, then the device should
+ use a infrared sensor reading to remove infrared noise from the
+ proximity reading. If this is not enabled, the driver can still
+ do this calculation manually by reading the infrared sensor
+ value and doing the negation in sw.
+
+What: /sys/bus/iio/devices/device[n]/in_proximity[_input|_raw]
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property is supported by proximity sensors and should be
+ used to return the value of a reading by the sensor. If this
+ value is returned in SI units, it should also include _input
+ but if it is not, then it should include _raw.
+
+What: /sys/bus/iio/devices/device[n]/intensity_infrared[_input|_raw]
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property is supported by sensors that have an infrared
+ sensing mode. This value should be the output from a reading
+ and if expressed in SI units, should include _input. If this
+ value is not in SI units, then it should include _raw.
+
+What: /sys/bus/iio/devices/device[n]/in_illuminance0_target
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property gets/sets the last known external
+ lux measurement used in/for calibration.
+
+What: /sys/bus/iio/devices/device[n]/in_illuminance0_integration_time
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property gets/sets the sensors ADC analog integration time.
+
+What: /sys/bus/iio/devices/device[n]/in_illuminance0_lux_table
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property gets/sets the table of coefficients
+ used in calculating illuminance in lux.
+
+What: /sys/bus/iio/devices/device[n]/in_intensity_clear[_input|_raw]
+What: /sys/bus/iio/devices/device[n]/in_intensity_red[_input|_raw]
+What: /sys/bus/iio/devices/device[n]/in_intensity_green[_input|_raw]
+What: /sys/bus/iio/devices/device[n]/in_intensity_blue[_input|_raw]
+KernelVersion: 3.6.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property is supported by sensors that have a RGBC
+ sensing mode. This value should be the output from a reading
+ and if expressed in SI units, should include _input. If this
+ value is not in SI units (irradiance, uW/mm^2), then it should
+ include _raw.
+
+What: /sys/bus/iio/devices/device[n]/in_cct0[_input|_raw]
+KernelVersion: 3.6.0
+Contact: linux-iio at vger.kernel.org
+Description:
+ This should return the correlated color temperature from the
+ light sensor. If it comes back in SI units, it should also
+ include _input else it should include _raw to signify it is not
+ in SI units.
+
diff --git a/Documentation/iio/sysfs-bus-iio-light-tsl2583 b/Documentation/iio/sysfs-bus-iio-light-tsl2583
new file mode 100644
index 0000000..660781d
--- /dev/null
+++ b/Documentation/iio/sysfs-bus-iio-light-tsl2583
@@ -0,0 +1,20 @@
+What: /sys/bus/iio/devices/device[n]/lux_table
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property gets/sets the table of coefficients
+ used in calculating illuminance in lux.
+
+What: /sys/bus/iio/devices/device[n]/illuminance0_calibrate
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property causes an internal calibration of the als gain trim
+ value which is later used in calculating illuminance in lux.
+
+What: /sys/bus/iio/devices/device[n]/illuminance0_input_target
+KernelVersion: 2.6.37
+Contact: linux-iio at vger.kernel.org
+Description:
+ This property is the known externally illuminance (in lux).
+ It is used in the process of calibrating the device accuracy.
diff --git a/Documentation/iio/trigger.txt b/Documentation/iio/trigger.txt
new file mode 100644
index 0000000..7c0e505
--- /dev/null
+++ b/Documentation/iio/trigger.txt
@@ -0,0 +1,35 @@
+IIO trigger drivers.
+
+Many triggers are provided by hardware that will also be registered as
+an IIO device. Whilst this can create device specific complexities
+such triggers are registered with the core in the same way as
+stand-alone triggers.
+
+struct iio_trig *trig = iio_trigger_alloc("<trigger format string>", ...);
+
+allocates a trigger structure. The key elements to then fill in within
+a driver are:
+
+trig->owner
+ Typically set to THIS_MODULE. Used to ensure correct
+ ownership of core allocated resources.
+
+trig->set_trigger_state:
+ Function that enables / disables the underlying source of the trigger.
+
+There is also a
+trig->alloc_list which is useful for drivers that allocate multiple
+triggers to keep track of what they have created.
+
+When these have been set call:
+
+iio_trigger_register(trig);
+
+to register the trigger with the core, making it available to trigger
+consumers.
+
+Trigger Consumers
+
+Currently triggers are only used for the filling of software
+buffers and as such any device supporting INDIO_BUFFER_TRIGGERED has the
+consumer interface automatically created.
diff --git a/drivers/staging/iio/Documentation/dac/max517 b/drivers/staging/iio/Documentation/dac/max517
deleted file mode 100644
index e60ec2f..0000000
--- a/drivers/staging/iio/Documentation/dac/max517
+++ /dev/null
@@ -1,41 +0,0 @@
-Kernel driver max517
-====================
-
-Supported chips:
- * Maxim MAX517, MAX518, MAX519
- Prefix: 'max517'
- Datasheet: Publicly available at the Maxim website
- http://www.maxim-ic.com/
-
-Author:
- Roland Stigge <stigge at antcom.de>
-
-Description
------------
-
-The Maxim MAX517/518/519 is an 8-bit DAC on the I2C bus. The following table
-shows the different feature sets of the variants MAX517, MAX518 and MAX519:
-
-Feature MAX517 MAX518 MAX519
---------------------------------------------------------------------------
-One output channel X
-Two output channels X X
-Simultaneous output updates X X
-Supply voltage as reference X
-Separate reference input X
-Reference input for each DAC X
-
-Via the iio sysfs interface, there are three attributes available: out1_raw,
-out2_raw and out12_raw. With out1_raw and out2_raw, the current output values
-(0..255) of the DACs can be written to the device. out12_raw can be used to set
-both output channel values simultaneously.
-
-With MAX517, only out1_raw is available.
-
-Via out1_scale (and where appropriate, out2_scale), the current scaling factor
-in mV can be read.
-
-When the operating system goes to a power down state, the Power Down function
-of the chip is activated, reducing the supply current to 4uA.
-
-On power-up, the device is in 0V-output state.
diff --git a/drivers/staging/iio/Documentation/device.txt b/drivers/staging/iio/Documentation/device.txt
deleted file mode 100644
index 8be32e5..0000000
--- a/drivers/staging/iio/Documentation/device.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-IIO Device drivers
-
-This is not intended to provide a comprehensive guide to writing an
-IIO device driver. For further information see the drivers within the
-subsystem.
-
-The crucial structure for device drivers in iio is iio_dev.
-
-First allocate one using:
-
-struct iio_dev *indio_dev = iio_device_alloc(sizeof(struct chip_state));
-where chip_state is a structure of local state data for this instance of
-the chip.
-
-That data can be accessed using iio_priv(struct iio_dev *).
-
-Then fill in the following:
-
-- indio_dev->dev.parent
- Struct device associated with the underlying hardware.
-- indio_dev->name
- Name of the device being driven - made available as the name
- attribute in sysfs.
-
-- indio_dev->info
- pointer to a structure with elements that tend to be fixed for
- large sets of different parts supported by a given driver.
- This contains:
- * info->driver_module:
- Set to THIS_MODULE. Used to ensure correct ownership
- of various resources allocate by the core.
- * info->event_attrs:
- Attributes used to enable / disable hardware events.
- * info->attrs:
- General device attributes. Typically used for the weird
- and the wonderful bits not covered by the channel specification.
- * info->read_raw:
- Raw data reading function. Used for both raw channel access
- and for associate parameters such as offsets and scales.
- * info->write_raw:
- Raw value writing function. Used for writable device values such
- as DAC values and calibbias.
- * info->read_event_config:
- Typically only set if there are some interrupt lines. This
- is used to read if an on sensor event detector is enabled.
- * info->write_event_config:
- Enable / disable an on sensor event detector.
- * info->read_event_value:
- Read value associated with on sensor event detectors. Note that
- the meaning of the returned value is dependent on the event
- type.
- * info->write_event_value:
- Write the value associated with on sensor event detectors. E.g.
- a threshold above which an interrupt occurs. Note that the
- meaning of the value to be set is event type dependant.
-
-- indio_dev->modes:
- Specify whether direct access and / or ring buffer access is supported.
-- indio_dev->buffer:
- An optional associated buffer.
-- indio_dev->pollfunc:
- Poll function related elements. This controls what occurs when a trigger
- to which this device is attached sends an event.
-- indio_dev->channels:
- Specification of device channels. Most attributes etc. are built
- from this spec.
-- indio_dev->num_channels:
- How many channels are there?
-
-Once these are set up, a call to iio_device_register(indio_dev)
-will register the device with the iio core.
-
-Worth noting here is that, if a ring buffer is to be used, it can be
-allocated prior to registering the device with the iio-core, but must
-be registered afterwards (otherwise the whole parentage of devices
-gets confused)
-
-On remove, iio_device_unregister(indio_dev) will remove the device from
-the core, and iio_device_free(indio_dev) will clean up.
diff --git a/drivers/staging/iio/Documentation/inkernel.txt b/drivers/staging/iio/Documentation/inkernel.txt
deleted file mode 100644
index ab528409..0000000
--- a/drivers/staging/iio/Documentation/inkernel.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-Industrial I/O Subsystem in kernel consumers.
-
-The IIO subsystem can act as a layer under other elements of the kernel
-providing a means of obtaining ADC type readings or of driving DAC type
-signals. The functionality supported will grow as use cases arise.
-
-Describing the channel mapping (iio/machine.h)
-
-Channel associations are described using:
-
-struct iio_map {
- const char *adc_channel_label;
- const char *consumer_dev_name;
- const char *consumer_channel;
-};
-
-adc_channel_label identifies the channel on the IIO device by being
-matched against the datasheet_name field of the iio_chan_spec.
-
-consumer_dev_name allows identification of the consumer device.
-This are then used to find the channel mapping from the consumer device (see
-below).
-
-Finally consumer_channel is a string identifying the channel to the consumer.
-(Perhaps 'battery_voltage' or similar).
-
-An array of these structures is then passed to the IIO driver.
-
-Supporting in kernel interfaces in the driver (driver.h)
-
-The driver must provide datasheet_name values for its channels and
-must pass the iio_map structures and a pointer to its own iio_dev structure
- on to the core via a call to iio_map_array_register. On removal,
-iio_map_array_unregister reverses this process.
-
-The result of this is that the IIO core now has all the information needed
-to associate a given channel with the consumer requesting it.
-
-Acting as an IIO consumer (consumer.h)
-
-The consumer first has to obtain an iio_channel structure from the core
-by calling iio_channel_get(). The correct channel is identified by:
-
-* matching dev or dev_name against consumer_dev and consumer_dev_name
-* matching consumer_channel against consumer_channel in the map
-
-There are then a number of functions that can be used to get information
-about this channel such as it's current reading.
-
-e.g.
-iio_read_channel_raw() - get a reading
-iio_get_channel_type() - get the type of channel
-
-There is also provision for retrieving all of the channels associated
-with a given consumer. This is useful for generic drivers such as
-iio_hwmon where the number and naming of channels is not known by the
-consumer driver. To do this, use iio_channel_get_all.
-
diff --git a/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2583 b/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2583
deleted file mode 100644
index 470f7ad..0000000
--- a/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2583
+++ /dev/null
@@ -1,6 +0,0 @@
-What: /sys/bus/iio/devices/device[n]/in_illuminance0_calibrate
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property causes an internal calibration of the als gain trim
- value which is later used in calculating illuminance in lux.
diff --git a/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2x7x b/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2x7x
deleted file mode 100644
index b2798b2..0000000
--- a/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2x7x
+++ /dev/null
@@ -1,13 +0,0 @@
-What: /sys/bus/iio/devices/device[n]/in_illuminance0_calibrate
-KernelVersion: 3.3-rc1
-Contact: linux-iio at vger.kernel.org
-Description:
- Causes an internal calibration of the als gain trim
- value which is later used in calculating illuminance in lux.
-
-What: /sys/bus/iio/devices/device[n]/in_proximity0_calibrate
-KernelVersion: 3.3-rc1
-Contact: linux-iio at vger.kernel.org
-Description:
- Causes a recalculation and adjustment to the
- proximity_thresh_rising_value.
diff --git a/drivers/staging/iio/Documentation/overview.txt b/drivers/staging/iio/Documentation/overview.txt
deleted file mode 100644
index 43f92b0..0000000
--- a/drivers/staging/iio/Documentation/overview.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-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.
diff --git a/drivers/staging/iio/Documentation/ring.txt b/drivers/staging/iio/Documentation/ring.txt
deleted file mode 100644
index 18718fc..0000000
--- a/drivers/staging/iio/Documentation/ring.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Buffer support within IIO
-
-This document is intended as a general overview of the functionality
-a buffer may supply and how it is specified within IIO. For more
-specific information on a given buffer implementation, see the
-comments in the source code. Note that some drivers allow buffer
-implementation to be selected at compile time via Kconfig options.
-
-A given buffer implementation typically embeds a struct
-iio_ring_buffer and it is a pointer to this that is provided to the
-IIO core. Access to the embedding structure is typically done via
-container_of functions.
-
-struct iio_ring_buffer contains a struct iio_ring_setup_ops *setup_ops
-which in turn contains the 4 function pointers
-(preenable, postenable, predisable and postdisable).
-These are used to perform device specific steps on either side
-of the core changing its current mode to indicate that the buffer
-is enabled or disabled (along with enabling triggering etc. as appropriate).
-
-Also in struct iio_ring_buffer is a struct iio_ring_access_funcs.
-The function pointers within here are used to allow the core to handle
-as much buffer functionality as possible. Note almost all of these
-are optional.
-
-store_to
- If possible, push data to the buffer.
-
-read_last
- If possible, get the most recent scan from the buffer (without removal).
- This provides polling like functionality whilst the ring buffering is in
- use without a separate read from the device.
-
-rip_first_n
- The primary buffer reading function. Note that it may well not return
- as much data as requested.
-
-request_update
- If parameters have changed that require reinitialization or configuration of
- the buffer this will trigger it.
-
-set_bytes_per_datum
- Set the number of bytes for a complete scan. (All samples + timestamp)
-
-set_length
- Set the number of complete scans that may be held by the buffer.
-
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192 b/drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192
deleted file mode 100644
index 1c35c50..0000000
--- a/drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192
+++ /dev/null
@@ -1,20 +0,0 @@
-What: /sys/.../iio:deviceX/ac_excitation_en
-KernelVersion: 3.1.0
-Contact: linux-iio at vger.kernel.org
-Description:
- This attribute, if available, is used to enable the AC
- excitation mode found on some converters. In ac excitation mode,
- the polarity of the excitation voltage is reversed on
- alternate cycles, to eliminate DC errors.
-
-What: /sys/.../iio:deviceX/bridge_switch_en
-KernelVersion: 3.1.0
-Contact: linux-iio at vger.kernel.org
-Description:
- This attribute, if available, is used to close or open the
- bridge power down switch found on some converters.
- In bridge applications, such as strain gauges and load cells,
- the bridge itself consumes the majority of the current in the
- system. To minimize the current consumption of the system,
- the bridge can be disconnected (when it is not being used
- using the bridge_switch_en attribute.
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-adc-ad7280a b/drivers/staging/iio/Documentation/sysfs-bus-iio-adc-ad7280a
deleted file mode 100644
index 863d385..0000000
--- a/drivers/staging/iio/Documentation/sysfs-bus-iio-adc-ad7280a
+++ /dev/null
@@ -1,21 +0,0 @@
-What: /sys/bus/iio/devices/deviceX/inY-inZ_balance_switch_en
-KernelVersion: 3.0.0
-Contact: linux-iio at vger.kernel.org
-Description:
- Writing 1 enables the cell balance output switch corresponding
- to input Y. Writing 0 disables it. If the inY-inZ_balance_timer
- is set to a none zero value, the corresponding switch will
- enable for the programmed amount of time, before it
- automatically disables.
-
-What: /sys/bus/iio/devices/deviceX/inY-inZ_balance_timer
-KernelVersion: 3.0.0
-Contact: linux-iio at vger.kernel.org
-Description:
- The inY-inZ_balance_timer file allows the user to program
- individual times for each cell balance output. The AD7280A
- allows the user to set the timer to a value from 0 minutes to
- 36.9 minutes. The resolution of the timer is 71.5 sec.
- The value written is the on-time in milliseconds. When the
- timer value is set 0, the timer is disabled. The cell balance
- outputs are controlled only by inY-inZ_balance_switch_en.
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-dds b/drivers/staging/iio/Documentation/sysfs-bus-iio-dds
deleted file mode 100644
index ee8c509..0000000
--- a/drivers/staging/iio/Documentation/sysfs-bus-iio-dds
+++ /dev/null
@@ -1,96 +0,0 @@
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_frequencyY
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Stores frequency into tuning word Y.
- There will be more than one out_altvoltageX_frequencyY file,
- which allows for pin controlled FSK Frequency Shift Keying
- (out_altvoltageX_pincontrol_frequency_en is active) or the user
- can control the desired active tuning word by writing Y to the
- out_altvoltageX_frequencysymbol file.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_frequencyY_scale
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Scale to be applied to out_altvoltageX_frequencyY in order to
- obtain the desired value in Hz. If shared across all frequency
- registers Y is not present. It is also possible X is not present
- if shared across all channels.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_frequencysymbol
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Specifies the active output frequency tuning word. The value
- corresponds to the Y in out_altvoltageX_frequencyY.
- To exit this mode the user can write
- out_altvoltageX_pincontrol_frequency_en or
- out_altvoltageX_out_enable file.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_phaseY
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Stores phase into Y.
- There will be more than one out_altvoltageX_phaseY file, which
- allows for pin controlled PSK Phase Shift Keying
- (out_altvoltageX_pincontrol_phase_en is active) or the user can
- control the desired phase Y which is added to the phase
- accumulator output by writing Y to the phase_en file.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_phaseY_scale
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Scale to be applied to out_altvoltageX_phaseY in order to obtain
- the desired value in rad. If shared across all phase registers
- Y is not present. It is also possible X is not present if
- shared across all channels.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_phasesymbol
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Specifies the active phase Y which is added to the phase
- accumulator output. The value corresponds to the Y in
- out_altvoltageX_phaseY. To exit this mode the user can write
- out_altvoltageX_pincontrol_phase_en or disable file.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_pincontrol_en
-What: /sys/bus/iio/devices/.../out_altvoltageX_pincontrol_frequency_en
-What: /sys/bus/iio/devices/.../out_altvoltageX_pincontrol_phase_en
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- out_altvoltageX_pincontrol_en: Both, the active frequency and
- phase is controlled by the respective phase and frequency
- control inputs. In case the device in features independent
- controls, then there are dedicated files
- (out_altvoltageX_pincontrol_frequency_en,
- out_altvoltageX_pincontrol_phase_en).
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_out_enable
-What: /sys/bus/iio/devices/.../out_altvoltageX_outY_enable
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- out_altvoltageX_outY_enable controls signal generation on
- output Y of channel X. Y may be suppressed if all channels are
- controlled together.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_outY_wavetype
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Specifies the output waveform.
- (sine, triangle, ramp, square, ...)
- For a list of available output waveform options read
- available_output_modes.
-
-What: /sys/bus/iio/devices/.../out_altvoltageX_outY_wavetype_available
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Lists all available output waveform options.
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933 b/drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933
deleted file mode 100644
index 79c7e88..0000000
--- a/drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933
+++ /dev/null
@@ -1,30 +0,0 @@
-What: /sys/bus/iio/devices/iio:deviceX/outY_freq_start
-KernelVersion: 3.1.0
-Contact: linux-iio at vger.kernel.org
-Description:
- Frequency sweep start frequency in Hz.
-
-What: /sys/bus/iio/devices/iio:deviceX/outY_freq_increment
-KernelVersion: 3.1.0
-Contact: linux-iio at vger.kernel.org
-Description:
- Frequency increment in Hz (step size) between consecutive
- frequency points along the sweep.
-
-What: /sys/bus/iio/devices/iio:deviceX/outY_freq_points
-KernelVersion: 3.1.0
-Contact: linux-iio at vger.kernel.org
-Description:
- Number of frequency points (steps) in the frequency sweep.
- This value, in conjunction with the outY_freq_start and the
- outY_freq_increment, determines the frequency sweep range
- for the sweep operation.
-
-What: /sys/bus/iio/devices/iio:deviceX/outY_settling_cycles
-KernelVersion: 3.1.0
-Contact: linux-iio at vger.kernel.org
-Description:
- Number of output excitation cycles (settling time cycles)
- that are allowed to pass through the unknown impedance,
- after each frequency increment, and before the ADC is triggered
- to perform a conversion sequence of the response signal.
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-light b/drivers/staging/iio/Documentation/sysfs-bus-iio-light
deleted file mode 100644
index 17e5c9c..0000000
--- a/drivers/staging/iio/Documentation/sysfs-bus-iio-light
+++ /dev/null
@@ -1,107 +0,0 @@
-
-What: /sys/bus/iio/devices/device[n]/range
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Hardware dependent ADC Full Scale Range used for some ambient
- light sensors in calculating lux.
-
-What: /sys/bus/iio/devices/device[n]/range_available
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Hardware dependent supported vales for ADC Full Scale Range.
-
-What: /sys/bus/iio/devices/device[n]/adc_resolution
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Hardware dependent ADC resolution of the ambient light sensor
- used in calculating the lux.
-
-What: /sys/bus/iio/devices/device[n]/adc_resolution_available
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Hardware dependent list of possible values supported for the
- adc_resolution of the given sensor.
-
-What: /sys/bus/iio/devices/device[n]/in_illuminance0[_input|_raw]
-KernelVersion: 2.6.35
-Contact: linux-iio at vger.kernel.org
-Description:
- This should return the calculated lux from the light sensor. If
- it comes back in SI units, it should also include _input else it
- should include _raw to signify it is not in SI units.
-
-What: /sys/.../device[n]/proximity_on_chip_ambient_infrared_suppression
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- Hardware dependent mode for an ALS device to calculate the value
- in proximity mode. When this is enabled, then the device should
- use a infrared sensor reading to remove infrared noise from the
- proximity reading. If this is not enabled, the driver can still
- do this calculation manually by reading the infrared sensor
- value and doing the negation in sw.
-
-What: /sys/bus/iio/devices/device[n]/in_proximity[_input|_raw]
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property is supported by proximity sensors and should be
- used to return the value of a reading by the sensor. If this
- value is returned in SI units, it should also include _input
- but if it is not, then it should include _raw.
-
-What: /sys/bus/iio/devices/device[n]/intensity_infrared[_input|_raw]
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property is supported by sensors that have an infrared
- sensing mode. This value should be the output from a reading
- and if expressed in SI units, should include _input. If this
- value is not in SI units, then it should include _raw.
-
-What: /sys/bus/iio/devices/device[n]/in_illuminance0_target
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property gets/sets the last known external
- lux measurement used in/for calibration.
-
-What: /sys/bus/iio/devices/device[n]/in_illuminance0_integration_time
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property gets/sets the sensors ADC analog integration time.
-
-What: /sys/bus/iio/devices/device[n]/in_illuminance0_lux_table
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property gets/sets the table of coefficients
- used in calculating illuminance in lux.
-
-What: /sys/bus/iio/devices/device[n]/in_intensity_clear[_input|_raw]
-What: /sys/bus/iio/devices/device[n]/in_intensity_red[_input|_raw]
-What: /sys/bus/iio/devices/device[n]/in_intensity_green[_input|_raw]
-What: /sys/bus/iio/devices/device[n]/in_intensity_blue[_input|_raw]
-KernelVersion: 3.6.0
-Contact: linux-iio at vger.kernel.org
-Description:
- This property is supported by sensors that have a RGBC
- sensing mode. This value should be the output from a reading
- and if expressed in SI units, should include _input. If this
- value is not in SI units (irradiance, uW/mm^2), then it should
- include _raw.
-
-What: /sys/bus/iio/devices/device[n]/in_cct0[_input|_raw]
-KernelVersion: 3.6.0
-Contact: linux-iio at vger.kernel.org
-Description:
- This should return the correlated color temperature from the
- light sensor. If it comes back in SI units, it should also
- include _input else it should include _raw to signify it is not
- in SI units.
-
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-light-tsl2583 b/drivers/staging/iio/Documentation/sysfs-bus-iio-light-tsl2583
deleted file mode 100644
index 660781d..0000000
--- a/drivers/staging/iio/Documentation/sysfs-bus-iio-light-tsl2583
+++ /dev/null
@@ -1,20 +0,0 @@
-What: /sys/bus/iio/devices/device[n]/lux_table
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property gets/sets the table of coefficients
- used in calculating illuminance in lux.
-
-What: /sys/bus/iio/devices/device[n]/illuminance0_calibrate
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property causes an internal calibration of the als gain trim
- value which is later used in calculating illuminance in lux.
-
-What: /sys/bus/iio/devices/device[n]/illuminance0_input_target
-KernelVersion: 2.6.37
-Contact: linux-iio at vger.kernel.org
-Description:
- This property is the known externally illuminance (in lux).
- It is used in the process of calibrating the device accuracy.
diff --git a/drivers/staging/iio/Documentation/trigger.txt b/drivers/staging/iio/Documentation/trigger.txt
deleted file mode 100644
index 7c0e505..0000000
--- a/drivers/staging/iio/Documentation/trigger.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-IIO trigger drivers.
-
-Many triggers are provided by hardware that will also be registered as
-an IIO device. Whilst this can create device specific complexities
-such triggers are registered with the core in the same way as
-stand-alone triggers.
-
-struct iio_trig *trig = iio_trigger_alloc("<trigger format string>", ...);
-
-allocates a trigger structure. The key elements to then fill in within
-a driver are:
-
-trig->owner
- Typically set to THIS_MODULE. Used to ensure correct
- ownership of core allocated resources.
-
-trig->set_trigger_state:
- Function that enables / disables the underlying source of the trigger.
-
-There is also a
-trig->alloc_list which is useful for drivers that allocate multiple
-triggers to keep track of what they have created.
-
-When these have been set call:
-
-iio_trigger_register(trig);
-
-to register the trigger with the core, making it available to trigger
-consumers.
-
-Trigger Consumers
-
-Currently triggers are only used for the filling of software
-buffers and as such any device supporting INDIO_BUFFER_TRIGGERED has the
-consumer interface automatically created.
--
1.9.1
More information about the firefly
mailing list