remarkable-linux/include/linux/iio/iio.h

766 lines
26 KiB
C
Raw Normal View History

/* The industrial I/O core
*
* 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 _INDUSTRIAL_IO_H_
#define _INDUSTRIAL_IO_H_
#include <linux/device.h>
#include <linux/cdev.h>
#include <linux/iio/types.h>
#include <linux/of.h>
/* IIO TODO LIST */
/*
* Provide means of adjusting timer accuracy.
* Currently assumes nano seconds.
*/
enum iio_chan_info_enum {
IIO_CHAN_INFO_RAW = 0,
IIO_CHAN_INFO_PROCESSED,
IIO_CHAN_INFO_SCALE,
IIO_CHAN_INFO_OFFSET,
IIO_CHAN_INFO_CALIBSCALE,
IIO_CHAN_INFO_CALIBBIAS,
IIO_CHAN_INFO_PEAK,
IIO_CHAN_INFO_PEAK_SCALE,
IIO_CHAN_INFO_QUADRATURE_CORRECTION_RAW,
IIO_CHAN_INFO_AVERAGE_RAW,
IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY,
IIO_CHAN_INFO_HIGH_PASS_FILTER_3DB_FREQUENCY,
IIO_CHAN_INFO_SAMP_FREQ,
IIO_CHAN_INFO_FREQUENCY,
IIO_CHAN_INFO_PHASE,
IIO_CHAN_INFO_HARDWAREGAIN,
IIO_CHAN_INFO_HYSTERESIS,
iio: Add INT_TIME (integration time) channel info attribute Integration time is in seconds; it controls the measurement time and influences the gain of a sensor. There are two typical ways that scaling is implemented in a device: 1) input amplifier, 2) reference to the ADC is changed. These both result in the accuracy of the ADC varying (by applying its sampling over a more relevant range). Integration time is a way of dealing with noise inherent in the analog sensor itself. In the case of a light sensor, a mixture of photon noise and device specific noise. Photon noise is dealt with by either improving the efficiency of the sensor, (more photons actually captured) which is not easily varied dynamically, or by integrating the measurement over a longer time period. Note that this can also be thought of as an averaging of a number of individual samples and is infact sometimes implemented this way. Altering integration time implies that the duration of a measurement changes, a fact the device's user may be interested in. Hence it makes sense to distinguish between integration time and simple scale. In some devices both types of control are present and whilst they will have similar effects on the amplitude of the reading, their effect on the noise of the measurements will differ considerably. Used by adjd_s311, tsl4531, tcs3472 The following drivers have similar controls (and could be adapted): * tsl2563 (integration time is controlled via CALIBSCALE among other things) * tsl2583 (has integration_time device_attr, but driver doesn't use channels yet) * tsl2x7x (has integration_time attr) Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Cc: Jon Brenner <jon.brenner@ams.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2013-09-08 09:20:00 -06:00
IIO_CHAN_INFO_INT_TIME,
IIO_CHAN_INFO_ENABLE,
IIO_CHAN_INFO_CALIBHEIGHT,
IIO_CHAN_INFO_CALIBWEIGHT,
IIO_CHAN_INFO_DEBOUNCE_COUNT,
IIO_CHAN_INFO_DEBOUNCE_TIME,
IIO_CHAN_INFO_CALIBEMISSIVITY,
IIO_CHAN_INFO_OVERSAMPLING_RATIO,
};
enum iio_shared_by {
IIO_SEPARATE,
IIO_SHARED_BY_TYPE,
IIO_SHARED_BY_DIR,
IIO_SHARED_BY_ALL
};
enum iio_endian {
IIO_CPU,
IIO_BE,
IIO_LE,
};
staging:iio: Add extended IIO channel info Sometimes devices have per channel properties which either do not map nicely to the current channel info scheme (e.g. string properties) or are very device specific, so it does not make sense to add generic support for them. Currently drivers define these attributes by hand for each channel. Depending on the number of channels this can amount to quite a few lines of boilerplate code. Especially if a driver supports multiple variations of a chip with different numbers of channels. In this case it becomes necessary to have a individual attribute list per chip variation and also a individual iio_info struct. This patch introduces a new scheme for handling such per channel attributes called extended channel info attributes. A extended channel info attribute consist of a name, a flag whether it is shared and read and write callbacks. The read and write callbacks are similar to the {read,write}_raw callbacks and take a IIO device and a channel as their first parameters, but instead of pre-parsed integer values they directly get passed the raw string value, which has been written to the sysfs file. It is possible to assign a list of extended channel info attributes to a channel. For each extended channel info attribute the IIO core will create a new sysfs attribute conforming to the IIO channel naming spec for the channels type, similar as for normal info attributes. Read and write access to this sysfs attribute will be redirected to the extended channel info attributes read and write callbacks. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-21 10:38:12 -07:00
struct iio_chan_spec;
struct iio_dev;
/**
* struct iio_chan_spec_ext_info - Extended channel info attribute
* @name: Info attribute name
* @shared: Whether this attribute is shared between all channels.
* @read: Read callback for this info attribute, may be NULL.
* @write: Write callback for this info attribute, may be NULL.
* @private: Data private to the driver.
staging:iio: Add extended IIO channel info Sometimes devices have per channel properties which either do not map nicely to the current channel info scheme (e.g. string properties) or are very device specific, so it does not make sense to add generic support for them. Currently drivers define these attributes by hand for each channel. Depending on the number of channels this can amount to quite a few lines of boilerplate code. Especially if a driver supports multiple variations of a chip with different numbers of channels. In this case it becomes necessary to have a individual attribute list per chip variation and also a individual iio_info struct. This patch introduces a new scheme for handling such per channel attributes called extended channel info attributes. A extended channel info attribute consist of a name, a flag whether it is shared and read and write callbacks. The read and write callbacks are similar to the {read,write}_raw callbacks and take a IIO device and a channel as their first parameters, but instead of pre-parsed integer values they directly get passed the raw string value, which has been written to the sysfs file. It is possible to assign a list of extended channel info attributes to a channel. For each extended channel info attribute the IIO core will create a new sysfs attribute conforming to the IIO channel naming spec for the channels type, similar as for normal info attributes. Read and write access to this sysfs attribute will be redirected to the extended channel info attributes read and write callbacks. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-21 10:38:12 -07:00
*/
struct iio_chan_spec_ext_info {
const char *name;
enum iio_shared_by shared;
ssize_t (*read)(struct iio_dev *, uintptr_t private,
struct iio_chan_spec const *, char *buf);
ssize_t (*write)(struct iio_dev *, uintptr_t private,
struct iio_chan_spec const *, const char *buf,
size_t len);
uintptr_t private;
staging:iio: Add extended IIO channel info Sometimes devices have per channel properties which either do not map nicely to the current channel info scheme (e.g. string properties) or are very device specific, so it does not make sense to add generic support for them. Currently drivers define these attributes by hand for each channel. Depending on the number of channels this can amount to quite a few lines of boilerplate code. Especially if a driver supports multiple variations of a chip with different numbers of channels. In this case it becomes necessary to have a individual attribute list per chip variation and also a individual iio_info struct. This patch introduces a new scheme for handling such per channel attributes called extended channel info attributes. A extended channel info attribute consist of a name, a flag whether it is shared and read and write callbacks. The read and write callbacks are similar to the {read,write}_raw callbacks and take a IIO device and a channel as their first parameters, but instead of pre-parsed integer values they directly get passed the raw string value, which has been written to the sysfs file. It is possible to assign a list of extended channel info attributes to a channel. For each extended channel info attribute the IIO core will create a new sysfs attribute conforming to the IIO channel naming spec for the channels type, similar as for normal info attributes. Read and write access to this sysfs attribute will be redirected to the extended channel info attributes read and write callbacks. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-21 10:38:12 -07:00
};
/**
* struct iio_enum - Enum channel info attribute
* @items: An array of strings.
* @num_items: Length of the item array.
* @set: Set callback function, may be NULL.
* @get: Get callback function, may be NULL.
*
* The iio_enum struct can be used to implement enum style channel attributes.
* Enum style attributes are those which have a set of strings which map to
* unsigned integer values. The IIO enum helper code takes care of mapping
* between value and string as well as generating a "_available" file which
* contains a list of all available items. The set callback will be called when
* the attribute is updated. The last parameter is the index to the newly
* activated item. The get callback will be used to query the currently active
* item and is supposed to return the index for it.
*/
struct iio_enum {
const char * const *items;
unsigned int num_items;
int (*set)(struct iio_dev *, const struct iio_chan_spec *, unsigned int);
int (*get)(struct iio_dev *, const struct iio_chan_spec *);
};
ssize_t iio_enum_available_read(struct iio_dev *indio_dev,
uintptr_t priv, const struct iio_chan_spec *chan, char *buf);
ssize_t iio_enum_read(struct iio_dev *indio_dev,
uintptr_t priv, const struct iio_chan_spec *chan, char *buf);
ssize_t iio_enum_write(struct iio_dev *indio_dev,
uintptr_t priv, const struct iio_chan_spec *chan, const char *buf,
size_t len);
/**
* IIO_ENUM() - Initialize enum extended channel attribute
* @_name: Attribute name
* @_shared: Whether the attribute is shared between all channels
* @_e: Pointer to an iio_enum struct
*
* This should usually be used together with IIO_ENUM_AVAILABLE()
*/
#define IIO_ENUM(_name, _shared, _e) \
{ \
.name = (_name), \
.shared = (_shared), \
.read = iio_enum_read, \
.write = iio_enum_write, \
.private = (uintptr_t)(_e), \
}
/**
* IIO_ENUM_AVAILABLE() - Initialize enum available extended channel attribute
* @_name: Attribute name ("_available" will be appended to the name)
* @_e: Pointer to an iio_enum struct
*
* Creates a read only attribute which lists all the available enum items in a
* space separated list. This should usually be used together with IIO_ENUM()
*/
#define IIO_ENUM_AVAILABLE(_name, _e) \
{ \
.name = (_name "_available"), \
.shared = IIO_SHARED_BY_TYPE, \
.read = iio_enum_available_read, \
.private = (uintptr_t)(_e), \
}
/**
* struct iio_mount_matrix - iio mounting matrix
* @rotation: 3 dimensional space rotation matrix defining sensor alignment with
* main hardware
*/
struct iio_mount_matrix {
const char *rotation[9];
};
ssize_t iio_show_mount_matrix(struct iio_dev *indio_dev, uintptr_t priv,
const struct iio_chan_spec *chan, char *buf);
int of_iio_read_mount_matrix(const struct device *dev, const char *propname,
struct iio_mount_matrix *matrix);
typedef const struct iio_mount_matrix *
(iio_get_mount_matrix_t)(const struct iio_dev *indio_dev,
const struct iio_chan_spec *chan);
/**
* IIO_MOUNT_MATRIX() - Initialize mount matrix extended channel attribute
* @_shared: Whether the attribute is shared between all channels
* @_get: Pointer to an iio_get_mount_matrix_t accessor
*/
#define IIO_MOUNT_MATRIX(_shared, _get) \
{ \
.name = "mount_matrix", \
.shared = (_shared), \
.read = iio_show_mount_matrix, \
.private = (uintptr_t)(_get), \
}
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
/**
* struct iio_event_spec - specification for a channel event
* @type: Type of the event
* @dir: Direction of the event
* @mask_separate: Bit mask of enum iio_event_info values. Attributes
* set in this mask will be registered per channel.
* @mask_shared_by_type: Bit mask of enum iio_event_info values. Attributes
* set in this mask will be shared by channel type.
* @mask_shared_by_dir: Bit mask of enum iio_event_info values. Attributes
* set in this mask will be shared by channel type and
* direction.
* @mask_shared_by_all: Bit mask of enum iio_event_info values. Attributes
* set in this mask will be shared by all channels.
*/
struct iio_event_spec {
enum iio_event_type type;
enum iio_event_direction dir;
unsigned long mask_separate;
unsigned long mask_shared_by_type;
unsigned long mask_shared_by_dir;
unsigned long mask_shared_by_all;
};
/**
* struct iio_chan_spec - specification of a single channel
* @type: What type of measurement is the channel making.
* @channel: What number do we wish to assign the channel.
* @channel2: If there is a second number for a differential
* channel then this is it. If modified is set then the
* value here specifies the modifier.
* @address: Driver specific identifier.
* @scan_index: Monotonic index to give ordering in scans when read
* from a buffer.
* @scan_type: sign: 's' or 'u' to specify signed or unsigned
* realbits: Number of valid bits of data
* storagebits: Realbits + padding
* shift: Shift right by this before masking out
* realbits.
* repeat: Number of times real/storage bits
* repeats. When the repeat element is
* more than 1, then the type element in
* sysfs will show a repeat value.
* Otherwise, the number of repetitions is
* omitted.
* endianness: little or big endian
* @info_mask_separate: What information is to be exported that is specific to
* this channel.
* @info_mask_separate_available: What availability information is to be
* exported that is specific to this channel.
* @info_mask_shared_by_type: What information is to be exported that is shared
* by all channels of the same type.
* @info_mask_shared_by_type_available: What availability information is to be
* exported that is shared by all channels of the same
* type.
* @info_mask_shared_by_dir: What information is to be exported that is shared
* by all channels of the same direction.
* @info_mask_shared_by_dir_available: What availability information is to be
* exported that is shared by all channels of the same
* direction.
* @info_mask_shared_by_all: What information is to be exported that is shared
* by all channels.
* @info_mask_shared_by_all_available: What availability information is to be
* exported that is shared by all channels.
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
* @event_spec: Array of events which should be registered for this
* channel.
* @num_event_specs: Size of the event_spec array.
staging:iio: Add extended IIO channel info Sometimes devices have per channel properties which either do not map nicely to the current channel info scheme (e.g. string properties) or are very device specific, so it does not make sense to add generic support for them. Currently drivers define these attributes by hand for each channel. Depending on the number of channels this can amount to quite a few lines of boilerplate code. Especially if a driver supports multiple variations of a chip with different numbers of channels. In this case it becomes necessary to have a individual attribute list per chip variation and also a individual iio_info struct. This patch introduces a new scheme for handling such per channel attributes called extended channel info attributes. A extended channel info attribute consist of a name, a flag whether it is shared and read and write callbacks. The read and write callbacks are similar to the {read,write}_raw callbacks and take a IIO device and a channel as their first parameters, but instead of pre-parsed integer values they directly get passed the raw string value, which has been written to the sysfs file. It is possible to assign a list of extended channel info attributes to a channel. For each extended channel info attribute the IIO core will create a new sysfs attribute conforming to the IIO channel naming spec for the channels type, similar as for normal info attributes. Read and write access to this sysfs attribute will be redirected to the extended channel info attributes read and write callbacks. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-21 10:38:12 -07:00
* @ext_info: Array of extended info attributes for this channel.
* The array is NULL terminated, the last element should
* have its name field set to NULL.
* @extend_name: Allows labeling of channel attributes with an
* informative name. Note this has no effect codes etc,
* unlike modifiers.
* @datasheet_name: A name used in in-kernel mapping of channels. It should
* correspond to the first name that the channel is referred
* to by in the datasheet (e.g. IND), or the nearest
* possible compound name (e.g. IND-INC).
* @modified: Does a modifier apply to this channel. What these are
* depends on the channel type. Modifier is set in
* channel2. Examples are IIO_MOD_X for axial sensors about
* the 'x' axis.
* @indexed: Specify the channel has a numerical index. If not,
* the channel index number will be suppressed for sysfs
* attributes but not for event codes.
* @output: Channel is output.
* @differential: Channel is differential.
*/
struct iio_chan_spec {
enum iio_chan_type type;
int channel;
int channel2;
unsigned long address;
int scan_index;
struct {
char sign;
u8 realbits;
u8 storagebits;
u8 shift;
u8 repeat;
enum iio_endian endianness;
} scan_type;
long info_mask_separate;
long info_mask_separate_available;
long info_mask_shared_by_type;
long info_mask_shared_by_type_available;
long info_mask_shared_by_dir;
long info_mask_shared_by_dir_available;
long info_mask_shared_by_all;
long info_mask_shared_by_all_available;
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
const struct iio_event_spec *event_spec;
unsigned int num_event_specs;
staging:iio: Add extended IIO channel info Sometimes devices have per channel properties which either do not map nicely to the current channel info scheme (e.g. string properties) or are very device specific, so it does not make sense to add generic support for them. Currently drivers define these attributes by hand for each channel. Depending on the number of channels this can amount to quite a few lines of boilerplate code. Especially if a driver supports multiple variations of a chip with different numbers of channels. In this case it becomes necessary to have a individual attribute list per chip variation and also a individual iio_info struct. This patch introduces a new scheme for handling such per channel attributes called extended channel info attributes. A extended channel info attribute consist of a name, a flag whether it is shared and read and write callbacks. The read and write callbacks are similar to the {read,write}_raw callbacks and take a IIO device and a channel as their first parameters, but instead of pre-parsed integer values they directly get passed the raw string value, which has been written to the sysfs file. It is possible to assign a list of extended channel info attributes to a channel. For each extended channel info attribute the IIO core will create a new sysfs attribute conforming to the IIO channel naming spec for the channels type, similar as for normal info attributes. Read and write access to this sysfs attribute will be redirected to the extended channel info attributes read and write callbacks. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-21 10:38:12 -07:00
const struct iio_chan_spec_ext_info *ext_info;
const char *extend_name;
const char *datasheet_name;
unsigned modified:1;
unsigned indexed:1;
unsigned output:1;
unsigned differential:1;
};
/**
* iio_channel_has_info() - Checks whether a channel supports a info attribute
* @chan: The channel to be queried
* @type: Type of the info attribute to be checked
*
* Returns true if the channels supports reporting values for the given info
* attribute type, false otherwise.
*/
static inline bool iio_channel_has_info(const struct iio_chan_spec *chan,
enum iio_chan_info_enum type)
{
return (chan->info_mask_separate & BIT(type)) |
(chan->info_mask_shared_by_type & BIT(type)) |
(chan->info_mask_shared_by_dir & BIT(type)) |
(chan->info_mask_shared_by_all & BIT(type));
}
/**
* iio_channel_has_available() - Checks if a channel has an available attribute
* @chan: The channel to be queried
* @type: Type of the available attribute to be checked
*
* Returns true if the channel supports reporting available values for the
* given attribute type, false otherwise.
*/
static inline bool iio_channel_has_available(const struct iio_chan_spec *chan,
enum iio_chan_info_enum type)
{
return (chan->info_mask_separate_available & BIT(type)) |
(chan->info_mask_shared_by_type_available & BIT(type)) |
(chan->info_mask_shared_by_dir_available & BIT(type)) |
(chan->info_mask_shared_by_all_available & BIT(type));
}
#define IIO_CHAN_SOFT_TIMESTAMP(_si) { \
.type = IIO_TIMESTAMP, \
.channel = -1, \
.scan_index = _si, \
.scan_type = { \
.sign = 's', \
.realbits = 64, \
.storagebits = 64, \
}, \
}
s64 iio_get_time_ns(const struct iio_dev *indio_dev);
unsigned int iio_get_time_res(const struct iio_dev *indio_dev);
/* Device operating modes */
#define INDIO_DIRECT_MODE 0x01
#define INDIO_BUFFER_TRIGGERED 0x02
#define INDIO_BUFFER_SOFTWARE 0x04
#define INDIO_BUFFER_HARDWARE 0x08
#define INDIO_EVENT_TRIGGERED 0x10
#define INDIO_ALL_BUFFER_MODES \
(INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE | INDIO_BUFFER_SOFTWARE)
#define INDIO_MAX_RAW_ELEMENTS 4
struct iio_trigger; /* forward declaration */
struct iio_dev;
/**
* struct iio_info - constant information about device
* @driver_module: module structure used to ensure correct
* ownership of chrdevs etc
* @event_attrs: event control attributes
* @attrs: general purpose device attributes
* @read_raw: function to request a value from the device.
* mask specifies which value. Note 0 means a reading of
* the channel in question. Return value will specify the
* type of value returned by the device. val and val2 will
* contain the elements making up the returned value.
* @read_raw_multi: function to return values from the device.
* mask specifies which value. Note 0 means a reading of
* the channel in question. Return value will specify the
* type of value returned by the device. vals pointer
* contain the elements making up the returned value.
* max_len specifies maximum number of elements
* vals pointer can contain. val_len is used to return
* length of valid elements in vals.
* @read_avail: function to return the available values from the device.
* mask specifies which value. Note 0 means the available
* values for the channel in question. Return value
* specifies if a IIO_AVAIL_LIST or a IIO_AVAIL_RANGE is
* returned in vals. The type of the vals are returned in
* type and the number of vals is returned in length. For
* ranges, there are always three vals returned; min, step
* and max. For lists, all possible values are enumerated.
* @write_raw: function to write a value to the device.
* Parameters are the same as for read_raw.
* @write_raw_get_fmt: callback function to query the expected
* format/precision. If not set by the driver, write_raw
* returns IIO_VAL_INT_PLUS_MICRO.
* @read_event_config: find out if the event is enabled.
* @write_event_config: set if the event is enabled.
* @read_event_value: read a configuration value associated with the event.
* @write_event_value: write a configuration value for the event.
* @validate_trigger: function to validate the trigger when the
* current trigger gets changed.
* @update_scan_mode: function to configure device and scan buffer when
* channels have changed
* @debugfs_reg_access: function to read or write register value of device
* @of_xlate: function pointer to obtain channel specifier index.
* When #iio-cells is greater than '0', the driver could
* provide a custom of_xlate function that reads the
* *args* and returns the appropriate index in registered
* IIO channels array.
iio: add support for hardware fifo Some devices have hardware buffers that can store a number of samples for later consumption. Hardware usually provides interrupts to notify the processor when the FIFO is full or when it has reached a certain watermark level. This helps with reducing the number of interrupts to the host processor and thus it helps decreasing the power consumption. This patch enables usage of hardware FIFOs for IIO devices in conjunction with software device buffers. When the hardware FIFO is enabled the samples are stored in the hardware FIFO. The samples are later flushed to the device software buffer when the number of entries in the hardware FIFO reaches the hardware watermark or when a flush operation is triggered by the user when doing a non-blocking read on an empty software device buffer. In order to implement hardware FIFO support the device drivers must implement the following new operations: setting and getting the hardware FIFO watermark level, flushing the hardware FIFO to the software device buffer. The device must also expose information about the hardware FIFO such it's minimum and maximum watermark and if necessary a list of supported watermark values. Finally, the device driver must activate the hardware FIFO when the device buffer is enabled, if the current device settings allows it. The software device buffer watermark is passed by the IIO core to the device driver as a hint for the hardware FIFO watermark. The device driver can adjust this value to allow for hardware limitations (such as capping it to the maximum hardware watermark or adjust it to a value that is supported by the hardware). It can also disable the hardware watermark (and implicitly the hardware FIFO) it this value is below the minimum hardware watermark. Since a driver may support hardware FIFO only when not in triggered buffer mode (due to different semantics of hardware FIFO sampling and triggered sampling) this patch changes the IIO core code to allow falling back to non-triggered buffered mode if no trigger is enabled. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-03-22 12:33:39 -06:00
* @hwfifo_set_watermark: function pointer to set the current hardware
* fifo watermark level; see hwfifo_* entries in
* Documentation/ABI/testing/sysfs-bus-iio for details on
* how the hardware fifo operates
* @hwfifo_flush_to_buffer: function pointer to flush the samples stored
* in the hardware fifo to the device buffer. The driver
* should not flush more than count samples. The function
* must return the number of samples flushed, 0 if no
* samples were flushed or a negative integer if no samples
* were flushed and there was an error.
**/
struct iio_info {
struct module *driver_module;
const struct attribute_group *event_attrs;
const struct attribute_group *attrs;
int (*read_raw)(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val,
int *val2,
long mask);
int (*read_raw_multi)(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int max_len,
int *vals,
int *val_len,
long mask);
int (*read_avail)(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
const int **vals,
int *type,
int *length,
long mask);
int (*write_raw)(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int val,
int val2,
long mask);
int (*write_raw_get_fmt)(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
long mask);
int (*read_event_config)(struct iio_dev *indio_dev,
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
const struct iio_chan_spec *chan,
enum iio_event_type type,
enum iio_event_direction dir);
int (*write_event_config)(struct iio_dev *indio_dev,
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
const struct iio_chan_spec *chan,
enum iio_event_type type,
enum iio_event_direction dir,
int state);
int (*read_event_value)(struct iio_dev *indio_dev,
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
const struct iio_chan_spec *chan,
enum iio_event_type type,
enum iio_event_direction dir,
enum iio_event_info info, int *val, int *val2);
int (*write_event_value)(struct iio_dev *indio_dev,
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
const struct iio_chan_spec *chan,
enum iio_event_type type,
enum iio_event_direction dir,
enum iio_event_info info, int val, int val2);
int (*validate_trigger)(struct iio_dev *indio_dev,
struct iio_trigger *trig);
int (*update_scan_mode)(struct iio_dev *indio_dev,
const unsigned long *scan_mask);
int (*debugfs_reg_access)(struct iio_dev *indio_dev,
unsigned reg, unsigned writeval,
unsigned *readval);
int (*of_xlate)(struct iio_dev *indio_dev,
const struct of_phandle_args *iiospec);
iio: add support for hardware fifo Some devices have hardware buffers that can store a number of samples for later consumption. Hardware usually provides interrupts to notify the processor when the FIFO is full or when it has reached a certain watermark level. This helps with reducing the number of interrupts to the host processor and thus it helps decreasing the power consumption. This patch enables usage of hardware FIFOs for IIO devices in conjunction with software device buffers. When the hardware FIFO is enabled the samples are stored in the hardware FIFO. The samples are later flushed to the device software buffer when the number of entries in the hardware FIFO reaches the hardware watermark or when a flush operation is triggered by the user when doing a non-blocking read on an empty software device buffer. In order to implement hardware FIFO support the device drivers must implement the following new operations: setting and getting the hardware FIFO watermark level, flushing the hardware FIFO to the software device buffer. The device must also expose information about the hardware FIFO such it's minimum and maximum watermark and if necessary a list of supported watermark values. Finally, the device driver must activate the hardware FIFO when the device buffer is enabled, if the current device settings allows it. The software device buffer watermark is passed by the IIO core to the device driver as a hint for the hardware FIFO watermark. The device driver can adjust this value to allow for hardware limitations (such as capping it to the maximum hardware watermark or adjust it to a value that is supported by the hardware). It can also disable the hardware watermark (and implicitly the hardware FIFO) it this value is below the minimum hardware watermark. Since a driver may support hardware FIFO only when not in triggered buffer mode (due to different semantics of hardware FIFO sampling and triggered sampling) this patch changes the IIO core code to allow falling back to non-triggered buffered mode if no trigger is enabled. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-03-22 12:33:39 -06:00
int (*hwfifo_set_watermark)(struct iio_dev *indio_dev, unsigned val);
int (*hwfifo_flush_to_buffer)(struct iio_dev *indio_dev,
unsigned count);
};
/**
* struct iio_buffer_setup_ops - buffer setup related callbacks
* @preenable: [DRIVER] function to run prior to marking buffer enabled
* @postenable: [DRIVER] function to run after marking buffer enabled
* @predisable: [DRIVER] function to run prior to marking buffer
* disabled
* @postdisable: [DRIVER] function to run after marking buffer disabled
* @validate_scan_mask: [DRIVER] function callback to check whether a given
* scan mask is valid for the device.
*/
struct iio_buffer_setup_ops {
int (*preenable)(struct iio_dev *);
int (*postenable)(struct iio_dev *);
int (*predisable)(struct iio_dev *);
int (*postdisable)(struct iio_dev *);
bool (*validate_scan_mask)(struct iio_dev *indio_dev,
const unsigned long *scan_mask);
};
/**
* struct iio_dev - industrial I/O device
* @id: [INTERN] used to identify device internally
* @modes: [DRIVER] operating modes supported by device
* @currentmode: [DRIVER] current operating mode
* @dev: [DRIVER] device structure, should be assigned a parent
* and owner
* @event_interface: [INTERN] event chrdevs associated with interrupt lines
* @buffer: [DRIVER] any buffer present
* @buffer_list: [INTERN] list of all buffers currently attached
* @scan_bytes: [INTERN] num bytes captured to be fed to buffer demux
* @mlock: [DRIVER] lock used to prevent simultaneous device state
* changes
* @available_scan_masks: [DRIVER] optional array of allowed bitmasks
* @masklength: [INTERN] the length of the mask established from
* channels
* @active_scan_mask: [INTERN] union of all scan masks requested by buffers
* @scan_timestamp: [INTERN] set if any buffers have requested timestamp
* @scan_index_timestamp:[INTERN] cache of the index to the timestamp
* @trig: [INTERN] current device trigger (buffer modes)
* @trig_readonly [INTERN] mark the current trigger immutable
* @pollfunc: [DRIVER] function run on trigger being received
* @pollfunc_event: [DRIVER] function run on events trigger being received
* @channels: [DRIVER] channel specification structure table
* @num_channels: [DRIVER] number of channels specified in @channels.
* @channel_attr_list: [INTERN] keep track of automatically created channel
* attributes
* @chan_attr_group: [INTERN] group for all attrs in base directory
* @name: [DRIVER] name of the device.
* @info: [DRIVER] callbacks and constant info from driver
* @clock_id: [INTERN] timestamping clock posix identifier
* @info_exist_lock: [INTERN] lock to prevent use during removal
* @setup_ops: [DRIVER] callbacks to call before and after buffer
* enable/disable
* @chrdev: [INTERN] associated character device
* @groups: [INTERN] attribute groups
* @groupcounter: [INTERN] index of next attribute group
* @flags: [INTERN] file ops related flags including busy flag.
* @debugfs_dentry: [INTERN] device specific debugfs dentry.
* @cached_reg_addr: [INTERN] cached register address for debugfs reads.
*/
struct iio_dev {
int id;
int modes;
int currentmode;
struct device dev;
struct iio_event_interface *event_interface;
struct iio_buffer *buffer;
struct list_head buffer_list;
int scan_bytes;
struct mutex mlock;
const unsigned long *available_scan_masks;
unsigned masklength;
const unsigned long *active_scan_mask;
bool scan_timestamp;
unsigned scan_index_timestamp;
struct iio_trigger *trig;
bool trig_readonly;
struct iio_poll_func *pollfunc;
struct iio_poll_func *pollfunc_event;
struct iio_chan_spec const *channels;
int num_channels;
struct list_head channel_attr_list;
struct attribute_group chan_attr_group;
const char *name;
const struct iio_info *info;
clockid_t clock_id;
struct mutex info_exist_lock;
const struct iio_buffer_setup_ops *setup_ops;
struct cdev chrdev;
#define IIO_MAX_GROUPS 6
const struct attribute_group *groups[IIO_MAX_GROUPS + 1];
int groupcounter;
unsigned long flags;
#if defined(CONFIG_DEBUG_FS)
struct dentry *debugfs_dentry;
unsigned cached_reg_addr;
#endif
};
const struct iio_chan_spec
*iio_find_channel_from_si(struct iio_dev *indio_dev, int si);
int iio_device_register(struct iio_dev *indio_dev);
void iio_device_unregister(struct iio_dev *indio_dev);
int devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev);
void devm_iio_device_unregister(struct device *dev, struct iio_dev *indio_dev);
int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp);
int iio_device_claim_direct_mode(struct iio_dev *indio_dev);
void iio_device_release_direct_mode(struct iio_dev *indio_dev);
extern struct bus_type iio_bus_type;
/**
* iio_device_put() - reference counted deallocation of struct device
* @indio_dev: IIO device structure containing the device
**/
static inline void iio_device_put(struct iio_dev *indio_dev)
{
if (indio_dev)
put_device(&indio_dev->dev);
}
/**
* iio_device_get_clock() - Retrieve current timestamping clock for the device
* @indio_dev: IIO device structure containing the device
*/
static inline clockid_t iio_device_get_clock(const struct iio_dev *indio_dev)
{
return indio_dev->clock_id;
}
/**
* dev_to_iio_dev() - Get IIO device struct from a device struct
* @dev: The device embedded in the IIO device
*
* Note: The device must be a IIO device, otherwise the result is undefined.
*/
static inline struct iio_dev *dev_to_iio_dev(struct device *dev)
{
return container_of(dev, struct iio_dev, dev);
}
/**
* iio_device_get() - increment reference count for the device
* @indio_dev: IIO device structure
*
* Returns: The passed IIO device
**/
static inline struct iio_dev *iio_device_get(struct iio_dev *indio_dev)
{
return indio_dev ? dev_to_iio_dev(get_device(&indio_dev->dev)) : NULL;
}
/**
* iio_device_set_drvdata() - Set device driver data
* @indio_dev: IIO device structure
* @data: Driver specific data
*
* Allows to attach an arbitrary pointer to an IIO device, which can later be
* retrieved by iio_device_get_drvdata().
*/
static inline void iio_device_set_drvdata(struct iio_dev *indio_dev, void *data)
{
dev_set_drvdata(&indio_dev->dev, data);
}
/**
* iio_device_get_drvdata() - Get device driver data
* @indio_dev: IIO device structure
*
* Returns the data previously set with iio_device_set_drvdata()
*/
static inline void *iio_device_get_drvdata(struct iio_dev *indio_dev)
{
return dev_get_drvdata(&indio_dev->dev);
}
/* Can we make this smaller? */
#define IIO_ALIGN L1_CACHE_BYTES
struct iio_dev *iio_device_alloc(int sizeof_priv);
static inline void *iio_priv(const struct iio_dev *indio_dev)
{
return (char *)indio_dev + ALIGN(sizeof(struct iio_dev), IIO_ALIGN);
}
static inline struct iio_dev *iio_priv_to_dev(void *priv)
{
return (struct iio_dev *)((char *)priv -
ALIGN(sizeof(struct iio_dev), IIO_ALIGN));
}
void iio_device_free(struct iio_dev *indio_dev);
int devm_iio_device_match(struct device *dev, void *res, void *data);
struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv);
void devm_iio_device_free(struct device *dev, struct iio_dev *indio_dev);
struct iio_trigger *devm_iio_trigger_alloc(struct device *dev,
const char *fmt, ...);
void devm_iio_trigger_free(struct device *dev, struct iio_trigger *iio_trig);
/**
* iio_buffer_enabled() - helper function to test if the buffer is enabled
* @indio_dev: IIO device structure for device
**/
static inline bool iio_buffer_enabled(struct iio_dev *indio_dev)
{
return indio_dev->currentmode
& (INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE |
INDIO_BUFFER_SOFTWARE);
}
/**
* iio_get_debugfs_dentry() - helper function to get the debugfs_dentry
* @indio_dev: IIO device structure for device
**/
#if defined(CONFIG_DEBUG_FS)
static inline struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
{
return indio_dev->debugfs_dentry;
}
#else
static inline struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
{
return NULL;
}
#endif
ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals);
int iio_str_to_fixpoint(const char *str, int fract_mult, int *integer,
int *fract);
/**
* IIO_DEGREE_TO_RAD() - Convert degree to rad
* @deg: A value in degree
*
* Returns the given value converted from degree to rad
*/
#define IIO_DEGREE_TO_RAD(deg) (((deg) * 314159ULL + 9000000ULL) / 18000000ULL)
/**
* IIO_RAD_TO_DEGREE() - Convert rad to degree
* @rad: A value in rad
*
* Returns the given value converted from rad to degree
*/
#define IIO_RAD_TO_DEGREE(rad) \
(((rad) * 18000000ULL + 314159ULL / 2) / 314159ULL)
/**
* IIO_G_TO_M_S_2() - Convert g to meter / second**2
* @g: A value in g
*
* Returns the given value converted from g to meter / second**2
*/
#define IIO_G_TO_M_S_2(g) ((g) * 980665ULL / 100000ULL)
/**
* IIO_M_S_2_TO_G() - Convert meter / second**2 to g
* @ms2: A value in meter / second**2
*
* Returns the given value converted from meter / second**2 to g
*/
#define IIO_M_S_2_TO_G(ms2) (((ms2) * 100000ULL + 980665ULL / 2) / 980665ULL)
#endif /* _INDUSTRIAL_IO_H_ */