redonkable/remarkable-linux
redonkable/remarkable-linux
1
0
Fork 0
Code Releases Activity
remarkable-linux/include/linux/iio/types.h

38 lines
873 B
C
Raw Normal View History

staging:iio: header reorganization Issue brought up by Lars-Peter Clausen. This is a varient of what he suggested. io/iio.h for driver stuff (has to include types.h) Sub files for the bits drivers may or may not use iio/sysfs.h iio/buffer.h (contents of current buffer_generic.h) (obviously anything offering events will need events.h as well) iio/types.h for the enums that matter to both iio_chan_type, iio_modifier iio/events.h for the event code stuff IIO_EVENT_CODE and friends. + everything in chrdev.h So this is the stuff that userspace cares about. Also include iio_event_type, iio_event_direction Thus iio drivers include iio.h + as required events.h sysfs.h buffer.h in kernel users (once that interface is merged) will need inkern.h which will pull in types.h Userspace will need just events.h (which pulls in types.h) to get everything they need to know about. Buffer userspace access doesn't currently need any core defines. All information about the data format is passed through sysfs. Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-26 10:41:32 -06:00
/* industrial I/O data types needed both in and out of kernel
*
* Copyright (c) 2008 Jonathan Cameron
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
#ifndef _IIO_TYPES_H_
#define _IIO_TYPES_H_
iio: Export userspace IIO headers After UAPI header file split [1] all user-kernel interfaces were placed under include/uapi/. This patch moves IIO user specific API from: * include/linux/iio/events.h => include/uapi/linux/iio/events.h * include/linux/types.h => include/uapi/linux/types.h Now there is no need for nasty tricks to compile userspace programs (e.g iio_event_monitor). Just installing the kernel headers with make headers_install command does the job. [1] http://lwn.net/Articles/507794/ Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-02-10 09:33:51 -07:00
#include <uapi/linux/iio/types.h>
iio: Extend the event config interface The event configuration interface of the IIO framework has not been getting the same attention as other parts. As a result it has not seen the same improvements as e.g. the channel interface has seen with the introduction of the channel spec struct. Currently all the event config callbacks take a u64 (the so called event code) to pass all the different information about for which event the callback is invoked. The callback function then has to extract the information it is interested in using some macros with rather long names. Most information encoded in the event code comes straight from the iio_chan_spec struct the event was registered for. Since we always have a handle to the channel spec when we call the event callbacks the first step is to add the channel spec as a parameter to the event callbacks. The two remaining things encoded in the event code are the type and direction of the event. Instead of passing them in one parameter, add one parameter for each of them and remove the eventcode from the event callbacks. The patch also adds a new iio_event_info parameter to the {read,write}_event_value callbacks. This makes it possible, similar to the iio_chan_info_enum for channels, to specify additional properties other than just the value for an event. Furthermore the new interface will allow to register shared events. This is e.g. useful if a device allows configuring a threshold event, but the threshold setting is the same for all channels. To implement this the patch adds a new iio_event_spec struct which is similar to the iio_chan_spec struct. It as two field to specify the type and the direction of the event. Furthermore it has a mask field for each one of the different iio_shared_by types. These mask fields holds which kind of attributes should be registered for the event. Creation of the attributes follows the same rules as the for the channel attributes. E.g. for the separate_mask there will be a attribute for each channel with this event, for the shared_by_type there will only be one attribute per channel type. The iio_chan_spec struct gets two new fields, 'event_spec' and 'num_event_specs', which is used to specify which the events for this channel. These two fields are going to replace the channel's event_mask field. For now both the old and the new event config interface coexist, but over the few patches all drivers will be converted from the old to the new interface. Once that is done all code for supporting the old interface will be removed. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-10-07 08:11:00 -06:00
enum iio_event_info {
IIO_EV_INFO_ENABLE,
IIO_EV_INFO_VALUE,
iio: Add a hysteresis event info attribute For some devices it is possible to configure a hysteresis for threshold (or similar) events. This patch adds a new hysteresis event info type which allows for easy creation and read/write handling of the sysfs attribute. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-10-07 08:11:00 -06:00
IIO_EV_INFO_HYSTERESIS,
iio: core : events ABI for specifying period The iio sysfs ABI defines a way to specify period for roc and thresholds. What: /sys/.../events/in_accel_x_thresh_rising_period What: /sys/.../events/in_accel_x_thresh_falling_period what: /sys/.../events/in_accel_x_roc_rising_period What: /sys/.../events/in_accel_x_roc_falling_period But there is no way to add period with the current event info enum. Added IIO_EV_INFO_PERIOD and corresponding string. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-08-07 16:29:00 -06:00
IIO_EV_INFO_PERIOD,
iio: core: add high pass filter attributes Add a high pass filter attribute for measurements (like the existing low pass) Also add both high and low pass attributes for events. Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-05-13 04:26:42 -06:00
IIO_EV_INFO_HIGH_PASS_FILTER_3DB,
IIO_EV_INFO_LOW_PASS_FILTER_3DB,
iio: Extend the event config interface The event configuration interface of the IIO framework has not been getting the same attention as other parts. As a result it has not seen the same improvements as e.g. the channel interface has seen with the introduction of the channel spec struct. Currently all the event config callbacks take a u64 (the so called event code) to pass all the different information about for which event the callback is invoked. The callback function then has to extract the information it is interested in using some macros with rather long names. Most information encoded in the event code comes straight from the iio_chan_spec struct the event was registered for. Since we always have a handle to the channel spec when we call the event callbacks the first step is to add the channel spec as a parameter to the event callbacks. The two remaining things encoded in the event code are the type and direction of the event. Instead of passing them in one parameter, add one parameter for each of them and remove the eventcode from the event callbacks. The patch also adds a new iio_event_info parameter to the {read,write}_event_value callbacks. This makes it possible, similar to the iio_chan_info_enum for channels, to specify additional properties other than just the value for an event. Furthermore the new interface will allow to register shared events. This is e.g. useful if a device allows configuring a threshold event, but the threshold setting is the same for all channels. To implement this the patch adds a new iio_event_spec struct which is similar to the iio_chan_spec struct. It as two field to specify the type and the direction of the event. Furthermore it has a mask field for each one of the different iio_shared_by types. These mask fields holds which kind of attributes should be registered for the event. Creation of the attributes follows the same rules as the for the channel attributes. E.g. for the separate_mask there will be a attribute for each channel with this event, for the shared_by_type there will only be one attribute per channel type. The iio_chan_spec struct gets two new fields, 'event_spec' and 'num_event_specs', which is used to specify which the events for this channel. These two fields are going to replace the channel's event_mask field. For now both the old and the new event config interface coexist, but over the few patches all drivers will be converted from the old to the new interface. Once that is done all code for supporting the old interface will be removed. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-10-07 08:11:00 -06:00
};
staging:iio: move iio data return types into types.h for use by inkern In kernel interfaces need these, so make them available. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-15 12:48:02 -07:00
#define IIO_VAL_INT 1
#define IIO_VAL_INT_PLUS_MICRO 2
#define IIO_VAL_INT_PLUS_NANO 3
iio: core: introduce dB scle: IIO_VAL_INT_PLUS_MICRO_DB Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-11 03:36:52 -06:00
#define IIO_VAL_INT_PLUS_MICRO_DB 4
IIO: core: Introduce read_raw_multi This callback is introduced to overcome some limitations of existing read_raw callback. The functionality of both existing read_raw and read_raw_multi is similar, both are used to request values from the device. The current read_raw callback allows only two return values. The new read_raw_multi allows returning multiple values. Instead of passing just address of val and val2, it passes length and pointer to values. Depending on the type and length of passed buffer, iio client drivers can return multiple values. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2014-04-28 17:51:00 -06:00
#define IIO_VAL_INT_MULTIPLE 5
iio: Introduce a new fractional value type Currently IIO uses a decimal fixed point representations for real type numbers. This patch introduces a new representation for rational type numbers. The number will be expressed by specifying a numerator and denominator. For converting a raw value to a processed value multiply it by the numerator and divide it by the denominator. The reasoning for introducing this new type is that for a lot of devices the scale can be represented easily by a fractional number, but it is not possible to represent it as fixed point number without rounding. E.g. for a simple DAC the scale is often the reference voltage divided by the number of possible values (Usually 2**n_bits - 1). Each driver currently implements the conversion of this fraction to a fixed point number on its own. Also when it comes to the in-kernel interface this allows to directly use the fractional factors to convert a raw value to a processed value. This should on one hand require less instructions and on the other hand increase the precision. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2012-09-14 09:21:00 -06:00
#define IIO_VAL_FRACTIONAL 10
iio: Add a logarithmic fractional value type For ADCs or DACs the denominator for fractional types often is a power of two. In this case we can use a shift operation instead of the rather expensive 64 bit division. This patch adds a new fractional type which expects the denominator to be specified as the log2 of the actual denominator. E.g. for ADCs and DACs this will usually be the number of significant bits. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2012-10-16 10:29:00 -06:00
#define IIO_VAL_FRACTIONAL_LOG2 11
staging:iio: move iio data return types into types.h for use by inkern In kernel interfaces need these, so make them available. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-15 12:48:02 -07:00
iio:core: add a callback to allow drivers to provide _available attributes A large number of attributes can only take a limited range of values. Currently in IIO this is handled by directly registering additional *_available attributes thus providing this information to userspace. It is desirable to provide this information via the core for much the same reason this was done for the actual channel information attributes in the first place. If it isn't there, then it can only really be accessed from userspace. Other in kernel IIO consumers have no access to what valid parameters are. Two forms are currently supported: * list of values in one particular IIO_VAL_* format. e.g. 1.300000 1.500000 1.730000 * range specification with a step size: e.g. [1.000000 0.500000 2.500000] equivalent to 1.000000 1.5000000 2.000000 2.500000 An addition set of masks are used to allow different sharing rules for the *_available attributes generated. This allows for example: in_accel_x_offset in_accel_y_offset in_accel_offset_available. We could have gone with having a specification for each and every info_mask element but that would have meant changing the existing userspace ABI. This approach does not. Signed-off-by: Jonathan Cameron <jic23@kernel.org> [forward ported, added some docs and fixed buffer overflows /peda] Acked-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-11-08 04:58:51 -07:00
enum iio_available_type {
IIO_AVAIL_LIST,
IIO_AVAIL_RANGE,
};
staging:iio: header reorganization Issue brought up by Lars-Peter Clausen. This is a varient of what he suggested. io/iio.h for driver stuff (has to include types.h) Sub files for the bits drivers may or may not use iio/sysfs.h iio/buffer.h (contents of current buffer_generic.h) (obviously anything offering events will need events.h as well) iio/types.h for the enums that matter to both iio_chan_type, iio_modifier iio/events.h for the event code stuff IIO_EVENT_CODE and friends. + everything in chrdev.h So this is the stuff that userspace cares about. Also include iio_event_type, iio_event_direction Thus iio drivers include iio.h + as required events.h sysfs.h buffer.h in kernel users (once that interface is merged) will need inkern.h which will pull in types.h Userspace will need just events.h (which pulls in types.h) to get everything they need to know about. Buffer userspace access doesn't currently need any core defines. All information about the data format is passed through sysfs. Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-10-26 10:41:32 -06:00
#endif /* _IIO_TYPES_H_ */
Copy permalink