From 57f0f512b273f60d52568b8c6b77e17f5636edc0 Mon Sep 17 00:00:00 2001 From: André Fabian Silva Delgado Date: Wed, 5 Aug 2015 17:04:01 -0300 Subject: Initial import --- 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 +++++++ 14 files changed, 630 insertions(+) create mode 100644 drivers/staging/iio/Documentation/dac/max517 create mode 100644 drivers/staging/iio/Documentation/device.txt create mode 100644 drivers/staging/iio/Documentation/inkernel.txt create mode 100644 drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2583 create mode 100644 drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2x7x create mode 100644 drivers/staging/iio/Documentation/overview.txt create mode 100644 drivers/staging/iio/Documentation/ring.txt create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192 create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-adc-ad7280a create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-dds create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-impedance-analyzer-ad5933 create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light-tsl2583 create mode 100644 drivers/staging/iio/Documentation/trigger.txt (limited to 'drivers/staging/iio/Documentation') diff --git a/drivers/staging/iio/Documentation/dac/max517 b/drivers/staging/iio/Documentation/dac/max517 new file mode 100644 index 000000000..e60ec2f91 --- /dev/null +++ b/drivers/staging/iio/Documentation/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 + +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 new file mode 100644 index 000000000..8be32e5a0 --- /dev/null +++ b/drivers/staging/iio/Documentation/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/drivers/staging/iio/Documentation/inkernel.txt b/drivers/staging/iio/Documentation/inkernel.txt new file mode 100644 index 000000000..ab528409b --- /dev/null +++ b/drivers/staging/iio/Documentation/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/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2583 b/drivers/staging/iio/Documentation/light/sysfs-bus-iio-light-tsl2583 new file mode 100644 index 000000000..470f7ad9c --- /dev/null +++ b/drivers/staging/iio/Documentation/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@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 new file mode 100644 index 000000000..b2798b258 --- /dev/null +++ b/drivers/staging/iio/Documentation/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@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@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 new file mode 100644 index 000000000..43f92b06b --- /dev/null +++ b/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. diff --git a/drivers/staging/iio/Documentation/ring.txt b/drivers/staging/iio/Documentation/ring.txt new file mode 100644 index 000000000..18718fcaf --- /dev/null +++ b/drivers/staging/iio/Documentation/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/drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192 b/drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192 new file mode 100644 index 000000000..1c35c507c --- /dev/null +++ b/drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192 @@ -0,0 +1,20 @@ +What: /sys/.../iio:deviceX/ac_excitation_en +KernelVersion: 3.1.0 +Contact: linux-iio@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@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 new file mode 100644 index 000000000..863d38567 --- /dev/null +++ b/drivers/staging/iio/Documentation/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@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@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 new file mode 100644 index 000000000..ee8c509c6 --- /dev/null +++ b/drivers/staging/iio/Documentation/sysfs-bus-iio-dds @@ -0,0 +1,96 @@ + +What: /sys/bus/iio/devices/.../out_altvoltageX_frequencyY +KernelVersion: 2.6.37 +Contact: linux-iio@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@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@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@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@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@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@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@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@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@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 new file mode 100644 index 000000000..79c7e88c6 --- /dev/null +++ b/drivers/staging/iio/Documentation/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@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@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@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@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 new file mode 100644 index 000000000..17e5c9c51 --- /dev/null +++ b/drivers/staging/iio/Documentation/sysfs-bus-iio-light @@ -0,0 +1,107 @@ + +What: /sys/bus/iio/devices/device[n]/range +KernelVersion: 2.6.37 +Contact: linux-iio@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@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@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@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@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@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@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@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@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@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@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@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@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 new file mode 100644 index 000000000..660781df4 --- /dev/null +++ b/drivers/staging/iio/Documentation/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@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@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@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 new file mode 100644 index 000000000..7c0e505e4 --- /dev/null +++ b/drivers/staging/iio/Documentation/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("", ...); + +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. -- cgit v1.2.3-54-g00ecf